Driver: xf86-video-ati 6.9.0 X.Org: 1.4.99.905 Linux kernel: 2.6.26 Hardware: Radeon X1950XT PCI-e (r580) Switching from X to a vesafb console works but produces "do_IRQ" kernel warnings: [drm] Setting GART location based on new memory map [drm] Loading R500 Microcode [drm] Num pipes: 4 [drm] writeback test succeeded in 1 usecs do_IRQ: 0.83 No irq handler for vector do_IRQ: 0.83 No irq handler for vector do_IRQ: 0.83 No irq handler for vector This is 100% reproducible when switching to a console. No warnings when switching back to X. When enabling compiz-fusion (it works), the same warnings appear but more often plus a new "__ratelimit: 5 messages suppressed" warning: do_IRQ: 0.83 No irq handler for vector do_IRQ: 0.83 No irq handler for vector [repeated 8 more times] __ratelimit: 5 messages suppressed do_IRQ: 0.83 No irq handler for vector do_IRQ: 0.83 No irq handler for vector My Xorg.0.log: http://realnc.pastebin.com/m28ee9247 My xorg.conf: http://realnc.pastebin.com/m134032cc (I'm also attaching them.) Furthermore, trying to enable v-sync (vblank_mode 1) results in this error when trying to run glxgears: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. glxgears "runs", but with sub-1FPS speed: 3 frames in 6.0 seconds = 0.500 FPS 2 frames in 6.0 seconds = 0.333 FPS 2 frames in 6.0 seconds = 0.333 FPS 2 frames in 6.0 seconds = 0.333 FPS 2 frames in 6.0 seconds = 0.333 FPS Should I open a new bug for this one?
Created attachment 17897 [details] Xorg.0.log
Created attachment 17898 [details] xorg.conf
It would probably be good to confirm from the kernel side first what exactly this message means/indicates. Can you do that Nikos?
(In reply to comment #3) > It would probably be good to confirm from the kernel side first what exactly > this message means/indicates. Can you do that Nikos? Just posted: http://thread.gmane.org/gmane.linux.kernel/712176
I just went on and completely disabled DRM in the kernel and loaded the proprietary fglrx driver instead to see what happens. The warnings still appear. It seems it's entirely a kernel issue? Note that this does not happen with 2.6.25 kernels. I will try to build some 2.6.26 ones with various config options and see if a specific option is responsible for this.
I've made a bit of progress. I changed the kernel config: - CONFIG_PCI_MSI=y + # CONFIG_PCI_MSI is not set In other words I disabled Message Signaled Interrupt support. Now instead of "do_IRQ: 0.83 No irq handler for vector" I get: +------ PCI-Express Device Error ------+ Error Severity : Uncorrected (Non-Fatal) PCIE Bus Error type : Transaction Layer Flow Control Protocol : First Receiver ID : 0010 VendorID=1106h, DeviceID=a208h, Bus=00h, Device=02h, Function=00h Broadcast error_detected message Broadcast mmio_enabled message Broadcast resume message AER driver successfully recovered (Repeated as many times as the "do_IRQ" message previously.) I hope this helps :P Just in case someone needs it, here's the complete dmesg: http://realnc.pastebin.com/d6534029 And here my kernel configuration: http://realnc.pastebin.com/dafc97a2 (I am also attaching those two in case the links disappear.)
Created attachment 17911 [details] dmesg
Created attachment 17912 [details] .config
(In reply to comment #5) > I just went on and completely disabled DRM in the kernel and loaded the > proprietary fglrx driver instead to see what happens. The warnings still > appear. And sync to vblank doesn't work correctly either? > It seems it's entirely a kernel issue? Quite possibly, so I still think it's a good idea to continue tracking it down there first. > Note that this does not happen with 2.6.25 kernels. I will try to build some > 2.6.26 ones with various config options and see if a specific option is > responsible for this. What if you disable CONFIG_PCIEAER? In the worst case, you could try git bisect between 2.6.25 and 2.6.26 to find the change(s) that introduced the problem.
(In reply to comment #9) > (In reply to comment #5) > > I just went on and completely disabled DRM in the kernel and loaded the > > proprietary fglrx driver instead to see what happens. The warnings still > > appear. > > And sync to vblank doesn't work correctly either? I works with fglrx. But not through DRI configuration (vblank_mode). fglrx doesn't allow for that. Rather through Catalyst Control Center. > > Note that this does not happen with 2.6.25 kernels. I will try to build some > > 2.6.26 ones with various config options and see if a specific option is > > responsible for this. > > What if you disable CONFIG_PCIEAER? In the worst case, you could try git bisect > between 2.6.25 and 2.6.26 to find the change(s) that introduced the problem. I'll try CONFIG_PCIEAER when I get back to my machine. As far as I understand it, the problem is that the hardware is doing something the kernel doesn't expect it to do.
This bug has been open long enough. In the end, I was never able to track the cause down, but today I updated to kernel 2.6.26.2, git master of X.Org and git master of xf86-video-ati and it's fixed. So I'm closing this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.