[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080203044428.GA10139@elte.hu>
Date: Sun, 3 Feb 2008 05:44:28 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Gene Heskett <gene.heskett@...il.com>
Cc: Jeff Garzik <jeff@...zik.org>, Chris Rankin <rankincj@...oo.com>,
linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] 2.6.24 refuses to boot - ATA problem?
* Gene Heskett <gene.heskett@...il.com> wrote:
> I think that one came from me, but it also gets over 14,000 hits on
> google.
>
> Now Jeff, here is the strange part. That error was killing me, many
> times an hour and eventually crashing completely, repeatedly.
>
> I applied that kernel argument acpi_use_timer_override once and have
> not had the error since, and that includes one test of a full let it
> cool for a minute powerdown reboot to see if it would come back, which
> it did not.
>
> That argument causes the kernel to log this as its responding to that
> command:
>
> [ 27.097095] ENABLING IO-APIC IRQs
> [ 27.097287] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> [ 27.107291] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> [ 27.107343] ...trying to set up timer (IRQ0) through the 8259A ... failed.
> [ 27.107346] ...trying to set up timer as Virtual Wire IRQ... failed.
> [ 27.117353] ...trying to set up timer as ExtINT IRQ... works.
>
> The last 4 lines above are not logged without that argument. So my
> theory ATM is that this forced the kernel to initialize something in
> the boards registers that it does not initialize without that command,
> and that its going fubar as shown in the msg quoted above is a totally
> random thing, perhaps dependent on the phase of one of jupiters moons
> as to what state it powers up in. And I got lucky, so far in that my
> single powerdown reset didn't trigger it again... And you _know_ what
> that knocking sound is by now. :)
that's weird. Could you try the hack below and _remove_ the
acpi_use_timer_override flag? The change should artificially cause the
above 4 lines to appear again, in all cases.
This would test the following aspects of your theory: is this unknown
side-effect of the the acpi_use_timer_override flag related to the timer
setup sequence in io_apic_32.c? If not, then the difference most likely
lies in the different ACPI setup sequence.
Ingo
---
arch/x86/kernel/io_apic_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/x86/kernel/io_apic_32.c
===================================================================
--- linux.orig/arch/x86/kernel/io_apic_32.c
+++ linux/arch/x86/kernel/io_apic_32.c
@@ -2208,7 +2208,7 @@ static inline void __init check_timer(vo
* Ok, does IRQ0 through the IOAPIC work?
*/
unmask_IO_APIC_irq(0);
- if (timer_irq_works()) {
+ if (timer_irq_works() && 0) {
if (nmi_watchdog == NMI_IO_APIC) {
disable_8259A_irq(0);
setup_nmi();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists