Announcement

**milkylainen** · 30 June 2019, 01:52 PM

In the age of modern x86, I'm surprised it took so long to get a system to fail boot because IRQ0 was gated.
So these x86-systems are the first ever to ship with it gated? Mind-boggling.

**tildearrow** · 30 June 2019, 05:44 PM

I wonder why would they clock-gate a timer in the first place.

**mlau** · 01 July 2019, 02:53 AM

Originally posted by tildearrow View Post

I wonder why would they clock-gate a timer in the first place.

Windows 10 probably doesn't need it any longer

**starshipeleven** · 01 July 2019, 05:16 AM

Originally posted by mlau View Post

Windows 10 probably doesn't need it any longer

More like it's useless on modern hardware. (from the linux kernel patch)

Modern sytems allow to discover the TSC and local APIC timer frequencies, so the calibration against the PIT is not required.
These systems have always running timers and the local APIC timer works also in deep power states.
So the setup of the PIT including the IO-APIC timer interrupt delivery checks are a pointless exercise.

**mlau** · 01 July 2019, 06:05 AM

Originally posted by starshipeleven View Post

More like it's useless on modern hardware. (from the linux kernel patch)

I don't disagree, BUT, BIOSes are only tested on Windows, and if an option like this is off by default it can only mean that latest Windows 10 doesn't need it (on that particular platform).
Also, Windows relies more on ACPI for device discovery. It doesn't probe the 8259 chip if there is no PNP0000 device in the ACPI DSDT, and I bet
the platforms in question don't expose it when the option is switched off. I'd say Linux' assumption that the 8259 is always present is wrong.

**Britoid** · 01 July 2019, 06:45 AM

Originally posted by mlau View Post

I don't disagree, BUT, BIOSes are only tested on Windows, and if an option like this is off by default it can only mean that latest Windows 10 doesn't need it (on that particular platform).
Also, Windows relies more on ACPI for device discovery. It doesn't probe the 8259 chip if there is no PNP0000 device in the ACPI DSDT, and I bet
the platforms in question don't expose it when the option is switched off. I'd say Linux' assumption that the 8259 is always present is wrong.

suggesting Windows does something right and Linux was doing it wrong, woah someones trying to start a storm.

**starshipeleven** · 01 July 2019, 08:45 AM

Originally posted by mlau View Post

I don't disagree, BUT, BIOSes are only tested on Windows,

It does not change one bit the part I quoted. It's not talking about Linux, but about hardware.

Modern sytems allow to discover the TSC and local APIC timer frequencies, so the calibration against the PIT is not required.
These systems have always running timers and the local APIC timer works also in deep power states.

It basically says that this timer register is useless legacy.

I'd say Linux' assumption that the 8259 is always present is wrong.

yes, and the commit message also says that even wehn this register is present, Linux kernel is using it for no real reason. The horror. The pain. the inefficiency.

the setup of the PIT including the IO-APIC timer interrupt delivery checks are a pointless exercise.

**uxmkt** · 01 July 2019, 12:24 PM

Originally posted by starshipeleven View Post

the commit message also says that even wehn this register is present, Linux kernel is using it for no real reason. The horror. The pain. the inefficiency.

You will get the benefit of the doubt that "use" meant just the setup code. During regular operation (call it boot-complete), the 8259 already stays unused; according to /proc/interrupts on my machine, the timer on IRQ0 has fired only 11 times ever since boot, so that is good. Of course, if the setup also ditches it, the better, but 1.366s kernel boot time is already good here.