We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages ---------------------------------------------- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected ----------------------------------------------
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
./Cal
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
./Cal
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
I'll try first thing in the morning Johnny. Wife's waitin' on me. :-)
./Cal
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote:
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers.
On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating "read: Connection reset by peer (104)".
On the server end, a core dump is generated and a abrt bug report is created.
/var/log/messages
Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected
This bug has been reported in the CentOS bug tracker here:
0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824
However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details.
tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443
We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug.
Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem.
I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix.
Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix.
Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one.
./Cal
On 08/17/2012 01:40 PM, Cal Webster wrote:
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote: > We began experiencing failed vnc connections to the console display on > servers that have been updated to EL 6.3. No such failures have occurred > on similar connections to EL 6.2 servers. > > On the client machine a normal vncviewer display appears with the > expected graphical login until the mouse pointer is moved within the > boundaries of the vncviewer window. At this point the window closes and > an error message appears in both a pop-up window and in the terminal > window in which the session was initiated stating "read: Connection > reset by peer (104)". > > On the server end, a core dump is generated and a abrt bug report is > created. > > /var/log/messages > ---------------------------------------------- > Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be > deleted > Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 > (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 > (42041344 bytes) > Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' > creation detected > ---------------------------------------------- > > This bug has been reported in the CentOS bug tracker here: > > 0005824: tigervnc-server-module keep crashing > http://bugs.centos.org/view.php?id=5824 > > However, this appears to be a bug upstream. The source RPM provided with > CentOS is identical to that of upstream with no modifications. Also, > there is an upstream bug reported that appears to have the same > symptoms. I have added a comment to the upstream bug report (listed > below) if anyone wishes to see the details. > > tigervnc-server-module crashes with dual screen setup > https://bugzilla.redhat.com/show_bug.cgi?id=820443 > > > > We have verified that rebuilding the unmodified source RPM for tigervnc > produces a tigervnc-server-module RPM that does not suffer from this > bug. > > Removing the original tigervnc-server-module package and replacing it > with the rebuilt one fixes the problem. > > I've duplicated the problem on 2 EL 6.3 x86_64 single-head display > machines and have verified the fix. > > Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that > currently still works after updating to EL 6.2 then confirm the the fix. > Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one.
./Cal
Thanks for testing.
I will build a new version for release with an incremented version and get you to test those before for release if you would do so for me.
Thanks, Johnny Hughes
On 08/17/2012 01:40 PM, Cal Webster wrote:
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote:
On 08/14/2012 05:23 PM, Cal Webster wrote: > We began experiencing failed vnc connections to the console display on > servers that have been updated to EL 6.3. No such failures have occurred > on similar connections to EL 6.2 servers. > > On the client machine a normal vncviewer display appears with the > expected graphical login until the mouse pointer is moved within the > boundaries of the vncviewer window. At this point the window closes and > an error message appears in both a pop-up window and in the terminal > window in which the session was initiated stating "read: Connection > reset by peer (104)". > > On the server end, a core dump is generated and a abrt bug report is > created. > > /var/log/messages > ---------------------------------------------- > Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be > deleted > Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 > (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 > (42041344 bytes) > Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' > creation detected > ---------------------------------------------- > > This bug has been reported in the CentOS bug tracker here: > > 0005824: tigervnc-server-module keep crashing > http://bugs.centos.org/view.php?id=5824 > > However, this appears to be a bug upstream. The source RPM provided with > CentOS is identical to that of upstream with no modifications. Also, > there is an upstream bug reported that appears to have the same > symptoms. I have added a comment to the upstream bug report (listed > below) if anyone wishes to see the details. > > tigervnc-server-module crashes with dual screen setup > https://bugzilla.redhat.com/show_bug.cgi?id=820443 > > > > We have verified that rebuilding the unmodified source RPM for tigervnc > produces a tigervnc-server-module RPM that does not suffer from this > bug. > > Removing the original tigervnc-server-module package and replacing it > with the rebuilt one fixes the problem. > > I've duplicated the problem on 2 EL 6.3 x86_64 single-head display > machines and have verified the fix. > > Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that > currently still works after updating to EL 6.2 then confirm the the fix. > Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild?
No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one.
Would you also test that these work:
http://people.centos.org/hughesjr/tigervnc/
(same link, newer files :D)
NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it.
On Fri, 2012-08-17 at 19:46 -0500, Johnny Hughes wrote:
On 08/17/2012 01:40 PM, Cal Webster wrote:
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: > On 08/14/2012 05:23 PM, Cal Webster wrote: >> We began experiencing failed vnc connections to the console display on >> servers that have been updated to EL 6.3. No such failures have occurred >> on similar connections to EL 6.2 servers. >> >> On the client machine a normal vncviewer display appears with the >> expected graphical login until the mouse pointer is moved within the >> boundaries of the vncviewer window. At this point the window closes and >> an error message appears in both a pop-up window and in the terminal >> window in which the session was initiated stating "read: Connection >> reset by peer (104)". >> >> On the server end, a core dump is generated and a abrt bug report is >> created. >> >> /var/log/messages >> ---------------------------------------------- >> Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be >> deleted >> Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 >> (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 >> (42041344 bytes) >> Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' >> creation detected >> ---------------------------------------------- >> >> This bug has been reported in the CentOS bug tracker here: >> >> 0005824: tigervnc-server-module keep crashing >> http://bugs.centos.org/view.php?id=5824 >> >> However, this appears to be a bug upstream. The source RPM provided with >> CentOS is identical to that of upstream with no modifications. Also, >> there is an upstream bug reported that appears to have the same >> symptoms. I have added a comment to the upstream bug report (listed >> below) if anyone wishes to see the details. >> >> tigervnc-server-module crashes with dual screen setup >> https://bugzilla.redhat.com/show_bug.cgi?id=820443 >> >> >> >> We have verified that rebuilding the unmodified source RPM for tigervnc >> produces a tigervnc-server-module RPM that does not suffer from this >> bug. >> >> Removing the original tigervnc-server-module package and replacing it >> with the rebuilt one fixes the problem. >> >> I've duplicated the problem on 2 EL 6.3 x86_64 single-head display >> machines and have verified the fix. >> >> Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that >> currently still works after updating to EL 6.2 then confirm the the fix. >> > Did you rebuild the SRPM using mock or directly on a physical machine > with rpmbuild? No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one.
Would you also test that these work:
http://people.centos.org/hughesjr/tigervnc/
(same link, newer files :D)
NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it.
Sorry Johnny. I've been deep in some internal issues past few days - Migration planning for Win7, building out new CentOS 6 servers, and such.
I'll be happy to test these.
./Cal
On Fri, 2012-08-17 at 19:46 -0500, Johnny Hughes wrote:
On 08/17/2012 01:40 PM, Cal Webster wrote:
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: > On 08/14/2012 05:23 PM, Cal Webster wrote: >> We began experiencing failed vnc connections to the console display on >> servers that have been updated to EL 6.3. No such failures have occurred >> on similar connections to EL 6.2 servers. >> >> On the client machine a normal vncviewer display appears with the >> expected graphical login until the mouse pointer is moved within the >> boundaries of the vncviewer window. At this point the window closes and >> an error message appears in both a pop-up window and in the terminal >> window in which the session was initiated stating "read: Connection >> reset by peer (104)". >> >> On the server end, a core dump is generated and a abrt bug report is >> created. >> >> /var/log/messages >> ---------------------------------------------- >> Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be >> deleted >> Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 >> (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 >> (42041344 bytes) >> Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' >> creation detected >> ---------------------------------------------- >> >> This bug has been reported in the CentOS bug tracker here: >> >> 0005824: tigervnc-server-module keep crashing >> http://bugs.centos.org/view.php?id=5824 >> >> However, this appears to be a bug upstream. The source RPM provided with >> CentOS is identical to that of upstream with no modifications. Also, >> there is an upstream bug reported that appears to have the same >> symptoms. I have added a comment to the upstream bug report (listed >> below) if anyone wishes to see the details. >> >> tigervnc-server-module crashes with dual screen setup >> https://bugzilla.redhat.com/show_bug.cgi?id=820443 >> >> >> >> We have verified that rebuilding the unmodified source RPM for tigervnc >> produces a tigervnc-server-module RPM that does not suffer from this >> bug. >> >> Removing the original tigervnc-server-module package and replacing it >> with the rebuilt one fixes the problem. >> >> I've duplicated the problem on 2 EL 6.3 x86_64 single-head display >> machines and have verified the fix. >> >> Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that >> currently still works after updating to EL 6.2 then confirm the the fix. >> > Did you rebuild the SRPM using mock or directly on a physical machine > with rpmbuild? No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one.
Would you also test that these work:
http://people.centos.org/hughesjr/tigervnc/
(same link, newer files :D)
NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it.
I haven't heard anyone on this list verify that the problem does, in fact, exist on RHEL 6. It would be nice to confirm this is an upstream bug versus a packaging issue with CentOS. If there are members here with mixed upstream and CentOS environments, such confirmation would be welcome. We just allowed the last of our entitlements to expire so I can't do it here.
./Cal
On Fri, 2012-08-17 at 19:46 -0500, Johnny Hughes wrote:
On 08/17/2012 01:40 PM, Cal Webster wrote:
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote:
On 08/16/2012 11:43 AM, Cal Webster wrote:
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote:
On 08/15/2012 09:47 AM, Cal Webster wrote:
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: > On 08/14/2012 05:23 PM, Cal Webster wrote: >> We began experiencing failed vnc connections to the console display on >> servers that have been updated to EL 6.3. No such failures have occurred >> on similar connections to EL 6.2 servers. >> >> On the client machine a normal vncviewer display appears with the >> expected graphical login until the mouse pointer is moved within the >> boundaries of the vncviewer window. At this point the window closes and >> an error message appears in both a pop-up window and in the terminal >> window in which the session was initiated stating "read: Connection >> reset by peer (104)". >> >> On the server end, a core dump is generated and a abrt bug report is >> created. >> >> /var/log/messages >> ---------------------------------------------- >> Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be >> deleted >> Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 >> (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 >> (42041344 bytes) >> Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' >> creation detected >> ---------------------------------------------- >> >> This bug has been reported in the CentOS bug tracker here: >> >> 0005824: tigervnc-server-module keep crashing >> http://bugs.centos.org/view.php?id=5824 >> >> However, this appears to be a bug upstream. The source RPM provided with >> CentOS is identical to that of upstream with no modifications. Also, >> there is an upstream bug reported that appears to have the same >> symptoms. I have added a comment to the upstream bug report (listed >> below) if anyone wishes to see the details. >> >> tigervnc-server-module crashes with dual screen setup >> https://bugzilla.redhat.com/show_bug.cgi?id=820443 >> >> >> >> We have verified that rebuilding the unmodified source RPM for tigervnc >> produces a tigervnc-server-module RPM that does not suffer from this >> bug. >> >> Removing the original tigervnc-server-module package and replacing it >> with the rebuilt one fixes the problem. >> >> I've duplicated the problem on 2 EL 6.3 x86_64 single-head display >> machines and have verified the fix. >> >> Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that >> currently still works after updating to EL 6.2 then confirm the the fix. >> > Did you rebuild the SRPM using mock or directly on a physical machine > with rpmbuild? No mock, just a simple "rpmbuild -ba SPEC/tigervnc.spec"
OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different.
I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems.
Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems.
One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary "ATI FirePro 2270" drivers, though. Once the rebuilt module is installed the systems run fine.
I've also updated the upstream bug report.
can you see if either or both of these work for you:
http://people.centos.org/hughesjr/tigervnc/
One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed.
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one.
Would you also test that these work:
http://people.centos.org/hughesjr/tigervnc/
(same link, newer files :D)
NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it.
Got them and tested on 3 different machines, 2 x86_64 (one single and one dual-head) and one i386. All work well. This time I updated all tigervnc packages, not just tigervnc-server-module.
I added all the packages to our internal "localcentos" repo so all our systems will pickup the update, thanks to your incremental version number change. I use the localcentos repo for one-off rpmbuilds and things like this that don't come through normal channels.
Thanks for the work you put into this Johnny, as well as your continuing efforts in this project. You often don't get the credit you deserve.
./Cal
Hi guys,
Could you be so kind to trim those quotes a little?
On Fri, 2012-08-17 at 14:40 -0400, Cal Webster wrote:
Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host.
Something in the bug report struck me as odd: The original report is from May 9th. Checking Red Hat's FTP I see there is a more recent SRPM than the one you are discussing.
ftp://ftp.nluug.nl/site/ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/tigervnc-1.0.90-0.15.20110314svn4359.el6_1.1.src.rpm
Seems like this update wasn't picked up even though it's two months old, and the previous (current) one was rebuilt three months after it was released by upstream.
Regards, Leonard.
On Sat, Aug 18, 2012 at 5:48 AM, Leonard den Ottolander leonard@den.ottolander.nl wrote:
ftp://ftp.nluug.nl/site/ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/tigervnc-1.0.90-0.15.20110314svn4359.el6_1.1.src.rpm
Seems like this update wasn't picked up even though it's two months old, and the previous (current) one was rebuilt three months after it was released by upstream.
That srpm is dated 06/13/2011 (from year 2011). The latest/current (tigervnc-1.0.90-0.17.20110314svn4359.el6.src.rpm) is dated 11/09/2011 (also from year 2011). Note also the difference between -0.15 and -0.17. :-)
Akemi
Hello Akemi,
On Sat, 2012-08-18 at 08:59 -0700, Akemi Yagi wrote:
That srpm is dated 06/13/2011 (from year 2011). The latest/current (tigervnc-1.0.90-0.17.20110314svn4359.el6.src.rpm) is dated 11/09/2011 (also from year 2011). Note also the difference between -0.15 and -0.17. :-)
Right, my bad. Too many numbers got me confused ;) . Does explain why my script didn't pick it up :) .
Anyway, I'm afraid most of the missing updates and packages I reported just now are actual issues.
Regards, Leonard.
On 08/18/2012 05:21 PM, Leonard den Ottolander wrote:
Anyway, I'm afraid most of the missing updates and packages I reported just now are actual issues.
what missing updates are you talking about ? your last few emails about missing packages was down to your script not working and you not considering binary / source relationships.
Hello Karanbir,
On Fri, 2012-08-24 at 14:43 +0100, Karanbir Singh wrote:
On 08/18/2012 05:21 PM, Leonard den Ottolander wrote:
Anyway, I'm afraid most of the missing updates and packages I reported just now are actual issues.
what missing updates are you talking about ? your last few emails about missing packages was down to your script not working and you not considering binary / source relationships.
Yes, my mail above predates Johnny's final conclusion. Indeed all packages are accounted for.
Regards, Leonard.
-
Akemi Yagi -
Cal Webster -
Johnny Hughes -
Johnny Hughes -
Karanbir Singh -
Leonard den Ottolander