Reported and tested by: Michael Butler <imb@protected-networks.net>
Fixes: 62d09b46ad75 ("x86: Defer LAPIC calibration until after timecounters are available")
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
This sounds very much as something i386-specific, i.e. relevant for Pentium-class machines, or older. Should it be under #ifdef i386? And then x2apic_mode check is not needed.
Indeed, the problem was reported with a pentium 3.
Should it be under #ifdef i386? And then x2apic_mode check is not needed.
I reused the check already present in, e.g., native_lapic_enable_{pmc,cmc}(). I suspect they should all be changed, then.
Interesting, native_lapic_enable_cmc() uses DEV_ATPIC as the guard. Perhaps all other cases should do the same, there must be lapic if there is no atpic.
And I was wrong that x2apic excludes i386, we do support x2apic mode for i386, just that nobody would run i386 kernel on such machine.
And I was wrong that x2apic excludes i386, we do support x2apic mode for i386, just that nobody would run i386 kernel on such machine.
Hmm, ok. It looks a bit weird to me: the 8259 does not provide a timer, and the code size reduction on amd64 is minimal.
And I was wrong that x2apic excludes i386, we do support x2apic mode for i386, just that nobody would run i386 kernel on such machine.
I think the reason for DEV_ATPIC guards is as kib@ noted: we require a local APIC if device atpic isn't present. I think it is not about the code size so much as you'd rather it crash and burn hard early on if for some reason the local APIC isn't found on a system that assumes a local APIC. The reason for DEV_ATPIC vs __i386__ is that in theory one can add device atpic to an amd64 kernel (though it's been several years since I've tested that and at this point that's probably not worth testing).