Bug #478
openX200 booting Linux takes a long time with TSC (`clocksource=hpet` works)
Added by Robert Gruber about 1 year ago. Updated 12 months ago.
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.
Updated by Paul Menzel about 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)
Updated by Robert Gruber about 1 year ago
Thank you for editing my description! tsc=unstable also works.
Updated by Robert Gruber about 1 year ago
- Target version changed from none to master
Updated by Bill XIE about 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?
Updated by Robert Gruber about 1 year ago
- Affected OS set to xubuntu 22.04 LTS, Trisquel 11.0
Updated by Robert Gruber about 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.
Updated by Nico Huber about 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.
Updated by Robert Gruber about 1 year ago
- File dmesg_slow.log dmesg_slow.log added
- File dmesg_fast_with_clocksource_hpet.log dmesg_fast_with_clocksource_hpet.log added
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.
Updated by Bill XIE about 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?
Updated by Bill XIE about 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.
Updated by Bill XIE about 1 year ago
- File dmesg-x200-cb-kali.log dmesg-x200-cb-kali.log added
Updated by Bill XIE about 1 year ago
4.19-1073-gcc5efa5c66 is https://review.coreboot.org/c/coreboot/+/74182/8
Updated by Bill XIE about 1 year ago
- File dmesg-x200-cb-kali-2.log dmesg-x200-cb-kali-2.log added
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 about 1 year ago
- File dmesg_vendor_x200t_fast.log dmesg_vendor_x200t_fast.log added
- File dmesg_vendor_x200t_fast_without_clocksource_parameter.log dmesg_vendor_x200t_fast_without_clocksource_parameter.log added
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.
Updated by Paul Menzel about 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.
Updated by Robert Gruber about 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 sReplace 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
Updated by Robert Gruber 12 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)