Project

General

Profile

Actions

Bug #478

open

X200 booting Linux takes a long time with TSC (`clocksource=hpet` works)

Added by Robert Gruber 11 months ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
04/04/2023
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:
xubuntu 22.04 LTS, Trisquel 11.0

Description

dmesg: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
After a period of time the boot finished by auto-switching to hpet. Setting kernel parameter directly to clocksource=hpet the system is booting fast.

Why is the faster clocksource tsc not working and tells coreboot is broken ?


Files

cbmem.log (38.6 KB) cbmem.log Robert Gruber, 04/04/2023 04:16 PM
dmesg_slow.log (63.5 KB) dmesg_slow.log Robert Gruber, 04/12/2023 04:21 PM
dmesg_fast_with_clocksource_hpet.log (63.8 KB) dmesg_fast_with_clocksource_hpet.log Robert Gruber, 04/12/2023 04:21 PM
dmesg-x200-vendor-kali.log (72.3 KB) dmesg-x200-vendor-kali.log Bill XIE, 04/13/2023 02:54 PM
dmesg-x200-cb-kali.log (63.9 KB) dmesg-x200-cb-kali.log Bill XIE, 04/13/2023 03:09 PM
dmesg-x200-cb-kali-2.log (61.4 KB) dmesg-x200-cb-kali-2.log Bill XIE, 04/13/2023 04:56 PM
dmesg_vendor_x200t_fast.log (85.8 KB) dmesg_vendor_x200t_fast.log Robert Gruber, 04/14/2023 01:37 PM
dmesg_vendor_x200t_fast_without_clocksource_parameter.log (85.8 KB) dmesg_vendor_x200t_fast_without_clocksource_parameter.log Robert Gruber, 04/14/2023 01:37 PM

Related links

Thank you for reporting this issue. Does booting with 'tsc=unstable also work?

Please the coreboot log messages for example by running cbmem -1.

Actions #1

Updated by Paul Menzel 11 months ago

  • Subject changed from X200 booting takes a long time to X200 booting Linux takes a long time with TSC (`clocksource=hpet` works)
  • Related links updated (diff)
Actions #2

Updated by Robert Gruber 11 months ago

Thank you for editing my description! tsc=unstable also works.

Actions #3

Updated by Robert Gruber 11 months ago

  • Target version changed from none to master
Actions #4

Updated by Bill XIE 11 months ago

Robert Gruber wrote:

dmesg: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
After a period of time the boot finished by auto-switching to hpet. Setting kernel parameter directly to clocksource=hpet the system is booting fast.

Why is the faster clocksource tsc not working and tells coreboot is broken ?

As stated in https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/tsc-resynchronization/ , there are 4 types of TSC, while a core 2 cpu only has Constant TSC, which may change on C state transitions.

Newer cpu like Ivy Bridge have nonstop_tsc and tsc_deadline in addition to constant_tsc. They can keep using tsc as clock source.

Does this issue remain on an x200 running vendor firmware?

Actions #5

Updated by Robert Gruber 11 months ago

  • Affected OS set to xubuntu 22.04 LTS, Trisquel 11.0
Actions #6

Updated by Robert Gruber 11 months ago

Bill XIE wrote in #note-4:

Robert Gruber wrote:

dmesg: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
After a period of time the boot finished by auto-switching to hpet. Setting kernel parameter directly to clocksource=hpet the system is booting fast.

Why is the faster clocksource tsc not working and tells coreboot is broken ?

As stated in https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/tsc-resynchronization/ , there are 4 types of TSC, while a core 2 cpu only has Constant TSC, which may change on C state transitions.

Newer cpu like Ivy Bridge have nonstop_tsc and tsc_deadline in addition to constant_tsc. They can keep using tsc as clock source.

Does this issue remain on an x200 running vendor firmware?

Only coreboot is affected. On vendor firmware the system boots with kernel defaults and clocksource=hpet fast.

Actions #7

Updated by Nico Huber 11 months ago

Can you provide a dmesg log? or even better, one with coreboot and one with vendor. It's probably just a flag somewhere that's telling Linux to use TSC. But that's easiest debugged in the OS.

Updated by Robert Gruber 11 months ago

Nico Huber wrote in #note-7:

Can you provide a dmesg log? or even better, one with coreboot and one with vendor. It's probably just a flag somewhere that's telling Linux to use TSC. But that's easiest debugged in the OS.

The coreboot dmesg log files are in the attachment. I have seen that some disks on AHCI are not affected by this issue some disks are affected. NVMe disks in the express card slot are always affected. clocksource=hpet always solves the problem for AHCI and NVMe disks.

Actions #9

Updated by Bill XIE 10 months ago

Robert Gruber wrote in #note-6:

Only coreboot is affected. On vendor firmware the system boots with kernel defaults and clocksource=hpet fast.

Whether it boots fast is not so important. We want to know whether tsc is unstable under vendor firmware, so could you provide a dmesg log under vendor firmware, with kernel defaults?

Actions #10

Updated by Bill XIE 10 months ago

Booting a Kali live on an x200 running vender firmware shows that the tsc seems stable enough, while on coreboot tsc becomes unstable.

Actions #12

Updated by Bill XIE 10 months ago

Actions #13

Updated by Bill XIE 10 months ago

Bill XIE wrote in #note-12:

4.19-1073-gcc5efa5c66 is https://review.coreboot.org/c/coreboot/+/74182/8

Bill XIE wrote in #note-10:

Booting a Kali live on an x200 running vender firmware shows that the tsc seems stable enough, while on coreboot tsc becomes unstable.

This dmesg log is collected on the same x200 from which dmesg-x200-vendor-kali.log is collected, running the same 4.19-1073-gcc5efa5c66 coreboot image. It may be a better comparable log.

Updated by Robert Gruber 10 months ago

Bill XIE wrote in #note-9:

Robert Gruber wrote in #note-6:

Only coreboot is affected. On vendor firmware the system boots with kernel defaults and clocksource=hpet fast.

Whether it boots fast is not so important. We want to know whether tsc is unstable under vendor firmware, so could you provide a dmesg log under vendor firmware, with kernel defaults?

I tested same AHCI disk on an X200T with vendor bios (please see attachments). tsc works fine and clocksource=hpet as well. Of course I can not test NVMe with vendor bios because there is no boot support.

In coreboot the system hangs for a while until it obviously autochanges to clocksource=hpet and boots normal.

Actions #15

Updated by Paul Menzel 10 months ago

Robert, thank you for providing all the information. As an update, on #coreboot@irc.libera.chat people suggested it might be the clockgen setup, and Arthur provided a patch. Unfortunately, it didn’t seem to help.

To collect some data points, could you please provide the output of the comment below with the vendor firmware and with coreboot?

$ sudo modprobe i2c-dev
$ sudo i2cdetect -l
[…]
i2c-7   smbus       SMBus I801 adapter at f040          SMBus adapter
[…]
$ sudo i2cdump -y 7 0x69 s

Replace the bus 7 with the value X in i2c-X in the i2cdetect output.

Actions #16

Updated by Robert Gruber 10 months ago

Paul Menzel wrote in #note-15:

Robert, thank you for providing all the information. As an update, on #coreboot@irc.libera.chat people suggested it might be the clockgen setup, and Arthur provided a patch. Unfortunately, it didn’t seem to help.

To collect some data points, could you please provide the output of the comment below with the vendor firmware and with coreboot?

$ sudo modprobe i2c-dev
$ sudo i2cdetect -l
[…]
i2c-7 smbus       SMBus I801 adapter at f040          SMBus adapter
[…]
$ sudo i2cdump -y 7 0x69 s

Replace the bus 7 with the value X in i2c-X in the i2cdetect output.

It's a pleasure for me to help. I got the following output on both coreboot and vendor bios:

$ apt-get install i2c-tools
$ sudo modprobe i2c-dev
$ sudo i2cdetect -l
i2c-0 smbus SMBus I801 adapter at 0400 SMBus adapter
i2c-1 i2c i915 gmbus ssc I2C adapter
i2c-2 i2c i915 gmbus vga I2C adapter
i2c-3 i2c i915 gmbus panel I2C adapter
i2c-4 i2c i915 gmbus dpc I2C adapter
i2c-5 i2c i915 gmbus dpb I2C adapter
i2c-6 i2c i915 gmbus dpd I2C adapter
i2c-7 i2c AUX B/DP B I2C adapter
i2c-8 i2c AUX C/DP C I2C adapter
i2c-9 i2c AUX D/DP D I2C adapter

$ sudo i2cdump -y 0 0x69 s
SMBus block mode is deprecated, please use i2cget instead
Error: Block read failed, return code -6

Btw: There is no loaded i2c-dev module:
$ lsmod |grep -i i2c
i2c_algo_bit 16384 1 i915
i2c_i801 36864 0
i2c_smbus 20480 1 i2c_i801

Actions #17

Updated by Robert Gruber 10 months ago

Paul Menzel wrote in #note-15:

$ sudo i2cdump -y 7 0x69 s

Is the output of i2cget still needed because of the deprecated i2cdump ? If yes, how do I get the required data with i2cget ?

Output from i2cget:
$ sudo i2cget -y 0 0x69 s
Error: Data address invalid!
Usage: i2cget [-f] [-y] [-a] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE [LENGTH]]]
I2CBUS is an integer or an I2C bus name
ADDRESS is an integer (0x08 - 0x77, or 0x00 - 0x7f if -a is given)
MODE is one of:
b (read byte data, default)
w (read word data)
c (write byte/read byte)
s (read SMBus block data)
i (read I2C block data)
Append p for SMBus PEC
LENGTH is the I2C block data length (between 1 and 32, default 32)

Actions

Also available in: Atom PDF