Had at least one other report like this...  Sleepiness prevents me from

recalling more at the moment, but I think the other report was fixed

with a special ACPI switch...
/me puts in pile for Monday...
	Jeff
--

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 my admittedly hardware oriented view of the goings on.  But I also

think it should be a good clue as to what piece of the acpi code

needs walked around in and its tires kicked again, with an eye toward

making that item a wee bit more intelligently done.  If you can cobble

up something that will extract the data and prove what fails, I'll be

glad to play guinea pig.  With ccache, a kernel build is < 15 minutes to

actually running it.
Thanks Jeff.  I'm glad to see that this isn't scheduled to 'fall through

the cracks' as does happen when folks get busy.
--

C...
[ message continues ]

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();

--

I believe its the same, but lemme paste it for sure, yes:

[   26.339926] ENABLING IO-APIC IRQs

[   26.340119] ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1

[   26.350129] ..MP-BIOS bug: 8254 timer not connected to IO-APIC

[   26.350182] ...trying to set up timer (IRQ0) through the 8259A ...  failed.

[   26.350185] ...trying to set up timer as Virtual Wire IRQ... failed.

[   26.360186] ...trying to set up timer as ExtINT IRQ... works.
The third line is the only line that makes it to the screen during the boot

trace.
Now, what does this tell us?
--

Cheers, Gene

"There are four boxes to be used in defense of liberty:

 soap, ballot, jury, and ammo. Please use in that order."

-Ed Howdershelt (Author)

As far as the laws of mathematics refer to reality, they are not

certain, and as far as they are certain, they do not refer to reality.

		-- Albert Einstein

--

the question would be:
 - if you remove the acpi_use_timer_override boot flag

 - and if you boot a kernel with this hack applied
=> do those weird PATA failures come back?
If the failues do _not_ come back then the problem is somehow

affected/worked-around by the IO-APIC code that generates the above 4

lines. If the failures are still the same then the above 4 lines are

really just an uninteresting side-effect of the acpi_use_timer_override

flag - and the real side-effects (that fixes PATA on your box) are to be

found elsewhere.
Sadly, the latter variant is the expected answer.
	Ingo

--

And at this point, I can't tell.  This reboot was from a cold start, without

the argument, and cold by long enough to make the rounds about the house and

pick up a beer, but not take my evening pillbox.  A minute cold, maybe 2 max.

The log is clean since except for a kudzu nag of some sort:
[   50.535388] warning: process `kudzu' used the deprecated sysctl system call

with 1.23.
which isn't your problem, but fedora's.
As I said before, that error has not returned since the first time I used that

argument, and I have booted several times now without it.  Uptime now is just

over an hour though, so I'm not taking bets just yet. :)
--

Cheers, Gene

"There are four boxes to be used in defense of liberty:

 soap, ballot, jury, and ammo. Please use in that order."

-Ed Howdershelt (Author)

Now I lay me down to sleep

I pray the double lock will keep;

May no brick through the window break,

And, no one rob me till I awake.

--

..
Just to muddy your observations:  it is quite possible that a cold (power-off)

reboot may be required to properly observe what happens here.
Cheers

--

Precisely why I've now done that twice, without using the extra argument.  No 
--

Cheers, Gene

"There are four boxes to be used in defense of liberty:

 soap, ballot, jury, and ammo. Please use in that order."

-Ed Howdershelt (Author)

He who makes a beast of himself gets rid of the pain of being a man.

		-- Dr. Johnson

--

i tried that patch on a box here, and it produces similar 4 lines:
[    0.172141] ENABLING IO-APIC IRQs

[    0.175498] init IO_APIC IRQs

[    0.176059]  IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.

[    0.187942] ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1

[    0.233859] ..MP-BIOS bug: 8254 timer not connected to IO-APIC

[    0.236014] ...trying to set up timer (IRQ0) through the 8259A ...  failed.

[    0.236014] ...trying to set up timer as Virtual Wire IRQ... failed.

[    0.236014] ...trying to set up timer as ExtINT IRQ... works.

[    0.277879] Using local APIC timer interrupts.
but ... in all likelyhood it's some ACPI side-effects of the

acpi_use_timer_override flag, not really this IO-APIC/timer-setup detail

that matters.
	Ingo

--