Bug 437706 - F-9 pv_ops xen: graphical nstall doesn't work - rhplx videocard probing doesn't find pvfb
Summary: F-9 pv_ops xen: graphical nstall doesn't work - rhplx videocard probing doesn...
Alias: None
Product: Fedora
Classification: Fedora
Component: rhpxl
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F9Blocker PvOpsTracker
TreeView+ depends on / blocked
Reported: 2008-03-16 20:02 UTC by Thomas DuBuisson
Modified: 2013-01-21 20:20 UTC (History)
7 users (show)

Fixed In Version: rhpxl-1.7-1.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-08 20:31:21 UTC
Type: ---

Attachments (Terms of Use)

Description Thomas DuBuisson 2008-03-16 20:02:19 UTC
Description of problem:
When trying to install rawhide as a PVM the VNC window comes up but remains
empty (black).  This is probably due to xenfb not being in rawhides initrd.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Try in install rawhide as a Xen PVM.  Example cmd line provided in bug 437217.
Actual results:
Black VNC screen.

Expected results:
Text install options followed by the anaconda graphical installer within the VNC

Additional info:
The host is an up-to-date F8 with minor modifications to OSDistro.py to avoid
bug 437217.

GUI install of guest F8 works fine, as does text install of rawhide.

Comment 1 Thomas DuBuisson 2008-03-17 01:39:23 UTC
So the last screen of tty 4 gives me:
<6>Floppy drive(s): fd0 is unknown type 15 (usb?) ....
<3>IRQ handler type mismatch for IRQ 6
<3> current handler: vkbd
<4>Pid: 468, comm: modprobe Not tainted 2.5.25-0.2.rc4.fc9xen #1
... a stack trace - I can reproduce for you if you want ...
<4>floppy: Unable to grab IRQ6 for the floppy driver
<6>BIOS EDD facility ....
<6>EDD information ont available.
<6>input: PC Speaker ....
<6>squashfs: version ....
<5>iscsi: registered transport (tcp)
<6>NET: Registered protocol family 10
<6>lo: Disabled Privacy Extensions
<6>Initialising Xen virtual etherenet driver.
<6> xvda: xvda1 xvda2
<4>modprobe used greatest stack depth: 2312 bytes left

And tty3 gives me:
[time omitted] INFO   : kernel command line:

[time omitted] INFO   : anaconda version on i386 starting
[time omitted] INFO   : text mode forced due to serial/virtpconsole
[time omitted] INFO   : 508004 kB are available
FATAL: Error inserting floppy
(/lib/modules/2.6.25-0.2.rc4.fc9xen/kernel/drivers/block/floppy.ko): Device or
resource busy

Shame of shames, it is going to text mode then failing - but I don't want text
mode.  Hopefully this is a good bit more helpful than "black screen" :-).

Comment 2 Jeremy Katz 2008-03-17 01:59:23 UTC
The fb driver should probably continue to be built-in rather than built as a module

Comment 3 Mark McLoughlin 2008-03-18 12:30:51 UTC
The fb driver is built in currently

Markus: could you take a look?

Comment 4 John Poelstra 2008-03-26 02:14:23 UTC
i'm seeing the same problem running RHEL5.2 beta (w/ latest packages) trying to
install rawhide

Comment 5 Markus Armbruster 2008-03-26 14:34:53 UTC
As far as I can see, both vfb and vkbd initialize just fine, and displays a
blank screen (as the reporter wrote).  Looks like pvfb works, but guest user
space doesn't use it.

If I complete the text install and reboot into the newly installed system, pvfb
works.  Same kernel, isn't it?

Also note this line from comment#1:
[time omitted] INFO   : text mode forced due to serial/virtpconsole

This seems to suggest that anaconda forces a text install.  Why does it do that?

Comment 6 Jeremy Katz 2008-03-26 15:36:20 UTC
Aha, that line is the key.  This is just the second part of bug 434763 (but
going to leave it separate for now)

It looks like what's going on is that the kernel is setting up hvc0 as the
console rather than the framebuffer.  And so when we do auto-console detection
in anaconda, we find that there's hvc0 and that the kernel has set it up as the
console.  If you have the framebuffer set up, then it needs to be the console as
far as the kernel is concerned.  This is what some of the original pain involved
in the xenfb code was all about.

Back to kernel-xen for now

*** This bug has been marked as a duplicate of 434763 ***

Comment 7 Jeremy Katz 2008-03-26 15:40:22 UTC
Whoops, did not mean to close

Comment 8 Mark McLoughlin 2008-03-26 16:09:45 UTC
So, the logic we're talking about here is:

    static struct termios orig_cmode;
    struct termios cmode, mode;
    int cfd;
    cfd =  open("/dev/console", O_RDONLY);

    cmode = orig_cmode;
    cmode.c_lflag &= (~ECHO);

    cfd = open("/dev/console", O_WRONLY);
    char * consoles[] = { "/dev/xvc0", "/dev/hvc0", NULL };
    for (i = 0; consoles[i] != NULL; i++) {
        if ((fd = open(consoles[i], O_RDWR)) >= 0 && !tcgetattr(fd, &mode) &&
            !termcmp(&cmode, &mode)) {
            printf("anaconda installer init version %s using %s as console\n",
                   VERSION, consoles[i]);
            isSerial = 3;
            console = strdup(consoles[i]);

    cfd = open("/dev/console", O_WRONLY);
        if (isSerial == 3) {
            *argvp++ = "--virtpconsole";
            *argvp++ = console;

i.e. we only force --virtpconsole if /dev/hvc0 is what underlies /dev/console

and pvfb is what *should* underly /dev/console

Comment 9 Jeremy Katz 2008-03-26 17:05:35 UTC
Right.  This was the root of a log of the register_console/unregister_console
stuff in the early pvfb patches.  

Comment 10 Markus Armbruster 2008-03-27 10:52:56 UTC
I believe the culprit is
We put that in to make the Xen console just work.  It sets the default
preferred console to hvc0.  But with PVFB compiled in, we want the
preferred console to be PVFB, i.e. tty0.  It is when I take out that
patch in an upstream kernel.  I haven't tried with an f9 kernel, or an
actual install.

Comment 11 Daniel Berrangé 2008-03-27 13:22:37 UTC
Yes, we only want  hvc0  to be the primary console, when the guest is not
configured to use PVFB in xenstore. eg, so 'virt-install --nographics' gets
anaconda text mode sent to hvc0, while 'virt-install --vnc' gets anaconda
graphical mode to pvfb.

Comment 12 Markus Armbruster 2008-03-28 14:57:43 UTC
Consoles tty, hvc and ttyS register in this order.

The framebuffer isn't up yet then, and tty is still the dummy console.

Unless the kernel command line dictates otherwise, the first one to
register becomes *the* console (the one behind /dev/console).  This is
tty.  Except we patched things so that hvc wins over tty in dom0.

We want to use tty if we have PVFB, else hvc.

If we have PVFB, xenfb_probe() gets to run.  But by the time that
happens, the console game's over.

I'll dig some more.

Comment 13 Markus Armbruster 2008-03-28 15:04:05 UTC
Err, wins over tty in *domU*.

Comment 14 Jeremy Katz 2008-03-28 15:22:35 UTC
Right.  Some of the various ppc and ia64 platforms where this matters can check
the firmware info early in the boot sequence to see if they should change their
preferred to the serial-ish console.  The problem with having xen domU do so is
that it required xenstore which can't be accessed early. 

Comment 15 Mark McLoughlin 2008-04-01 14:00:53 UTC
I've dropped "prefer hvc0" patch again in kernel-xen-2.6-2.6.25-0.12.rc7.git6.fc9

bug #437761 should track getting hvc0 to be preferred if there's no pvfb

Comment 16 Mark McLoughlin 2008-04-03 13:44:25 UTC
Okay, now with kernel-xen-2.6-2.6.25-0.12.rc7.git6.fc9 I'm seeing:

  INFO: No video hardware found, assuming headless

Comment 17 Jeremy Katz 2008-04-03 13:53:22 UTC
ajax -- how did you want to handle fbdev devices in rhpxl now?

Comment 18 Mark McLoughlin 2008-04-03 14:56:17 UTC
rhplx seems to be filtering on pci.device_class, which pvfb doesn't have:

class VideoCardInfo:
    def __init__ (self, forceDriver = None):
        pdevs = [x for x in pdevs if x.GetPropertyInteger('pci.device_class') == 3]

lshal shows the following for pvfb:

udi = '/org/freedesktop/Hal/devices/xen_vfb_0'
  info.linux.driver = 'vfb'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
  info.product = 'Xen Device (vfb)'  (string)
  info.subsystem = 'xen'  (string)
  info.udi = '/org/freedesktop/Hal/devices/xen_vfb_0'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'xen'  (string)
  linux.sysfs_path = '/sys/devices/vfb-0'  (string)
  xen.bus_id = 'vfb-0'  (string)
  xen.path = 'device/vfb/0'  (string)
  xen.type = 'vfb'  (string)

Comment 19 Mark McLoughlin 2008-04-03 15:15:09 UTC
Just seems like the xen support got lost when moving from probing with kudzu,
which used to do:

    name = __readString(path);
    if (!name)
    if (!strcmp(name, "xen")) {
        xendev = xenNewDevice(NULL);
        xendev->desc = strdup("Xen Virtual Framebuffer");
        xendev->type = CLASS_VIDEO;
        xendev->driver = strdup("xenfb");
        xendev->classprivate = (void *)strdup("fbdev");
        if (devlist)
            xendev->next = devlist;
        devlist = (struct device *) xendev;

Moving to rhpxl

Comment 20 Adam Jackson 2008-04-08 20:31:21 UTC
Fix for this (I hope) built as rhpxl 1.4.  Please test, and reopen if this isn't

Comment 21 Mark McLoughlin 2008-04-11 09:24:56 UTC
Thanks, seems to be working fine now with the 2008-04-10 install tree

(i.e. rhpxl-1.7-1.fc9)

Note You need to log in before you can comment on or make changes to this bug.