Bug 16850

Summary: Spurious "No irq handler for vector" kernel warnings
Product: DRI Reporter: Nikos Chantziaras <realnc>
Component: DRM/otherAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
xorg.conf
none
dmesg
none
.config none

Description Nikos Chantziaras 2008-07-25 14:04:21 UTC
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?
Comment 1 Nikos Chantziaras 2008-07-25 14:05:10 UTC
Created attachment 17897 [details]
Xorg.0.log
Comment 2 Nikos Chantziaras 2008-07-25 14:06:55 UTC
Created attachment 17898 [details]
xorg.conf
Comment 3 Michel Dänzer 2008-07-26 04:05:37 UTC
It would probably be good to confirm from the kernel side first what exactly this message means/indicates. Can you do that Nikos?
Comment 4 Nikos Chantziaras 2008-07-26 13:49:01 UTC
(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
Comment 5 Nikos Chantziaras 2008-07-26 23:21:09 UTC
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.
Comment 6 Nikos Chantziaras 2008-07-27 03:02:14 UTC
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.)
Comment 7 Nikos Chantziaras 2008-07-27 03:05:16 UTC
Created attachment 17911 [details]
dmesg
Comment 8 Nikos Chantziaras 2008-07-27 03:05:39 UTC
Created attachment 17912 [details]
.config
Comment 9 Michel Dänzer 2008-07-28 00:45:28 UTC
(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.
Comment 10 Nikos Chantziaras 2008-07-28 16:10:17 UTC
(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.
Comment 11 Nikos Chantziaras 2008-08-26 10:41:55 UTC
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.