Bug 1043209

+++ This bug was initially created as a clone of Bug #1019940 +++

Description of problem:  While working in Calc.  Click on tab of current spreadsheet to move it to a different position.  System freezes. Mouse still moves, but no action possible.  Had to power down and restart.


Version-Release number of selected component (if applicable):
Version: 4.1.2.3
Build ID: 4.1.2.3-3.fc19

How reproducible:
Appears to be reproducible.  Happened twice in a row to me.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Eike Rathke on 2013-10-17 06:59:52 EDT ---

Sounds more like an X or Window manager problem if the entire GUI appears to freeze. An application shouldn't be able to do that. Is it really reproducible, always, or always only with a specific document?

--- Additional comment from Jochen Meissner on 2013-10-17 13:51:20 EDT ---

I tested it with an empty new spreadsheet, added a tab and then moved it.  Same thing. The little tab symbol attaches to the mouse cursor and that is the end of the story.  Mouse still moves but you cannot "click" the tab in a new place.

I wonder if this could be related to Bug 983834.  (No real insights though, I am just a simple Linux user who gave up on Windows a dew years ago.)

I will also upload a video taken with my phone (all else failed since I needed to shut PC off)

--- Additional comment from Jochen Meissner on 2013-10-17 13:54:52 EDT ---

I tested it with an empty new spreadsheet, added a tab and then moved it.  Same thing. The little tab symbol attaches to the mouse cursor and that is the end of the story.  Mouse still moves but you cannot "click" the tab in a new place.

I wonder if this could be related to Bug 983834.  (No real insights though, I am just a simple Linux user who gave up on Windows a dew years ago.)

I also uploaded a video taken with my phone (all else failed since I needed to shut PC off) to a public dropbox folder: 

https://dl.dropboxusercontent.com/u/16233879/20131017_124716.mp4

--- Additional comment from Damien Sticklen on 2013-11-17 08:34:11 EST ---

I tested this same problem on Fedora 19 and 20 Rawhide with HD7870 running RadeonSI driver and could replicate the OP comment.  I note that calc is slower to start than usual as well.

I then tested under Fedora 19 with AMD Catalyst (proprietary) driver and note that start times for calc improved along with tab manipulation.  I think that in my case, something is amiss with the RadeonSI drivers as I have been able to replicate this to other distros with the RadeonSI driver.

--- Additional comment from Damien Sticklen on 2013-12-01 01:51:28 EST ---

As at 1 December, after a full update on Fedora 20 Rawhide (amd64 architecture), this problem remains.

Probably could do with a way-ahead from the assigned developer since release is not far away.

- Damien

--- Additional comment from David Mansfield on 2013-12-05 16:15:14 EST ---

My colleague is also having severe problems with libreoffice and radeonsi.

- Covering part of a sheet and exposing it can take 10-20 seconds to "repaint".  

- calc takes many times as long to open as it should.

Booting with module.blacklist=radeon on the kernel cmd line makes the problems go away, but the dual monitors are stuck in "mirror" mode so it's not a viable workaround.

Also found: in gnome settings panel, some panels show black areas instead of background & title bar.

Chipset is (from Xorg.0.log):

[    37.632] (--) RADEON(0): Chipset: "VERDE" (ChipID = 0x683d)

Willing to do any experimenting to get to the bottom of this.

--- Additional comment from David Mansfield on 2013-12-05 16:24:29 EST ---

And I can confirm what was stated in comment#4: all problems disappear using catalyst driver.

see https://fedoraproject.org/wiki/Fglrx

--- Additional comment from Damien Sticklen on 2013-12-06 19:44:59 EST ---

I see no such resolution by adding module.blacklist=radeon on the kernel cmd line.  I suspect David Mansfield had the fglrx driver also installed, thereby having using the fglrx driver once the module.blacklist=radeon  option had been executed.

--- Additional comment from David Mansfield on 2013-12-09 15:55:52 EST ---

I mistyped it, actually.  It's modprobe.blacklist=radeon  Sorry.

fglrx was 100% for sure not installed at the time. 

FYI Blacklisting radeon had 3 effects:

1) blue one-line progress bar in text mode during boot (if you don't see this, it didn't get blacklisted)

2) no dual head support

3) no slowness problems in oocalc or graphical articfacts in control center

--- Additional comment from Damien Sticklen on 2013-12-10 23:21:47 EST ---

David,

Thanks for the update; I will take a look at this later today.

Did you find that you get the correct native resolution for the monitor?

Can you give the result of (as a normal user in X):

glxinfo |grep -i opengl

--- Additional comment from Damien Sticklen on 2013-12-11 05:50:31 EST ---

I have done this myself and found: 

glxinfo |grep -i opengl
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 256 bits)
OpenGL version string: 2.1 Mesa 9.2.4
OpenGL shading language version string: 1.30
OpenGL extensions:

Also, latency has gone with Calc, but at the expense of hardware accelerated 3D rendering as indicated above by llvmpipe which is the just in time software renderer.

--- Additional comment from Damien Sticklen on 2013-12-11 05:51:30 EST ---

Also note with the above workaround, that kernel modesetting is unavailable.

--- Additional comment from Damien Sticklen on 2013-12-14 18:47:32 EST ---

I would like to clone this bug for Fedora 20.  Any advice?  I have seen the clone link.  However, the response is that I need to select a classification.