do_IRQ: 0.83/0.84 No irq handler for vector

do_IRQ: 0.83/0.84 No irq handler for vector

[Nikos Chantziaras]

Hello list.

Kernel 2.6.26 (on x86-64) gives "do_IRQ: 0.83 No irq handler for vector" 
(and "do_IRQ: 0.83", but less often) warnings periodically.  It seems 
that the kernel's Radeon DRM driver is at fault, or at least involved 
(no warnings on a kernel without Radeon DRM).  The hardware in question 
is an R580 chip (AFAIK, R500 support was introduced with 2.6.26).

The "do_IRQ: 0.83" warning is 100% reproducible when switching from X 
(xf86-video-ati 6.9.0) to a console (vesafb):

   [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

When enabling 3D (compiz fusion) this happens:

   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

Some apps (glxgears) report the following when they try to do vertical 
synchronization (vblank_mode 1):

   do_wait: drmWaitVBlank returned -1, IRQs don't seem
   to be working correctly.

(the result is that vsync doesn't work as intended and rendering speed 
gets locked at exactly 0.333 FPS).

Of course I filed a bug on X.Org's bugzilla first 
(http://bugs.freedesktop.org/show_bug.cgi?id=16850), but it is not clear 
what exactly this warning means and I'm not sure if it's a problem with 
the kernel's DRM driver or with X.Org (or both.)

Re: do_IRQ: 0.83/0.84 No irq handler for vector

[Nikos Chantziaras]

Nikos Chantziaras wrote:
> Hello list.
> 
> Kernel 2.6.26 (on x86-64) gives "do_IRQ: 0.83 No irq handler for vector" 
> (and "do_IRQ: 0.83", but less often) warnings periodically.  It seems 
> that the kernel's Radeon DRM driver is at fault, or at least involved 
> (no warnings on a kernel without Radeon DRM).

Sorry, I'll take that back.  It does happen even when compiling 
completely without DRM, so it's probably not related to DRM at all.

Re: do_IRQ: 0.83/0.84 No irq handler for vector

[Nikos Chantziaras]

Nikos Chantziaras wrote:
> Kernel 2.6.26 (on x86-64) gives "do_IRQ: 0.83 No irq handler for vector" 
> (and "do_IRQ: 0.83", but less often) warnings periodically.

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.)

In case someone needs it, this is my complete dmesg:

   http://realnc.pastebin.com/d6534029

and this is the kernel configuration: 
http://bugs.freedesktop.org/attachment.cgi?id=17912

Re: do_IRQ: 0.83/0.84 No irq handler for vector

[Robert Hancock]

Nikos Chantziaras wrote:
> Nikos Chantziaras wrote:
>> Kernel 2.6.26 (on x86-64) gives "do_IRQ: 0.83 No irq handler for 
>> vector" (and "do_IRQ: 0.83", but less often) warnings periodically.
> 
> 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.)
> 
> In case someone needs it, this is my complete dmesg:
> 
>   http://realnc.pastebin.com/d6534029
> 
> and this is the kernel configuration: 
> http://bugs.freedesktop.org/attachment.cgi?id=17912

My guess is some device is that some device is generating MSI interrupts 
without any handler being registered for it, and with MSI support 
disabled it now generates a master abort instead. Most likely whatever 
device is connected to the Bus=00h, Device=02h, Function=00h bridge. Can 
you post "lspci -vv" output?

Re: do_IRQ: 0.83/0.84 No irq handler for vector

[Nikos Chantziaras]

Robert Hancock wrote:
> Nikos Chantziaras wrote:
>> Nikos Chantziaras wrote:
>>> Kernel 2.6.26 (on x86-64) gives "do_IRQ: 0.83 No irq handler for 
>>> vector" (and "do_IRQ: 0.83", but less often) warnings periodically.
>>
>> 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.)
>>
>> In case someone needs it, this is my complete dmesg:
>>
>>   http://realnc.pastebin.com/d6534029
>>
>> and this is the kernel configuration: 
>> http://bugs.freedesktop.org/attachment.cgi?id=17912
> 
> My guess is some device is that some device is generating MSI interrupts 
> without any handler being registered for it, and with MSI support 
> disabled it now generates a master abort instead. Most likely whatever 
> device is connected to the Bus=00h, Device=02h, Function=00h bridge. Can 
> you post "lspci -vv" output?

The device in question is my graphics card (an AMD/ATI Radeon X1950XT 
PCI-e):

02:00.0 VGA compatible controller: ATI Technologies Inc R580 [Radeon 
X1900] (prog-if 00 [VGA controller])
02:00.1 Display controller: ATI Technologies Inc Unknown device 7264

02:00.1 should be the card's second head I guess?

Here's the complete lspci -vv: http://realnc.pastebin.com/m6ac97572