amd64 -CURRENT freezes on ThinkPad X1 Carbon 7th gen

razrx

razrx

I recently bought an X1 Carbon 7th gen. (type 20QDCTO1WW)

It's running the latest UEFI 1.41 BIOS (it came shipped with BIOS 1.40).​

Initially it came with Win10 Pro (created a Lenovo USB recovery stick just in case I need to go back to win10 pro after actually installing 13 -CURRENT on bare metal).
The laptop has run idle but stable on win10 pro for multiple days.
All the hardware tests also passed.

After disabling UEFI secure boot from BIOS in order to boot other OSes, I booted into the livecd (so no install yet) using https://download.freebsd.org/ftp/sn...md64-20210107-f2b794e1e90-255641-memstick.img
I have also tried running the 20201224 and 20201210 snapshot memstick images.
The longest I've been able to just let the live cd run (running top) when on AC before my system completely freezes is roughly about 7 hours.
When it freezes the cooling fan kicks in at a fairly high rpm.
Unless I forcibly power down the high rpm just continues.
Power mode for AC is set to max performance.
Adaptive thermal management scheme for AC also set to max performance.

I've sent this Carbon X1 back once already to Lenovo because sometimes the livecd of any of the abovementioned 13-CURRENT snapshot images hardly had started before a freeze would already occur.
According to the system board serial number shown in BIOS that's what they have replaced (different serial number showing compared to before sending it back).
I've tried booting both using UEFI and also legacy BIOS but in both cases I've experienced the same behaviour.

Any Carbon X1 7th gen users on here that have any pointers to a solution?
Any specific settings in BIOS to perhaps avoid?

I bought this ThinkPad based on the info listed on https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon

edit: just made the following BIOS changes:

config -> power -> adaptive thermal management > scheme for AC : balanced (was : maximize performance)
config -> power -> sleep state : Linux (was: windows 10)
config -> intel AMT > intel AMT control : disabled (was : enabled)
security -> security chip > security chip : Off (was : On) <-- security chip type : TPM 2.0

Just made these changes .. going to boot into livecd again using the 20210107 snapshot memstick and let it run over night running top to keep the system at least a bit busy.
 
razrx I have these exact same problems with my Thinkpad T490.
- PR 248659
- https://lists.freebsd.org/pipermail/freebsd-current/2020-September/077050.html

The root cause has not yet been found. I'm kind of waiting for 13-STABLE to branch so that more people will observe this problem and it will receive the correct priority. You could reply again on the mail thread, it seems specific to ThinkPad's. Also I tried 12-STABLE and here the bug is not present. Have you tried with 12-STABLE trying to run it for long time?
 
Duffyx said:
I'm kind of waiting for 13-STABLE to branch so that more people will observe this problem and it will receive the correct priority.
Click to expand...
I suggest you take this up on the mailing lists now so it can actually be fixed before the release.

13-CURRENT is unsupported here on the forums. That doesn't mean the developers aren't going to listen to problem reports.
 
SirDice said:
I suggest you take this up on the mailing lists now so it can actually be fixed before the release.
Click to expand...
I have done that. The problem is that the bug is very vague which is hard to debug for a remote developer which is why I think this bug hasn't been picked up yet. I suggest to just add a "me too" on top of the mail thread, as I suggested to the OP. I'll send a reminder somewhere this week.
 
Do you have a PR to refer too? That will make it easier for others to chime in.
 
Duffyx said:
razrx I have these exact same problems with my Thinkpad T490.
- PR 248659
- https://lists.freebsd.org/pipermail/freebsd-current/2020-September/077050.html

The root cause has not yet been found. I'm kind of waiting for 13-STABLE to branch so that more people will observe this problem and it will receive the correct priority. You could reply again on the mail thread, it seems specific to ThinkPad's. Also I tried 12-STABLE and here the bug is not present. Have you tried with 12-STABLE trying to run it for long time?
Click to expand...
Thanks for the update and PR.
No I haven't tried 12-STABLE yet but I will.
And I was using the default english kb layout when I actually installed 13-CURRENT on the X1 but that didn't improve anything.
Yesterday's test was very unsuccessful .. I booted into the live cd .. only ran a tail -f on /var/log/messages and it froze within 5 seconds.
I'll reply to the list about me also having this issue on recent -CURRENT images.

EDIT: I sent a reply to the list mentioning the PR that you provided.
 
razrx said:
No I haven't tried 12-STABLE yet but I will.
And I was using the default english kb layout when I actually installed 13-CURRENT on the X1 but that didn't improve anything.
Yesterday's test was very unsuccessful .. I booted into the live cd .. only ran a tail -f on /var/log/messages and it froze within 5 seconds.
I'll reply to the list about me also having this issue on recent -CURRENT images.
Click to expand...
If you have the problem on 12-STABLE too then make sure to mention this. If it gets fixed in 13-CURRENT the fix can be MFC'ed to 12-STABLE. That will make sure the issue is fixed for future 12.x releases too.
 
SirDice said:
If you have the problem on 12-STABLE too then make sure to mention this. If it gets fixed in 13-CURRENT the fix can be MFC'ed to 12-STABLE. That will make sure the issue is fixed for future 12.x releases too
Click to expand...
Yes, am very much aware of the MFC process.
Here's hoping 12-STABLE will at least give me a working laptop.
 
Duffyx said:
12-STABLE did not have the bug I observed on 13-CURRENT.
Click to expand...
Running the 12.2-STABLE snapshot for the last 1h38 minutes (running top again).
So far still stable .. will let it run throughout the night.
If all is still well tomorrow morning I'll do an actual install again and start using my tarsnap backup to recover most of my configs and will reply back to the -current list with my findings.
 
razrx said:
Running the 12.2-STABLE snapshot for the last 1h38 minutes (running top again).
So far still stable .. will let it run throughout the night.
If all is still well tomorrow morning I'll do an actual install again and start using my tarsnap backup to recover most of my configs and will reply back to the -current list with my findings.
Click to expand...
12.2-STABLE r368787 installed (ZFS) and has been running stable for over 24 hours.
I've sent a follow-up to the -current list.
I've added a comment to PR 248659
 
I don't know if you want to risk it, as you have something working now, but from 12.1 it's really easy to upgrade to 12.2. Also, are you running STABLE, rather than RELEASE? STABLE is actually more in flux than RELEASE will be. I think I would try 12.2-RELEASE and see how it works. My situation was the reverse, on a T495 Ryzen, 12.2-RELEASE wouldn't give me X save for vesa, so I use CURRENT, because it's what working for me. But CURRENT is always a bit of a gamble (aside from not being supported here), and so, unless you have hardware unsupported in RELEASE, or are doing development and testing for FreeBSD, it's almost always better to stick with RELEASE.

There's an old article Freddie Cash wrote, around the time of FreeBSD-4, 5, and 6 all being out together, giving, IMHO, a great explanation of the differences between RELEASE, STABLE, and CURRENT. He let me put it up, and it's still there. Though it refers to very old releases, the explanation of terms is still valid.
 
scottro said:
I don't know if you want to risk it, as you have something working now, but from 12.1 it's really easy to upgrade to 12.2. Also, are you running STABLE, rather than RELEASE? STABLE is actually more in flux than RELEASE will be. I think I would try 12.2-RELEASE and see how it works. My situation was the reverse, on a T495 Ryzen, 12.2-RELEASE wouldn't give me X save for vesa, so I use CURRENT, because it's what working for me. But CURRENT is always a bit of a gamble (aside from not being supported here), and so, unless you have hardware unsupported in RELEASE, or are doing development and testing for FreeBSD, it's almost always better to stick with RELEASE.

There's an old article Freddie Cash wrote, around the time of FreeBSD-4, 5, and 6 all being out together, giving, IMHO, a great explanation of the differences between RELEASE, STABLE, and CURRENT. He let me put it up, and it's still there. Though it refers to very old releases, the explanation of terms is still valid.
Click to expand...
I have no interest in running -RELEASE.
I've run -CURRENT on my X230 for quite some years but that unfortunately died on me recently hence my need for getting a new laptop.
Running -CURRENT has always been my choice.. I haven't run anything -RELEASE for many years (think it was FreeBSD 7).
With ZFS BEs I run no risk in making world whenever something new has been committed or an update pushed like with OpenZFS and the introduction of zstd compression.
I'll stick with 12.2-STABLE for the time until, hopefully, the problem with 13 will be sorted.
 
vega o
scottro said:
I don't know if you want to risk it, as you have something working now, but from 12.1 it's really easy to upgrade to 12.2. Also, are you running STABLE, rather than RELEASE? STABLE is actually more in flux than RELEASE will be. I think I would try 12.2-RELEASE and see how it works. My situation was the reverse, on a T495 Ryzen, 12.2-RELEASE wouldn't give me X save for vesa, so I use CURRENT, because it's what working for me. But CURRENT is always a bit of a gamble (aside from not being supported here), and so, unless you have hardware unsupported in RELEASE, or are doing development and testing for FreeBSD, it's almost always better to stick with RELEASE.

There's an old article Freddie Cash wrote, around the time of FreeBSD-4, 5, and 6 all being out together, giving, IMHO, a great explanation of the differences between RELEASE, STABLE, and CURRENT. He let me put it up, and it's still there. Though it refers to very old releases, the explanation of terms is still valid.
Click to expand...
vega could work on freebsd12 ,just installing drm5 drivers https://forums.freebsd.org/threads/...utorial-for-beginner-update-2020-12-16.73901/
 
razrx said:
I recently bought an X1 Carbon 7th gen. (type 20QDCTO1WW)

It's running the latest UEFI 1.41 BIOS (it came shipped with BIOS 1.40).​

Initially it came with Win10 Pro (created a Lenovo USB recovery stick just in case I need to go back to win10 pro after actually installing 13 -CURRENT on bare metal).
The laptop has run idle but stable on win10 pro for multiple days.
All the hardware tests also passed.

After disabling UEFI secure boot from BIOS in order to boot other OSes, I booted into the livecd (so no install yet) using https://download.freebsd.org/ftp/sn...md64-20210107-f2b794e1e90-255641-memstick.img
I have also tried running the 20201224 and 20201210 snapshot memstick images.
The longest I've been able to just let the live cd run (running top) when on AC before my system completely freezes is roughly about 7 hours.
When it freezes the cooling fan kicks in at a fairly high rpm.
Unless I forcibly power down the high rpm just continues.
Power mode for AC is set to max performance.
Adaptive thermal management scheme for AC also set to max performance.

I've sent this Carbon X1 back once already to Lenovo because sometimes the livecd of any of the abovementioned 13-CURRENT snapshot images hardly had started before a freeze would already occur.
According to the system board serial number shown in BIOS that's what they have replaced (different serial number showing compared to before sending it back).
I've tried booting both using UEFI and also legacy BIOS but in both cases I've experienced the same behaviour.

Any Carbon X1 7th gen users on here that have any pointers to a solution?
Any specific settings in BIOS to perhaps avoid?

I bought this ThinkPad based on the info listed on https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon

edit: just made the following BIOS changes:

config -> power -> adaptive thermal management > scheme for AC : balanced (was : maximize performance)
config -> power -> sleep state : Linux (was: windows 10)
config -> intel AMT > intel AMT control : disabled (was : enabled)
security -> security chip > security chip : Off (was : On) <-- security chip type : TPM 2.0

Just made these changes .. going to boot into livecd again using the 20210107 snapshot memstick and let it run over night running top to keep the system at least a bit busy.
Click to expand...
Off topic question. I'm unable to load the intel-current-kmod package. Its saying the kernel versions are incompatible. Did you use pkg or ports to setup? Any problems?
 
SirDice said:
You might be interested in knowing that 13/stable was branched off recently.
Click to expand...
Yeah I'm currently building world off of stable/13 and will experiment a bit more.
I'm also tracking main since I do want to be on 14-CURRENT when pkg(8) starts behaving a bit more
 
k3y5 said:
Off topic question. I'm unable to load the intel-current-kmod package. Its saying the kernel versions are incompatible. Did you use pkg or ports to setup? Any problems?
Click to expand...
Do you mean drm-(current-)kmod ?
I'm not running -CURRENT currently but 12.2-STABLE without X.
However experience has taught me always to (re)install drm-(current-)kmod from ports as it needs to match your kernel.
I suggest to move this to both the -current mailing list and also report your findings on bugzilla since discussing -CURRENT issues on these forums is not supported

https://forums.freebsd.org/threads/topics-about-unsupported-freebsd-versions.40469/
 
Currently running 13.0-ALPHA-3 with the default GENERIC kernel after a src upgrade using the stable/13 branch.

13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #0 stable/13-c256220-g76dd854f47f4: Sun Jan 31 15:10:40 UTC 2021 root@harbinger.fritz.box:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

With hint.hwpstate_intel.0.disabled="1" in loader.conf I haven't experienced any hard wedging/freezes yet.
Without the hint I have the same issue as before with the X1 carbon hard wedging (running solid on 12.2-STABLE).

Just to test k3y5's situation I installed drm-current-kmod from pkg (after a pkg bootstrap -f).

$ pkg info drm-current-kmod
drm-current-kmod-5.4.62.g20210118
Name : drm-current-kmod
Version : 5.4.62.g20210118
Installed on : Sun Jan 31 16:57:36 2021 UTC
Origin : graphics/drm-current-kmod
Architecture : FreeBSD:13:amd64
Prefix : /usr/local
Categories : graphics kld
Licenses : BSD2CLAUSE, MIT, GPLv2
Maintainer : x11@FreeBSD.org
WWW : https://github.com/FreeBSDDesktop/kms-drm
Comment : DRM modules for the linuxkpi-based KMS components
Options :
DEBUG : off
SOURCE : on
Annotations :
FreeBSD_version: 1300136
repo_type : binary
repository : FreeBSD
Flat size : 194MiB
Description :
amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components.
Currently corresponding to Linux 4.16 DRM.
This version is for FreeBSD CURRENT.
amdgpu and radeonkms are known to fail with EFI boot.

WWW: https://github.com/FreeBSDDesktop/kms-drm

Using kld_list="i915kms" i915kms gets loaded but does throw the expected:

$ dmesg | grep 915
KLD i915_kbl_dmc_ver1_04_bin.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/i915_kbl_dmc_ver1_04_bin.ko - unsupported file type
drmn0: failed to link firmware kernel module with mapped name: i915_kbl_dmc_ver1_04_bin
i915/kbl_dmc_ver1_04.bin: could not load firmware image, error 2
[drm] Initialized i915 1.6.0 20190822 for drmn0 on minor 0
drmn0: fb0: i915drmfb frame buffer device
i915/kbl_dmc_ver1_04.bin: could not load firmware image, error 2
drmn0: failed to load firmware with name: i915/kbl_dmc_ver1_04.bin
drmn0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.
drmn0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

$ kldstat | grep 915
10 1 0xffffffff84c90000 158458 i915kms.ko

HTH
 
razrx said:
Currently running 13.0-ALPHA-3 with the default GENERIC kernel after a src upgrade using the stable/13 branch.

13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #0 stable/13-c256220-g76dd854f47f4: Sun Jan 31 15:10:40 UTC 2021 root@harbinger.fritz.box:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

With hint.hwpstate_intel.0.disabled="1" in loader.conf I haven't experienced any hard wedging/freezes yet.
Without the hint I have the same issue as before with the X1 carbon hard wedging (running solid on 12.2-STABLE).

Just to test k3y5's situation I installed drm-current-kmod from pkg (after a pkg bootstrap -f).

$ pkg info drm-current-kmod
drm-current-kmod-5.4.62.g20210118
Name : drm-current-kmod
Version : 5.4.62.g20210118
Installed on : Sun Jan 31 16:57:36 2021 UTC
Origin : graphics/drm-current-kmod
Architecture : FreeBSD:13:amd64
Prefix : /usr/local
Categories : graphics kld
Licenses : BSD2CLAUSE, MIT, GPLv2
Maintainer : x11@FreeBSD.org
WWW : https://github.com/FreeBSDDesktop/kms-drm
Comment : DRM modules for the linuxkpi-based KMS components
Options :
DEBUG : off
SOURCE : on
Annotations :
FreeBSD_version: 1300136
repo_type : binary
repository : FreeBSD
Flat size : 194MiB
Description :
amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components.
Currently corresponding to Linux 4.16 DRM.
This version is for FreeBSD CURRENT.
amdgpu and radeonkms are known to fail with EFI boot.

WWW: https://github.com/FreeBSDDesktop/kms-drm

Using kld_list="i915kms" i915kms gets loaded but does throw the expected:

$ dmesg | grep 915
KLD i915_kbl_dmc_ver1_04_bin.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/i915_kbl_dmc_ver1_04_bin.ko - unsupported file type
drmn0: failed to link firmware kernel module with mapped name: i915_kbl_dmc_ver1_04_bin
i915/kbl_dmc_ver1_04.bin: could not load firmware image, error 2
[drm] Initialized i915 1.6.0 20190822 for drmn0 on minor 0
drmn0: fb0: i915drmfb frame buffer device
i915/kbl_dmc_ver1_04.bin: could not load firmware image, error 2
drmn0: failed to load firmware with name: i915/kbl_dmc_ver1_04.bin
drmn0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.
drmn0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

$ kldstat | grep 915
10 1 0xffffffff84c90000 158458 i915kms.ko

HTH
Click to expand...
THANK YOU :)
 
You must log in or register to reply here.
Back
Top