[coreboot] Re: Atomic Accesses to Local APIC

2021-10-06 Thread ron minnich
The specific case is code that is technical debt for *two* steppings (B and C2) of *one* instance of a CPU (P54C). There's no need to keep that around, especially since, as pointed out in the CL, it's causing trouble. I +2'ed the CL based on this discussion. On Wed, Oct 6, 2021 at 5:27 AM Peter

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-06 Thread Peter Stuge
ron minnich wrote: > same applies to new software applied to antiques. While you are correct for some software and some antiques I find this premise completely unacceptable. This attitude may be convenient for developers but it only further normalizes planned obsolecense. Not OK! Software can

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread ron minnich
"Doctor, it hurts when I do this" "Then don't do that" same applies to new software applied to antiques. On Tue, Oct 5, 2021 at 1:48 PM Matt B wrote: > > My concern is more about surprise brokenness when trying to use the newest > version, if any of those pentiums remain. > > On Tue, Oct 5,

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread Keith Emery
https://youtu.be/qpMvS1Q1sos I'm sorry. :( On 6/10/21 7:47 am, Matt B wrote: My concern is more about surprise brokenness when trying to use the newest version, if any of those pentiums remain. On Tue, Oct 5, 2021 at 4:06 PM ron minnich > wrote: That's what

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread Matt B
My concern is more about surprise brokenness when trying to use the newest version, if any of those pentiums remain. On Tue, Oct 5, 2021 at 4:06 PM ron minnich wrote: > That's what versions are all about. It seems sensible to me to leave > the old bad stuff behind; if people need it, it's all

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread ron minnich
That's what versions are all about. It seems sensible to me to leave the old bad stuff behind; if people need it, it's all still there if they know the tag. On Tue, Oct 5, 2021 at 1:02 PM Matt B wrote: > > I should note I'm not 100% sure what they're doing there. > > Are there any more of these

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread Matt B
I should note I'm not 100% sure what they're doing there. Are there any more of these buggy pentiums left in the coreboot tree? (If he chooses to update) I can imagine RMS getting real snippy if we break his thinkpad. :P On Tue, Oct 5, 2021 at 3:53 PM ron minnich wrote: > nice fine. Might be

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread ron minnich
nice fine. Might be worth adding the text of this comment (modified as needed) to the CL so that in years to come people understand the reasons. On Tue, Oct 5, 2021 at 12:51 PM Matt B wrote: > > A quick google turned this up: >

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread Matt B
A quick google turned this up: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.0/arch/x86/kernel/cpu/intel.c#253 On Tue, Oct 5, 2021 at 4:06 AM Julian Stecklina < julian.steckl...@cyberus-technology.de> wrote: > On Tue, 2021-10-05 at 09:29 +0300, Kyösti Mälkki wrote:

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread Julian Stecklina
On Tue, 2021-10-05 at 09:29 +0300, Kyösti Mälkki wrote: > On Mon, Oct 4, 2021 at 8:12 PM Julian Stecklina > wrote: > > > > But it looks like the workaround was just carried forward with no discussion > > of > > whether it's still necessary or what it actually works around. > > > > Hi > >

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-05 Thread Kyösti Mälkki
On Mon, Oct 4, 2021 at 8:12 PM Julian Stecklina wrote: > > The X86_GOOD_APIC was set in the past in a few configs. You can find them via: > > git log -S GOOD_APIC --source --all > > The define itself was finally removed in: > > commit fc57d6c4c2848726be1361f6dee3c33e7551b857 > Author: Patrick

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-04 Thread Julian Stecklina
The X86_GOOD_APIC was set in the past in a few configs. You can find them via: git log -S GOOD_APIC --source --all The define itself was finally removed in: commit fc57d6c4c2848726be1361f6dee3c33e7551b857 Author: Patrick Rudolph Date: Tue Nov 12 16:30:14 2019 +0100 cpu/x86/lapic:

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-04 Thread ron minnich
I would be happy if all those old buggy systems were gone, good idea Peter! On Mon, Oct 4, 2021 at 9:39 AM Peter Stuge wrote: > > ron minnich wrote: > > The problem, at this point, is that a change this broad must also be > > tested across all platforms to make sure it's not breaking. > > While

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-04 Thread Peter Stuge
ron minnich wrote: > The problem, at this point, is that a change this broad must also be > tested across all platforms to make sure it's not breaking. While true it could be worthwhile to check how often CONFIG_X86_GOOD_APIC is unset... > This looks like it was done for a hardware problem. We

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-04 Thread ron minnich
The problem, at this point, is that a change this broad must also be tested across all platforms to make sure it's not breaking. This looks like it was done for a hardware problem. We had a lot of x86 implementations in tree at that time, and they had lots of bugs. On Mon, Oct 4, 2021 at 8:11 AM

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-04 Thread Julian Stecklina
On Mon, 2021-10-04 at 07:32 -0700, ron minnich wrote: > that was pre-git but is there any useful comment in git anyway? I only > have the vaguest memory of why it went in. It was introduced in c84c1906b7 and fcd5ace00b3 without explanation. I particularly don't understand the lapic_write_around

[coreboot] Re: Atomic Accesses to Local APIC

2021-10-04 Thread ron minnich
that was pre-git but is there any useful comment in git anyway? I only have the vaguest memory of why it went in. On Mon, Oct 4, 2021 at 7:14 AM Julian Stecklina wrote: > > Hello, > > I was looking at the Local APIC code in coreboot and was wondering about > `lapic_write_atomic` in