Project

General

Profile

Actions
Copy link

Bug #478

open

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

Added by Robert Gruber over 1 year ago. Updated over 1 year ago.

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

0%

Estimated time:
Affected versions:
4.15, 4.16, 4.17, 4.18, 4.19, master
Needs backport to:
master
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

Download all 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
Copy link
 #1

Updated by Paul Menzel over 1 year 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
Copy link
 #2

Updated by Robert Gruber over 1 year ago

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

Actions
Copy link
 #3

Updated by Robert Gruber over 1 year ago

  • Target version changed from none to master
Actions
Copy link
 #4

Updated by Bill XIE over 1 year 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
Copy link
 #5

Updated by Robert Gruber over 1 year ago

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

Updated by Robert Gruber over 1 year 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
Copy link
 #7

Updated by Nico Huber over 1 year 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.

Actions
Copy link Download all files
 #8

Updated by Robert Gruber over 1 year 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
Copy link
 #9

Updated by Bill XIE over 1 year 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
Copy link
 #10

Updated by Bill XIE over 1 year 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
Copy link
 #12

Updated by Bill XIE over 1 year ago

Actions
Copy link
 #13

Updated by Bill XIE over 1 year 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.

Actions
Copy link Download all files
 #14

Updated by Robert Gruber over 1 year 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
Copy link
 #15

Updated by Paul Menzel over 1 year 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
Copy link
 #16

Updated by Robert Gruber over 1 year 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
Copy link
 #17

Updated by Robert Gruber over 1 year 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
Copy link

Also available in: Atom PDF