I am experiencing an issue with the radeon kernel driver in relation to an external audio device (Edirol FA-101). The device is driven by Jack/FFADO (http://ffado.org) connected to a TI pcmcia firewire card, and running into a TI cardbus controller. I have reported this problem to the ffado-users mailing-list and you can see the thread archived here: http://sourceforge.net/mailarchive/message.php?msg_id=29666161 I have previously used the device on a dedicated and infrequently updated debian linux partition, which was running stable for a long time. Unfortunately this setup was lost to a failing disk, and now I am attempting to run the device on an up-to-date archlinux distribution. The bug basically causes a loss in sync between the streaming server (Jack/FFADO) and the system bus when there is a certain kind of 2d-graphic update. I have tested this against as many kernels as possible and the last working kernel is the 2.6.32-lts distributed by archlinux. The first kernel that I can install where this bug appears is 2.6.34 (2.6.33 fails to boot because it was not compiled with DEVTMPFS support, and attempts to compile it failed as there are numerous incompatibilities with later gcc versions). The most optimum environment is using the usb-live distro 'pure:dyne' (ubuntu based) which is running 2.6.31 (RT PREEMPT) - this probably most closely replicates the performance I had previously. The bug occurs when audio is streaming to the device, and there is an update to a 2D window, it is not the case with all 2D software, only some. Some scenerios where I can demonstrate this bug include: Resizing window geometry (any window). Typing a message in Evolution (GTK), each new line creates a dropout. Repeated updates to Xorg/XTerm ('cat /var/log/messages' or 'top') Various manipulations to the software Fontforge (internal toolkit) Moving objects around a canvas in Pure Data (TCL/TK). Pure Data is the software I typically use for DSP processing, so it's frustrating that it has such a profound effect, doing any basic manipulation to the window makes the bug appear regardless of if it's running a DSP chain or not (the software can be run without audio). This led me to test TCL/TK, and it can create a full dropout and disconnect of the streaming server just by running a small repeating canvas animation found here: http://wiki.tcl.tk/4293 A lot of other software seems to peacefully coexist - drawing with gimp or inkscape, performing 3d compositing by gnome-shell, browsing in firefox or chromium - all quite demanding tasks graphically - no dropouts. I have found that switching off KMS (radeon.modeset=0) improves the situation, with the dropouts (XRUNS) no longer being reported by Jack/FFADO but there is still tearing in the audio itself, and all 2d functions run quite sluggishly with KMS switched off. I have attempted the following kernel settings without any improvements. radeon.disp_priority=1 radeon.msi=0 video=LVDS-1:640x480 threadirqs I'll attach as many related logs as possible, but please let me know what might be useful to debug.
Created attachment 65676 [details] dmesg - working kernel 2.6.31-9
Created attachment 65677 [details] lsmod - working kernel 2.6.31-9
Created attachment 65678 [details] lspci - working kernel 2.6.31-9
Created attachment 65679 [details] Xorg.0.log - working kernel 2.6.31-9
Created attachment 65680 [details] dmesg - earliest broken kernel 2.6.34
Created attachment 65681 [details] lsmod - earliest broken kernel 2.6.34
Created attachment 65682 [details] Xorg.0.log - earliest broken kernel 2.6.34
Created attachment 65684 [details] output of the FFADO diagnostic utility (ffado-diag) - earliest broken kernel 2.6.34
Created attachment 65686 [details] output of the jack/FFADO session running against a small TCL/TK animation
I forgot to mention that this issue can not be replicated using jack/alsa with the internal soundcard. This problem does not pertain to sound in general or to jack specifically, it only occurs connecting to the firewire device (through jack/FFADO - which is the only way of getting I/O to and from the device). Changing the periods (latency) or samplerate of the jack server has no effect.
Maybe and EMI issue? Does changing the clock on the radeon chip help? E.g., select a different power state? echo mid > /sys/class/drm/card0/device/power_profile Also can you try disabling the LVDS panel and using only an external monitor? You can also try setting: Option "NoAccel" "True" in the device section of your xorg.conf and see if that helps.
(In reply to comment #11) > Maybe and EMI issue? Does changing the clock on the radeon chip help? E.g., > select a different power state? > echo mid > /sys/class/drm/card0/device/power_profile No change > Also can you try disabling the LVDS panel and using only an external monitor? Sorry, no external monitor here. > You can also try setting: > Option "NoAccel" "True" This works and without any noticeable tearing or clipping. No hardware acceleration but this is working better than disabling KMS.
(In reply to comment #12) > > You can also try setting: > > Option "NoAccel" "True" > > This works and without any noticeable tearing or clipping. No hardware > acceleration but this is working better than disabling KMS. It might be bandwidth contention. The GPU pushes a lot of data around.
(In reply to comment #13) > (In reply to comment #12) > > > You can also try setting: > > > Option "NoAccel" "True" > > > > This works and without any noticeable tearing or clipping. No hardware > > acceleration but this is working better than disabling KMS. > > It might be bandwidth contention. The GPU pushes a lot of data around. Sure, but why specifically in circumstances where the redrawing is limited to 2D and only with a few ui toolkits? I don't experience the dropouts when gnome-shell is doing its fancy transitions and compositing or using a sophisticated canvas tool like gimp, only with what seem like quite crude and unsophisticated renderings - cat in a xterm for example?
(In reply to comment #14) > Sure, but why specifically in circumstances where the redrawing is limited to > 2D and only with a few ui toolkits? I don't experience the dropouts when > gnome-shell is doing its fancy transitions and compositing or using a > sophisticated canvas tool like gimp, only with what seem like quite crude and > unsophisticated renderings - cat in a xterm for example? Might be operations that cause software fallbacks and hence push a lot of data across the bus.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/36.
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.