|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] Re: FULL VIRTUALIZATION - missing /dev/fb0
The kernel options are the same and are set to "y".
But I have found in /dev/.udev/failed the file devices@platform@vesafb.0
But in no log found what could be wrong with vesafb...
Is there any logging of udev events? I found only /dev/hotplug.log, which
does not contain any interesting information (errors, etc.)...
With regards
Archie
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Petersson, Mats
Sent: Thursday, June 21, 2007 1:06 PM
To: Artur Linhart - Linux communication; Andre Rein;
xen-users@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-users] Re: FULL VIRTUALIZATION - missing /dev/fb0
> -----Original Message-----
> From: Artur Linhart - Linux communication
> [mailto:AL.LINUX@xxxxxxxxxxx]
> Sent: 21 June 2007 12:02
> To: Petersson, Mats; 'Andre Rein'; xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Re: FULL VIRTUALIZATION - missing /dev/fb0
>
> Hello,
>
> Yes there are a lot of differences (for example, in the section
> dedicated to the initialization of the CPU1-3 there are no
> messages by Xen,
> by etch it is normally initialized - see evt. the attachments).
> Related to the console and the fb device there are following
> differences:
>
> Dmesg-xen:
> io scheduler cfq registered (default)
> Real Time Clock Driver v1.12ac
>
> - between both this two lines there is nothing by xen, but by
> etch there is
> the loading of the vesafb driver and creation of /dev/fb0:
>
> Dmesg-etch:
> io scheduler cfq registered (default)
> PCI: Setting latency timer of device 0000:00:02.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:02.0:pcie00]
> Allocate Port Service[0000:00:02.0:pcie01]
> PCI: Setting latency timer of device 0000:00:03.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:03.0:pcie00]
> Allocate Port Service[0000:00:03.0:pcie01]
> PCI: Setting latency timer of device 0000:00:04.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:04.0:pcie00]
> Allocate Port Service[0000:00:04.0:pcie01]
> PCI: Setting latency timer of device 0000:00:05.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:05.0:pcie00]
> Allocate Port Service[0000:00:05.0:pcie01]
> PCI: Setting latency timer of device 0000:00:06.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:06.0:pcie00]
> Allocate Port Service[0000:00:06.0:pcie01]
> PCI: Setting latency timer of device 0000:00:07.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:07.0:pcie00]
> Allocate Port Service[0000:00:07.0:pcie01]
> PCI: Setting latency timer of device 0000:01:00.0 to 64
> Allocate Port Service[0000:01:00.0:pcie10]
> Allocate Port Service[0000:01:00.0:pcie11]
> PCI: Setting latency timer of device 0000:02:00.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:02:00.0:pcie20]
> Allocate Port Service[0000:02:00.0:pcie21]
> Allocate Port Service[0000:02:00.0:pcie22]
> PCI: Setting latency timer of device 0000:02:01.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:02:01.0:pcie20]
> Allocate Port Service[0000:02:01.0:pcie21]
> PCI: Setting latency timer of device 0000:02:02.0 to 64
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:02:02.0:pcie20]
> Allocate Port Service[0000:02:02.0:pcie21]
> vesafb: framebuffer at 0xb0000000, mapped to 0xffffc20010100000, using
> 3072k, total 16384k
> vesafb: mode is 1024x768x16, linelength=2048, pages=9
> vesafb: scrolling: redraw
> vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
> Console: switching to colour frame buffer device 128x48
> fb0: VESA VGA frame buffer device
> Real Time Clock Driver v1.12ac
>
> I have no idea, why by xen nothing happens...
I don't think the "Found MSI capability" has much to do with the FB, but I
would say that it indicates that youre VESA-FB driver is either not loading
at all (do you have "CONFIG_FB_VESA=y" in the .config for your Linux build?)
or there's something wrong with the driver that decides to not instantiate
itself with no error message.
--
Mats
>
> Cheers
>
> Archie
>
> -----Original Message-----
> From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
> Sent: Thursday, June 21, 2007 12:23 PM
> To: Artur Linhart - Linux communication; Andre Rein;
> xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Re: FULL VIRTUALIZATION - missing /dev/fb0
>
>
>
> > -----Original Message-----
> > From: Artur Linhart - Linux communication
> > [mailto:AL.LINUX@xxxxxxxxxxx]
> > Sent: 21 June 2007 11:03
> > To: Petersson, Mats; 'Andre Rein'; xen-users@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-users] Re: FULL VIRTUALIZATION - missing /dev/fb0
> >
> > Hello, Mats,
> >
> > I have problems with "xenified" Dom0 (Etch). The original Etch
> > booted directly works normally, also framebuffer device is
> > present and I can
> > start the graphical applications like directvnc, etc.. But if
> > I boot Etch as
> > xen Dom0, the /dev/df0 is not present - also if I specify the kernel
> > parameter vga=... then it is not reflected, the console is
> > still in text
> > mode...
> >
> > So, from the point of view of the mail before, it "is
> > correctly set
> > up" - in the original etch system - but udev does not
> > recognize the devices
> > under xen...
> >
> > Are there any other kernel options for xen kernel which
> > could impact
> > this behavior or any other configuration possibilities? For example
> > something similar for Dom0 like I can specify for domU?
>
> What graphics driver are you using for your graphic card?
>
> Is it loading correctly for your Dom0 installation? Check
> "dmesg" for both
> native and Dom0 to see if there's any differences.
>
> --
> Mats
> >
> > With best regards
> >
> > Archie
> >
> >
> > -----Original Message-----
> > From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
> > Sent: Thursday, June 21, 2007 10:58 AM
> > To: Artur Linhart - Linux communication; Andre Rein;
> > xen-users@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-users] Re: FULL VIRTUALIZATION - missing /dev/fb0
> >
> >
> >
> > > -----Original Message-----
> > > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > > Artur Linhart - Linux communication
> > > Sent: 20 June 2007 17:54
> > > To: 'Andre Rein'; xen-users@xxxxxxxxxxxxxxxxxxx
> > > Subject: RE: [Xen-users] Re: FULL VIRTUALIZATION -
> missing /dev/fb0
> > >
> > > Hello,
> > >
> > > I have the same problem like the one described below...
> > >
> > > Did somebody resolved the issue with the missing
> > > /dev/fd0 device?
> > >
> > > Mknod does not help. What does it mean "configure udev
> > > properly"? If
> > > fb works OK without Xen, how should I configure udev for xen
> > > - what should
> > > be modified in the xen configuration to get Dom0 working
> > > again, like if
> > > running without Xen?
> >
> > I don't think there should be any difference between udev for
> > native Linux
> > and Xen-ified linux - the hint on configuring it "properly"
> > was more to the
> > point of "make sure it's set up".
> >
> > But I guess another point is that /dev/fbN is the
> > "frame-buffer", which is
> > only available on certain models of graphics cards - you may
> > not be able to
> > do that with the graphics card you've specified in the domain
> > config (are
> > you by any chance using "stdvga=1"?).
> >
> > --
> > Mats
> > >
> > > Any help would be appreciated,
> > >
> > > With best regards
> > >
> > > Archie
> > >
> > > -----Original Message-----
> > > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > Andre Rein
> > > Sent: Wednesday, February 28, 2007 4:09 PM
> > > To: xen-users@xxxxxxxxxxxxxxxxxxx
> > > Subject: [Xen-users] Re: FULL VIRTUALIZATION
> > >
> > > Petersson, Mats <Mats.Petersson <at> amd.com> writes:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Carlo [mailto:carlo <at> granisso.it]
> > > > > Sent: 28 February 2007 10:54
> > > > > To: Petersson, Mats; Carlo; xen-users <at> lists.xensource.com
> > > > > Subject: RE: [Xen-users] FULL VIRTUALIZATION
> > > > >
> > > > > I've solved the first problem: path of qemu-dm in the
> > > config file was
> > > > > uncorrect...
> > > > >
> > > > > Now, qemu-dm say:
> > > > >
> > > > > domid: 6
> > > > > qemu: the number of cpus is 1
> > > > > shared page at pfn:1ffff, mfn: df18
> > > > > buffered io page at pfn:1fffd, mfn: df1a
> > > > >
> > > > > ---------------------- DirectFB v0.9.25
> > > ---------------------
> > > > > (c) 2000-2002 convergence integrated media GmbH
> > > > > (c) 2002-2004 convergence GmbH
> > > > >
> > > -----------------------------------------------------------
> > > > >
> > > > > (*) DirectFB/Core: Single Application Core. (2006-12-04 07:00)
> > > > > (*) Direct/Memcpy: Using MMXEXT optimized memcpy()
> > > > > (!) Direct/Util: opening '/dev/fb0' and '/dev/fb/0' failed
> > > > > --> No such file or directory
> > > > > (!) DirectFB/FBDev: Error opening framebuffer device!
> > > > > (!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER
> > > environment
> > > > > variable.
> > > > > (!) DirectFB/Core: Could not initialize 'system' core!
> > > > > --> Initialization error!
> > > > > Could not initialize SDL - exiting
> > >
> > > got the same Problem here :)
> > > You don´t have a Framebufferdevice /dev/fb0. Create one withe
> > > mknod or
> > > configure udev properly.
> > >
> > > Second choice, use vnc (vnc=1) and connect with xvncviewer
> > > ip:0, so I do.
> > >
> > > here my config:
> > >
> > >
> > > kernel = '/usr/lib/xen-3.0.3-1/boot/hvmloader'
> > > builder = 'hvm'
> > > memory = '1024'
> > > device_model='/usr/lib/xen-3.0.3-1/bin/qemu-dm'
> > >
> > >
> > > disk = [
> > >
> > > 'file:/home/xen/windoof/windisk.img,ioemu:hda,w',
> > > 'file:/home/ar/WXPVOL_DE.ISO,ioemu:hdc:cdrom,r'
> > > ]
> > > #disk = [ 'phy:/dev/hda,hda,r' ]
> > >
> > >
> > > name = 'windoof'
> > >
> > >
> > > vif = ['type=ioemu, bridge=xenbr0']
> > >
> > >
> > > boot='d'
> > > vnc=1
> > > vncpassword='xyz'
> > > vncunused=1
> > > vncviewer=0
> > > #vnclisten="127.0.0.1"
> > > serial='pty'
> > > sdl=0
> > >
> > >
> > >
> > > greetings
> > >
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-users
> > >
> > > __________ Informace od NOD32 2082 (20070226) __________
> > >
> > > Tato zprava byla proverena antivirovym systemem NOD32.
> > > http://www.nod32.cz
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-users
> > >
> > >
> > >
> >
> >
> >
> > __________ Informace od NOD32 2342 (20070621) __________
> >
> > Tato zprava byla proverena antivirovym systemem NOD32.
> > http://www.nod32.cz
> >
> >
> >
> >
> >
>
>
>
> __________ Informace od NOD32 2342 (20070621) __________
>
> Tato zprava byla proverena antivirovym systemem NOD32.
> http://www.nod32.cz
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
__________ Informace od NOD32 2342 (20070621) __________
Tato zprava byla proverena antivirovym systemem NOD32.
http://www.nod32.cz
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |