Closed cyring closed 1 year ago
Unfortunately this laptop is a family member's and is not currently available for testing... I'll dig through some of my untested laptops and see if any are Airmont/Braswell like this one.
The laptop which created the dump is an Asus X540SA, with the memory directly attached to the motherboard.
Unfortunately this laptop is a family member's and is not currently available for testing... I'll dig through some of my untested laptops and see if any are Airmont/Braswell like this one.
The laptop which created the dump is an Asus X540SA, with the memory directly attached to the motherboard.
Will it help if I'm proving a bootable ISO including the Airmont branch ?
I was able to recreate the issue with a Airmont/Cherry Trail CPU, and the new branch seems to be outputting something. Please check for coherency. BIOS does not provide current speeds or timings.
I was able to recreate the issue with a Airmont/Cherry Trail CPU, and the new branch seems to be outputting something. Please check for coherency. BIOS does not provide current speeds or timings.
Thank you for those results.
Good you have this Cherry Trail
platform, according to ark there are things to solve:
and to fix:
@svmlegacy Hello,
Can you please test those registers ?
## MSR_IA32_PLATFORM_ID
rdmsr -ax 0x00000017
## MSR_THERM2_CTL
rdmsr -ax 0x0000019d
## MSR_MISC_PWR_MGMT
rdmsr -ax 0x000001aa
## MSR_IA32_THERM_CONTROL
rdmsr -ax 0x0000019a
## MSR_TURBO_RATIO_LIMIT
rdmsr -ax 0x000001ad
I'm not surprised if the core is hotter, the box is passively cooled and warm to touch, while the Braswell chip was actively cooled.
Burst appears to be working, as I do catch the CPU above 1.44 GHz in /proc/cpuinfo
Also:
## MSR_IA32_PLATFORM_ID
rdmsr -ax 0x00000017
f090041752
f090041752
f090041449
f090041449
## MSR_THERM2_CTL
rdmsr -ax 0x0000019d
62d
62d
62d
62d
## MSR_MISC_PWR_MGMT
rdmsr -ax 0x000001aa
rdmsr: CPU 0 cannot read MSR 0x000001aa
## MSR_IA32_THERM_CONTROL
rdmsr -ax 0x0000019a
0
0
0
0
## MSR_TURBO_RATIO_LIMIT
rdmsr -ax 0x000001ad
0
0
0
0
Burst appears to be working, as I do catch the CPU above 1.44 GHz in /proc/cpuinfo
Thank you, branch is committed 69e370a51f39c168cb390259da119ccccfbd8ad0 to allow those MSR.
Perhaps Burst frequency ratio will show up ?
EDIT Listed among the Turbo Boost
ratios of Processor
window
|- Clock Modulation ODCM <Disable>
|- DutyCycle [ 0.00%]
Clock Modulation is now also permitted. You should be able to apply a DutyCycle
percent with no processor crash.
Please let me know if it is working safely ?
It is supposed to lower frequency based on the selected percent.
Airmont is the common CPUID 06_4C
Stepping 3
is assigned to both Atom x5-Z8300
and Pentium N3700
Fortunately we can manage a brands table in CoreFreq driver to split in two platform codenames: Cherry Trail
and Braswell
Code enhancement should also concern the PCI Host bridge id 8086:2280
which differs only in revision number (rev 22)
vs (rev 21)
according to lspci
.
So far driver has no code to query the revision and I wonder if it's worth the effort to provide the true platform codename in the IMC output, rather than a common codename ?
Just a quick update on this - I'm currently experimenting to get this system stable in Linux. I've been suffering random crashes, especially when the iGPU is loaded. Once it's stable I'll be able to test the duty cycle modulation. I haven't seen it lock up in a tty console, but I can't be certain it is stable. I may have to try alternative distro's to get it, or older kernels.
On platform codename - To me Cherry Trail and Braswell are effectively the same silicon, just with different target markets. I don't think it's worth the effort in splitting the codename without fully understanding if the Host Bridge revisions within each codename are unique. There seems to be some cherry trail chips with rev 20, for example)
Found these frequency and turbo ratios, and voltage VID registers in kernel. Apparently undocumented in SDM.
Can you please rdmsr
these four MSR ?
I seem to be having a stretch of stability after setting a max c-state of 1, similar to Bay Trail. See this: https://bugzilla.kernel.org/show_bug.cgi?id=109051
#define [MSR_ATOM_CORE_RATIOS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_RATIOS) 0x0000066a
# rdmsr -ax 0x0000066a
120602
120602
120602
120602
#define [MSR_ATOM_CORE_VIDS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_VIDS) 0x0000066b
# rdmsr -ax 0x0000066b
442d2d
442d2d
442d2d
442d2d
#define [MSR_ATOM_CORE_TURBO_RATIOS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_TURBO_RATIOS) 0x0000066c
# rdmsr -ax 0x0000066c
14141717
14141717
14141717
14141717
#define [MSR_ATOM_CORE_TURBO_VIDS](https://elixir.bootlin.com/linux/latest/C/ident/MSR_ATOM_CORE_TURBO_VIDS) 0x0000066d
# rdmsr -ax 0x0000066d
49495252
49495252
49495252
49495252
I seem to be having a stretch of stability after setting a max c-state of 1, similar to Bay Trail. See this: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Well done!
In the past I investigated a Silvermont/Bay_Trail
crash, issue happened late after resuming from S3
.
# rdmsr -ax 0x0000066a
120602
--------->
480 MHz (6 x 80 MHz)->
1440 MHz# rdmsr -ax 0x0000066b
442d2d
->
Vcore = 0.4700V
# rdmsr -ax 0x0000066d
49495252
->
Vcore = 0.6550V
# rdmsr -ax 0x0000066c
14141717
->
1840 MHz (23 x 80 MHz)->
1840 MHz->
1600 MHz->
1600 MHzWhat we are getting new are the Turbo Boost frequency ratios.
Are those four MSR_ATOM writable ?
Can you wrmsr
them with same value as read ?
Perhaps check if modified values are taken into account, especially the Turbo ratios.
Everything is now part of last commit 8521699cc8f3d5be002abecefd40f705bb2c600a You should discover the architecture code name and the Turbo Boost ratios. Feel free to refresh your CLI outputs.
With my system all four MCR's are not writable.
Refreshed output: https://gist.github.com/svmlegacy/deb7288b6dbef976a0002a0ed29ae783#file-cherry-trail-develop-2022-11-06
With my system all four MCR's are not writable.
Refreshed output: https://gist.github.com/svmlegacy/deb7288b6dbef976a0002a0ed29ae783#file-cherry-trail-develop-2022-11-06
Thank you. Many things I've to process looking at your output.
May be to arrange temperature, you could go down to C1E
and makes kernel idling with the HLT
instruction.
See Readme to register CoreFreq as CPU-Idle
driver. Next select HALT as the route in [Settings]
, and C1E
as the limit in [Kernel]
With my system all four MCR's are not writable.
OK, Commit 5c5b0a7c41dafcd6323b500b9b32044247d891dc to make them as read-only ratios
@svmlegacy I don't get a C-States Base Address
within the output, can you read this MSR ?
rdmsr -ax 0xE4
EDIT: It may also be a BIOS option.
@svmlegacy Can you please dump some registers ?
About this source code line in function SLM_PTR
, add debugging code as below:
/* Error Correcting Code */
TIMING(mc, cha).ECC = \
RO(Proc)->Uncore.MC[mc].SLM.BIOS_CFG.EFF_ECC_EN
| RO(Proc)->Uncore.MC[mc].SLM.BIOS_CFG.ECC_EN;
/* Debugging Code */
printf( "IMC(%d:%d)\tDRP[%x]\tDTR0[%x]\tBIOS[%x]\n", mc, cha,
RO(Proc)->Uncore.MC[mc].SLM.DRP.value,
RO(Proc)->Uncore.MC[mc].SLM.DTR0.value,
RO(Proc)->Uncore.MC[mc].SLM.BIOS_CFG.value );
and post the traces which should output from daemon corefreqd
Keep this Intel® Atom™ Z8000 Processor Series Datasheet (Volume 2 of 2)
@svmlegacy What you will notice in specs is that IMC registers differ from those of Silvermont/BYT; some bits are shifted of just a few position. Now I don't confirm previous Timings without a reference coming from your BIOS, memtest, or SPD. The Z8000's IMC decoder has to be programmed.
@svmlegacy Hello, I would like to merge current developments into master; but it would be nice to finalize Airmont IMC before. Is your platform still available ?
@cyring
Thanks for your patience... Life was just being life for a bit. Should be able to catch back up this weekend!
@svmlegacy I don't get a
C-States Base Address
within the output, can you read this MSR ?rdmsr -ax 0xE4
EDIT: It may also be a BIOS option.
Result:
# rdmsr -ax 0xE4
20000
20000
20000
20000
@svmlegacy Can you please dump some registers ? About this source code line in function
SLM_PTR
, add debugging code as below:/* Error Correcting Code */ TIMING(mc, cha).ECC = \ RO(Proc)->Uncore.MC[mc].SLM.BIOS_CFG.EFF_ECC_EN | RO(Proc)->Uncore.MC[mc].SLM.BIOS_CFG.ECC_EN; /* Debugging Code */ printf( "IMC(%d:%d)\tDRP[%x]\tDTR0[%x]\tBIOS[%x]\n", mc, cha, RO(Proc)->Uncore.MC[mc].SLM.DRP.value, RO(Proc)->Uncore.MC[mc].SLM.DTR0.value, RO(Proc)->Uncore.MC[mc].SLM.BIOS_CFG.value );
and post the traces which should output from daemon
corefreqd
Result:
# ./corefreqd
CoreFreq Daemon 1.93.0 Copyright (C) 2015-2022 CYRIL INGENIERIE
IMC(0:0) DRP[58091] DTR0[1344c630] BIOS[468f0010]
Keep this Intel® Atom™ Z8000 Processor Series Datasheet (Volume 2 of 2)
@svmlegacy What you will notice in specs is that IMC registers differ from those of Silvermont/BYT; some bits are shifted of just a few position. Now I don't confirm previous Timings without a reference coming from your BIOS, memtest, or SPD. The Z8000's IMC decoder has to be programmed.
Unfortunately the BIOS is very limited and does not provide the information. The memory is soldered directly onto the mainboard, as well. I'll see about getting Memtest running on this machine and posting the results.
@svmlegacy Fyi commit ff64902ede51b63996391edfe9b85060fb6f2380 adds specs of Z8000 IMC registers
On-going IMC developments moved to #395
@svmlegacy Hello,
Refering to the Wiki page,
corefreq-cli -m
does not output the IMC data.EDIT: Branch
develop_Airmont
is an attempt to decodeAirmont
IMC using theSLM/Bay Trail
SoC decoder.Please feel free to test and post the IMC output of this branch.