X on UEFI systems.
Hi, folks.Currently at Virtualbox has introduced UEFI support in 3.1 release. But there is one issue with X server. When trying configure X with -configure. Resulted xorg.conf.new looks right except missed Modes. Observing code I've supposed that missed information should be somehow fetched from screen info (prepared by EFIFB) via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't called and doing strace of X -configure the /dev/fb0 is open and than immediately closed ([pastebin.org]). So the question is what should be added in VirtualBox/UEFI firmware to get full xorg.conf? xorg.conf.new Description: Binary data -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote: > Hi, folks. > > > Currently at Virtualbox has introduced UEFI support in 3.1 release. > But there is one issue with X server. When trying configure X with > -configure. Resulted xorg.conf.new looks right except missed Modes. > Observing code I've supposed that missed information should be somehow > fetched from screen info (prepared by EFIFB) > via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't > called and doing strace of X -configure the /dev/fb0 is open and than > immediately closed ([pastebin.org]). So the question is what should be > added in VirtualBox/UEFI firmware to get full xorg.conf? > Does it not work without an xorg.conf, that would be the first goal. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Dec 10, 2009, at 8:06 AM, Dave Airlie wrote: > On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote: >> Hi, folks. >> >> >> Currently at Virtualbox has introduced UEFI support in 3.1 release. >> But there is one issue with X server. When trying configure X with >> -configure. Resulted xorg.conf.new looks right except missed Modes. >> Observing code I've supposed that missed information should be somehow >> fetched from screen info (prepared by EFIFB) >> via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't >> called and doing strace of X -configure the /dev/fb0 is open and than >> immediately closed ([pastebin.org]). So the question is what should be >> added in VirtualBox/UEFI firmware to get full xorg.conf? >> > > Does it not work without an xorg.conf, that would be the first goal. > No. > Dave. > > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Dec 10, 2009, at 8:06 AM, Dave Airlie wrote:
> On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote:
>> Hi, folks.
>>
>>
>> Currently at Virtualbox has introduced UEFI support in 3.1 release.
>> But there is one issue with X server. When trying configure X with
>> -configure. Resulted xorg.conf.new looks right except missed Modes.
>> Observing code I've supposed that missed information should be somehow
>> fetched from screen info (prepared by EFIFB)
>> via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't
>> called and doing strace of X -configure the /dev/fb0 is open and than
>> immediately closed ([pastebin.org]). So the question is what should be
>> added in VirtualBox/UEFI firmware to get full xorg.conf?
>>
>
> Does it not work without an xorg.conf, that would be the first goal.
>
Right, ability to work with built-in config would be excellent :).
I've debugged X and X -configure and noticed in both cases
#0 fbdev_open (scrnIndex=, dev=0x1501fc "/dev/fb0",
namep=0x0) at fbdevhw.c:412
#1 0x0014fc80 in fbdevHWProbe (pPci=0x0, device=0x0, namep=0x0) at
fbdevhw.c:442
#2 0x00c5e4b5 in FBDevProbe (drv=0x8236b00, flags=) at
fbdev.c:394
#3 0x080a7c4e in xf86CallDriverProbe (drv=0x8236b00, detect_only=0) at
xf86Init.c:663
#4 0x080a92fe in InitOutput (pScreenInfo=0x8212500, argc=1, argv=0xbfd96fc4)
at xf86Init.c:939
#5 0x0806ba2b in main (argc=1, argv=0xbfd96fc4, envp=0xbfd96fcc) at main.c:315
fbdev_open called with namep = 0, that blocks fetch information from efifb
if (namep) {
if (-1 == ioctl(fd,FBIOGET_FSCREENINFO,(void*)(&fix))) {
*namep = NULL;
xf86DrvMsg(scrnIndex, X_ERROR,
"FBIOGET_FSCREENINFO: %s\n", strerror(errno));
return -1;
} else {
*namep = xnfalloc(16);
strncpy(*namep,fix.id,16);
}
}
calling right ioctl from gdb:
(gdb) call ioctl(fd,0x4602,(void*)(&fix))
$2 = 0
(gdb) p fix
$3 = {id = "EFI VGA\0\0\0\0\0\0\0\0", smem_start = 0x8000 , smem_len = 6291456, type = 0,
type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 0, ywrapstep = 0,
line_length = 4096, mmio_start = 0x0, mmio_len = 0, accel = 0,
reserved = {0, 0, 0}}
shows that efifb prepared right information for frame buffer clients.
the difference between X and X -configure, is vesa driver (it seems) tries to
occur information via libint10, assuming existence of VGA BIOS, which ofc is
absent in our case.
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Loading /usr/lib/xorg/modules//libvbe.so
(II) Module vbe: vendor="X.Org Foundation"
compiled for 1.6.3.901, module version = 1.1.0
ABI class: X.Org Video Driver, version 5.0
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/lib/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
compiled for 1.6.3.901, module version = 1.0.0
ABI class: X.Org Video Driver, version 5.0
(II) VESA(0): initializing int10
(EE) VESA(0): V_BIOS address 0x0 out of range
(II) UnloadModule: "vesa"
(II) UnloadModule: "int10"
(II) Unloading /usr/lib/xorg/modules//libint10.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/lib/xorg/modules//libvbe.so
(EE) Screen(s) found, but none have a usable configuration.
> Dave.
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >> Does it not work without an xorg.conf, that would be the first goal. >> > > No. File a bug please, attaching your xorg.conf, Xorg.0.log and output of the dmesg command (all from inside of VB virtual machine, of course). Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Why should I travel, when I'm already there? -- Bostonian lady, when being asked why she never visited other places than Boston -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Dec 10, 2009, at 10:57 AM, Matěj Cepl wrote: > Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >>> Does it not work without an xorg.conf, that would be the first goal. >>> >> >> No. > > File a bug please, attaching your xorg.conf, Xorg.0.log and output of > the dmesg command (all from inside of VB virtual machine, of course). > the bug is filed https://bugzilla.redhat.com/show_bug.cgi?id=546166 please let me know if more information is required. > Matěj > > -- > http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz > GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC > > Why should I travel, when I'm already there? >-- Bostonian lady, when being asked why she never visited >other places than Boston > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: > Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): > >> Does it not work without an xorg.conf, that would be the first goal. > >> > > > > No. > > File a bug please, attaching your xorg.conf, Xorg.0.log and output of > the dmesg command (all from inside of VB virtual machine, of course). ...nd (oh boy, I love it when a plan comes together) mark it as blocking F13Beta , because I reckon this breaks beta criterion #4: https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On 12/11/2009 02:41 PM, Adam Williamson wrote: > On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: >> Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): Does it not work without an xorg.conf, that would be the first goal. >>> >>> No. >> >> File a bug please, attaching your xorg.conf, Xorg.0.log and output of >> the dmesg command (all from inside of VB virtual machine, of course). > > ...nd (oh boy, I love it when a plan comes together) mark it as > blocking F13Beta , because I reckon this breaks beta criterion #4: > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria I like the sentiment here, but I'm not sure this is really in the spirit of the criteria - Vasily, as I understand it, is still in the process of implementing the support for UEFI on VirtualBox. Which is to say, yes, we need to fix the parts that are distro problems, but I'm not sure we've gotten to the point where VirtualBox+UEFI is expected to be a working system in the first place. But maybe I'm wrong - Vasily, what do you think? -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: > On 12/11/2009 02:41 PM, Adam Williamson wrote: > > On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: > >> Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): > Does it not work without an xorg.conf, that would be the first goal. > > >>> > >>> No. > >> > >> File a bug please, attaching your xorg.conf, Xorg.0.log and output of > >> the dmesg command (all from inside of VB virtual machine, of course). > > > > ...nd (oh boy, I love it when a plan comes together) mark it as > > blocking F13Beta , because I reckon this breaks beta criterion #4: > > > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > > I like the sentiment here, but I'm not sure this is really in the > spirit of the criteria - Vasily, as I understand it, is still in the > process of implementing the support for UEFI on VirtualBox. > > Which is to say, yes, we need to fix the parts that are distro problems, > but I'm not sure we've gotten to the point where VirtualBox+UEFI is > expected to be a working system in the first place. > > But maybe I'm wrong - Vasily, what do you think? >From what I saw in the thread, the bug seems to be that X is assuming the presence of a VGA BIOS, which would seem to be a fairly generic problem that would hit any EFI setup. AIUI anyway. See Vasily's message of a couple of days ago. But I could be wrong, and also I'm not sure why he's testing with F11 rather than F12 or Rawhide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Dec 12, 2009, at 1:27 AM, Adam Williamson wrote: > On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: >> On 12/11/2009 02:41 PM, Adam Williamson wrote: >>> On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): >> Does it not work without an xorg.conf, that would be the first goal. >> > > No. File a bug please, attaching your xorg.conf, Xorg.0.log and output of the dmesg command (all from inside of VB virtual machine, of course). >>> >>> ...nd (oh boy, I love it when a plan comes together) mark it as >>> blocking F13Beta , because I reckon this breaks beta criterion #4: >>> >>> https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria >> >> I like the sentiment here, but I'm not sure this is really in the >> spirit of the criteria - Vasily, as I understand it, is still in the >> process of implementing the support for UEFI on VirtualBox. >> >> Which is to say, yes, we need to fix the parts that are distro problems, >> but I'm not sure we've gotten to the point where VirtualBox+UEFI is >> expected to be a working system in the first place. >> >> But maybe I'm wrong - Vasily, what do you think? > Right, we still in progress (e.g. VBox 3.1 is failing to load FC12 with ACPI, and it can't load Windows Vista and 7/EFI) but with VBox 3.1 with manually edited config runs FC11(i386/x86_64) fine. >> From what I saw in the thread, the bug seems to be that X is assuming > the presence of a VGA BIOS, which would seem to be a fairly generic > problem that would hit any EFI setup. I guess real EFI systems has proprietary drivers + corresponding drivers, e.g. nvidia, and there're no serious reasons to use vga bios. > AIUI anyway. See Vasily's message > of a couple of days ago. But I could be wrong, and also I'm not sure why > he's testing with F11 rather than F12 or Rawhide. > About rawhide, could you please give me some pointers on ISO images, instructions for kernel compilations (looks like it bit different from compilation of vanilla kernels)? > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Sun, 2009-12-13 at 10:49 +0300, Vasily Levchenko wrote: > Right, we still in progress (e.g. VBox 3.1 is failing to load FC12 with ACPI, > and it can't load > Windows Vista and 7/EFI) but with VBox 3.1 with manually edited config runs > FC11(i386/x86_64) > fine. > > > >> From what I saw in the thread, the bug seems to be that X is assuming > > the presence of a VGA BIOS, which would seem to be a fairly generic > > problem that would hit any EFI setup. > > I guess real EFI systems has proprietary drivers + corresponding drivers, > e.g. nvidia, > and there're no serious reasons to use vga bios. Fedora never assumes the presence of proprietary drivers. When we say we want EFI to work, we mean with the drivers included in Fedora. > > AIUI anyway. See Vasily's message > > of a couple of days ago. But I could be wrong, and also I'm not sure why > > he's testing with F11 rather than F12 or Rawhide. > > About rawhide, could you please give me some pointers on ISO images, > instructions for kernel compilations (looks like it bit different from > compilation of > vanilla kernels)? Live images go up nightly here: http://alt.fedoraproject.org/pub/alt/nightly-composes/ building kernels - well, approaches differ. Personally I tend to grab the latest .src.rpm, make the changes I want in the spec, build it back into a .src.rpm and compile with mock. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: > On 12/11/2009 02:41 PM, Adam Williamson wrote: > > On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: > >> File a bug please, attaching your xorg.conf, Xorg.0.log and output of > >> the dmesg command (all from inside of VB virtual machine, of course). > > > > ...nd (oh boy, I love it when a plan comes together) mark it as > > blocking F13Beta , because I reckon this breaks beta criterion #4: > > > > https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria > > I like the sentiment here, but I'm not sure this is really in the > spirit of the criteria - Vasily, as I understand it, is still in the > process of implementing the support for UEFI on VirtualBox. There's at least two issues here. One is that we're not shipping the native X driver for vbox video yet. Last I checked this was because it's hidden away in the vbox source, and didn't build against whatever X server we were shipping, and that vbox upstream didn't _want_ it shipped externally yet because they hadn't finalized the interface. The other is that the kernel doesn't seem to be binding an efifb device to it, and/or that it is and X is not noticing that and thus loads vesa instead of fbdev. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Dec 14, 2009, at 5:44 PM, Adam Jackson wrote:
> On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote:
>> On 12/11/2009 02:41 PM, Adam Williamson wrote:
>>> On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote:
File a bug please, attaching your xorg.conf, Xorg.0.log and output of
the dmesg command (all from inside of VB virtual machine, of course).
>>>
>>> ...nd (oh boy, I love it when a plan comes together) mark it as
>>> blocking F13Beta , because I reckon this breaks beta criterion #4:
>>>
>>> https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
>>
>> I like the sentiment here, but I'm not sure this is really in the
>> spirit of the criteria - Vasily, as I understand it, is still in the
>> process of implementing the support for UEFI on VirtualBox.
>
> There's at least two issues here.
>
> One is that we're not shipping the native X driver for vbox video yet.
> Last I checked this was because it's hidden away in the vbox source, and
> didn't build against whatever X server we were shipping, and that vbox
> upstream didn't _want_ it shipped externally yet because they hadn't
> finalized the interface.
>
Right, looks like it isn't good time to package vboxvideo.
> The other is that the kernel doesn't seem to be binding an efifb device
> to it,
Kernel uses efifb, and progress bar with logo drawn in the center looks nice
and correct.
> and/or that it is and X is not noticing that and thus loads vesa
> instead of fbdev.
X detects fbdev right (at least X -configure creates xorg.conf with right
driver), but it couldn't detect modes (resolution)
using fbdev, thus X loads vesa to somehow fill the gaps imho.
#0 fbdev_open (scrnIndex=, dev=0x1501fc "/dev/fb0",
namep=0x0) at fbdevhw.c:412
#1 0x0014fc80 in fbdevHWProbe (pPci=0x0, device=0x0, namep=0x0) at
fbdevhw.c:442
#2 0x00c5e4b5 in FBDevProbe (drv=0x8236b00, flags=) at
fbdev.c:394
#3 0x080a7c4e in xf86CallDriverProbe (drv=0x8236b00, detect_only=0) at
xf86Init.c:663
#4 0x080a92fe in InitOutput (pScreenInfo=0x8212500, argc=1, argv=0xbfd96fc4)
at xf86Init.c:939
#5 0x0806ba2b in main (argc=1, argv=0xbfd96fc4, envp=0xbfd96fcc) at main.c:315
fbdev_open with (,namep = 0x0,) doesn't call ioctl(/*
/dev/fb0*/,FBIOGET_FSCREENINFO,), which might returns required information:
(gdb) call ioctl(fd,0x4602,(void*)(&fix))
$2 = 0
(gdb) p fix
$3 = {id = "EFI VGA\0\0\0\0\0\0\0\0", smem_start = 0x8000 , smem_len = 6291456, type = 0,
type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 0, ywrapstep = 0,
line_length = 4096, mmio_start = 0x0, mmio_len = 0, accel = 0,
reserved = {0, 0, 0}}
ioctl(/* /dev/fb0*/,FBIOGET_FSCREENINFO,) called from fbdev_open with (,namep
!= 0x0,), but I am not sure how fbdevHWProbe(,namep != 0x0,) will affect
probing algorithm and X working :) .
>
> - ajax
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
