Z3735G update to 0x838 microcode causes tablet to hang at boot
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- linux
- Domain
- operating-systems
Research direction
Start by reproducing the boot hang on the Glavey TM800A550L with the microcode update enabled, comparing BIOS microcode 0x830 with the attempted 0x838 update and the Acer S1002 behavior. Check whether dis_ucode_ldr consistently avoids the failure and document a verified diagnosis or safe resolution, including the impact on EFI NVRAM.
Written by the indexing model from the issue text.
Description
While running Linux on a Glavey TM800A550L tablet I noticed that it hangs at boot, sometimes showing various color patterns on the display, suggesting that the processor is writing over random memory, including the framebuffer.
It took me a while to figure this out, but adding dis_ucode_ldr on the kernel commandline fixes this. This is quite a sever bug, at one point in when I forgot to add dis_ucode_ldr on the kernel commandline the CPU overwrote parts of the memory-mapped SPI flash which contains the EFI nvram variables, including the Setup EFI variable which contains the BIOS settings. After this the tablet would no longer boot at all. I eventually managed to unbrick it without needing an eeprom programmer by using DNX mode which still worked, see the blogpost which I wrote on this.
The BIOS on the troublesome tablet comes with ucode version 0x830 and the attempted update (which breaks things) tries to update it to 0x838. Perhaps there is a problem with the specific jump from 0x830 to 0x838 ?
Note I have an Acer S1002 tablet which also has a Z3735G processor and there the microcode update works fine.
- Dominant language
- No language data
- Stars
- 826
- Forks
- 86
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from intel/Intel-Linux-Processor-Microcode-Data-Files
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
intel/Intel-Linux-Processor-Microcode-Data-Files#112 · 36 comments · 22 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
intel/Intel-Linux-Processor-Microcode-Data-Files#109 · 6 comments · 2 reactions ·
-
Microcode not foundOpen
Difficulty 3/5 1-2 days Newbie friendliness 35/100
intel/Intel-Linux-Processor-Microcode-Data-Files#108 · 4 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
intel/Intel-Linux-Processor-Microcode-Data-Files#107 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 35/100
intel/Intel-Linux-Processor-Microcode-Data-Files#106 · 1 comment · 1 reaction ·
All issues in intel/Intel-Linux-Processor-Microcode-Data-Files
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
yetone/magpie#3737 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
raspberrypi/linux#7718 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
sameerasw/essentials#1579 ·
Maintainers usually reply within 1 day
-
easy enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
lacs-project/sysknife#682 · 1 comment ·
Maintainers usually reply within 2 days
-
C-bug needs-triage O-UEFI T-libs
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day