Created attachment 37442 [details] [review] Xorg log file Since I’ve started using my RV730 (HD4670) card and the r600 driver with it I am frequently experiencing sudden slowdowns in window handling. Both window switching as well as resizing becomes really laggy and so far I had to resort to restarting my system to circumvent this. Here’s an example from dmesg as soon as this happens: [22020.840240] irq 17: nobody cared (try booting with the "irqpoll" option) [22020.840247] Pid: 2926, comm: /usr/bin/deluge Not tainted 2.6.35-rc6-amd64 #1 [22020.840249] Call Trace: [22020.840252] <IRQ> [<ffffffff8108c4bd>] ? __report_bad_irq+0x30/0x7d [22020.840262] [<ffffffff8108c611>] ? note_interrupt+0x107/0x16e [22020.840266] [<ffffffff8108cd34>] ? handle_fasteoi_irq+0x96/0xb7 [22020.840270] [<ffffffff8100af04>] ? handle_irq+0x17/0x1f [22020.840273] [<ffffffff8100a5c6>] ? do_IRQ+0x54/0xb9 [22020.840277] [<ffffffff812fcb53>] ? ret_from_intr+0x0/0x11 [22020.840279] <EOI> [<ffffffff81238a13>] ? acpi_pm_read+0x7/0xd [22020.840288] [<ffffffff8106286f>] ? ktime_get_ts+0x66/0xab [22020.840291] [<ffffffff8105a17d>] ? posix_ktime_get_ts+0xc/0x11 [22020.840295] [<ffffffff8105ad24>] ? sys_clock_gettime+0x53/0x93 [22020.840298] [<ffffffff810785f9>] ? compat_sys_clock_gettime+0x2e/0x79 [22020.840302] [<ffffffff81031342>] ? ia32_sysret+0x0/0x5 [22020.840304] handlers: [22020.840306] [<ffffffffa06a8c9c>] (radeon_driver_irq_handler_kms+0x0/0x1c [radeon]) [22020.840341] Disabling IRQ #17 Even the latest Git master I was pointed at in IRC did not yield any difference. I have also tried pci=noacpi but except of different IRQ numbering nothing did change. Please let me know what kind of other information you need.
Please attach your dmesg as well. Does booting with pci=nomsi help?
Created attachment 37443 [details] Dmesg log
(In reply to comment #1) > Does booting with pci=nomsi help? No. Started that way yesterday evening and just now both the interrupts for my sound card as well as my graphics card where disabled. I was giving xvinv3d a go at that time if that matters.
Today I tried using UMS instead and got pretty much the same error while playing Torus Trooper. However, window switching and resizing remains quick: [ 3800.874875] irq 17: nobody cared (try booting with the "irqpoll" option) [ 3800.874882] Pid: 0, comm: swapper Not tainted 2.6.35-rc6-amd64 #1 [ 3800.874885] Call Trace: [ 3800.874887] <IRQ> [<ffffffff8108c4bd>] ? __report_bad_irq+0x30/0x7d [ 3800.874898] [<ffffffff8108c611>] ? note_interrupt+0x107/0x16e [ 3800.874902] [<ffffffff8108cd34>] ? handle_fasteoi_irq+0x96/0xb7 [ 3800.874906] [<ffffffff8100af04>] ? handle_irq+0x17/0x1f [ 3800.874909] [<ffffffff8100a5c6>] ? do_IRQ+0x54/0xb9 [ 3800.874913] [<ffffffff812fcb53>] ? ret_from_intr+0x0/0x11 [ 3800.874915] <EOI> [<ffffffff8102670c>] ? native_safe_halt+0x2/0x3 [ 3800.874923] [<ffffffff8100f999>] ? default_idle+0x31/0x4e [ 3800.874926] [<ffffffff8100faad>] ? c1e_idle+0xf7/0xfb [ 3800.874931] [<ffffffff81007b5d>] ? cpu_idle+0xa3/0xdd [ 3800.874935] [<ffffffff812f65d6>] ? start_secondary+0x1ed/0x1f3 [ 3800.874938] handlers: [ 3800.874939] [<ffffffffa06140d3>] (radeon_driver_irq_handler+0x0/0x139 [radeon]) [ 3800.874972] Disabling IRQ #17
(In reply to comment #4) > Today I tried using UMS instead and got pretty much the same error while > playing Torus Trooper. However, window switching and resizing remains quick: Not sure what's going on here. UMS doesn't enable interrupts on r6xx/r7xx chips.
Created attachment 37534 [details] Xorg log with UMS Here’s the current Xorg log file. Apparently IRQ #17 is taken by the DMA controller which is not mentioned with KMS.
(In reply to comment #6) > Here’s the current Xorg log file. Apparently IRQ #17 is taken by the DMA > controller which is not mentioned with KMS. According to a comment on top of the radeon_driver_irq_handler() function this is not really true and "just a hangover from dri prehistory". Still no real clue here. According to kernel/irq/spurious.c in the kernel source tree this can only happen if "unlikely(desc->irqs_unhandled > 99900)" which I understand in that way that too little IRQs where unhandled. Does not make any sense to me.
(In reply to comment #7) > Still no real clue here. According to kernel/irq/spurious.c in the kernel > source tree this can only happen if "unlikely(desc->irqs_unhandled > 99900)" > which I understand in that way that too little IRQs where unhandled. Does not > make any sense to me. Maybe we could also ask a kernel developer about this?
(In reply to comment #8) > > Maybe we could also ask a kernel developer about this? File a kernel bug: https://bugzilla.kernel.org/ This doesn't look like a radeon driver issue.
(In reply to comment #9) > (In reply to comment #8) > > > > Maybe we could also ask a kernel developer about this? > > File a kernel bug: https://bugzilla.kernel.org/ > This doesn't look like a radeon driver issue. It is possible that this does not occur with kernel 2.6.36 RC6 anymore. I cannot tell for sure though due to a different more grave issue: I get sudden freezes and immediate restarts on certain events. Namely using the "gl" output driver for mplayer and switching Flash videos to fullscreen having hardware acceleration enabled. It seems to me that OpenGL is the common factor here. I was not able to find anything useful in /var/log, most likely due to the suddenness of the restart. Do you think that this one is also related to the kernel? Admittedly I haven’t experienced something like this ever before. I’d be glad to provide more info granted that I am able to retrieve it somehow.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > > > > Maybe we could also ask a kernel developer about this? > > > > File a kernel bug: https://bugzilla.kernel.org/ > > This doesn't look like a radeon driver issue. > > It is possible that this does not occur with kernel 2.6.36 RC6 anymore. I > cannot tell for sure though due to a different more grave issue: I get sudden > freezes and immediate restarts on certain events. Namely using the "gl" output > driver for mplayer […] Not exactly the "-vo gl" is the issue but usage of "-dr". If I omit this, I can play videos with the "gl" output just fine. If I add it I get sudden restarts again. Now I am puzzled: is this an issue with mplayer, radeon or the kernel? The former is not really likely because as I said, I experience the same issue with accelerated output in the Adobe Flash plugin.
Just FYI: one of the recent commits must have fixed even this issue. I get no crashes at all anymore and can play any video just fine. Whoever is responsible for fixing this can be assured to have my gratitude. :-)
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.