Ok, I just got an old AMD K5 PR100 and my apic timer code doesn´t work on it. The funny thing is, I got some K6-2, a K6 166, all Pentiums (>= 90) and MMX cpus and all have the apic disabled on my board (EP-MVP3E), but this old cpu has it enabled, but my irq handler doesn´t get called.
So for what should I look? I know (I hope so) that my code works, I tested it on my core2duo pc. Maybe it could be the apic write bug of which brendan wrote some (long) time ago. But how can I write a macro (in C) for making a read and then writing to the apic, because gcc complains that I have a var which isn´t used, because I only write to it, but doesn´t read it (a dummy read of the apic).
APIC Timer
Re: APIC Timer
Hi,
Cheers,
Brendan
For older K5 CPUs, the feature flags returned by "CPUID 0x00000001" in EDX are dodgy - bit 9 is used to indicate support for PGE (and not used to indicate support for the local APIC). Basically I'm guessing that your CPU doesn't have a local APIC (even though CPUID says it does), and that is why your local APIC code isn't working...FlashBurn wrote:Ok, I just got an old AMD K5 PR100 and my apic timer code doesn´t work on it. The funny thing is, I got some K6-2, a K6 166, all Pentiums (>= 90) and MMX cpus and all have the apic disabled on my board (EP-MVP3E), but this old cpu has it enabled, but my irq handler doesn´t get called.
That particular bug was in an Intel CPU (Pentium I think).FlashBurn wrote:Maybe it could be the apic write bug of which brendan wrote some (long) time ago.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: APIC Timer
Thanks, that was the problem. For anyone who is interested should take a look at http://sandpile.org. There are much more bugs documented in x86 cpus. So my code will then also work on a P6 (pentium pro) which says it supports SEP, but it doesn´t.
What I find interesting is, that the AMD K5 supports PGE, this was a feature what was support first by the pentium pro, but nice to know.
Do you know where I can find some info about the apic write bug? I mean on which cpus it will occur and when?
What I find interesting is, that the AMD K5 supports PGE, this was a feature what was support first by the pentium pro, but nice to know.
Do you know where I can find some info about the apic write bug? I mean on which cpus it will occur and when?
Re: APIC Timer
Hi,
The relevant specification updates refer you to Appendix A in Intel's Pentium® Processor Family Developer’s Manual. The exact errata is "11AP. Back to Back Assertions of HOLD or BOFF# May Cause Lost APIC Write Cycle" on page A-96.
However, if you're serious about stability/reliability, then I'd recommend that your OS collect CPU information during boot (including obtaining corrected feature flags, and flaw/errata flags), and that the OS (and applications) use this corrected information after boot (instead of CPUID, which should never be used after boot), and that you examine all of the errata documentation for all CPUs and assess each piece of errata and decide what you should do about it. Otherwise, you might only find out about the most well known CPU bugs, and you won't find out about hundreds of less well known CPU bugs...
Note: Part of this "errata assessment" is deciding how each piece of errata could effect your users. For bugs that effect features reported by CPUID you can silently correct them (e.g. K5's dodgy APIC feature flag). For some of them you can implement work-arounds in your kernel to ensure that applications can't be effected (e.g. Cyrix COMA, Pentium F00F, etc). For some you can disable features (for e.g. to avoid issues with Pentium FPU bugs maybe you might want to disable the FPU). A lot of them can be ignored (for all OSs) or are motherboard/BIOS designer's problem (where you're unable to determine if the motherboard/BIOS is effected or not), and some of them can be ignored for your specific OS but not all OSs (for e.g. because I know my OS never uses Virtual8086 mode I know I can safely ignore all Virtual8086 mode bugs). For some of them, you might want to warn the user that there's a serious problem that can't be avoided.
Cheers,
Brendan
My code says vendor = Intel, family = 5, model = 2; with stepping < 5 or stepping = 11.FlashBurn wrote:Do you know where I can find some info about the apic write bug? I mean on which cpus it will occur and when?
The relevant specification updates refer you to Appendix A in Intel's Pentium® Processor Family Developer’s Manual. The exact errata is "11AP. Back to Back Assertions of HOLD or BOFF# May Cause Lost APIC Write Cycle" on page A-96.
However, if you're serious about stability/reliability, then I'd recommend that your OS collect CPU information during boot (including obtaining corrected feature flags, and flaw/errata flags), and that the OS (and applications) use this corrected information after boot (instead of CPUID, which should never be used after boot), and that you examine all of the errata documentation for all CPUs and assess each piece of errata and decide what you should do about it. Otherwise, you might only find out about the most well known CPU bugs, and you won't find out about hundreds of less well known CPU bugs...
Note: Part of this "errata assessment" is deciding how each piece of errata could effect your users. For bugs that effect features reported by CPUID you can silently correct them (e.g. K5's dodgy APIC feature flag). For some of them you can implement work-arounds in your kernel to ensure that applications can't be effected (e.g. Cyrix COMA, Pentium F00F, etc). For some you can disable features (for e.g. to avoid issues with Pentium FPU bugs maybe you might want to disable the FPU). A lot of them can be ignored (for all OSs) or are motherboard/BIOS designer's problem (where you're unable to determine if the motherboard/BIOS is effected or not), and some of them can be ignored for your specific OS but not all OSs (for e.g. because I know my OS never uses Virtual8086 mode I know I can safely ignore all Virtual8086 mode bugs). For some of them, you might want to warn the user that there's a serious problem that can't be avoided.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: APIC Timer
Yeah, I already do as much as possible in my loader and do such work a round there. At the moment I think I will ignore this apic write bug, because I haven´t seen a singel cpu board (sockel 5 and 7) which enables the apic and so I hope it´s save to ignore it. Maybe I will come up with a prober way of working around this some day.