AAAGGHH! I'm glad I found this bug, this problem has been driving me crazy for a
couple of days now. This bug is preventing me from using the latest compiz+aiglx
code along with suspend-to-ram/disk. The original report says USB devices don't
work, but it's anything on IRQ 11: for me this includes the CardBus controller,
sound, and most annoyingly, both the wired and wireless network controllers
(e100 and ipw2200, respectively). My USB Wacom tablet works, but it's very
dodgy--the pointer moves in fits and starts, usually my first sure sign after
waking up from a suspend that this bug has bit again. I suspect that the XInput
wacom driver is accessing it from userspace somehow and that's why it works at
all, but I have no idea.

Is this fixed by any change in the real 2.6.16? I added a fix to disable the
interrupts properly on irq uninstall which I think is what happens on vt switch..

No, sorry. I tried suspending (which does a VT switch) on a vanilla 2.6.16:

Apr 21 09:22:56 r51 kernel: irq 11: nobody cared (try booting with the "irqpoll"
option)
Apr 21 09:22:56 r51 kernel:  [__report_bad_irq+43/105] __report_bad_irq+0x2b/0x69
Apr 21 09:22:56 r51 kernel:  [note_interrupt+452/499] note_interrupt+0x1c4/0x1f3
Apr 21 09:22:56 r51 kernel:  [handle_IRQ_event+32/76] handle_IRQ_event+0x20/0x4c
Apr 21 09:22:56 r51 kernel:  [__do_IRQ+141/205] __do_IRQ+0x8d/0xcd
Apr 21 09:22:56 r51 kernel:  [do_IRQ+25/36] do_IRQ+0x19/0x24
Apr 21 09:22:56 r51 kernel:  [common_interrupt+26/32] common_interrupt+0x1a/0x20
Apr 21 09:22:56 r51 kernel:  [__do_softirq+44/125] __do_softirq+0x2c/0x7d
Apr 21 09:22:56 r51 kernel:  [do_softirq+34/38] do_softirq+0x22/0x26
Apr 21 09:22:56 r51 kernel:  [irq_exit+41/52] irq_exit+0x29/0x34
Apr 21 09:22:56 r51 kernel:  [do_IRQ+30/36] do_IRQ+0x1e/0x24
Apr 21 09:22:57 r51 kernel:  [common_interrupt+26/32] common_interrupt+0x1a/0x20
Apr 21 09:22:57 r51 kernel:  [__copy_from_user_ll+217/226]
__copy_from_user_ll+0xd9/0xe2
Apr 21 09:22:57 r51 kernel:  [sys_vm86old+51/139] sys_vm86old+0x33/0x8b
Apr 21 09:22:57 r51 kernel:  [setup_apic_nmi_watchdog+86/534]
setup_apic_nmi_watchdog+0x56/0x216
Apr 21 09:22:57 r51 kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Apr 21 09:22:57 r51 kernel: handlers:
Apr 21 09:22:57 r51 kernel: [pg0+805436507/1070175232] (usb_hcd_irq+0x0/0x54
[usbcore])
Apr 21 09:22:57 r51 last message repeated 3 times
Apr 21 09:22:57 r51 kernel: [pg0+806346243/1070175232] (yenta_interrupt+0x0/0xb5
[yenta_socket])
Apr 21 09:22:57 r51 kernel: [pg0+807019385/1070175232]
(snd_intel8x0_interrupt+0x0/0x1c3 [snd_intel8x0m])
Apr 21 09:22:57 r51 kernel: [pg0+807580575/1070175232] (ipw_isr+0x0/0xbb [ipw2200])
Apr 21 09:22:57 r51 kernel: [pg0+806427244/1070175232]
(snd_intel8x0_interrupt+0x0/0x1d2 [snd_intel8x0])
Apr 21 09:22:57 r51 kernel: Disabling IRQ #11

I just tried 2.6.17-rc2 where the same error happens.

Hi! Great news: changing the line

Option "VBERestore" "true"

to

Option "VBERestore" "false"

in xorg.conf made the problem go away. I have succesfully chvt'd away and back a
few times without IRQ 11 blowing up on me. This is with stock i915.ko version
1.4.0 from kernel 2.6.16.

My i810 driver is version 1.6.0, this is newer than what is available in both
official Debian (I'm running unstable) and Ubuntu channels--it seems needed for
the latest AIGLX and Compiz eyecandy goodness. I mention this because I think in
some versions of the i810 driver the logic of the VBERestore option is inverted.

yeah the bios code must confuse the interrupt handling somehow.. we'll just have
to wait for non-VBE modesetting etc... unless alanh can figure a way around it...

Using 

Option "VBERestore" "false"

is the same as not having the option at all - and that's the default.

So I'm not sure why you have the option as "true" in the first place as that
should only be used in rare circumstances of VT switching not restoring the console.

Closing as it's a known issue with VBERestore.