linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Len Brown <lenb@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-next@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP systems
Date: Tue, 8 Jul 2008 13:24:02 +0200	[thread overview]
Message-ID: <20080708112402.GA2301@alberich.amd.com> (raw)
In-Reply-To: <Pine.LNX.4.55.0807010055070.30785@cliff.in.clinika.pl>

On Tue, Jul 01, 2008 at 01:12:06AM +0100, Maciej W. Rozycki wrote:
> From: Matthew Garrett <mjg59@srcf.ucam.org>
> 
>  Some HP laptops have a problem with their DSDT reporting as
> HP/SB400/10000, which includes some code which overrides all temperature
> trip points to 16C if the INTIN2 input of the I/O APIC is enabled.  This
> input is incorrectly designated the ISA IRQ 0 via an interrupt source
> override even though it is wired to the output of the master 8259A and
> INTIN0 is not connected at all.  So far two models have been identified, 
> namely nx6125 and nx6325.

Out of sheer curiosity. What makes you think that IRQ0 is not
connected to INT0 of IO APIC? The IRQ0 pin2 override?

Why would we trust that BIOS information if the broken BIOS does
weird things if INT2 of IO APIC is _not_ masked?

IMHO on those HP systems we should skip the (bogus?) timer override,
leave IRQ0 -> IOAPIC/INT0 and mask IOAPIC/INT2. Or at least we should
test that configuration.

I admit that I have lost track of who has provided which patches,
which patch does exactly what ((IO|L)A)PIC configuration, and who has
tested what combinations, and what the results were.

So I've just done the following (based on x86/master as of yesterday):

Booting an HP nx6325

(1)  with "acpi_skip_timer_override" to avoid configuration
     of IOAPIC/INT2 and to avoid masking of IOAPIC/INT0.

  plus

(2) adding (hardcoded in check_timer()) some code to explicitly mask
    IOAPIC/INT2 to quiesce the fan (work around the DSDT issue).

With that setup my test box boots w/o problems (no fan noise, no
throttling, no stablity problems so far). Here the relevant dmesg
parts:

Command line: root=/dev/sda2 video=radeonfb:noaccel debug apic=debug acpi_skip_timer_override
  ...
IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 
  ...
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
  ...
using C1E aware idle routine
  ...
init IO_APIC IRQs
IOAPIC[0]: Set routing entry (2-0 -> 0x30 -> IRQ 0 Mode:0 Active:0)
IOAPIC[0]: Set routing entry (2-1 -> 0x31 -> IRQ 1 Mode:0 Active:0)
IOAPIC[0]: Set routing entry (2-2 -> 0x32 -> IRQ 2 Mode:0 Active:0)
  ...
IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20 not connected.
IOAPIC[0]: Set routing entry (2-21 -> 0x49 -> IRQ 21 Mode:1 Active:1)
IO-APIC (apicid-pin) 2-22, 2-23 not connected.
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
CPU0: AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping 02
Using local APIC timer interrupts.
  ...
IO APIC #2......
  ...
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:   
00 003 0    0    0   0   0    1    1    30
01 003 0    0    0   0   0    1    1    31
02 003 1    0    0   0   0    1    1    32


I think we have 3 alternatives to setup timer interrupt on those machines

(A) Setup timer as Virtual Wire IRQ.
    (that's the way the old code used to configure it, e.g. in 2.6.25)
(B) The current approach to setup timer as ExtINT.
(C) Use IOAPIC/INT0.

Shouldn't be that hard to find the best solution here:

(A) proved to work (and even "accidentially" masked IOAPIC/INT2 which
    avoided the DSDT problem)

(B) ??? who tested this, Rafael -- The stability issues, did they happen
    with a kernel based on that solution?

(C) ... is my preferred solution. I tested it and I've not seen problems
    with it (so far) -- maybe it's naive but I think it's the most
    obvious solution (*)


Regards,

Andreas

(*) BTW, default for SB400 is to route IRQ0 to IOAPIC/INT0 and output
    of PIC to IOAPIC/INT2. On my test box this wasn't configured
    differently. Thus I don't understand why the BIOS provided an
    IRQ0/INT2 override at all.

  parent reply	other threads:[~2008-07-08 11:24 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01  0:12 [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP systems Maciej W. Rozycki
2008-07-01  0:17 ` Matthew Garrett
2008-07-01  8:46   ` Ingo Molnar
2008-07-01 19:58     ` Rafael J. Wysocki
2008-07-01 20:24       ` Ingo Molnar
2008-07-04 21:21         ` Rafael J. Wysocki
2008-07-06 23:02         ` Rafael J. Wysocki
2008-07-07  1:19           ` Rafael J. Wysocki
2008-07-07  7:17             ` Ingo Molnar
2008-07-07  7:36               ` Ingo Molnar
2008-07-07 12:24                 ` Rafael J. Wysocki
2008-07-07 11:41               ` Maciej W. Rozycki
2008-07-07 12:23                 ` Rafael J. Wysocki
2008-07-07 14:01                   ` Maciej W. Rozycki
2008-07-07 18:03                     ` Rafael J. Wysocki
2008-07-07 20:10                       ` Maciej W. Rozycki
2008-07-07 20:31                         ` Rafael J. Wysocki
2008-07-07 21:39                           ` Maciej W. Rozycki
2008-07-07 22:10                             ` Rafael J. Wysocki
2008-07-07 12:28                 ` Rafael J. Wysocki
2008-07-07 17:10                   ` Maciej W. Rozycki
2008-07-07 17:51                     ` Ray Lee
2008-07-07 18:09                     ` Rafael J. Wysocki
2008-07-07 19:59             ` Maciej W. Rozycki
2008-07-07 20:17               ` Rafael J. Wysocki
2008-07-07 21:38                 ` Maciej W. Rozycki
2008-07-07 20:30               ` Maciej W. Rozycki
2008-07-07  3:54 ` Zhao Forrest
2008-07-07 12:34   ` Rafael J. Wysocki
2008-07-08 11:24 ` Andreas Herrmann [this message]
2008-07-08 14:39   ` Maciej W. Rozycki
2008-07-08 15:27   ` Rafael J. Wysocki
2008-07-08 16:25     ` Maciej W. Rozycki
2008-07-08 16:54       ` Rafael J. Wysocki
     [not found] <fa.OuKI5CNmq3HqeBQCfWOUtrq4+oA@ifi.uio.no>
2008-07-03  5:44 ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080708112402.GA2301@alberich.amd.com \
    --to=andreas.herrmann3@amd.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=mingo@elte.hu \
    --cc=mjg59@srcf.ucam.org \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).