Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP systems

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Andreas Herrmann <andreas.herrmann3@...>
Cc: Ingo Molnar <mingo@...>, Matthew Garrett <mjg59@...>, Rafael J. Wysocki <rjw@...>, Len Brown <lenb@...>, Thomas Gleixner <tglx@...>, <linux-next@...>, <linux-acpi@...>, <linux-kernel@...>
Date: Tuesday, July 8, 2008 - 10:39 am

On Tue, 8 Jul 2008, Andreas Herrmann wrote:


 The test I prepared a couple of weeks ago which Rafael ran for me.  The 
test forcibly rerouted IRQ0 to INTIN0, but the timer did not work with 
that setup.


 This is why I prepared the workaround to ignore BIOS IRQ0 configuration 
triggered by DMI matching proposed by Matthew.


 Unfortunately it did not work for Rafael's box and diagnostic messages 
have been quiesced in the 64-bit variation of code so bootstrap logs 
archived throughout the Internet could not be used as a reference.


 I can be blamed for the vast majority.  If you are unsure what does what,
then feel free to ask me.


 Now that you mentioned (2) a sudden insight made me realise in the
absence of an overlapping override we register ISA IRQ2 as an
edge-triggered I/O APIC interrupt, which means its input will be
implicitly unmasked.  But despite the ACPI spec does not make it
explicitly clear, there is no such thing as ISA IRQ2 -- what used to be
IRQ2 up to PC/XT got remapped to IRQ9 when the IR2 line of the 8259A was
reused as a cascade to the slave and no device since has ever been able to
make use of IRQ2.  Therefore I think we should actually not register this
IRQ2 thingy at all under any circumstances.  I'll send a patch.


 I am assuming by "Virtual Wire IRQ" you mean a setup we are referring to
as "8259A Virtual Wire" (without this additional qualifier the term is 
synonymous to ExtINTA).

 Given (C) did not work a workaround has been prepared to implement (A).  
As it does DMI ID matching and "knows" for this system (C) would not work 
I decided there is no point in trying such a configuration.

 Now you say your machine actually supports (C), which makes me wonder why 
Rafael's does not, hmm...


 Well, this is a piece of information I could not know.  Documentation for 
the SB400 is not publicly available.  I asked whether anybody could answer 
how this piece of circuitry has been designed in the chip and you are the 
first to provide some kind of an answer.


 One or more of the following:

1. Because the 8254 is not in fact routed to INTIN0 (as seen with the
   test).

2. Because almost everything else requires such an override and it was 
   left in place in the code base by mistake/misunderstanding/etc.

 OK, to recap: given what you have written, I think we should refrain from
registering IRQ2 as suggested above and then it will be safe to ignore the
interrupt override for the two systems affected based on a DMI quirk,
which means INTIN0 will be tried first, which may or may not work.  Of
course if it does not, then we have to quiesce the warning about the BIOS
having provided us with incorrect interrupt routing information, because
we ignored what it told us. ;)

  Maciej
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP..., Maciej W. Rozycki, (Mon Jun 30, 8:12 pm)
Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for som..., Rafael J. Wysocki, (Tue Jul 8, 11:27 am)
Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for som..., Maciej W. Rozycki, (Tue Jul 8, 12:25 pm)
Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for som..., Rafael J. Wysocki, (Tue Jul 8, 12:54 pm)
Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for som..., Maciej W. Rozycki, (Tue Jul 8, 10:39 am)
Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for som..., Maciej W. Rozycki, (Mon Jul 7, 10:01 am)