(Multiseat) screen shifts when /dev/console written to

Please attach your /var/log/Xorg.0.log[.old] files showing the failure and the output of lspci -vvnn. See https://wiki.ubuntu.com/X/Debugging for more info on debugging X problems, and other info you could include to help triage this bug.

I wrote to the console as root
echo "some random text">/dev/console
eight times and the screen rotated back to normal. This happened just before I took a snapshot of the Xorg log file. The date on this file is 2007-10-19 17:27, whereas I tested at 18:10, so I'm pretty sure the last messages didn't happen at the same time as the shift. I've also notice that it's not just a plain side screen rotation , but the screen actually shifts what appears to be one bit up, so that eventually you start seeing the top of the screen at the bottom.

This is the result of my lspci -vvnn:

00:00.0 Host bridge [0600]: ATI Technologies Inc Unknown device [1002:7910]
 Subsystem: ASUSTeK Computer Inc. Unknown device [1043:826d]
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
 Latency: 64

00:01.0 PCI bridge [0604]: ATI Technologies Inc Unknown device [1002:7912] (prog-if 00 [Normal decode])
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 99
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
 I/O behind bridge: 0000d000-0000dfff
 Memory behind bridge: fdb00000-fdcfffff
 Prefetchable memory behind bridge: 00000000f8000000-00000000f9ffffff
 Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
 Capabilities: [44] HyperTransport: MSI Mapping
 Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device [1002:7912]

00:07.0 PCI bridge [0604]: ATI Technologies Inc Unknown device [1002:7917] (prog-if 00 [Normal decode])
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0, Cache Line Size: 32 bytes
 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
 I/O behind bridge: 0000e000-0000efff
 Memory behind bridge: fdf00000-fdffffff
 Prefetchable memory behind bridge: 00000000fdd00000-00000000fddfffff
 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
 Capabilities: [50] Power Management version 3
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [58] Express Root Port (Slot-) IRQ 0
  Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
  Device: Latency L0s <64ns, L1 <1us
  Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
  Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
  Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
  Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 4
  Link: Latency L0s <64ns, L1 <1us
  Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
  Link: Speed 2.5Gb/s, Width x1
  Root: Correctable- Non-Fatal- Fatal- PME-
 Capabilities: [80] Message Signalled Interr...

I took this screen shot of the screen shot! The (Gnome) screen shot shows how the screen is supposed to look. When I connecte and unconnected the camera I used for this screen shot, the screen dutifully shifted right. It seems very reproducible.

It might also be relevant how I start the X servers via gdm. gdm.conf is unchanged and gdm.conf-custom is:

# GDM Configuration Customization file.
#
<snip comments>
# NOTE: Lines that begin with "#" are considered comments.
#
# Have fun!

[daemon]

[security]

[xdmcp]

[gui]
GtkRC=

[greeter]
GraphicalTheme=happygnome-list
GraphicalThemedColor=#000000
Browser=true
Exclude=bin,daemon,adm,lp,sync,shutdown,halt,mail,news,uucp,operator,nobody,gdm,postgres,pvm,rpm,luis,gallery

[chooser]

[debug]

[servers]
0=Standard0
1=Standard1

[server-Standard0]
name=Standard server
#command=/usr/X11R6/bin/X -novtswitch -sharevts -isolateDevice PCI:1:5:0 -layout Seat0
command=/usr/X11R6/bin/X -sharevts -isolateDevice PCI:1:5:0 -layout Seat0
flexible=true

[server-Standard1]
name=Standard server
#command=/usr/X11R6/bin/X -novtswitch -sharevts -isolateDevice PCI:3:6:0 -layout Seat1
command=/usr/X11R6/bin/X -sharevts -isolateDevice PCI:3:6:0 -layout Seat1
flexible=true

I updated to Gutsy, and that problem went away. I believe the fix was actually in the kernel as I noticed that the fix in the vgacon.c shows up in the default Gutsy kernel. And it does make sense that it's the kernel that is allowing a leak from the console into the hardware controlled by X.

Never mind, still present.

See
http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg00440.html
for a description of (probably) the same bug and also
http://<email address hidden>/msg14998.html
for the patch.

I am encountering the same bug on debian etch on a multi seat system with to nvidia fx5200.

As a workaround omitting -sharevts in the command line that starts the X server on the primary graphics card works for me (with gdm).

Thanks for your comment. Unfortunately it seems that the patch doesn't really fix this issue. I'm running 2.6.22-14, and the patch is already there (according to LXR it was put there in the first 2.6.22 kernel), but the problem persist. I'm about to reboot to try your suggestion about -sharevts, so I'll soon know if that helps.

It does seem to help, but then I have to explicitly disable AIGLX in xorg.conf. It seems that it is trying to do some vt operations and then my primary screen locks up. But at least I tried writing:
 echo "Some random text" >/dev/console
and the secondary monitor didn't wrap, so I'm keeping my fingers crossed.

I am also having the same problem on Gutsy, and I too have a multiseat setup (two nVidia cards using the nvidia 169.09 driver). The shift only seems to happen on the first seat, although my second seat is rarely used. The shift doesn't happen very often, especially since I added the "isolateDevice" parameter to my gdm.conf-custom, but it does seem to happen fairly reliably upon shutdown.

My guess is that the patch in the LKML thread mentioned in the original post (and present in 2.6.22, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ae854777592856ad8ce4d4cdb6114804e2e28f6) fixed most instances of the screen shift problem, but there's something about multiseat X setups that allow the occasional write to /dev/console to leak through and cause a scroll.

There seems to be a few similar Ubuntu bugs (bug #75214, bug #100105, and bug #139546) but I'm guessing that kernel 2.6.22 used in Gutsy resolved those. I think that the only remaining instances of this screen shift issue are in multiseat X setups.

luis: Are you still able to reproduce this in Gutsy? I can't figure out how to reproduce it. Also, would you mind changing the subject to mention "multiseat" so that this doesn't get marked as a duplicate to the other screen shift bugs?

I guess I should mention that my screen shifts to the left, not to the right.

Other people having the same problem with a multiseat setup: http://ubuntuforums.org/showpost.php?p=3618100&postcount=6 http://www.linuxquestions.org/questions/linux-hardware-18/dual-nvidia-7300-display-shift-left-597433/

I had to go back to single seat mode. The system wasn't stable enough, for other reasons actually. I had it working briefly yesterday and it did happen, and this is indeed Gutsy.

Workaround at end of message.

I have been experiencing the same bug. After reading this bug report and doing a little experimentation, I can confirm that output (specifically scrolling) to /dev/console triggers the screen shifting to occur. Furthermore, the problem only occurs when /dev/console is connected to the vga console.

Once the problem has occurred,
    echo -n > /dev/console
does not affect the shifting since it omits the carriage return and does not scroll the screen.
    echo -n "a" > /dev/console
Does affect the shifting after being run 80 times, causing the console to scroll.

Until a kernel fix is available, I have worked around the problem by adding
    console=ttyS1,38400
to my kernel boot options (/boot/grub/menu.lst) to prevent all output to the vga console.

--
Steve

vandebo: Do you have multiple video cards configured? Are you running Gutsy? Running 'echo -n "a" > /dev/console' many times doesn't trigger the problem for me.

I'm running two nvidia 6200's (one pci, one agp). I'm on dapper, but the root problem seems the same. If you run 'echo > /dev/console' more than 24 times it should trigger the problem. Once the problem has triggered, running 'echo -n "a" > /dev/console' 80/81 times should get it to shift.... unless you set the vga mode to more characters, then it might take 125ish? 'a' to cause a shift.

--
Steve

> I'm on dapper, but the root problem seems the same.

Sort of. The 2.6.22 release of the Linux kernel contains a fix that eliminated most of the shifting that happened in 2.6.21 and earlier. With 2.6.22, it is no longer possible to get the screen to shift by typing "echo -n a > /dev/console" many times. However, the fix doesn't appear to cover all cases of screen shifting -- multiseat configurations still somehow trigger the shift, although not nearly as often as before 2.6.22.

My previous work around had one negative side affect... with console output redirected to the serial port, unplugging my usb keyboard (which generates several lines of console output) caused the machine to hang hard. A new work around I found is to specify the kernel boot parameter "no-scroll". According to the bootparam man page: "This option tells the console driver not to use hardware scroll (where a scroll is effected by moving the screen origin in video memory, instead of moving the data). It is required by certain Braille machines."

--
Steve

Sounds like a kernel issue; refiling against linux.

Hi Everyone,

Can anyone confirm this issue on Hardy Heron 8.04 which is set to be released in the next day or two. It contains kernel 2.6.24. If the issue still exists, per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

It also might be helpful to wait to capture the dmesg output until after you've triggered the bug. Maybe something will be logged that will help with the debugging. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

People,

 I have tested several multiseat solutions, for 6 months, there are one stable configuration for now (of course it not depending on your video board, you can use ati, sis...):

 Take has an example:

 4 Nvidias with 2 outputs (one VGA and one DVI or svga)
 4 DVI to VGA adapter

 Use nvidia-xconfig to get your xorg.conf.

 For all your graphics cards, you MUST run just one X server, without xinerama, having for example, 8 screens, 2 n each PCI.
 So, after running, you got one stable X process controlling all of your PCIs. After that, you can start one Xephyr (a modern nested X server) on each of your X screen, remember that, you have 8 independent screen on your big X server, so let's start more 7 Xephyrs... to do this test, type on any console:

on tty1:

aptitude install xserver-xephyr

DISPLAY=:0.1 Xephyr :1 &
DISPLAY=:0.2 Xephyr :2 &
...
DISPLAY=:0.7 Xephyr :7 &
DISPLAY=:0.8 Xephyr :8 &

 Let's see what we have now, 8 X (Xephyrs) servers that's works exactly the same way of a normal X, waiting for a Window Manager! If this test works, you can do the next part of the idea.

 Now you can configure your gdm.conf to start that one first X server, not putting a login window on it, but instead you can setup your Xephyrs sessions and getting a login prompt on each of it.

 It's very nice, very stable, without "shifts right and wraps around" effects... And you can play Quake on each Xehpyr! :-D

 Configuring keyboards and mices it's another question...

 I think running more than one X on the same machine is the real issue (ins't stable yet), this ins't a "Ubuntu BUG". Think about it, if you start one X server for each PCI board, TILTS is going to happen, because you need to use some specific X options (aka isolateDevice thing) to get it work. I can see it's more beautiful to have each user with your own X but, ins't stable! And you lost 4 seats (with nvidias with dual output).

 Try the Ubuntu based distro called Userful (http://support.userful.com/wiki/index.php/How_To/Desktop_Multiplier_on_Ubuntu). It's like this setup that I was talking about. You can learn...

 Now if you *really* want to setup this solution on a enterprise environment, I suggest you to try Ubuntu with LTSP and thin-clients, it's MUCH more stable and less cost too.

Best regards,
Thiago

@Leann: Confirmed on Hardy. I will attach the requested info. I waited until the display shifted before collecting the info but there's nothing interesting in dmesg.

Note that the agpgart messages late in this dmesg output are not related to the shift; I restarted X a few times because I had just upgraded to Hardy and was playing around with my xorg.conf (stupid evdev changes). The shift happened much later than 2725 seconds after boot.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

I finally upgraded to Intrepid and took out the 'no-scroll' kernel argument. Unfortunately, the problem still exists.

I am using Fedora 8 and I have the same problem. My screen shifts to the right when a message is written to the console. When I run xconsole, the problem goes away. xconsole consumes the messages so it never makes it to the screen. Its not always possible to have xconsole running, ie when your at the login screen. So I wrote a short program to redirect the console. Its working great so far. My plan is to kick the app off on boot and redirect the output to a file.

gcc -lutil conredir.c -o conredir

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <pty.h>
#include <utmp.h>

int main(int argc, char *argv[])
{
 int pty;
 int tty;
 FILE *input;
 int e;

 //creates a new terminal
 e = openpty(&pty, &tty, NULL, NULL, NULL);
 if (e == -1)
 {
  printf("Error creating pty\n");
  return 1;
 }

 int on = 1;
 //assigns the out on the terminal to a console
 e = ioctl(tty, TIOCCONS, (char *)&on);
 if (e == -1)
 {
  printf("Error taking console\n");
  return 1;
 }

 //opens a file stream to the terminal
 input = fdopen (pty, "r");

 char buf[1024];

 //print what we get
 while(1)
 {
  fgets(buf, 1024, input);
  printf("%s", buf);
  fflush(stdout);

 }
 return 0;
}

@shawa: xconsole is a good idea. A few questions for you:
1. Is your kernel 2.6.22 or newer?
2. Do you have a multiseat setup?
3. Does the screen shift happen every time something is written to /dev/console, or only occasionally?
4. Can you reproduce the screen shift on demand? If so, how?
5. Based on the messages that appear in xconsole, can you tell what messages might be causing the shift?

Thanks!

This bug is affecting me too on a multiseat setup. Every time the Enter key is pressed, the first screen shifts. (I suspect this is because the input is being sent to a tty as well as X.org, but it doesn't invalidate the bug.)

I can confirm that adding "no-scroll" to the kernel parameters works around this bug, though.

@a7x
1. Is your kernel 2.6.22 or newer? 2.6.23.15. I tried no-scroll but it didn't work for me. After 25 or so lines were written to the console it started shifting the screen.

2. Do you have a multiseat setup? Yes, two seats, using nvidia cards with proprietary driver.

3. Does the screen shift happen every time something is written to /dev/console, or only occasionally? The screen will shift to the right only when the screen needs to scroll. i.e. after a reboot, you get ~25 writes to the console without shifting, the 26th time and after, the screen will shift to the right. Or at least that is what happened to me.

4. Can you reproduce the screen shift on demand? If so, how? 'echo "test" > /dev/console' as root.

5. Based on the messages that appear in xconsole, can you tell what messages might be causing the shift? For me it is any message, doesn't matter where it came from. Anything that writes to the console and there are a lot of places that it can come from, will cause it to scroll.

When I log off of one seat and X is restarting, the second seat picks up both keyboards and mice. Once X has restarted the mouse and keyboard goes back to the correct X session. Any Ideas? Not a huge issue as I almost never log off but could be confusing since I plan on having the seats in different rooms.

I have also multiseat setup with two NVidia cards (AGP and PCI) using description on page
#http://linuxgazette.net/124/smith.html
#http://www.linuxtoys.org/multiubuntu/multiubuntu.html
with proprietary nvidia driver.

I can confirm that this problem still exists on fully updated Ubuntu Jaunty 9.04.

My kernel is
Linux gizmo 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

I can also confirm that hitting ENTER on the console on the secondary screen shifts the primary screen from right to left.

In addition I can confirm that adding no-scroll to kernel boot parameters fixes the scrolling problem

bastafidli, even though your screen is no longer scrolling, I suspect your keystrokes are still being sent to both X.Org and a tty. This is dangerous, because when you enter your login details in GDM, you could not only be logging in to your GNOME session, but also unknowingly executing commands in an invisible command shell.

To test this, reboot, log in to GDM as normal, click Places > Home Folder. Then, while you are looking at your Nautilus window, type "touch test" and press Enter. If a file called "test" appears in your home folder, then you are affected by this. The way I solved it was to not have a getty running on the tty I run X.Org on -- there is a udev config file you can edit to control this.

Jeremy, it is surprising that your multiseat sessions start on ttys with gettys. Convention has been to start X sessions on higher ttys where no getty is running. You should be able to do that by properly configuring GDM. Specifying vt# on the X command line (i.e. /usr/bin/X :0 vt7 ...) should do that.

I am having possible related problem in jaunty in my multiseat. When i type on one display, I can see the display on the primary console distort in specific location as you type you continue to type the distortion increases left to right like you would if writing normally except, that they are not visable characters. I though i was having irq device driver issues. But seems like this could be related. I was wondering if Jeremy could elaborate a little more on how I would duplicate his workaround got no idea about getty and tty. thanks

Jeremy, I have tried what you have suggested and no file has appeared. Everything seems to be working just fine for me. I am using two Wireless USB Natural Keyboard/Mouse sets with vanilla Ubuntu Jauty 9.04 fully patched. This is my test installation before i upgrade my main instance, thus no tweaks, just vanilla install. The only things I did was to modify /etc/gdm/gdm.conf

#0=Standard device=/dev/console
0=Standard0
1=Standard1

# Example of how to set up DISPLAY :1 to also use Standard.
#1=Standard

# If you wish to run the XDMCP chooser on the local display use the following
# line
#0=Chooser

# X Server Definitions
#
# Note: Is your X server not listening to TCP requests? Refer to the
# security/DisallowTCP setting!

[server-Standard0]
name=Standard server 0
command=/usr/X11R6/bin/X -br -audit 0 -nolisten tcp -layout seat0 -sharevts -novtswitch -isolateDevice PCI:1:0:0
flexible=true

[server-Standard1]
name=Standard server 1
command=/usr/X11R6/bin/X -br -audit 0 -nolisten tcp -layout seat1 -sharevts -novtswitch -isolateDevice PCI:0:8:0
flexible=true

and my xorg.conf (see attachment). Also I added the no-scroll and removed splash booth parameters to solve the scrolling issue and proper initialization of displays.

I had this screen shifting problem on my multiseat system. I know very little of the internal things inside Xorg an GDM, but I managed to circumvent screen shifting with the following configuration in /etc/gdm/gdm.cont.

In [servers] section:

0=Standard device=/dev/console
1=Ilkka

[server-Ilkka]
name=Standard server
command=/usr/X11R6/bin/X -layout LayoutIlkka -br -audit 0 -nolisten tcp -sharevts -isolateDevice PCI:3:0:0 vt8
flexible=true
handled=true

***

Previously I had server section for my primary and secondary graphics card. Then shifting appeared. I configured X to start server 0 by default and I set up a server section in /etc/gdm/gdm.conf only for the second seat. Now the screen shifting has completely disappeared and both seats work nicely.

I verified it doesn't mess console by running screendump 1 to see that no characters are written to console. Now even switching to virtual terminals (ctrl+alt+f1..f6) doesn't mess the screen like before.

DO NOT USE no-scroll in kernel boot parameter for this because it just makes the problem harder to see and fix. The console at tty1 still works even if it doesn't scroll, so you can mess your computer badly if you type rm -rf * in a text editor in X because it is going to be executed in tty1 shell, too!

I have not had any problem with input going to the console using no-scroll. It is something to be aware of and test for, but it is a viable option to make things work. no-scroll has nothing to do with where input is sent. It's more likely that input showing up on the console directly is related to incorrect input configuration than the issue in this bug at all.

For all the users having problems with X keyboard input ending up on the console (bastafidli, Jeremy, others): I finally appear to have solved it for my system. Apparently, the newer evdev-code doesn't perform exclusive grabbing of the device anymore! See this http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=4912e2aa7f867a86d383010023b8426c881fb3b0 commit. So, the very simple fix is to add 'Option "GrabDevice" "yes"' to all your evdev input devices in xorg.conf.

I'm seeing much the same right shifting of the console while running a serial console. System is Dell T110 PowerEdge, running Ubuntu 10.04 Lucid. Serial Console is running on windows with the same results using either a mintty windows or a Cygwin X xterm window. It mostly seems to affect shutdown messages rather than boot messages, and, as far as I can figure out it's related to shutdown messages generated using echo -n. When the "newline" finally comes it causes a line feed but not a carriage return. The text gradually shifts right making some of it unreadable. I'm not sure this is the same problem you're seeing, but it sounds very similar.

In the case that I've examined I can add that the newline is supplied by the log_success_msg function in /etc/lsb-base-logging.sh which is sourced into the bash script providing the echo -n (Dell/SARA's /etc/init.d/dataeng in this particular case).

I now realise my comments were about a different kind of right-shifting behaviour which affects only the text on a line by line basis, not the whole screen, and which appears to be known as the "staircase effect". Sorry for posting off topic. But, since I started, I'll mention that I managed to solve the problem by disabling Plymouth at shutdown. I'm not sure if this has other undesirable effects, but it did sort out my shutdown messages!

For the record I filed this as Ubuntu Bug https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/606512

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

(Katya, 25yo), I serch for beloved man, are you?

hello again!
I am Katya 25 y.o
I wish to meet love of my life, are you?
Here are my message for you and new photos:

http://hotruladies.ru

Note!
New free service! check info at the site!
( to unsubscribe -click link and enter e-mail address.)