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.

Zitat von wdaniels im Beitrag #76

---

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.

---

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?

I haven't tested my friend's tablet yet. On my 7130 I have installed Dell System Detect and Dell Command Update, no Power Manager.

The problem can be formulated as follows: In Windows 10 if the keyboard lid is closed after the tablet was at least once in S3 sleep state, then when the keyboard is opened the cpufreq is locked to 600MHz. In Linux the problem does not exist. It is actually quite a challenge to find out which driver initiates the cpufreq upon keyboard lid open (and doing that only when the tablet was at least once in a sleep state before). I found a Dell 5540 user who reported exactly the same problem here (post by bisebaer). I feel tempted to install an older bios ...

My workaround is to press the button to put the tablet in sleep before closing the keyboard. Note: I have changed the ACPI Lid driver to the MS Volumecontrol driver and disabled that one. The second best workaround is to keep the standard ACPI Lid driver and set Hibernate for the "what to do when the lid is closed" power setting in battery mode. I would also like to find out whether there is a mechanical switch or a (magnetic) sensor to detect lid close and lid open.

Other than that I have no problems whatsoever with this tablet :-)

EDIT1: I first made a SPI backup and then downgraded the bios from A22 to version A11, effectively this only flashes the BIOS and the EC. Test result: the problem does no longer occur !!

EDIT2: I restored the SPI and am back to A22. Test result: the problem does no longer occur !! Now how can that be explained? My guess is the embedded controller bios in the chipset (PCH) was downgraded when I flashed A11. The EC BIOS is not stored in the SPI and A11 includes version X39 of the EC BIOS.

EDIT3: I noticed I wasn't on the latest BIOS which is A23, so I installed it. It only flashed the system BIOS and the EC, so I must have been on the latest ME already. Anyway the test result is that the problem is back! The EC BIOS version of A19 to A23 is X58

EDIT4: I made a full backup of the A23 based SPI and then flashed A11 again, followed by a restore of the A23 SPI. Test result: the problem does no longer occur !! That proves the point that the EC BIOS causes the problem and I am now trying to find out from which EC BIOS version number the problem was introduced

EDIT5: So I worked my way back through the available Dell software updates and found that the problem was introduced with A17 which includes EC BIOS version X56. The latest software update where the problem does not occur is A16 which includes EC BIOS version X53.

@wdaniels: please make a full backup of your SPI, then flash Dell A16. Power cycle your system 1 or 2 times and verify the problem does not occur. Then restore your SPI, power cycle 1 or 2 times and again check whether the problem occurs. On my tablet it doesn't.

I think all this makes the EC BIOS a very interesting reverse engineering target! As can be read here https://en.m.wikipedia.org/wiki/Embedded_controller, the EC is controlling power management, fan control, thermal management and throttling amongst other things. Perhaps it is possible to flash an EC BIOS from another and less restricted computer with similar specs and same chipset.

Just speculating: does Dell intentionally cripple their chipsets with bad EC firmware updates after some point in time ?? :)

Great work! I will try this ASAP, tomorrow I have some time. I am slowed down a bit unfortunately, my Win10 install got corrupted on the tablet.

I see in the changelog of A17 that they "Improved Lid switch function in BIOS post". This probably warrants that EC update. Should we poke Dell about this problem? I am surprised they haven't noticed yet, it is an older update.

Also surprising that it doesn't pose a problem in Linux. I guess both OSes handle ACPI differently.

I have finally installed A16 over A23 and will see what happens now. ME of course didn't get downgraded but the BIOS and the EC firmware did.

Not sure if I want to flash the A23 BIOS via fptw over this, maybe the BIOS and EC firmware versions are linked (you normally can't do this anyway). Also, going through the changelist, there is nothing noteworthy except added support for Win10 Device Guard, something I don't use. All A2x BIOS releases are just there to update ME it seems.

Will let you know if this fixed it, so I can finally use the suspend function again on the tablet :) If it does, I will try and email dell support to see what their take is on this.

EDIT: first results -> not good. It happened again almost straight away after using the cover to sleep the tablet. Will try to reboot it a couple of times and remove/replace the battery. Should I reset BIOS settings too?

Hello

I have exactly the same problem and symptoms as the author of the topic. But I also have another working Venue, same model, same bios. My question is - can (and how) I make 1:1 copy of ME and flash it to corrupted Venue?

Thank you for your response. Unfortunately, at the moment it seems too difficult for me. I'll try to educate on this subject before I make any action.

@Attitude - do you have flash programmer? if yes, attach dump from both systems. If not, does this system have a 2pin jumper labeled FD, FDO, ME, Service etc? If yes, place pins on jumper and then dump entire BIOS via FPT and upload both for me and I will fix for you and tell you how to flash back

I solved the problem by buying a new-used motherboard for $ 20. Unfortunately, the ME was good, the problem was with booting. The Dell logo appeared twice with a long break between each other. I solved the problem thanks to jockyw2001. In attachment file extracted from the last bios. Packed by winrar, because the size exceeds the maximum size of the attachment

7130/7139 vPro System BIOS A27 11 Dec 2018
 

Zitat von jockyw2001 im Beitrag #49

---

Zitat von wdaniels im Beitrag #48

---

Yup that's exactly the issue I have been trying to solve. Normal BIOS down/upgrades didn't solve anything, so hoping that flashing through FPTW will help.

---

Yes, it's fixed :-) All is well now. Fast boot and no more spurious ASF2 entries in the power eventlog.

1
2
3
4
 

fptw64.exe -f section_0_A.23.data -bios
fptw64.exe -greset
 
 

---

I have 3 Dell Venue 11 Pro 7139 tablets that I use for my computer business. I work on computers, networking, and electronics everyday (self-employed) and I have been struggling with the discussed issue. I have the mobile keyboards that I constantly use. All systems are updated. All running 1803-1807 Windows 10 Pro, A27 Bios, and newest drivers.

I have a work around for now but not a beautiful fix. The main work around is near the bottom. As far as I know there is not a real fix yet. It appears that jockyw2001 was getting close, but nobody has verified the fix. I have been working on this issue and researching for over a year now.

I feel compelled to post here because I have a few points that may help, and I want to be tied in if and when a real fix is found. I read this whole forum and I have a few comments and additions to the already large amount of compiled information.

Just to be sure of clarity I will reiterate the issue and a few main points. While using the mobile keyboard the tablet will experience some kind of processor throttling after the tablet is put to sleep by closing it while attached to the keyboard. After opening the tablet when it was put to sleep by the keyboard the processor frequency is stuck at .59Ghz and will only get to 37% possessor utilization. It is found that this issue happens only if put to sleep by the keyboard twice in a row when another event of shut down, restart, power source for at least a few seconds, or a sleep cycle (other than from closing the tablet and keyboard) was not done in between to two sleep cycles. The tablet is close to a paperweight at this time as it is god offal slow. To bring the tablet out of the state it has been found that the system needs a complete system restart, or it needs a power source for a few seconds. After plugging the system into a power source either attached or detached from the keyboard the tablet will remove the processor restriction in just a few seconds and then the power source can be removed, and it is back to normal. It has been found that in any other circumstance when the tablet is put to sleep and pulled out of sleep this issue does not occur. It only occurs when the keyboard tells the tablet to go to sleep. Just to mention a few sleep possibilities the tablet can be put to sleep after a set time of non-use, the tablet can be put to sleep in Windows by clicking the start button and clicking power and then sleep, and the tablet can be put to sleep by hitting the power button when it is programed to put the system to sleep. None of these three sleep situations (attached or detached from the keyboard) cause the processor throttling when returning from sleep.

Some users have mentioned going after the switch or action of the keyboard, so the keyboard does not cause the issue. I have a few observations I would like to share. The screen is shut down and the tablet is put to sleep by a magnetic sensor. There are 2 magnets in the keyboard. Both are towards the user when it is opened in using position. It appears the left magnet actually hits the sensor in the tablet and does the actuating while the right magnet is there the help keep the two devices together and from accidentally opening. With the tablet and keyboard connected when I take a typical magnet and put in the upper left-hand corner of the tablet screen the screen shuts off and the machine goes to sleep. I remove the magnet and it wakes up. It is working okay now as it needs two cycles to show the issue. I put the magnet their again and go through another sleep cycle. After returning from the second the throttling is back. I plug in a power source and it goes away. This tells us the sensor causing the issue is in the upper left-hand corner of the screen (the sensor is not causing the issue but that sensor is activated putting the system in different or corrupt sleep mode which is the issue). I removed the tablet from the keyboard and tested this just on the tablet and without the keyboard. It did the exact same thing. After the second sleep the system was throttled. This tells me that the issue has absolutely nothing to do with the keyboard but for the keyboard magnet puts the system to sleep. There is no angle sensor in the keyboard and there is no other sensor checking the closed operation and if there is it has nothing to do with our problem.

I remembered seeing a few controls in the BIOS that may affect sleep states or processor configurations. They are listed as
1. Performance
a. Intel Speedstep
b. C-State control
c. Intel Turbo Boost
d. HyperThread Control
e. Rapid Start Technology
2. Power Management
a. Block Sleep
3. Virtualization Support
a. All headings

Below is the same list but here I have all my findings as I experiment with the different settings.
4. Performance
a. Intel Speedstep
i. As soon as I disabled this the issue went away. I could not get the issue to return at all. I performed multiple restarts and countless sleep cycles. After I went back in and enabled the function, the issue returned immediately.
b. C-State control
i. Disabling this does not affect the throttling.
c. Intel Turbo Boost
i. Disabling this does affect the throttling some. With the turbo boost disabled there is still the same throttling, but it locks the processor at 0.69Ghz and 43% utilization.
d. HyperThread Control
i. As soon as I disabled this the issue went away. I could not get the issue to return at all. I performed multiple restarts and countless sleep cycles. After I went back in and enabled the function, the issue returned immediately.
e. Rapid Start Technology
i. I tried setting to 00, 01, and 999 and either way the issue is still there.
5. Power Management
a. Block Sleep
i. Disabling this does not affect the throttling.
6. Virtualization Support
a. All headings
i. Disabling this does affect the throttling some. With all of virtualization options disabled the there is still the same throttling, but it locks the processor at 0.26Ghz and 17% utilization.

I am excited to see some response with these settings as they may help someone find a better fix. The old way I was getting around the issue was by setting the power button to put the system to sleep and then punch it a few seconds before closing the lid so the system went to sleep normally without the keyboard sensor and then it would not show the throttling. I forgot many times and had to plug in a power source after opening it up again to get it to work properly.

My current work around is, shutting off the Intel Speed Step. It is working okay for now. I will use it more and see if I get a large performance or battery longevity difference.

Ok, i decided to fix my old brocken mainboard. I dump images from mainboard with working ME and BIOS using commands:

fptw64 -d spi.bin
fptw64 -d fd.bin -desc
fptw64 -d bios.bin -bios
fptw64 -d me.bin -me
fptw64 -d gbe.bin -gbe

All was succesfull.

My question is if i use commands in brocken MB:

fptw64 -f spi.bin
fptw64 -f bios.bin -bios
fptw64 -f me.bin -me
fptw64 -f gbe.bin -gbe
fptw64 -greset

It will fix my ME system? My old brocken mainboard have older bios and ME version, so i decide to flash all. Do i thinking good, or i will brick mainboard? Both mainboard have unlocked bios.