Hi Christopher, the apport-collected data above was gathered from my main desktop, which only has Intel graphics. (I mentioned the other system with Radeon just because it *didn’t* suffer from this problem despite having the same software. I no longer have access to that system so unfortunately I can’t provide the same logs from it for comparision.)

Since upgrading HWE from -lts-saucy to -lts-trusty, I have had recurring graphical glitches on screen, with short black horizontal lines appearing briefly on screen (on top of normal contents), particularly when switching between applications. The lines appear only for a few 100 ms before going away (just enough to register in your eye that there’s something there), so I’ve been trying to make a screen recording to capture it, but of course the phenomenon goes away when I do (perhaps RecordMyDesktop does something with the screen that makes it less likely to appear).

I have another 12.04 system with desktop Radeon graphics, and there -lts-trusty has not produced this issue so far (the one with the issue and the one I’m attaching the logs here from has Intel).

I don’t recall seeing this with -lts-saucy or other previous Xorg packages. It was so obvious right after upgrading that either it never occurred before or was so rare or quick to flash away that it didn’t register.

I’ve just had a GPU lockup with 3.3.0-030300rc4-generic. Would this be yet another issue (i.e. not this bug nor bug #938894)? If so, where (if anywhere) should I file it? I’m pasting below here what was in syslog about it.

Feb 26 19:53:38 saegusa kernel: [ 8031.040107] radeon 0000:01:05.0: GPU lockup CP stall for more than 419884msec
Feb 26 19:53:38 saegusa kernel: [ 8031.040113] GPU lockup (waiting for 0x00103023 last fence id 0x00103022)
Feb 26 19:53:38 saegusa kernel: [ 8031.040125] [drm] Disabling audio support
Feb 26 19:53:38 saegusa kernel: [ 8031.041548] radeon 0000:01:05.0: GPU softreset
Feb 26 19:53:38 saegusa kernel: [ 8031.041550] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xA0003030
Feb 26 19:53:38 saegusa kernel: [ 8031.041551] radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003
Feb 26 19:53:38 saegusa kernel: [ 8031.041553] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20000040
Feb 26 19:53:38 saegusa kernel: [ 8031.041559] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00007FEE
Feb 26 19:53:38 saegusa kernel: [ 8031.056444] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00000001
Feb 26 19:53:38 saegusa kernel: [ 8031.072335] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xA0003030
Feb 26 19:53:38 saegusa kernel: [ 8031.072337] radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003
Feb 26 19:53:38 saegusa kernel: [ 8031.072339] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20008040
Feb 26 19:53:38 saegusa kernel: [ 8031.073333] radeon 0000:01:05.0: GPU reset succeed
Feb 26 19:53:38 saegusa kernel: [ 8031.094096] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
Feb 26 19:53:38 saegusa kernel: [ 8031.094153] radeon 0000:01:05.0: WB enabled
Feb 26 19:53:38 saegusa kernel: [ 8031.094156] [drm] fence driver on ring 0 use gpu addr 0xa0000c00 and cpu addr 0xffff88020f609c00
Feb 26 19:53:38 saegusa kernel: [ 8031.127631] [drm] ring test on 0 succeeded in 1 usecs
Feb 26 19:53:38 saegusa kernel: [ 8031.127656] [drm] ib test on ring 0 succeeded in 1 usecs
Feb 26 19:53:38 saegusa kernel: [ 8031.127659] [drm] Enabling audio support

While waiting for this to reoccur, now that I came to think of it: I have radeon.audio=1 on my kernel parameters due to Bug #864735. Radeon audio is considered too buggy by developers to be enabled by default, so my force-enabling it definitely makes it a suspect here.

Hi David, thanks for responding. I tested fglrx just now and every time I launched VLC with audio, or in this case even Totem with audio, the X session went boom right before any sound came out. So if you meant ”does it work without tsched=0 when using fglrx”, I guess the answer is no. I’ll attach the X log, although this crash is probably unrelated to this report. (I only use the free drivers myself so I won’t bother to report this separately. It was pretty consistent and should be easily reproducible though.)

I didn’t know whether the radeon.audio=1 kernel parameter matters when fglrx is in use, so I tried both with it and without it, with the same result (X crash).

The only thing audiowise that didn’t crash the session was PA’s speaker test (from the audio settings). It didn’t make any sound either though.

Luckily, enabling Radeon audio in the kernel hasn’t given me any problems on this setup, at least such that I could link to it. I do have Bug #917668 filed in, but it’ll have to reoccur to get more data to see if that’s connected.

Note to others here suffering from this with Radeon HDMI only as I am: as per @David’s comments, I’ve just filed Bug #927323 about this.

Bug #751265 describes the symptom: when VLC uses Pulseaudio for audio output, the sound from it becomes garbled after playing for a while, with heavy digital artefacts and echoing. Comment #23 in that report suggests modifying /etc/pulse/default.pa so that load-module module-udev-detect is followed by tsched=0. I’ve done that, and with it VLC seems to work fine with Pulseaudio. Furthermore, in comment #30 @David Henningsson prompted us suffering from this and with the tsched=0 workaround working to file our own reports for each specific hardware. This is my report.

I believe apport adds data about the hardware automatically. I’ll add to that that for me this only occurs with the Radeon HDMI output; through the analog output (via headphones) the audio works fine. As Bug #864735 describes, Radeon audio is off by default in recent kernels, but I’ve re-enabled it by passing the radeon.audio=1 kernel commandline parameter.

If I switch to ALSA output for VLC (without tsched=0), VLC audio goes mute after a while. After some time of silence it sort of fast forwards itself to get up to sync with the video again. This keeps repeating, so it’s not really a workaround.

@David: I have this bug but only with HDMI output from my gfx adapter. #23 works here, so as per your #30 I’m about to file a separate bug, but would the driver at fault in this case be for the underlying (Intel) sound card or for the (Radeon) display adapter? Audio coming through analog (headphones) never crackles.

I can confirm the bug and the workaround both hold on an up-to-date Precise system with a Radeon HD 3200.