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