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...
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
dmesg-xen.txt
Description: Text document
dmesg-etch.txt
Description: Text document
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home