VirtualBox

Opened 14 years ago

Closed 14 years ago

#5760 closed defect (invalid)

X stays black in Gentoo guest on Kubuntu 9.10 host -> closed as obsolete

Reported by: Rutger van Bergen Owned by:
Component: GUI Version: VirtualBox 3.1.0
Keywords: X black Cc:
Guest type: Linux Host type: Linux

Description

I have a VirtualBox 3.1.0 machine running Gentoo (kernel 2.6.31) on a Kubuntu 9.10 host. I installed the guest additions that came with VirtualBox (that is, not the ones that are available as Gentoo packages), and fired up Xorg (1.6.5) after that. What happens then is that the virtual machine's window resizes but stays black, while the Xorg log file seems to indicate that X started successfully. It is possible to successfully switch to another tty (using Host + Fn), from which I can then kill X. When X is killed, the console does come back up normally.

I have tested this using a plain text console and a VESA framebuffer console (albeit in the opposite order), with the exact same result both times.

I'm attaching my Xorg.0.log and xorg.conf for your reference.

Attachments (5)

xorg.conf.txt (2.6 KB ) - added by Rutger van Bergen 14 years ago.
Xorg.conf file
Xorg.0.log (12.8 KB ) - added by Rutger van Bergen 14 years ago.
Xorg server log file
Xorg.0.log.kdm (16.8 KB ) - added by Rutger van Bergen 14 years ago.
Xorg server log file, with KDM enabled
xorg.conf.kdm (2.6 KB ) - added by Rutger van Bergen 14 years ago.
Xorg.conf file, used when the Xorg.0.log.kdm file was generated
Xorg.0.log.novboxmouse (16.2 KB ) - added by Rutger van Bergen 14 years ago.
Xorg server log file, with KDM, without the VBox mouse driver

Download all attachments as: .zip

Change History (14)

by Rutger van Bergen, 14 years ago

Attachment: xorg.conf.txt added

Xorg.conf file

by Rutger van Bergen, 14 years ago

Attachment: Xorg.0.log added

Xorg server log file

comment:1 by Michael Thayer, 14 years ago

The log file shows a server segfault (crash). Unfortunately there is no trace information available in the log file. When you say that you tested this with the VESA framebuffer, do you mean that you re-enabled the VESA driver? And what happens if you delete (or rename) the VBox mouse driver?

comment:2 by Rutger van Bergen, 14 years ago

First off, I want to thank you for responding so quickly.

The "crash" you mentioned is caused by, or at least related to, me hitting Ctrl-C in the console that I started X in, with the purpose of killing it. The log you looked at was generated when the VESA framebuffer was disabled, but the results are exactly the same (even at a logging level) when it is enabled.

Anyway, in the meantime the plot has thickened further. I have installed (that is, emerged) KDE 4.3.3, and now the behavior is different. When I start kdm I *do* get the kdm login screen, but after entering my credentials, the screen turns and stays black again. With one relevant difference: this time there is a blinking (text console) cursor in the upper left corner of the screen, which was not there in the "bare X" scenario. In the area of logging there are also differences. In /var/log/messages, kdm is making the following complaints (vboxvideo related kernel messages included because of potential relevance):

Dec 15 10:20:03 vbox-gentoo kernel: [ 125.103993] pci 0000:00:02.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11 Dec 15 10:20:03 vbox-gentoo kernel: [ 125.109579] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0 Dec 15 10:20:12 vbox-gentoo kdm: :0[3585]: Cannot open ConsoleKit session: Unable to open session: Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success Dec 15 10:20:12 vbox-gentoo kdm: :0[3585]: Client start failed Dec 15 10:20:12 vbox-gentoo kdm: :0[3585]: Cannot close ConsoleKit session: Unable to close session: no session open Dec 15 10:20:13 vbox-gentoo kdm[3578]: X server for display :0 terminated unexpectedly Dec 15 10:20:13 vbox-gentoo kdm[3578]: Unable to fire up local display :0; disabling.

The Xorg.0.log file does now show a "spontaneous" crash. See the Xorg.0.log.kdm attachment that I will add in a minute. I will also attach my current xorg.conf (xorg.conf.kdm), in which I have commented out the Input section in which the keyboard module is explicitly loaded.

For purpose of completeness, I want to note that the logs have been created when the VESA framebuffer was disabled.

I have not yet tried to rename the VBox mouse driver, which I will try as soon as possible after finishing this addition to the ticket. I expect, but I admit that is not based on any knowledge of the inner structure or workings of the VBox drivers, that will not make much of a difference, considering the fact that the X backtrace does not mention the mouse, but instead the video driver.

Anyway, I will let you know what the results of that are, and perhaps the new attachments constitute a clue until then.

by Rutger van Bergen, 14 years ago

Attachment: Xorg.0.log.kdm added

Xorg server log file, with KDM enabled

by Rutger van Bergen, 14 years ago

Attachment: xorg.conf.kdm added

Xorg.conf file, used when the Xorg.0.log.kdm file was generated

comment:3 by Rutger van Bergen, 14 years ago

I have retested, this time with the VBox mouse driver renamed, with no functional difference. The only difference (which was expected) is that the Xorg log (Xorg.0.log.novboxmouse) now mentions that it can't find the vbox mouse driver.

by Rutger van Bergen, 14 years ago

Attachment: Xorg.0.log.novboxmouse added

Xorg server log file, with KDM, without the VBox mouse driver

comment:4 by Rutger van Bergen, 14 years ago

This message is just to indicate that the issue still occurs in VirtualBox 3.1.2.

comment:5 by Michael Thayer, 14 years ago

The crash in Xorg.0.log.kdm occurs inside a call to VBOXMapVidMem., and this issue looks similar to #5788, which was apparently a bug in X.Org Server. Might this be the same thing?

comment:6 by Rutger van Bergen, 14 years ago

I certainly can't rule it out, because the highest stable xorg-server version in Gentoo is 1.6.5 (plus one round of patches), and the last comment of bug #5788 refers to a patched version of 1.7.4. If it is a bug in X.Org Server, would that mean that it is not possible to run Gentoo with X in VirtualBox until 1.7.4 (with the apparently necessary patches) is marked stable within Gentoo?

comment:7 by Michael Thayer, 14 years ago

Maybe you could try the Gentoo X.Org maintainers? Sorry if I sound mean, but I really don't feel like setting up a Gentoo VM just now to investigate, especially not if there is a good chance that it is someone else's bug.

comment:8 by Rutger van Bergen, 14 years ago

I wouldn't say it sounds mean, I would say it's fair enough. Anyway, I have actually moved away from running Gentoo in VirtualBox; instead I'm running it as the host OS now. Sorry if I sound mean ( ;-) ), but I do have to say that the "Gentoo version" of X.Org does run fine directly on the hardware, which seems to indicate that although the issue may be fixed by a modification in X.Org, it is the combination of X.Org and VirtualBox that makes the issue manifest itself. For the purpose of being complete: on the Gentoo host I am now running OpenSolaris within VirtualBox (on the Gentoo host), with X running perfectly both on Gentoo and OpenSolaris.

comment:9 by Michael Thayer, 14 years ago

Resolution: invalid
Status: newclosed
Summary: X stays black in Gentoo guest on Kubuntu 9.10 hostX stays black in Gentoo guest on Kubuntu 9.10 host -> closed as obsolete

In that case I will close the ticket. Thanks for letting me know!

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use