Bug 381331

Summary: Kernel stack trace and irq problems when running "compiz-manager"
Product: [Fedora] Fedora Reporter: David Campbell <david>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 8CC: chris.brown, quantumburnz, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-22 21:15:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Campbell 2007-11-14 00:25:42 UTC
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

Comment 1 Christopher Brown 2008-02-13 22:05:11 UTC
Hello David,

Looks like I found one you didn't CC me into! :)

Are you still having problems here?

Comment 2 Christopher D. Stover 2008-10-22 21:15:19 UTC
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.