Bugzilla – Bug 297441
[XEN]When booting into XEN, you have to restart X before it comes up right
Last modified: 2007-08-21 04:42:55 UTC
Description: Boot into XEN (runlevel 5), X should appear off in one way or another (half screen, fuzzy, or some other variation), in order to have it come up proper you have to hit 'ctrl atl backspace'
I also see such problems on my HP Compaq nx6325 laptop with openSUSE 10.3. When X starts, the screen "fades" to all white. I don't even have to kill X to get it back; I have to hit Ctrl-Alt-F1 then Ctrl-Alt-F7 and then my desktop repaints fine. (Maybe this reinitializes the video card somehow?) This does not occur when I boot openSUSE 10.3 without Xen. It also does not occur with SLES 10 SP1 (with or without Xen).
Created attachment 155763 [details] hwinfo from my laptop
Created attachment 155775 [details] Xorg log after failure
How does the logfile look like when the Xserver starts fine (the second time)? Please also attach /etc/X11/xorg.conf.
Charles, would you be able to provide that second log?
Created attachment 155784 [details] xorg.conf from laptop
Created attachment 155785 [details] log file after restarting X coffing@ccoffing1:~> diff Xorg.0.log.bad Xorg.0.log.good 14c14 < (==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 6 11:52:24 2007 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 6 13:18:36 2007 1015d1014 < SynapticsCtrl called. 1027c1026 < (**) RADEON(0): Programming CRTC2, offset: 0x00000000 --- > (**) RADEON(0): Programming CRTC2, offset: 0x40000000
Hmm. Given that the third time the Xserver works as well. What's the difference in logfile between second and third time? I want to make sure that the difference between first and second Xserver start are relevant at all.
This might be easier to investigate if you have an opensuse 10.3 alpha7 machine with xen installed on it. Again, Charles can I have you grab the third log file off of your machine. thanks
Created attachment 155826 [details] tar file of the 3 logs I had to reinstall, so I re-did all 3 logs to be sure they are comparable. Process was: booted moved log to .1 init 3 init 5 moved log to .2 init 3 init 5 moved log to .3
Relevant changes: --- Xorg.0.log.1.bad 2007-08-07 00:54:40.000000000 +0200 +++ Xorg.0.log.2.good 2007-08-07 00:56:14.000000000 +0200 @@ -1023,7 +1023,7 @@ (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. -(**) RADEON(0): Programming CRTC2, offset: 0x00000000 +(**) RADEON(0): Programming CRTC2, offset: 0x40000000 (**) RADEON(0): Wrote: 0x00000000 0x00000000 0x00000000 (0x00006400) (**) RADEON(0): Wrote: rd=0, fd=0, pd=0 (**) RADEON(0): Programming CRTC1, offset: 0x00000000 --- Xorg.0.log.1.bad 2007-08-07 00:54:40.000000000 +0200 +++ Xorg.0.log.3.good 2007-08-07 00:56:47.000000000 +0200 @@ -1023,7 +1023,7 @@ (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. -(**) RADEON(0): Programming CRTC2, offset: 0x00000000 +(**) RADEON(0): Programming CRTC2, offset: 0x40000000 (**) RADEON(0): Wrote: 0x00000000 0x00000000 0x00000000 (0x00006400) (**) RADEON(0): Wrote: rd=0, fd=0, pd=0 (**) RADEON(0): Programming CRTC1, offset: 0x00000000
Reassigning to Luc.
This issue might not be Xen kernel related at all. Disable earlyxdm by running "chkconfig earlyxdm off". Then restart your system to verify if the problem persists.
could be a similar problem as #299623. Still, i'm not ready to mark it as duplicate.
If you are going to add needinfo to me, then you need to ask me something??? I don't know what info you need...
I looked at bug #299623 I don't think these are the same issue at all. All of the machines that this has happened on work just fine without XEN. Did you want me to try disabling earlyxdm? If so, I soon as I get back from my vacation I can do that. Should be this Friday.
Yes, see comment #15.
Still no feedback. :-( What's the output of fbset with and without running the XEN kernel?
sorry, I was on vacation. It looks like disabling earlyxdm works. do you still need the fbset output? If so, where do I grab that from?
Yes, I'm still interested. fbset should be installed. It's part of fbset package.
that doesn't help me, I think. Do I just run 'fbset'? Never used the tool
Of course. What else should you do with a command than just run it?
most of the linux commands that I run have switches. Usually without them they are relatively useless :P booted into XEN xen14:~ # fbset open /dev/fb0: No such file or directory xen14:~ # booted without XEN xen14:~ # fbset mode "1024x768-76" # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 16 timings 12714 128 32 16 4 128 4 rgba 5/11,6/5,5/0,0/0 endmode xen14:~ #
Then I bet it's a duplicate of Bug #299623. See comments #63/65. Please verify.
*** This bug has been marked as a duplicate of bug 302010 ***
> most of the linux commands that I run have switches. Usually without them they > are relatively useless :P Right. Not in this case, though. Otherwise we would have told you ;) > > booted into XEN > > xen14:~ # fbset > open /dev/fb0: No such file or directory This is the line we were looking for. Thx! > xen14:~ # > > > booted without XEN > > xen14:~ # fbset > > mode "1024x768-76" > # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz > geometry 1024 768 1024 768 16 > timings 12714 128 32 16 4 128 4 > rgba 5/11,6/5,5/0,0/0 > endmode Cool! And I assume here you don't see any distortions, right? This indeed looks like the other bugs which Stefan has already marked as duplicates of this one.