For awhile now I've been struggling with what is probably a Vesa driver issue related to but different from Fedora Core bug# 10238. I'm running the latest X (7.2) under FC6 in a Parallels VM on a Mac and the server won't start unless I specify the HorizSync in the Monitor section of xorg.conf. I dug around and found references to vesa-1.3.0-range-hack.patch which I applied but this made no difference. My group is putting together a livecd for demo purposes and the xorg.conf generated by system-config-display (FC6) doesn't add a HorizSync so X won't start. Hopefully someone will have an idea how to fix this otherwise I might have to hack the config to add the HorizSync as an interim solution, any thoughts?
On Sun, 2007-03-25 at 08:24 -0600, Xavier Toth wrote:
For awhile now I've been struggling with what is probably a Vesa driver issue related to but different from Fedora Core bug# 10238. I'm running the latest X (7.2) under FC6 in a Parallels VM on a Mac and the server won't start unless I specify the HorizSync in the Monitor section of xorg.conf. I dug around and found references to vesa-1.3.0-range-hack.patch which I applied but this made no difference. My group is putting together a livecd for demo purposes and the xorg.conf generated by system-config-display (FC6) doesn't add a HorizSync so X won't start. Hopefully someone will have an idea how to fix this otherwise I might have to hack the config to add the HorizSync as an interim solution, any thoughts?
Parallels needs to be taught to emulate DDC as well, it seems.
But if you have an X log, and there's an identifying string in the VBE info, then we might be able to hack something up.
- ajax
Indeed I do have a log file and I'd greatly appreciate any assistance you can give me.
On 3/26/07, Adam Jackson ajackson@redhat.com wrote:
On Sun, 2007-03-25 at 08:24 -0600, Xavier Toth wrote:
For awhile now I've been struggling with what is probably a Vesa driver issue related to but different from Fedora Core bug# 10238. I'm running the latest X (7.2) under FC6 in a Parallels VM on a Mac and the server won't start unless I specify the HorizSync in the Monitor section of xorg.conf. I dug around and found references to vesa-1.3.0-range-hack.patch which I applied but this made no difference. My group is putting together a livecd for demo purposes and the xorg.conf generated by system-config-display (FC6) doesn't add a HorizSync so X won't start. Hopefully someone will have an idea how to fix this otherwise I might have to hack the config to add the HorizSync as an interim solution, any thoughts?
Parallels needs to be taught to emulate DDC as well, it seems.
But if you have an X log, and there's an identifying string in the VBE info, then we might be able to hack something up.
- ajax
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, 2007-03-26 at 13:58 -0600, Xavier Toth wrote:
Indeed I do have a log file and I'd greatly appreciate any assistance you can give me.
That log appears to be from a successful startup. Odd.
We can definitely tell if we're running under Parallels though:
(II) VESA(0): VESA VBE OEM Vendor: Parallels Software International, Inc.
The trick is just knowing what we're supposed to do when we detect Parallels. I don't have it, so I don't know. What _should_ we do?
- ajax
The error that kills the xserver ends up on stderr. This may be a bug in the xserver or the Xinerama extension and I will pursue that. In the meantime as an interim solution maybe you could direct me as to how I could hack the system-config-display to add a HorizSync line to the xorg.conf file.
On 3/26/07, Adam Jackson ajackson@redhat.com wrote:
On Mon, 2007-03-26 at 13:58 -0600, Xavier Toth wrote:
Indeed I do have a log file and I'd greatly appreciate any assistance you can give me.
That log appears to be from a successful startup. Odd.
We can definitely tell if we're running under Parallels though:
(II) VESA(0): VESA VBE OEM Vendor: Parallels Software International, Inc.
The trick is just knowing what we're supposed to do when we detect Parallels. I don't have it, so I don't know. What _should_ we do?
- ajax
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, 2007-03-27 at 10:23 -0600, Xavier Toth wrote:
The error that kills the xserver ends up on stderr. This may be a bug in the xserver or the Xinerama extension and I will pursue that. In the meantime as an interim solution maybe you could direct me as to how I could hack the system-config-display to add a HorizSync line to the xorg.conf file.
That log is not from any X server we've ever shipped. Neither the FC6 or FC7 X server will try to talk to dbus, or issue any error messages that look like that.
- ajax
I'm sorry if I didn't make it clear but as I mentioned in my original post I'm building and running the latest (7.2) with the XACE patches because of a requirement to run a trusted X. From what I understand this code base is what may be built in FC8 but you would know better than I. Hopefully you can still help me understand what would need to be done to get a xorg.conf that will function for our livecd :)
Ted
Adam Jackson wrote:
On Tue, 2007-03-27 at 10:23 -0600, Xavier Toth wrote:
The error that kills the xserver ends up on stderr. This may be a bug in the xserver or the Xinerama extension and I will pursue that. In the meantime as an interim solution maybe you could direct me as to how I could hack the system-config-display to add a HorizSync line to the xorg.conf file.
That log is not from any X server we've ever shipped. Neither the FC6 or FC7 X server will try to talk to dbus, or issue any error messages that look like that.
- ajax
On Tue, 2007-03-27 at 13:26 -0500, Ted X Toth wrote:
I'm sorry if I didn't make it clear but as I mentioned in my original post I'm building and running the latest (7.2) with the XACE patches because of a requirement to run a trusted X. From what I understand this code base is what may be built in FC8 but you would know better than I. Hopefully you can still help me understand what would need to be done to get a xorg.conf that will function for our livecd :)
X is coming up. GTK is crashing.
Run "X -verbose :0" by itself and notice how your X server comes up just fine. Then control-alt-backspace, run startx, and watch the session fall over.
The reason GTK is aborting is because the security extension is prohibiting it from doing things that it would normally otherwise do. In other words, you asked for it, and you got it.
- ajax
I agree that GTK is crashing and bringing down the server but I don't agree that it is doing so because of the XSELinux extension. First of all I'm currently running in permissive mode because the policy for the extension is still being developed so nothing really gets 'prohibited'. And then there's the fact that all I have to do is add a HorizSync line to my xorg.conf file and sure enough the xserver/gnome/... starts and life is good (albeit that the extension generates so many of its' idea of an avc that the log eats up all of my virtual disk space).
Ted
Adam Jackson wrote:
On Tue, 2007-03-27 at 13:26 -0500, Ted X Toth wrote:
I'm sorry if I didn't make it clear but as I mentioned in my original post I'm building and running the latest (7.2) with the XACE patches because of a requirement to run a trusted X. From what I understand this code base is what may be built in FC8 but you would know better than I. Hopefully you can still help me understand what would need to be done to get a xorg.conf that will function for our livecd :)
X is coming up. GTK is crashing.
Run "X -verbose :0" by itself and notice how your X server comes up just fine. Then control-alt-backspace, run startx, and watch the session fall over.
The reason GTK is aborting is because the security extension is prohibiting it from doing things that it would normally otherwise do. In other words, you asked for it, and you got it.
- ajax
On Tue, 2007-03-27 at 14:39 -0500, Ted X Toth wrote:
I agree that GTK is crashing and bringing down the server but I don't agree that it is doing so because of the XSELinux extension. First of all I'm currently running in permissive mode because the policy for the extension is still being developed so nothing really gets 'prohibited'. And then there's the fact that all I have to do is add a HorizSync line to my xorg.conf file and sure enough the xserver/gnome/... starts and life is good (albeit that the extension generates so many of its' idea of an avc that the log eats up all of my virtual disk space).
The X log you gave earlier from running under Parallels shows it _not_ using any HorizSync line from the config file, and starting up at the perfectly expected 800x600.
- ajax
Correct x.log (which is a capture of stdout and stderr and not the real log file, Xorg.0.log) was a capture of the failure mode, no HorizSync in the config file. I sent that because the GTK error message doesn't get written to Xorg.0.log. So the scenario is the server seems to be coming up just fine then the GTK error occurs and the server aborts. The way I originally figured out to add HorizSync to the config file was by debugging through the server and seeing a huge obviously invalid value for the horizontal sync. What I'm going to do is go back and figure out exactly where that value was coming from and hopefully that will shed some light on the root of the problem.
Adam Jackson wrote:
On Tue, 2007-03-27 at 14:39 -0500, Ted X Toth wrote:
I agree that GTK is crashing and bringing down the server but I don't agree that it is doing so because of the XSELinux extension. First of all I'm currently running in permissive mode because the policy for the extension is still being developed so nothing really gets 'prohibited'. And then there's the fact that all I have to do is add a HorizSync line to my xorg.conf file and sure enough the xserver/gnome/... starts and life is good (albeit that the extension generates so many of its' idea of an avc that the log eats up all of my virtual disk space).
The X log you gave earlier from running under Parallels shows it _not_ using any HorizSync line from the config file, and starting up at the perfectly expected 800x600.
- ajax
On Tue, 2007-03-27 at 15:45 -0500, Ted X Toth wrote:
Correct x.log (which is a capture of stdout and stderr and not the real log file, Xorg.0.log) was a capture of the failure mode, no HorizSync in the config file. I sent that because the GTK error message doesn't get written to Xorg.0.log. So the scenario is the server seems to be coming up just fine then the GTK error occurs and the server aborts. The way I originally figured out to add HorizSync to the config file was by debugging through the server and seeing a huge obviously invalid value for the horizontal sync. What I'm going to do is go back and figure out exactly where that value was coming from and hopefully that will shed some light on the root of the problem.
Please don't top post.
You're still managing to avoid the original question here, which is "what should the vesa driver do when it notices it's being run under Parallels". Every log I've seen from you is of the server _starting_, and getting far enough that it can actually serve clients.
We can easily fix the vesa driver to do something smarter in that situation, which avoids ever screwing with the config file, or with the horror of s-c-d.
- ajax
Adam Jackson wrote:
On Tue, 2007-03-27 at 15:45 -0500, Ted X Toth wrote:
Correct x.log (which is a capture of stdout and stderr and not the real log file, Xorg.0.log) was a capture of the failure mode, no HorizSync in the config file. I sent that because the GTK error message doesn't get written to Xorg.0.log. So the scenario is the server seems to be coming up just fine then the GTK error occurs and the server aborts. The way I originally figured out to add HorizSync to the config file was by debugging through the server and seeing a huge obviously invalid value for the horizontal sync. What I'm going to do is go back and figure out exactly where that value was coming from and hopefully that will shed some light on the root of the problem.
Please don't top post.
You're still managing to avoid the original question here, which is "what should the vesa driver do when it notices it's being run under Parallels". Every log I've seen from you is of the server _starting_, and getting far enough that it can actually serve clients.
We can easily fix the vesa driver to do something smarter in that situation, which avoids ever screwing with the config file, or with the horror of s-c-d.
- ajax
I'm not avoiding the question at this point I just don't know what the right answer is. When I have more information I'll post again.
Ted
-
Adam Jackson -
Ted Toth