[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: Tree for July 8: nx6325-related commits
On Wed, 9 Jul 2008, Rafael J. Wysocki wrote:

> Commits 0b3d81ad4f765513347a04434efc15cbdc4e1c54
> ("x86, ioapic, acpi: add a knob to disable IRQ 0 through I/O APIC") and
> e38502eb8aa82314d5ab0eba45f50e6790dadd88
> ("x86, ioapic, acpi quirk: disable IRQ 0 through I/O APIC for some HP systems")
> don't work on x86_64, because acpi_dmi_table[] depends on __i386__.
> Moreover, if you make them work (by removing that dependency), they hang my
> nx6325 solid early during boot.

I have build an x86-64 cross-compiler now and can test 64-bit kernels.
I have tested the patches you have requested to be reverted in a 64-bit
configuration now and discovered the following problems elsewhere:

1. Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for
the "8259A Virtual Wire" through the local APIC timer configuration
does not fully configure the relevant irq_chip structure. Instead it
relies on the preceding I/O APIC code to have set it up, which does not
happen if the I/O APIC variants have not been tried. I think this is
the reason of your hang.

2. As mentioned in the other mail, there is no such entity as ISA IRQ2.
The ACPI spec does not make it explicitly clear, but does not preclude
it either -- all it says is ISA legacy interrupts are identity mapped
by default (subject to overrides), but it does not state whether IRQ2
exists or not. As a result if there is no IRQ0 override, then IRQ2 is
normally initialised as an ISA interrupt, which implies an
edge-triggered line, which is unmasked by default as this is what we do
for edge-triggered I/O APIC interrupts so as not to miss an edge.

To the best of my knowledge it is useless, as IRQ2 has not been in use
since the PC/AT as back then it was taken by the 8259A cascade
interrupt to the slave, with the line posiotion in the slot rerouted to
newly-created IRQ9. No device could thus make use of this line with
the pair of 8259A chips. Now in theory INTIN2 of the I/O APIC may be
usable, but the interrupt of the device wired to it would not be
available in the PIC mode at all, so I seriously doubt if anybody
decided to reuse it for a regular device (anybody please feel free to
prove me otherwise).

However there are two common uses of INTIN2. One is for IRQ0, with an
ACPI interrupt override (or its equivalent in the MP table). But in
this case IRQ2 is gone entirely with INTIN0 left vacant. The other one
is for an 8959A ExtINTA cascade. In this case IRQ0 goes to INTIN0 and
if ACPI is used INTIN2 is assumed to be IRQ2 (there is no override and
ACPI has no way to report ExtINTA interrupts). This is where a problem

The problem is INTIN2 is configured as a native APIC interrupt, with a
vector assigned and the mask cleared. And the line may indeed get
active and inject interrupts if the master 8959A has its timer
interrupt enabled (it might happen for other interrupts too, but they
are normally masked in the process of rerouting them to the I/O APIC).
There are two cases where it will happen:

* When the I/O APIC NMI watchdog is enabled. This is actually a
misnomer as the watchdog pulses are delivered through the 8259A to
the LINT0 inputs of all the local APICs in the system. The
implication is the output of the master 8259A goes high and low
repeatedly, signalling interrupts to INTIN2 which is enabled too!

[The origin of the name is I think for a brief period during the
development we had a capability in our code to configure the watchdog
to use an I/O APIC input; that would be INTIN2 in this scenario.]

* When the native route of IRQ0 via INTIN0 fails for whatever reason --
as it happens with the system considered here. In this scenario the
timer pulse is delivered through the 8259A to LINT0 input of the
local APIC of the bootstrap processor, quite similarly to how is done
for the watchdog described above. The result is, again, INTIN2
receives these pulses too. Rafael's system used to escape this
scenario, because an incorrect IRQ0 override would occupy INTIN2 and
prevent it from being unmasked.

My conclusion is IRQ2 should be excluded from configuration in all the
cases and the current exception for ACPI systems should be lifted. The
reason being the exception not only being useless, but harmful as well.

I have patches ready to address both issues, but I will test them against
linux-next yet, to avoid any dissynchronisation that may happen similar to
some recent experiences. I shall post the patches later today. At that
point 0b3d81ad4f765513347a04434efc15cbdc4e1c54 and
e38502eb8aa82314d5ab0eba45f50e6790dadd88 should be safe to bring back.


 \ /
  Last update: 2008-07-09 16:21    [W:0.189 / U:1.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site