Description of problem: I find that if I run the "compiz-manager" command, most of the time, the kernel immediately logs a stack trace and the system becomes unusable such that I have to power it off and reboot. Version-Release number of selected component (if applicable): 2.6.23.1-49.fc8 and 2.6.23.1-42.fc8 How reproducible: Gets kernel stack trace every time, but system locks up most times Steps to Reproduce: 1. Login to desktop environment 2. Run compiz-manager from commandline 3. Observe message from kernel and peruse dmesg Actual results: [dcampbel@localhost ~]$ compiz-manager Checking for Xgl: not present. Detected PCI ID for VGA: 01:00.0 0300: 1002:4e50 (prog-if 00 [VGA]) Checking for texture_from_pixmap: not present. Trying again with indirect rendering: Checking for texture_from_pixmap: present. Checking for non power of two support: present. Checking for Composite extension: present. Comparing resolution (1680x1050) to maximum 3D texture size (2048): Passed. Checking for nVidia: not present. Checking for FBConfig: present. Checking for Xgl: not present. Starting gtk-window-decorator Message from syslogd@localhost at Nov 14 08:49:41 ... kernel: Disabling IRQ #17 Then if you look at the dmesg: irq 17: nobody cared (try booting with the "irqpoll" option) [<c045b106>] __report_bad_irq+0x36/0x75 [<c045b31c>] note_interrupt+0x1d7/0x213 [<c045a7a3>] handle_IRQ_event+0x23/0x51 [<c045baa7>] handle_fasteoi_irq+0x86/0xa6 [<c045ba21>] handle_fasteoi_irq+0x0/0xa6 [<c04074c3>] do_IRQ+0x8c/0xb9 [<c0405b6f>] common_interrupt+0x23/0x28 ======================= handlers: [<f8a4ff9e>] (snd_intel8x0_interrupt+0x0/0x1a3 [snd_intel8x0m]) Disabling IRQ #17 Expected results: Should work properly without getting kernel stacktraces Additional info: Using the irqpoll option to the kernel does work around this
Hello David, Looks like I found one you didn't CC me into! :) Are you still having problems here?
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED: INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.