Micha Feigin wrote:
> On Sun, Feb 01, 2004 at 02:48:28AM +0100, Prakash K. Cheemplavam wrote:
> 
>>This happened once with rc-1 vanilla and once with rc-3 (haven't used 
>>rc2 long enough.) Never happened with a earlier kernel. The message 
>>repeats eternally itself making the system next to unusuable.
>>
>>Any idea how to fix it?
>>
>>I am using siimage ide driver.
>>
>>Prakash
>>
>>Feb  1 02:34:48 tachyon handlers:
>>Feb  1 02:34:48 tachyon [<c02a6b50>] (ide_intr+0x0/0x190)
>>Feb  1 02:34:48 tachyon [<c03248c0>] (snd_intel8x0_interrupt+0x0/0x210)
>>Feb  1 02:34:48 tachyon Disabling IRQ #11
>>Feb  1 02:34:48 tachyon irq 11: nobody cared!
> 
> 
> This irq message has been reported by several people (including me), I
> don't think there is a solution yet. AFAIK its not swsusp related.

Yes, it is NOT swsusp related.

> 
>>Feb  1 02:34:48 tachyon Call Trace:
>>Feb  1 02:34:48 tachyon [<c010b0aa>] __report_bad_irq+0x2a/0x90
>>Feb  1 02:34:48 tachyon [<c010b19c>] note_interrupt+0x6c/0xb0
>>Feb  1 02:34:48 tachyon [<c010b451>] do_IRQ+0x121/0x130
>>Feb  1 02:34:48 tachyon [<c0109854>] common_interrupt+0x18/0x20
>>Feb  1 02:34:48 tachyon [<c0124080>] do_softirq+0x40/0xa0
>>Feb  1 02:34:48 tachyon [<c010b42d>] do_IRQ+0xfd/0x130
>>Feb  1 02:34:48 tachyon [<c0109854>] common_interrupt+0x18/0x20
>>Feb  1 02:34:48 tachyon [<c0281056>] generic_unplug_device+0x26/0x80
>>Feb  1 02:34:48 tachyon [<c028121a>] blk_run_queues+0x7a/0xb0
>>Feb  1 02:34:48 tachyon [<c016605f>] __wait_on_buffer+0xbf/0xd0
>>Feb  1 02:34:48 tachyon [<c011e1c0>] autoremove_wake_function+0x0/0x50
>>Feb  1 02:34:48 tachyon [<c011e1c0>] autoremove_wake_function+0x0/0x50
>>Feb  1 02:34:48 tachyon [<c020dbb8>] submit_logged_buffer+0x38/0x60
>>Feb  1 02:34:48 tachyon [<c020e1a3>] kupdate_one_transaction+0x1b3/0x210
>>Feb  1 02:34:48 tachyon [<c020e275>] reiserfs_journal_kupdate+0x75/0xb0
>>Feb  1 02:34:48 tachyon [<c0210ed4>] flush_old_commits+0x144/0x1d0
>>Feb  1 02:34:48 tachyon [<c0122583>] do_exit+0x293/0x500
>>Feb  1 02:34:48 tachyon [<c01fe942>] reiserfs_write_super+0x82/0x90
>>Feb  1 02:34:48 tachyon [<c016b94c>] sync_supers+0xac/0xc0
>>Feb  1 02:34:48 tachyon [<c014b526>] wb_kupdate+0x36/0x120
>>Feb  1 02:34:48 tachyon [<c02602d3>] tty_write+0x1d3/0x3f0
>>Feb  1 02:34:48 tachyon [<c026008e>] tty_read+0x18e/0x200
>>Feb  1 02:34:48 tachyon [<c011c86d>] schedule+0x31d/0x590
>>Feb  1 02:34:48 tachyon [<c01214c0>] reparent_to_init+0xf0/0x180
>>Feb  1 02:34:48 tachyon [<c014bb4b>] __pdflush+0xcb/0x1b0
>>Feb  1 02:34:48 tachyon [<c014bc30>] pdflush+0x0/0x20
>>Feb  1 02:34:48 tachyon [<c014bc3f>] pdflush+0xf/0x20
>>Feb  1 02:34:48 tachyon [<c014b4f0>] wb_kupdate+0x0/0x120
>>Feb  1 02:34:48 tachyon [<c0107284>] kernel_thread_helper+0x0/0xc
>>Feb  1 02:34:48 tachyon [<c0107289>] kernel_thread_helper+0x5/0xc
>>Feb  1 02:34:48 tachyon
> 
> 
> I didn't check it in the kernel but at first sight it looks like
> regular disks updates. I don't know what it goes into a loop. Are you
> sure that you don't have something that keeps updating the disk?

Nope, as I investigated further: I tried using libata and then rc3 
already hang at boot - just after libata init - with above (or similar) 
oops. rc2 did the same. Only rc1 did boot and I am currently using it to 
see ho far it goes.

So there seems to be some serious issue since 2.6.2-rc2 going on. Maybe 
some ACPI related update?

I attached my .config, in case if it of interest.

Prakash