Issue #121 has been updated by Anastasios Koutian.
Anastasios Koutian wrote in #note-100:
> Have been using this change: https://review.coreboot.org/c/coreboot/+/78609
> since it was merged (May 23) and haven't seen any freezes.
> It's possible that this solves the issue. Can others confirm?
St
Issue #121 has been updated by Nemanja Z.
I also finally updated my T520 i7-3740QM to 24.08-631-gf8d4283e78d2. (from
4.14-2082-gee760b4be8)
No kernel options, C7 working now, no crashes in Debian 12, Windows 10 also
seems fine.
Bug #121: T520: Hangs in
Issue #121 has been updated by Ján Mlynek.
I updated to main a week ago and after more than 100 hours of uptime, I didn't
experience any hangs so far. This amount of time wasn't possible to achieve
before. I will report again in a few weeks if no hangs occur but it looks
promising.
T420, i7-3
Issue #121 has been updated by Anastasios Koutian.
Have been using this change: https://review.coreboot.org/c/coreboot/+/78609
since it was merged (May 23) and haven't seen any freezes.
It's possible that this solves the issue. Can others confirm?
Bug #1
Issue #121 has been updated by Patrick Rudolph.
> I tried booting with kernel command line parameter idle=nomwait.
That should make the OS use the `hlt` instruction instead of `mwait`, which is
similar to package C1-state.
When using `powertop` or similar tools it should show how much time it s
Issue #121 has been updated by Anastasios Koutian.
Alex Gravitos wrote in #note-97:
> Anastasios Koutian wrote in #note-96:
> > I tried booting with kernel command line parameter idle=nomwait.
> > There were no freezes for 1 week, 5 days and 16 hours, which was not
> > possible previously.
> >
Issue #121 has been updated by Alex Gravitos.
Anastasios Koutian wrote in #note-96:
> I tried booting with kernel command line parameter idle=nomwait.
> There were no freezes for 1 week, 5 days and 16 hours, which was not possible
> previously.
> After this, I powered down and removed the param
Issue #121 has been updated by Anastasios Koutian.
I tried booting with kernel command line parameter idle=nomwait.
There were no freezes for 1 week, 5 days and 16 hours, which was not possible
previously.
After this, I powered down and removed the parameter to see what happens. The
system fro
Issue #121 has been updated by Anastasios Koutian.
The freezes have been quite random for me, sometimes happening within minutes
of booting, sometimes hours, and sometimes days.
It is possible that there are two separate issues that have the same symptom.
You mentioned that using mrc.bin seems t
Issue #121 has been updated by Patrick Rudolph.
My X220 is stable for more than 48h, which wasn't possible before as it would
crash within a couple of hours.
Since the issue doesn't appear any more I must assume it's fixed on my device.
There might be other settings causing a similar problem, ho
Issue #121 has been updated by Anastasios Koutian.
Anastasios Koutian wrote in #note-90:
> Patrick Rudolph wrote in #note-89:
> > I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2
> > and PSI3 values to 0 in PowerManagment2.efi.
> > The X230 vendor BIOS does not hard-co
Issue #121 has been updated by Patrick Rudolph.
Jun Muta wrote in #note-91:
> Patrick Rudolph wrote in #note-89:
> > I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2
> > and PSI3 values to 0 in PowerManagment2.efi.
> > The X230 vendor BIOS does not hard-code those valu
Issue #121 has been updated by Jun Muta.
Patrick Rudolph wrote in #note-89:
> I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2
> and PSI3 values to 0 in PowerManagment2.efi.
> The X230 vendor BIOS does not hard-code those values in PowerManagment2.efi.
> Thus this is l
Issue #121 has been updated by Anastasios Koutian.
Patrick Rudolph wrote in #note-89:
> I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2
> and PSI3 values to 0 in PowerManagment2.efi.
> The X230 vendor BIOS does not hard-code those values in PowerManagment2.efi.
> Thus
Issue #121 has been updated by Patrick Rudolph.
I checked the vendor BIOS for (X220, T420 and T420s) and it hard-codes PSI2 and
PSI3 values to 0 in PowerManagment2.efi.
The X230 vendor BIOS does not hard-code those values in PowerManagment2.efi.
Thus this is likely a bug in the voltage regulator
Issue #121 has been updated by Patrick Rudolph.
I made good progress with https://review.coreboot.org/c/coreboot/+/81597
It allows to configure the VR12-compatible regulator adjusting the CPU core
voltage.
Especially the PSI state are from interest, since those are using in Package C3
or deeper
Issue #121 has been updated by Patrick Rudolph.
I compared the vendor ACPI code for T520 and T530:
- The T520 is missing _CST entries, thus the C-states are reported in FADT. I
couldn't find a firmware dump that has a FADT.
- The T530 has _CST, but the latencies are higher: For C3 148usec, vs 63
Issue #121 has been updated by Patrick Rudolph.
Does limiting the max C-state in MSR MSR_PKG_CST_CONFIG_CONTROL also work
around the issue?
What setting is being used on vendor firmware for MSR
MSR_PKG_CST_CONFIG_CONTROL?
Currently the code doesn't check if the processor supports C6/C3 sleep s
Issue #121 has been updated by Anastasios Koutian.
File defconfig added
The issue is resolved for me after doing the following:
a) Change motherboards from FRU 04W2049 (dGPU + iGPU) to FRU 04W2045 (iGPU).
b) Update coreboot to 4.21 with EDK II (defconfig is attached).
System has been stable for
Issue #121 has been updated by Evgeny Zinoviev.
On my x230 with gentoo, with recent kernel the situation has worsened
significally. If on 5.x kernels it worked somewhat stable (I had crashes maybe
once in a month or so and maybe it wasn't even coreboot related), now I after
upgrade to 6.1.12-g
Issue #121 has been updated by Anastasios Koutian.
File defconfig added
Andrey A. wrote in #note-70:
> T420 and IVB cpu here again.
> After 9 months with intel_idle.max_cstate=4 (and last kernel and coreboot) I
> get a full stable system without a freeze.
I have a similar setup:
Mainboard: T42
21 matches
Mail list logo