Screen Freeze

Im using openSUSE 12.1 x86_64, with latest stable kernel (3.7.1) and Xorg (xf86-video-ati 7.0.0).
KDE 4.9.4

The thing is, whenever im using Firefox for an extended period of time, i get random screen freezes. The screen freezes but i can still move the mouse and when hovering over links, the arrow changes to a hand, just as usual.
Theres no way of unfreezing the screen, i tried using top on another userspace, but no processes seem to be taking too much resources.

Only thing im left to do, is reboot the computer from the commandline.

Anyone experiencing this issue?

Thanks!

I had issues with nVIDIA, both open source and proprietary drivers, but it seems to have been caused by the VirtualBox 4.2.4 driver, which was then upgraded to 4.2.6 that seemed to fix the issue. I also see some problems with Tumbleweed and kernel 3.7.1, but I compile my own with the SAKC bash script, don’t use Tumbleweed so kernel 3.7.1 is working fine now for me.

Thank You,

After some investigation, I determined likely cause was FF rendering engine, I monitored CPU and RAM usage concluding ample available resuources. Possible anomaly wa intermittent unexplainable VRAM starvation.

I disabled FF hardware acceleration which seems to have resolved.

HTH,
TSU

Indeed, disableing hardware acceleration fixes the issue! Weird bug

Thanks tsu2

On 2012-12-28 03:26, assas1n wrote:
>
> tsu2;2513647 Wrote:
>> After some investigation, I determined likely cause was FF rendering
>> engine, I monitored CPU and RAM usage concluding ample available
>> resuources. Possible anomaly wa intermittent unexplainable VRAM
>> starvation.
>>
>> I disabled FF hardware acceleration which seems to have resolved.
>>

>
> Indeed, disableing hardware acceleration fixes the issue! Weird bug

Firefox hardware accel? Are you sure? Not Flash?

If it is FF, you should report the issue in bugzilla.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

U

Unfortunately just had a freeze with Hardware Acceleracion disabled. Its awfully annoying.

PD: Another freeze, just seconds after rebooting. Opened a picture heavy site on a firefox tab, and freeze.

It appears to be a radeon/kernel bug.

From my /var/logs/messages:

Dec 29 00:46:39 linux-a7dy kernel:   389.898634] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec
Dec 29 00:46:39 linux-a7dy kernel:   389.898638] radeon 0000:01:00.0: GPU lockup (waiting for 0x000000000000334e last fence id 0x000000000000334d)
Dec 29 00:46:39 linux-a7dy kernel:   390.565133] radeon 0000:01:00.0: couldn't schedule ib
Dec 29 00:46:39 linux-a7dy kernel:   390.565137] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
Dec 29 00:46:39 linux-a7dy kernel:   390.580357] radeon 0000:01:00.0: couldn't schedule ib
Dec 29 00:46:39 linux-a7dy kernel:   390.580364] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !

And that error goes on for like a hundred lines.

Hmm … what radeon hardware do you have on your PC ? Do you have any custom graphic configuration settings in place ?

None really, just have the latest xorg and mesa files from the x11 repository. Tried enabling pci express 2 but made no difference. This is all with a radeon 4850 sapphire. No xorg.conf file either.

Thanks

Do you have the VirtualBox application loaded and if so, what is its version?

Thank You,

There are a number of posts with this noted as a recent problem also in other GNU/Linux versions … for example this bug report ( # 45018 ) : [Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11](http://lists.freedesktop.org/archives/dri-devel/2012-July/025012.html) … I can’t say whether they are the same, nor have I surfed enough to see if there is a solution provided …

Does the same problem exist with the proprietary graphic driver ?

Looked in yast for virtualbox packages but found none

If this is the same bug, and it may not be, there is more detail here: https://bugs.freedesktop.org/show_bug.cgi?id=45018

I note that comment #119 in that bug report has reference to an updated Mesa version which may implement a fix. As to when such an upstream update will make its way downstream to openSUSE is something I am not knowledgeable enough to comment on. Nor can I comment knowledgeably as to whether it is the same problem.

That fix was posted on August, so i suppose its already implemented?

Unlikely IMHO.

openSUSE was released in September ?? … but there was a ‘freeze’ on all but very critical bugs for a least a month or two prior. Hence the odds of that fix being in openSUSE-12.2 is slim and IMHO it is most unlikely the fix made it to openSUSE-12.2.

However it ‘might’ be in a Tumbleweed based on openSUSE-12.2.

Not even if im updating Xorg files through the X11 repository?

Its been a while since I looked at the X11 repository. Is that not ‘factory’ ? Ergo is it not unstable and risky ? I recall last time I tried that (many years back) I totally hosed my desktop and was forced to do a re-install.

The ‘advantage’ of Tumbleweed is it adds an extra layer of testing on packages that are in factory, and hence provides an extra layer of stability. Of course it is also not as ‘cutting edge’ as factory.

Before trying any install, did you check the change history of the applicable package (what ever it might be) in factory to see if it has the fix you are looking for?

Its not a factory repository:

Index of /repositories/X11:/XOrg/openSUSE_12.2

And looking at the Mesa.changes log, its not very detailed onto which fixes are implemented.

Indeed its not easy … looking at the .SRC file of the Mesa version in the X11 repos I note this for content:


Mesa-nodate.diff
Mesa-rpmlintrc
Mesa.spec
MesaLib-9.0.1.tar.bz2
README.updates
baselibs.conf
drirc
manual-pages.tar.bz2
u_Fix-crash-in-swrast-when-setting-a-texture-for-a-pix.patch
u_mesa-8.0-llvmpipe-shmget.patch
u_mesa-8.0.1-fix-16bpp.patch
u_remove-os-abi-tag.patch

and looking at the change log for the Mesa in the x11 repos I note:


* Fri Dec 14 2012 tobias.johannes.klausmann@mni.thm.de
- Remove unrecognized configure option "--disable-glu"

* Mon Dec 10 2012 sndirsch@suse.com
- Update to Version 9.0.1
  * bug fix release

* Tue Oct 16 2012 sndirsch@suse.com
- improved packages descriptions

* Mon Oct 08 2012 tobias.johannes.klausmann@mni.thm.de
- Update to version 9.0:
  Mesa 9.0 has been released.  Mesa 9.0 is a feature release.
  "The" big feature is the availability of OpenGL 3.1 on some
  supported hardware.
  + Remove the Git Commit ID

* Tue Sep 25 2012 tobias.johannes.klausmann@mni.thm.de
- Update the Mesa 9.0 Git Snapshot
  + Add the Git CommitID to the buildscript
  + Minor cleanup of the buildscript

* Mon Sep 24 2012 sndirsch@suse.com
- removed any .la file
- moved libglapi.so from Mesa-devel to Mesa-libglapi-devel package;
  Mesa-devel requires Mesa-libglapi-devel package anyway

* Fri Sep 21 2012 sndirsch@suse.com
- fixed libOSMesa packaging (only a dangling symlink has been
  packaged)

* Fri Sep 21 2012 coolo@suse.com
- fix baselibs.conf after package split

* Thu Sep 20 2012 sndirsch@suse.com
- instead of using "make install" for installing libIndirectGL/
  libOSMesa, do install these libs manually, so we no longer end
  up with linking *everything* against libIndirectGL (instead of
  having it correctly linked against GL!)

* Fri Aug 24 2012 tobias.johannes.klausmann@mni.thm.de
- Update to 8.1 prerelease:
  + Added radeonsi to the dri drivers for x86/x86_64
  + Rewrite the configuration parts of the spec file
  + Changed u_Fix-crash-in-swrast-when-setting-a-texture-for-a-pix.patch
    to apply!
  + Changed u_remove-os-abi-tag.patch to apply! (Removed parts of it)
  + Changed u_mesa-8.0.1-fix-16bpp.patch to apply! (Removed parts of it)
  + Remove upstreamed patches: (double checked)
  - upstream-llvm-patch.diff
  - U_i965-gen7-Reduce-GT1-WM-thread-count-according-to-up.patch

* Thu Aug 23 2012 fcrozat@suse.com
- Add u_mesa-8.0-llvmpipe-shmget.patch (Fedora): use shmget under
  llvmpipe, if available (bnc#766498).
- Update u_mesa-8.0.1-fix-16bpp.patch to work with shmget patch.

* Wed Aug 08 2012 tiwai@suse.de
- U_i965-gen7-Reduce-GT1-WM-thread-count-according-to-up.patch
  * Fix GPU hang with IVB GT1 desktop (bnc#775048)

* Tue Jul 10 2012 tobias.johannes.klausmann@mni.thm.de
- Update to Version 8.0.4 (minor bugfix release)
- Back to bz2 tarballs

* Sat Jun 16 2012 coolo@suse.com
- remove buildrequire on vim, it creates a pretty big cycle for
  no (obvious) benefit

that is a bit different from the changelog of openSUSE-12.2 Mesa, where openSUSE-12.2 Mesa has the following for changes from July to August


* Tue Aug 28 2012 sndirsch@suse.com
- U_glsl-linker-Avoid-buffer-over-run-in-parcel_out_unif.patch
  * Avoid buffer over-run in parcel_out_uniform_storage::visit_field
    When too may uniforms are used, the error will be caught in
    check_resources (src/glsl/linker.cpp). (CVE-2012-2864, bnc#777461)

* Thu Aug 23 2012 fcrozat@suse.com
- Add u_mesa-8.0-llvmpipe-shmget.patch (Fedora): use shmget under
  llvmpipe, if available (bnc#766498).
- Update u_mesa-8.0.1-fix-16bpp.patch to work with shmget patch.

* Wed Aug 08 2012 tiwai@suse.de
- U_i965-gen7-Reduce-GT1-WM-thread-count-according-to-up.patch
  * Fix GPU hang with IVB GT1 desktop (bnc#775048)

* Tue Jul 10 2012 tobias.johannes.klausmann@mni.thm.de
- Update to Version 8.0.4 (minor bugfix release)
- Back to bz2 tarballs

* Sat Jun 16 2012 coolo@suse.com
- remove buildrequire on vim, it creates a pretty big cycle for
  no (obvious) benefit

… and as near as I can tell none of the patches are in either Mesa version, where we are looking for http://lists.freedesktop.org/archives/mesa-dev/2012-August/025715.html … ie:



[PATCH 1/7] gallium/radeon: Make va_offset 64 bits wide.
[PATCH 2/7] gallium/radeon: Merge holes when freeing virtual address
[PATCH 3/7] gallium/radeon: Fix losing holes when allocating virtual
[PATCH 4/7] gallium/radeon: Delete uppermost virtual address space
[PATCH 5/7] gallium/radeon: Fix potential address space loss in
[PATCH 6/7] gallium/radeon: Create hole for waste when allocating
[PATCH 7/7] gallium/radeon: Don't assign virtual address space for