> On Tue, Sep 26, 2006 at 01:29:35PM -0400, Adam Jackson wrote: >> Just as an update, I'm still looking into this, it's pretty brutal. It >> appears to be a bug in the kernel's VT handling code, which is making my >> eyes go all crossy. Hopefully I'll have at least a hacky workaround by >> the end of the day, in the meantime just disable rhgb. > > Any more details and I'll look into the kernel side as I'm working on > tty and vt locking currently. Excuse the elementary question... Would these tty and vt errors in any way be related to some odd behaviour I'm seeing with the "screen" virtual terminal utility? I'm experiencing some lockups in screen whenever I do anything particularly "busy". E.g., when doing an update it will freeze on printing the hashed progress bar. That screen session will hang completely. Even the SSH escape sequence will not disconnect me. I need to open a second SSH session and "kill -9" the existing screen sessions. To reproduce: >From a terminal on a client machine, use OpenSSH or Putty to login to an FC6T3 machine. Start screen. My default is a split window setup so: screen, ALT-S, ALT-TAB, ALT-C. su to root then do something with lots of screen updates. E.g. "yum clean all; yum update". About 5/6 times it will hang on pulling the update or updating the screen. It works from the console machine or from a plain SSH session (i.e., no screen) every time so it appears that screen is the only difference. SELinux is disabled. -- * The Digital Hermit http://www.digitalhermit.com * Unix and Linux Solutions kwan@xxxxxxxxxxxxxxxxx -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list