Re: [PATCH] x86: change IO-APIC ack method default forsingle IO-APIC systems

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 21/01/2009 14:51, "Jan Beulich" <jbeulich@novell.com> wrote:

>> I don't specifically recall that this issue required two IO-APICs. In fact I
>> think it did not. It was actually something to do with the chipset trying to
>> distinguish between an OS using 'legacy' routing versus 'mp-bios' routing,
>> via a rather distasteful IO-APIC hack. Unfortunately the hack was not that
>> uncommon and I don't think those chipsets had more than one IO-APIC.
> 
> I'm rather certain that it did involve multiple IO-APICs. What the chipsets
> were trying to cover was the ACPI vs. no-ACPI case, since secondary IO-APICs
> generally can be (or should I say are being/have been at that time on
> "certain"
> OSes) discovered only with ACPI. Hence when an IRQ normally going to a
> secondary IO-APIC's pin go masked in that IO-APIC, a replacement route
> was automatically established (and not torn down when the mask bit got
> cleared again) to a pin of the primary IO-APIC.

Yes, I think actually you are correct.
http://thread.gmane.org/gmane.os.freebsd.current/67490/focus=67490

>> Overall I think ack_type new has worked quite well. I was actually about to
>> remove the old ack_type! (But now I won't ;-) I'm not inclined to take this
>> patch though.
> 
> If I had an affected system to debug the issue, I'd try to do so (though
> remembering how long it took to understand the original issue I'm hesitant
> to say so). With the above explanation I hope you may reconsider...

Well, it seems not great to avoid the new ack_type for some unknown bug. And
noone else has run with your patch and zero other issues with the new
ack_type have been reported. So this seems to be papering over a rather rare
and potentially nasty underlying issue. On the other hand, perhaps old
ack_type is preferable (faster) if we can be sure we're on a system where it
is safe. Hmmm.

 -- Keir