Re: [BUG] 2.6.24 refuses to boot - ATA problem?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Gene Heskett <gene.heskett@xxxxxxxxx> 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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux