Bug 437706 - F-9 pv_ops xen: graphical nstall doesn't work - rhplx videocard probing doesn't find pvfb
F-9 pv_ops xen: graphical nstall doesn't work - rhplx videocard probing doesn...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rhpxl (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F9Blocker PvOpsTracker
  Show dependency treegraph
 
Reported: 2008-03-16 16:02 EDT by Thomas DuBuisson
Modified: 2013-01-21 15:20 EST (History)
7 users (show)

See Also:
Fixed In Version: rhpxl-1.7-1.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-08 16:31:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Thomas DuBuisson 2008-03-16 16:02:19 EDT
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:
Consistent

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
window.

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-16 21:39:23 EDT
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:
method=http://mirrors/kernel.org/fedora/

[time omitted] INFO   : anaconda version 11.4.0.52 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-16 21:59:23 EDT
The fb driver should probably continue to be built-in rather than built as a module
Comment 3 Mark McLoughlin 2008-03-18 08:30:51 EDT
The fb driver is built in currently

Markus: could you take a look?

Comment 4 John Poelstra 2008-03-25 22:14:23 EDT
i'm seeing the same problem running RHEL5.2 beta (w/ latest packages) trying to
install rawhide
Comment 5 Markus Armbruster 2008-03-26 10:34:53 EDT
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 11:36:20 EDT
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 11:40:22 EDT
Whoops, did not mean to close
Comment 8 Mark McLoughlin 2008-03-26 12:09:45 EDT
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);
    tcgetattr(cfd,&orig_cmode);
    close(cfd);

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

    cfd = open("/dev/console", O_WRONLY);
    tcsetattr(cfd,TCSANOW,&cmode);
    close(cfd);
    ...
    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]);
            break;
        }
        close(fd);
    }

    cfd = open("/dev/console", O_WRONLY);
    tcsetattr(cfd,TCSANOW,&orig_cmode);
    close(cfd); 
    ...
        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 13:05:35 EDT
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 06:52:56 EDT
I believe the culprit is
linux-2.6-xen-0004-xen-Make-hvc0-the-preferred-console-in-domU.patch
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 Berrange 2008-03-27 09:22:37 EDT
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 10:57:43 EDT
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 11:04:05 EDT
Err, wins over tty in *domU*.
Comment 14 Jeremy Katz 2008-03-28 11:22:35 EDT
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 10:00:53 EDT
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 09:44:25 EDT
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 09:53:22 EDT
ajax -- how did you want to handle fbdev devices in rhpxl now?
Comment 18 Mark McLoughlin 2008-04-03 10:56:17 EDT
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 11:15:09 EDT
Just seems like the xen support got lost when moving from probing with kudzu,
which used to do:

    snprintf(path,64,"/sys/class/graphics/fb%d/name",i);
    name = __readString(path);
    if (!name)
        break;
    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 16:31:21 EDT
Fix for this (I hope) built as rhpxl 1.4.  Please test, and reopen if this isn't
resolved.
Comment 21 Mark McLoughlin 2008-04-11 05:24:56 EDT
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.