Bug 437706
Summary: | F-9 pv_ops xen: graphical nstall doesn't work - rhplx videocard probing doesn't find pvfb | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thomas DuBuisson <thomas.dubuisson> |
Component: | rhpxl | Assignee: | Adam Jackson <ajax> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | ajax, berrange, ehabkost, katzj, maurizio.antillon, poelstra, xen-maint |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | rhpxl-1.7-1.fc9 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-04-08 20:31:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 235706, 434756 |
Description
Thomas DuBuisson
2008-03-16 20:02:19 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: 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" :-). The fb driver should probably continue to be built-in rather than built as a module The fb driver is built in currently Markus: could you take a look? i'm seeing the same problem running RHEL5.2 beta (w/ latest packages) trying to install rawhide 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? 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 *** Whoops, did not mean to close 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 Right. This was the root of a log of the register_console/unregister_console stuff in the early pvfb patches. 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. 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. 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. Err, wins over tty in *domU*. 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. 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 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 ajax -- how did you want to handle fbdev devices in rhpxl now? 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) 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 Fix for this (I hope) built as rhpxl 1.4. Please test, and reopen if this isn't resolved. Thanks, seems to be working fine now with the 2008-04-10 install tree (i.e. rhpxl-1.7-1.fc9) |