Xen devel - Nov 2011 - OpenSuse 11 hvm domU: screen resolution up to 640x480

Hello,

I''ve recently installed a hvm domU opensuse 11 guest and I cannot set
the screen
resolution higher then 640x480. This seems very strange to me, because
I don''t have
any problem to set higher resolution on a windows 7 domU, using the
following parameters
in the configuration file:
stdvga=1
videoram=16

What could the problem be? Is some video driver missing?

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 6 November 2011 00:20, jim burns <jim_burn@bellsouth.net>
wrote:
>
> That''s what I got when I set stdvga=1. According to the comment in
> /etc/xen/xmexample.hvm:
>
> # enable stdvga, default = 0 (use cirrus logic device model)
>
> so I use stdvga=0.
Thanks,
I''ve put stdvga=0 and I''ve got the max resolution up to
800x600 now,
but it is not sufficient for me.
>
> Also, be warned, if you use ''xl'' instead of
''xm'', it (currently) limits you to
> videoram=4, according to an error message in /var/log/xen/qemu-dm.log. See
the
> thread I started on 10/29:
Yes, I''ve noticed that actually. This doesn''t happen on
windows domUs.
>
> Problems with ''xl create winxp'' (hvm) on xen 4.1.2 (also
affects GPLPV)
Well, I''ve read it. I use xl and I didn''t understand why I
don''t have
this problem on windows-domU.
Actually the screen resolution is higher and the 4M videoram
limitation error message
doesn''t not appear in the qemu-dm-windows-7.log. What about the
"cirrus" vga device
model? Something tells me that with my Open Suse guest, I''ve used a
cirrus vga
device model, but not on windows-7. I don''t remember to have done this
choice somewhere.


Thank you.

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 6 November 2011 08:28, Flavio <fbcyborg@gmail.com>
wrote:
> Well, I''ve read it. I use xl and I didn''t understand why
I don''t have
> this problem on windows-domU.
> Actually the screen resolution is higher and the 4M videoram
> limitation error message
> doesn''t not appear in the qemu-dm-windows-7.log. What about the
> "cirrus" vga device
> model? Something tells me that with my Open Suse guest, I''ve used
a cirrus vga
> device model, but not on windows-7. I don''t remember to have done
this
> choice somewhere.
By the way: if I try to setup a domU using the qemu-system command, the
installation starts, but after pressing "Install", I get a blank
screen!

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 6 2011, 8:56:53 AM, Flavio wrote:
> On 6 November 2011 08:28, Flavio <fbcyborg@gmail.com> wrote:
> > Well, I''ve read it. I use xl and I didn''t understand
why I don''t have
> > this problem on windows-domU.
> > Actually the screen resolution is higher and the 4M videoram
> > limitation error message
> > doesn''t not appear in the qemu-dm-windows-7.log. What about
the
> > "cirrus" vga device
> > model? Something tells me that with my Open Suse guest, I''ve
used a
> > cirrus vga device model, but not on windows-7. I don''t
remember to have
> > done this choice somewhere.
> 
> By the way: if I try to setup a domU using the qemu-system command, the
> installation starts, but after pressing "Install", I get a blank
screen!
> 
> --
> Flavio
If you do a ''rpm -qi qemu-system-x86'' (or whatever the package
name is in your
system (and package manager)), you''ll see that is a kvm package, and
thus not
modified for xen.

Quote:

On 6 November 2011 00:20, jim burns <jim_burn@bellsouth.net>
wrote:
>
> That''s what I got when I set stdvga=1. According to the comment in
> /etc/xen/xmexample.hvm:
>
> # enable stdvga, default = 0 (use cirrus logic device model)
>
> so I use stdvga=0.
Thanks,
I''ve put stdvga=0 and I''ve got the max resolution up to
800x600 now,
but it is not sufficient for me.
>
> Also, be warned, if you use ''xl'' instead of
''xm'', it (currently) limits you
to
> videoram=4, according to an error message in /var/log/xen/qemu-dm.log. See 
the
> thread I started on 10/29:
Yes, I''ve noticed that actually. This doesn''t happen on
windows domUs.
>
> Problems with ''xl create winxp'' (hvm) on xen 4.1.2 (also
affects GPLPV)
Well, I''ve read it. I use xl and I didn''t understand why I
don''t have
this problem on windows-domU.
Actually the screen resolution is higher and the 4M videoram
limitation error message
doesn''t not appear in the qemu-dm-windows-7.log. What about the
"cirrus" vga device
model? Something tells me that with my Open Suse guest, I''ve used a
cirrus vga
device model, but not on windows-7. I don''t remember to have done this
choice somewhere.


Thank you.

-- 
Flavio

:End Quote

I''ve never had to do a linux hvm install, so I can''t comment
on the
differences. Could be that the ''videoram='' option is only
meant for linux or
windows, but not both. I do know I get the cirrus model in my winxp domu with 
''stdvga=0'', and I get the 4M videoram error with videorams
greater than 4 and
using ''xl create''. I have also noticed that being limited to
videoram=4 in my
winxp domu doesn''t prevent me from getting 1280x1024 in vnc. (Of
course, I
usually use rdp, anyway, where the client (rdesktop) lets you set the 
resolution on the command line.)

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 6 November 2011 09:44, jim burns <jim_burn@bellsouth.net>
wrote:
> If you do a ''rpm -qi qemu-system-x86'' (or whatever the
package name is in your
> system (and package manager)), you''ll see that is a kvm package,
and thus not
> modified for xen.
OK.
> I''ve never had to do a linux hvm install, so I can''t
comment on the
> differences.
I think it''s just a performance issue. As far as I know, there is no
longer great difference
between hvm and pv guest in XEN.
> Could be that the ''videoram='' option is only meant for
linux or
> windows, but not both.
I don''t think so. I have a windows-7 (but also a windows-xp) and a
CentOS domU (not hvm)
both using videoram=16 and stdvga=1, and there is no problem. High
resolution in both cases.

> I do know I get the cirrus model in my winxp domu with
> ''stdvga=0'', and I get the 4M videoram error with
videorams greater than 4 and
> using ''xl create''.
This happens to me only with this opensuse hvm guest. Now I''ve finally
got the setup under
qemu-system-x86_64 system working, so, I will see what will happen in
this case, when
I will boot the domU as a PV guest and not hvm.
> I have also noticed that being limited to videoram=4 in my
> winxp domu doesn''t prevent me from getting 1280x1024 in vnc.
mmmh.. So the screen resolution limitation is not related to this problem...
interesting and much more confusing.

I will let you know.

Thank you.
-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 6 November 2011 09:52, Flavio <fbcyborg@gmail.com>
wrote:
> I will let you know.
The installation has failed, as expected. :(

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 6 2011, 9:52:48 AM, Flavio wrote:
> On 6 November 2011 09:44, jim burns <jim_burn@bellsouth.net> wrote:
> > If you do a ''rpm -qi qemu-system-x86'' (or whatever
the package name is
> > in your system (and package manager)), you''ll see that is a
kvm
> > package, and thus not modified for xen.
> 
> OK.
> 
> > I''ve never had to do a linux hvm install, so I can''t
comment on the
> > differences.
> 
> I think it''s just a performance issue. As far as I know, there is
no
> longer great difference
> between hvm and pv guest in XEN.
No, I mean there may be a difference between how linux and windows look at the 
emulated devices qemu-dm provides - in particular, they may honor or ignore 
some of the config file options, like eg: videoram=.
> > Could be that the ''videoram='' option is only meant
for linux or
> > windows, but not both.
> 
> I don''t think so. I have a windows-7 (but also a windows-xp) and a
> CentOS domU (not hvm)
> both using videoram=16 and stdvga=1, and there is no problem. High
> resolution in both cases.
Umm - videoram and stdvga are hvm config file options. If the CentOS is pv, 
it''s ignoring them.
> > I do know I get the cirrus model in my winxp domu with
> > ''stdvga=0'', and I get the 4M videoram error with
videorams greater than
> > 4 and using ''xl create''.
> 
> This happens to me only with this opensuse hvm guest. Now I''ve
finally
> got the setup under
> qemu-system-x86_64 system working, so, I will see what will happen in
> this case, when
> I will boot the domU as a PV guest and not hvm.
Umm - if you are using kvm''s qemu, I believe you are by definition
doing an
hvm install - qemu is an emulator. Xen''s qemu-dm is modified to provide
pv
drivers depending on the -M option. Look at a ''/bin/ps a -A|grep
qemu''. For
hvm, it will say ''-M xenfv'', and for pv it will say
''-M xenpv''.
> > I have also noticed that being limited to videoram=4 in my
> > winxp domu doesn''t prevent me from getting 1280x1024 in vnc.
> 
> mmmh.. So the screen resolution limitation is not related to this
problem...
> interesting and much more confusing.
> 
> I will let you know.
> 
> Thank you.
> --
> Flavio
The only other thing I can think of - in the opensuse domu''s 
/boot/grub/memu.lst, on the ''kernel'' line, make sure you are
specifying the
vga= parm. With me, vga=0x31a gives me 1280x1024. Or, you could specify 
vga=ask, and run thru the possibilities.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 6 November 2011 23:21, jim burns <jim_burn@bellsouth.net>
wrote:
>
> No, I mean there may be a difference between how linux and windows look at
the
> emulated devices qemu-dm provides - in particular, they may honor or ignore
> some of the config file options, like eg: videoram=.
OK
> Umm - videoram and stdvga are hvm config file options. If the CentOS is pv,
> it''s ignoring them.
Yes, you are right. I made a mistake actually. The max resolution in that domU
is still 800x600 and, as you said, those options are ignored.
> Umm - if you are using kvm''s qemu, I believe you are by definition
doing an
> hvm install - qemu is an emulator.
I don''t use the package qemu-kvm, but qemu. Maybe there is no great
difference
but the package I''ve installed is qemu, and I use it to setup PV
guest, according
to this guide:
http://www.virtuatopia.com/index.php/Using_QEMU_Disk_Images_for_Xen_DomainU_Systems
> Xen''s qemu-dm is modified to provide pv
> drivers depending on the -M option. Look at a ''/bin/ps a -A|grep
qemu''. For
> hvm, it will say ''-M xenfv'', and for pv it will say
''-M xenpv''.
OK
> The only other thing I can think of - in the opensuse domu''s
> /boot/grub/memu.lst, on the ''kernel'' line, make sure you
are specifying the
> vga= parm. With me, vga=0x31a gives me 1280x1024. Or, you could specify
> vga=ask, and run thru the possibilities.
vga=0x31 didn''t work for me. It says it is not available. But
I''ve
selected 318 and
the boot screen was bigger than before. Anyway, when the XDM started,
the resolution
come back to 800x600.

Very strange!


-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 6 2011, 5:21:14 PM, jim burns wrote:
> The only other thing I can think of - in the opensuse domu''s 
> /boot/grub/memu.lst, on the ''kernel'' line, make sure you
are specifying the
> vga= parm. With me, vga=0x31a gives me 1280x1024. Or, you could specify
> vga=ask, and run thru the possibilities.
Also, since it''s linux, you can play with lspci in your opensuse domu.
Find
out the pci device number for the emulated video card, then do an
''lspci -s
pci-device-number -vvv'', and look at the ''Region''
lines for the amount of
memory on the card. See if that memory varies by the setting of your videoram= 
config line.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 6 2011, 11:51:17 PM, Flavio wrote:
> I don''t use the package qemu-kvm, but qemu. Maybe there is no
great
> difference but the package I''ve installed is qemu, and I use it to
setup PV
> guest, according
> to this guide:
>
http://www.virtuatopia.com/index.php/Using_QEMU_Disk_Images_for_Xen_DomainU_
> Systems
Ok, I see what you are doing. You use qemu-img to create the disk, then using 
qemu to install from a cdrom (since cdroms are only available in hvm mode), 
installing a xen enabled kernel, then using pygrub in your config to boot the 
created image as a pv domain. That will work. Assuming you created your 
opensuse domu this way, as soon as you boot it with pygrub, it''s now a
pv
domain, not an hvm domain, and videoram/stdvga no longer apply. Have I got 
this right?

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon, Nov 7, 2011 at 5:51 AM, Flavio <fbcyborg@gmail.com>
wrote:
> On 6 November 2011 23:21, jim burns <jim_burn@bellsouth.net> wrote:
>>
>> No, I mean there may be a difference between how linux and windows look
at the
>> emulated devices qemu-dm provides - in particular, they may honor or
ignore
>> some of the config file options, like eg: videoram=.
> OK
>
>> Umm - videoram and stdvga are hvm config file options. If the CentOS is
pv,
>> it''s ignoring them.
> Yes, you are right. I made a mistake actually. The max resolution in that
domU
> is still 800x600 and, as you said, those options are ignored.
Try http://lists.xensource.com/archives/html/xen-users/2011-03/msg00090.html

-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 7 November 2011 00:09, jim burns <jim_burn@bellsouth.net>
wrote:
> Also, since it''s linux, you can play with lspci in your opensuse
domu. Find
> out the pci device number for the emulated video card, then do an
''lspci -s
> pci-device-number -vvv'', and look at the
''Region'' lines for the amount of
> memory on the card. See if that memory varies by the setting of your
videoram> config line.
>
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at f3000000 (32-bit, non-prefetchable) [size=4K]

and videoram is equal to 16 with stdvga=0, as you told me.

On 7 November 2011 00:31, jim burns <jim_burn@bellsouth.net>
wrote:
> Ok, I see what you are doing. You use qemu-img to create the disk, then
using
> qemu to install from a cdrom (since cdroms are only available in hvm mode),
> installing a xen enabled kernel, then using pygrub in your config to boot
the
> created image as a pv domain.
Yes, that''s it, but unfortunately the domU doesn''t start in
this way:
blank screen
after the grub kernel selection. So I came back to use the hvm domU
I''ve previously
created.
> That will work. Assuming you created your
> opensuse domu this way, as soon as you boot it with pygrub, it''s
now a pv
> domain, not an hvm domain, and videoram/stdvga no longer apply. Have I got
> this right?
Yes. But as said above, now consider that this pv domain has been cancelled.
Now I only have one opensuse domU and it is hvm. The only one that can boot.

On 7 November 2011 03:39, Fajar A. Nugraha <list@fajar.net>
wrote:
> Try
http://lists.xensource.com/archives/html/xen-users/2011-03/msg00090.html
Well, as far as I understand, it is a kernel configuration issue. Isn''t
it?
So, compiling the XEN_FBDEV_FRONTEND module within the domU kernel should solve
the problem?

Thanks a lot!

Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon, Nov 7, 2011 at 4:25 PM, Flavio <fbcyborg@gmail.com>
wrote:
> On 7 November 2011 03:39, Fajar A. Nugraha <list@fajar.net> wrote:
>> Try
http://lists.xensource.com/archives/html/xen-users/2011-03/msg00090.html
> Well, as far as I understand, it is a kernel configuration issue.
Isn''t it?
> So, compiling the XEN_FBDEV_FRONTEND module within the domU kernel should
solve
> the problem?
No, what that thread says is that you need a configuration option
passwd to xen-fbfront. How you pass it depends on how it''s compiled,
whether it''s built-in or module.

-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 7 November 2011 10:35, Fajar A. Nugraha <list@fajar.net>
wrote:
> No, what that thread says is that you need a configuration option
> passwd to xen-fbfront.
Excuse me: what do you mean for "configuration option passwd"?
> How you pass it depends on how it''s compiled,
> whether it''s built-in or module.
Of course. Anyway, to not make confusion we are still talking about
the domU kernel, isn''t it?

Thanks,

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon, Nov 7, 2011 at 4:37 PM, Flavio <fbcyborg@gmail.com>
wrote:
> On 7 November 2011 10:35, Fajar A. Nugraha <list@fajar.net> wrote:
>> No, what that thread says is that you need a configuration option
>> passwd to xen-fbfront.
> Excuse me: what do you mean for "configuration option passwd"?
PASSED

(sorry, typo. "E" and "W" is close :) )
>
>> How you pass it depends on how it''s compiled,
>> whether it''s built-in or module.
> Of course. Anyway, to not make confusion we are still talking about
> the domU kernel, isn''t it?
Yes.

-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Pls remember to cc: me, as I don''t receive mail from the list.

Quote:
> On 7 November 2011 00:09, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
>> Also, since it''s linux, you can play with lspci in your
opensuse domu.
>> Find out the pci device number for the emulated video card, then do an
>> ''lspci -s pci-device-number -vvv'', and look at the
''Region'' lines for the
>> amount of memory on the card. See if that memory varies by the setting
of
>> your videoram= config line.
> Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
> Region 1: Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
> and videoram is equal to 16 with stdvga=0, as you told me.
Your region 0 is 32M, and your videoram=16, so opensuse is not paying any 
attention to the videoram. Actually, this is exactly what my winxp domu says - 
2 regions of 32m and 4k. I''m beginning to think the videoram= line only
applies if stdvga=1, but everything is predefined for stdvga=0 - the cirrus 
model.
> On 7 November 2011 00:31, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
>> Ok, I see what you are doing. You use qemu-img to create the disk, then
>> using qemu to install from a cdrom (since cdroms are only available in
hvm
>> mode), installing a xen enabled kernel, then using pygrub in your
config
>> to boot the created image as a pv domain.
> Yes, that''s it, but unfortunately the domU doesn''t start
in this way:
> blank screen after the grub kernel selection. So I came back to use the hvm
> domU I''ve previously created.
I''m going to assume you picked the xen enabled kernel in the grub
display.
>> That will work. Assuming you created your
>> opensuse domu this way, as soon as you boot it with pygrub,
it''s now a pv
>> domain, not an hvm domain, and videoram/stdvga no longer apply. Have I
got
>> this right?
> Yes. But as said above, now consider that this pv domain has been
cancelled.
> Now I only have one opensuse domU and it is hvm. The only one that can
boot.
:end Quote

Alright, why don''t you post the full config for your hvm opensuse domu?
Maybe
something else will jump out at me.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 7 November 2011 10:39, Fajar A. Nugraha <list@fajar.net>
wrote:
> On Mon, Nov 7, 2011 at 4:37 PM, Flavio <fbcyborg@gmail.com> wrote:
>> On 7 November 2011 10:35, Fajar A. Nugraha <list@fajar.net>
wrote:
>>> No, what that thread says is that you need a configuration option
>>> passwd to xen-fbfront.
>> Excuse me: what do you mean for "configuration option
passwd"?
>
> PASSED
>
> (sorry, typo. "E" and "W" is close :) )
Thanks! :)

Excuse me for the late replay, but I had some problem with the kernel.

I''ve tried to pass extra = ''video=32,1280,1024''
option in the config file
but no luck. Furthermore, the domU kernel, which is 2.6.37, seems to
not have that module.
So I downloaded the last vanilla kernel sources and I tried to compile that
module as built in.
I have reconfigured the kernel, but unfortunately, I had some problem during
the kernel compilation. I have to retry using a smaller configuration.

By the way: zypper info kernel-xen says that:
"This kernel can be used both as the domain0 ("xen0") and as an
unprivileged ("xenU") kernel."

but even installing it, I am not able to use it in order to boot the domU.

The problem is that if i try to compile a kernel inside the domU,
which is a modified
version (of the config file) of the kernel in /boot directory, I
always remain with no space
on the device (because of the huge quantity of the modules to be
compiled -  I know,
I should remove all the unused modules). So every time I''m not able to
install the
new domU kernel.

On 8 November 2011 00:15, jim burns <jim_burn@bellsouth.net>
wrote:
> Pls remember to cc: me, as I don''t receive mail from the list.
Sorry, I didn''t know that.
> Your region 0 is 32M, and your videoram=16, so opensuse is not paying any
> attention to the videoram. Actually, this is exactly what my winxp domu
says -
> 2 regions of 32m and 4k. I''m beginning to think the videoram= line
only
> applies if stdvga=1, but everything is predefined for stdvga=0 - the cirrus
> model.
OK
> Alright, why don''t you post the full config for your hvm opensuse
domu? Maybe
> something else will jump out at me.
Here we go:

kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 1024

shadow_memory = 8
name = "opensuse-11.4"
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
acpi = 1
apic = 1
disk = [
''file:/mnt/xen/vmstore/opensuse-11.4/opensuse-11.4.img,hda,w''
]

boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''''
vnclisten="192.168.1.100"
stdvga=0
videoram=16
keymap="it"

serial=''pty''
usbdevice=''tablet''
extra = ''video=32,1280,1024''

Thank you,

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 8 November 2011 15:27, Flavio <fbcyborg@gmail.com>
wrote:
> Here we go:
>
> kernel = "/usr/lib/xen/boot/hvmloader"
> builder=''hvm''
> memory = 1024
>
> shadow_memory = 8
> name = "opensuse-11.4"
> vif = [ ''type=ioemu, mac=00:16:3e:00:00:21,
bridge=xenbr0'' ]
> acpi = 1
> apic = 1
> disk = [
''file:/mnt/xen/vmstore/opensuse-11.4/opensuse-11.4.img,hda,w''
]
>
> boot="dc"
> sdl=0
> vnc=1
> vncconsole=1
> vncpasswd=''''
> vnclisten="192.168.1.100"
> stdvga=0
> videoram=16
> keymap="it"
>
> serial=''pty''
> usbdevice=''tablet''
> extra = ''video=32,1280,1024''
>
> Thank you,
I finally finished to compile the 3.1 kernel. I have compiled the kernel
with the xenfb module as built in, but even passing the video option
to the kernel line
I still cannot set a resolution higher than 800x600.

This is the kernel command line in menu.lst:
kernel /boot/vmlinuz-3.1.0-1.2-desktop
root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
quiet showopts vga=0x314 extra=''video=32,1280,1024''

and this is what cat /proc/cmdline says:
root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
quiet vga=0x314 extra=''video=32,1280,1024''


-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Nov 9, 2011 at 4:05 AM, Flavio <fbcyborg@gmail.com>
wrote:
> I finally finished to compile the 3.1 kernel. I have compiled the kernel
> with the xenfb module as built in,
it should still be called xen-fbfront
> but even passing the video option
> to the kernel line
> I still cannot set a resolution higher than 800x600.
>
> This is the kernel command line in menu.lst:
> kernel /boot/vmlinuz-3.1.0-1.2-desktop
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet showopts vga=0x314 extra=''video=32,1280,1024''
>
> and this is what cat /proc/cmdline says:
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet vga=0x314 extra=''video=32,1280,1024''
do you know how to pass option to a module?

Passing it in kernel command line is somewhat tricky. What you''re
doing simply wont work. You probably need something like
"xen-fbfront.video" instead of just "video" (untested).

Better just put it in /etc/modprobe.d and rebuild your initrd.

-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 8 November 2011 22:19, Fajar A. Nugraha <list@fajar.net>
wrote:
> it should still be called xen-fbfront
Yes, I made a mistake typing the right name.

OK, I''m compiling the kernel again with xen-fbfront as module.
> do you know how to pass option to a module?
Yes, I''ve seen this link:
http://lists.xensource.com/archives/html/xen-users/2011-03/msg00090.html
>
> Passing it in kernel command line is somewhat tricky. What you''re
> doing simply wont work. You probably need something like
> "xen-fbfront.video" instead of just "video" (untested).
>
> Better just put it in /etc/modprobe.d and rebuild your initrd.
OK! I will let you know!

Thank you

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue November 8 2011, 10:05:40 PM, Flavio wrote:
> > serial=''pty''
> > usbdevice=''tablet''
> > extra = ''video=32,1280,1024''
> > 
> > Thank you,
> 
> I finally finished to compile the 3.1 kernel. I have compiled the kernel
> with the xenfb module as built in, but even passing the video option
> to the kernel line
> I still cannot set a resolution higher than 800x600.
> 
> This is the kernel command line in menu.lst:
> kernel /boot/vmlinuz-3.1.0-1.2-desktop
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet showopts vga=0x314 extra=''video=32,1280,1024''
> 
> and this is what cat /proc/cmdline says:
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet vga=0x314 extra=''video=32,1280,1024''
This won''t work for another reason: ''extra='' is a pv
config option for passing
extra kernel options to the boot process, as reflected by /proc/cmdline. Only 
adding it to menu.lst would work, IF xen-fbfront is builtin, and the syntax is 
as Fajar suggested - xen-fbfront.video=32,1280,1024. If it is not builtin, you 
must use the /etc/modprobe.d approach.

However, beyond syntax problems. I doubt this would work at all in an hvm 
domu, as they don''t use fbfront - that''s a pv driver. (Fajar -
you can verify
this, right?) ''lspci -vvv'' will tell you what driver is loaded
for your video
controller. Pls post the output of ''lspci -vvv -s
video-device-number'', and
then for the driver mentioned at the end, post ''modinfo
driver-name''.

A further note: if you ever intend to convert this domu to boot as a pv domu, 
the above syntax for /dev/disk-by-id won''t work, since pv domus 
don''t use
qemu disks. (That''s one of those device differences between pv and hvm
domus I
was talking about.) I suppose this is a worry for much further down the road. 
In my opensuse memu.lst, it is sufficient to say:

kernel /vmlinuz root=/dev/system/root resume=/dev/system/swap [...]

if you are using lvm, or simply /dev/sda?, where ?=partition number. Then 
/etc/fstab would have a similar problem, where you would have to use 
/dev/sda?, or /dev/disk/by-uuid. As I say, this is much further down the road.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue November 8 2011, 3:27:15 PM, Flavio wrote:
> I''ve tried to pass extra = ''video=32,1280,1024''
option in the config file
> but no luck. Furthermore, the domU kernel, which is 2.6.37, seems to
> not have that module.
Btw, opensuse''s kernel-xen-2.6.37 is still using the old xenlinux
module
names, even tho'' it has modern modules like evtchn, gntdev and blktap2.
It
would appear that the framebuffer is built in (CONFIG_XEN_FRAMEBUFFER=y).

jimb@Dell4550 11/08/11 11:31PM:~
[584] > rpm -qlp Documents/rpms/kernel-xen*|grep xen.*xen
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/char/tpm/tpm_xenu.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/net/netxen
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/net/netxen/netxen_nic.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/watchdog/xen_wdt.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkback
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkback/blkback-pagemap.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkback/blkbk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkfront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkfront/xenblk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blktap
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blktap/blktap.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blktap2
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blktap2/blktap2.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/core
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/core/domctl.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/evtchn.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/gntdev
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/gntdev/gntdev.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/netback
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/netback/netbk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/netfront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/netfront/xennet.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/pciback
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/pciback/pciback.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/scsiback
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/scsiback/xen-scsibk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/scsifront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/scsifront/xenscsi.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/sfc_netfront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/sfc_netfront/sfc_netfront.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/sfc_netutil
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/sfc_netutil/sfc_netutil.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/tpmback
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/tpmback/tpmbk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/usbback
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/usbback/usbbk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/usbfront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/usbfront/xen-hcd.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/xenbus
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/xenbus/xenbus_be.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkfront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/blkfront/xenblk.ko
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/netfront
/lib/modules/2.6.37.6-0.9-xen/kernel/drivers/xen/netfront/xennet.ko

root@Dell4550 11/08/11 11:37PM:~
[571] > grep XEN /boot/config-2.6.37.6-0.9-xen    
CONFIG_X86_XEN=y
CONFIG_X86_XEN_MCE=y
# CONFIG_PCI_GOXEN_FE is not set
CONFIG_XEN_PCIDEV_FRONTEND=y
# CONFIG_XEN_PCIDEV_FE_DEBUG is not set
CONFIG_NETXEN_NIC=m
CONFIG_TCG_XEN=m
CONFIG_XEN_WDT=m
CONFIG_XEN=y
CONFIG_XEN_INTERFACE_VERSION=0x00030207
# XEN
CONFIG_XEN_PRIVILEGED_GUEST=y
# CONFIG_XEN_UNPRIVILEGED_GUEST is not set
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_DOMCTL=m
CONFIG_XEN_XENBUS_DEV=y
CONFIG_XEN_NETDEV_ACCEL_SFC_UTIL=m
CONFIG_XEN_BACKEND=m
CONFIG_XEN_BLKDEV_BACKEND=m
CONFIG_XEN_BLKDEV_TAP=m
CONFIG_XEN_BLKDEV_TAP2=m
CONFIG_XEN_BLKBACK_PAGEMAP=m
CONFIG_XEN_NETDEV_BACKEND=m
CONFIG_XEN_NETDEV_TX_SHIFT=10
# CONFIG_XEN_NETDEV_PIPELINED_TRANSMITTER is not set
# CONFIG_XEN_NETDEV_LOOPBACK is not set
CONFIG_XEN_PCIDEV_BACKEND=m
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
# CONFIG_XEN_PCIDEV_BACKEND_PASS is not set
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set
CONFIG_XEN_TPMDEV_BACKEND=m
CONFIG_XEN_SCSI_BACKEND=m
CONFIG_XEN_USB_BACKEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_ACCEL_SFC_FRONTEND=m
CONFIG_XEN_SCSI_FRONTEND=m
CONFIG_XEN_USB_FRONTEND=m
# CONFIG_XEN_USB_FRONTEND_HCD_STATS is not set
# CONFIG_XEN_USB_FRONTEND_HCD_PM is not set
CONFIG_XEN_GRANT_DEV=m
CONFIG_XEN_FRAMEBUFFER=y
CONFIG_XEN_KEYBOARD=y
# CONFIG_XEN_DISABLE_SERIAL is not set
CONFIG_XEN_SYSFS=y
CONFIG_XEN_NR_GUEST_DEVICES=256
# CONFIG_XEN_COMPAT_030002_AND_LATER is not set
# CONFIG_XEN_COMPAT_030004_AND_LATER is not set
# CONFIG_XEN_COMPAT_030100_AND_LATER is not set
# CONFIG_XEN_COMPAT_030200_AND_LATER is not set
# CONFIG_XEN_COMPAT_030300_AND_LATER is not set
# CONFIG_XEN_COMPAT_030400_AND_LATER is not set
CONFIG_XEN_COMPAT_040000_AND_LATER=y
# CONFIG_XEN_COMPAT_LATEST_ONLY is not set
CONFIG_XEN_COMPAT=0x040000
CONFIG_XEN_VCPU_INFO_PLACEMENT=y
CONFIG_XEN_SMPBOOT=y
CONFIG_XEN_DEVMEM=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Nov 9, 2011 at 10:35 AM, jim burns <jim_burn@bellsouth.net>
wrote:
> On Tue November 8 2011, 10:05:40 PM, Flavio wrote:
> This won''t work for another reason: ''extra='' is
a pv config option for passing
> extra kernel options to the boot process, as reflected by /proc/cmdline.
Only
> adding it to menu.lst would work, IF xen-fbfront is builtin, and the syntax
is
> as Fajar suggested - xen-fbfront.video=32,1280,1024. If it is not builtin,
you
> must use the /etc/modprobe.d approach.
>
I lost track of what Flavio is using.

Anyway, if it''s PV, using something like
"xen-fbfront.video=16,1280,1024" on kernel command line should work
regardless whether its built-on or module. If it''s module, you also
have the option of using /etc/modprobe.d

> However, beyond syntax problems. I doubt this would work at all in an hvm
> domu, as they don''t use fbfront - that''s a pv driver.
(Fajar - you can verify
> this, right?) ''lspci -vvv'' will tell you what driver is
loaded for your video
> controller. Pls post the output of ''lspci -vvv -s
video-device-number'', and
> then for the driver mentioned at the end, post ''modinfo
driver-name''.
with stdvga=0, you''d get

00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
[VGA controller])
	Subsystem: XenSource, Inc. Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at <unassigned> [disabled]
	Kernel modules: cirrusfb

and starting X directly would get you lots of entries like this on Xorg.0.log

[    89.540] (II) CIRRUS(0): Not using default mode "1280x1024" (bad
mode clock/interlace/doublescan)
[    89.540] (II) CIRRUS(0): Not using default mode "1600x1200"
(insufficient memory for mode)
[    89.540] (II) CIRRUS(0): Not using default mode "800x600" (bad
mode clock/interlace/doublescan)

... and

[    89.541] (--) CIRRUS(0): Virtual size is 1024x768 (pitch 1024)
[    89.542] (**) CIRRUS(0): *Default mode "1024x768": 65.0 MHz, 48.4
kHz, 60.0 Hz
[    89.542] (II) CIRRUS(0): Modeline "1024x768"x60.0   65.00  1024
1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[    89.542] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9
kHz, 60.3 Hz
[    89.542] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800 840
968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)


-- 
Fajar

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed November 9 2011, 12:55:48 PM, Fajar A. Nugraha
wrote:
> Anyway, if it''s PV, using something like
> "xen-fbfront.video=16,1280,1024" on kernel command line should
work
> regardless whether its built-on or module. If it''s module, you
also
> have the option of using /etc/modprobe.d
Hmm - putting xen-pciback on the kernel command line doesn''t work for
me. I
always have to do late binding in /etc/rc.local in fedora (where it''s a
module).
> ... and
> 
> [    89.541] (--) CIRRUS(0): Virtual size is 1024x768 (pitch 1024)
> [    89.542] (**) CIRRUS(0): *Default mode "1024x768": 65.0 MHz,
48.4
> kHz, 60.0 Hz
> [    89.542] (II) CIRRUS(0): Modeline "1024x768"x60.0   65.00 
1024
> 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
> [    89.542] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz,
37.9
> kHz, 60.3 Hz
> [    89.542] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800
840
> 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
Huh! Hadn''t thought of that. Useful debug info.

Flavio - besides the lspci and modinfo output I asked for, post your 
Xorg.0.log as well. Then I can compare it to what Fajar posted.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Here again,

please excuse me for the late replays but the kernel compilation takes a lot
of time and I have to wait very much between one test and the other.

On 9 November 2011 04:35, jim burns <jim_burn@bellsouth.net>
wrote:
> This won''t work for another reason: ''extra='' is
a pv config option for passing
> extra kernel options to the boot process, as reflected by /proc/cmdline.
Only
> adding it to menu.lst would work, IF xen-fbfront is builtin, and the syntax
is
> as Fajar suggested - xen-fbfront.video=32,1280,1024. If it is not builtin,
you
> must use the /etc/modprobe.d approach.
OK, I am still actually compiling the kernel after having put the xen-fbfront as
module, in order to use the /etc/modprobe.d approach.
>
> However, beyond syntax problems. I doubt this would work at all in an hvm
> domu, as they don''t use fbfront - that''s a pv driver.
(Fajar - you can verify
> this, right?)
Indeed it is just what I''ve thought too, but I did want to make tests
even I
think that this is not the right way to proceed (what I am doing is of course
not recommended).
What am I doing?
1) I''ve got the vanilla sources (3.1.0) and extracted to /usr/src/
2) cp /boot/config-2.6.37.1-1.2-desktop /usr/src/linux/.config
3) make menuconfig
4) I selected all the modules needed by domU (including XEN_FBDEV):
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_DEBUG is not set
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
# CONFIG_XEN_WDT is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_XEN_BALLOON is not set
# CONFIG_XEN_DEV_EVTCHN is not set
# CONFIG_XEN_BACKEND is not set
# CONFIG_XENFS is not set
# CONFIG_XEN_SYS_HYPERVISOR is not set
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
# CONFIG_XEN_PLATFORM_PCI is not set
CONFIG_SWIOTLB_XEN=y

5) I compiled using make rpm
6) I installed the new kernel and rebooted with the option in menu.lst
I''ve written in my previous message.

After reboot, the only problem (apart the screen) is that xennet (or
similar) and another module
were not available. So the network didn''t work (but this is another
issue). Let''s concentrate on
the screen now.

Now, I am trying to recompile the kernel but setting the
XEN_FBDEV_FRONTEND as module.
Meanwhile I am replying you, it is still compiling.
> ''lspci -vvv'' will tell you what driver is loaded for your
video
> controller. Pls post the output of ''lspci -vvv -s
video-device-number'', and
> then for the driver mentioned at the end, post ''modinfo
driver-name''.
# lspci -vvv -s 00:02.0
00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
[VGA controller])
        Subsystem: XenSource, Inc. Device 0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
        Region 1: Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled]

And it seems no kernel module is used! O_O
>
> A further note: if you ever intend to convert this domu to boot as a pv
domu,
> the above syntax for /dev/disk-by-id won''t work, since pv domus
 don''t use
> qemu disks. (That''s one of those device differences between pv and
hvm domus I
> was talking about.) I suppose this is a worry for much further down the
road.
> In my opensuse memu.lst, it is sufficient to say:
>
> kernel /vmlinuz root=/dev/system/root resume=/dev/system/swap [...]
OK.
For sure I am doing something wrong, even for the fact that I am using a domU
kernel in a hvm guest. Anyway I don''t want to convert it as a pv domU.
I tried to install opensuse as a pv domu, but the installation doesn''t
wont to start
for a screen problem (I mean the setup using qemu-system-x86_64).
>
> if you are using lvm, or simply /dev/sda?, where ?=partition number. Then
> /etc/fstab would have a similar problem, where you would have to use
> /dev/sda?, or /dev/disk/by-uuid. As I say, this is much further down the
road.
I am not using lvm and this is my /etc/fstab:
/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 swap
swap       defaults              0 0
/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2 /
ext4       acl,user_xattr        1 1
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
> Btw, opensuse''s kernel-xen-2.6.37 is still using the old xenlinux
module
> names, even tho'' it has modern modules like evtchn, gntdev and
blktap2. It
> would appear that the framebuffer is built in (CONFIG_XEN_FRAMEBUFFER=y).
I tried to install kernel-xen-2.6.37.6-0.9.1 but no luck with it.
Actually, even the info says that: "This kernel can be used both as the
domain0
("xen0") and as an unprivileged ("xenU") kernel." I
tried to boot with it but:
1) it create an entry in menu.lst and it is for a dom0, since it
create the "kernel /xen.gz"
line, so it can''t boot, since the hypervisor has noot been installed.
Furthermore, I don''t
want to install the hypervisor, since it is a hvm domU.

2) if I delete the kernel line and I leave only the two following
(i.e. the kernel and the
initrd lines) the domU doesn''t start.

So I decided to uninstall that kernel-xen package and to compile the
sources by myself.

On 9 November 2011 06:55, Fajar A. Nugraha <list@fajar.net>
wrote:
> I lost track of what Flavio is using.
I hope that my previous clarifications were useful to get you on the right way
to understand what I am doing! ;-)
>
> Anyway, if it''s PV, using something like
> "xen-fbfront.video=16,1280,1024" on kernel command line should
work
> regardless whether its built-on or module. If it''s module, you
also
> have the option of using /etc/modprobe.d
>
> with stdvga=0, you''d get
>
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
> [VGA controller])
>        Subsystem: XenSource, Inc. Device 0001
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
>        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 0
>        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
>        Region 1: Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>        Expansion ROM at <unassigned> [disabled]
>        Kernel modules: cirrusfb
>
> and starting X directly would get you lots of entries like this on
Xorg.0.log
>
> [    89.540] (II) CIRRUS(0): Not using default mode "1280x1024"
(bad
> mode clock/interlace/doublescan)
> [    89.540] (II) CIRRUS(0): Not using default mode "1600x1200"
> (insufficient memory for mode)
> [    89.540] (II) CIRRUS(0): Not using default mode "800x600"
(bad
> mode clock/interlace/doublescan)
>
> ... and
>
> [    89.541] (--) CIRRUS(0): Virtual size is 1024x768 (pitch 1024)
> [    89.542] (**) CIRRUS(0): *Default mode "1024x768": 65.0 MHz,
48.4
> kHz, 60.0 Hz
> [    89.542] (II) CIRRUS(0): Modeline "1024x768"x60.0   65.00 
1024
> 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
> [    89.542] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz,
37.9
> kHz, 60.3 Hz
> [    89.542] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800
840
> 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
OK, but it''s hvm. And I get nothing of that.


On 9 November 2011 09:27, jim burns <jim_burn@bellsouth.net>
wrote:
> Flavio - besides the lspci and modinfo output I asked for, post your
> Xorg.0.log as well. Then I can compare it to what Fajar posted.
Of course, here we go: http://pastebin.com/d49wcUxD

In conclusion, I am aware that what I am doing is not properly
correct, and I would
simply be able to install a rpm kernel without compiling a new one
every time, because
it is something insane.
I''ve found this: http://forum.3tera.com/showthread.php?t=2161
Maybe there is some rpm ready to use, and to solve the problem, but I
would like to
try with the kernel I am still compiling now.

Cheers,

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 9 November 2011 10:48, Flavio <fbcyborg@gmail.com>
wrote:
> After reboot, the only problem (apart the screen) is that xennet (or
> similar) and another module
> were not available. So the network didn''t work (but this is
another
> issue). Let''s concentrate on
> the screen now.
Heres the missing modules:
modprobe: Module xennet not found.
WARNING: no dependencies for kernel module ''xennet'' found.
modprobe: Module xenblk not found.
WARNING: no dependencies for kernel module ''xenblk'' found.

I''ve just recompiled the kernel.
And now:
# cat /etc/modprobe.d/xen-fbfront.conf
options xen-fbfront video=32,1280,1024

but when I modprobe the module, it says:
FATAL: Error inserting xen_fbfront
(/lib/modules/3.1.0-1.2-desktop/kernel/drivers/video/xen-fbfront.ko):
No such device

So, definitely this is not the right way to solve the problem.
-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed November 9 2011, 1:47:52 PM, Flavio wrote:
> On 9 November 2011 10:48, Flavio <fbcyborg@gmail.com> wrote:
> > After reboot, the only problem (apart the screen) is that xennet (or
> > similar) and another module
> > were not available. So the network didn''t work (but this is
another
> > issue). Let''s concentrate on
> > the screen now.
> 
> Heres the missing modules:
> modprobe: Module xennet not found.
> WARNING: no dependencies for kernel module ''xennet''
found.
> modprobe: Module xenblk not found.
> WARNING: no dependencies for kernel module ''xenblk''
found.
> 
> I''ve just recompiled the kernel.
> And now:
> # cat /etc/modprobe.d/xen-fbfront.conf
> options xen-fbfront video=32,1280,1024
> 
> but when I modprobe the module, it says:
> FATAL: Error inserting xen_fbfront
> (/lib/modules/3.1.0-1.2-desktop/kernel/drivers/video/xen-fbfront.ko):
> No such device
> 
> So, definitely this is not the right way to solve the problem.
Correct - as I said, wrong driver for hvm. That is a pv driver.

On Wed November 9 2011, 10:48:19 AM, Flavio wrote:
> Indeed it is just what I''ve thought too, but I did want to make
tests even I
> think that this is not the right way to proceed (what I am doing is of
> course not recommended).
> What am I doing?
> 1) I''ve got the vanilla sources (3.1.0) and extracted to /usr/src/
> 2) cp /boot/config-2.6.37.1-1.2-desktop /usr/src/linux/.config
> 3) make menuconfig
> 4) I selected all the modules needed by domU (including XEN_FBDEV):
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_XEN_DEBUG is not set
> CONFIG_PCI_XEN=y
> CONFIG_XEN_PCIDEV_FRONTEND=y
> CONFIG_XEN_BLKDEV_FRONTEND=y
> CONFIG_NETXEN_NIC=m
> CONFIG_XEN_NETDEV_FRONTEND=y
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> # CONFIG_XEN_WDT is not set
> CONFIG_XEN_FBDEV_FRONTEND=y
> # CONFIG_XEN_BALLOON is not set
> # CONFIG_XEN_DEV_EVTCHN is not set
> # CONFIG_XEN_BACKEND is not set
> # CONFIG_XENFS is not set
> # CONFIG_XEN_SYS_HYPERVISOR is not set
> CONFIG_XEN_XENBUS_FRONTEND=y
> # CONFIG_XEN_GNTDEV is not set
> # CONFIG_XEN_GRANT_DEV_ALLOC is not set
> # CONFIG_XEN_PLATFORM_PCI is not set
> CONFIG_SWIOTLB_XEN=y
Actually, I''m surprised you got as close as you did. As I mentioned, 
opensuse''s 2.6.37 is based on the old xen architecture, called
xenlinux. 3.1
is using the newer pvops architecture, and uses somewhat different config 
options. I see you''ve got most of this builtin (=y), and not as modules
(=m).
That''s not a bad idea, especially for the ''FRONTEND''
config options - it
avoids missing modules in initrd. You probably want BALLOON set. In a dom0, 
you would have various BACKENDs set (not shown, probably because the names are 
different in 2.6.37), and you would also want EVTCHN & GNTDEV set. You can 
probably get away without these in a domu. Not sure about PLATFORM_PCI - 
definitely required in a pv domu for pci passthrough to work. Not sure what an 
hvm domu needs for passthrough.

Your modprobe errors for xennet and xenblk are probably because opensuse 
expects those names (xenlinux) instead of the newer names (pvops). They can be 
ignored if your FRONTENDS are builtin. Look in /etc/sysconfig/kernel, on the 
line with the variable DOMU_INITRD_MODULES. Another interesting file is 
/etc/sysconfig/bootloader, where you set defaults for menu.lst.
> 5) I compiled using make rpm
> 6) I installed the new kernel and rebooted with the option in menu.lst
> I''ve written in my previous message.
> 
> After reboot, the only problem (apart the screen) is that xennet (or
> similar) and another module
> were not available. So the network didn''t work (but this is
another
> issue). Let''s concentrate on
> the screen now.
> 
> Now, I am trying to recompile the kernel but setting the
> XEN_FBDEV_FRONTEND as module.
> Meanwhile I am replying you, it is still compiling.
> 
> > ''lspci -vvv'' will tell you what driver is loaded for
your video
> > controller. Pls post the output of ''lspci -vvv -s
video-device-number'',
> > and then for the driver mentioned at the end, post ''modinfo
> > driver-name''.
> # lspci -vvv -s 00:02.0
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
> [VGA controller])
>         Subsystem: XenSource, Inc. Device 0001
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
>         Region 1: Memory at f3000000 (32-bit, non-prefetchable) [size=4K]
>         Expansion ROM at <unassigned> [disabled]
> 
> And it seems no kernel module is used! O_O
> 
Interesting - otherwise, it''s exactly the same as what Fajar posted.
Try this
- edit /etc/init.d/boot.local, and add the line ''modprobe
cirrusfb'', and
reboot. That will execute before any of the services start up.
> I am not using lvm and this is my /etc/fstab:
> /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 swap
> swap       defaults              0 0
> /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2 /
> ext4       acl,user_xattr        1 1
> proc                 /proc                proc       defaults             
0
> 0 sysfs                /sys                 sysfs      noauto              
>  0 0 debugfs              /sys/kernel/debug    debugfs    noauto           
>     0 0 usbfs                /proc/bus/usb        usbfs      noauto        
>        0 0 devpts               /dev/pts             devpts    
> mode=0620,gid=5       0 0
Yep - same problem. In a pv domain,there would be no QEMU by-id lines. an be 
ignored for now.
> > Btw, opensuse''s kernel-xen-2.6.37 is still using the old
xenlinux module
> > names, even tho'' it has modern modules like evtchn, gntdev
and blktap2.
> > It would appear that the framebuffer is built in
> > (CONFIG_XEN_FRAMEBUFFER=y).
> I tried to install kernel-xen-2.6.37.6-0.9.1 but no luck with it.
> Actually, even the info says that: "This kernel can be used both as
the
> domain0 ("xen0") and as an unprivileged ("xenU")
kernel." I tried to boot
> with it but: 1) it create an entry in menu.lst and it is for a dom0, since
> it create the "kernel /xen.gz"
> line, so it can''t boot, since the hypervisor has noot been
installed.
> Furthermore, I don''t
> want to install the hypervisor, since it is a hvm domU.
> 
> 2) if I delete the kernel line and I leave only the two following
> (i.e. the kernel and the
> initrd lines) the domU doesn''t start.
I''m assuming you changed ''module vmlinuz...'' to
''kernel vmlinuz...'', and
''module initrd.../initramfs...'' to ''initrd
initrd.../initramfs...''. (Systems
that use dracut to run the boot process use initramfs instead of initrd. 
Opensuse 11.4 (where 2.6.37 came from) doesn''t use dracut.) In other
words,
with opensuse''s habit of providing the symlinks vmlinuz and initrd
pointing to
the actual binaries in /boot, your grub entry would be similar to:

title openSUSE
    root (hd0,1)
    kernel /vmlinuz root=/dev/system/root resume=/dev/system/swap showopts 
vga=0x31a CPUFREQ=no
    initrd /initrd

if you use lvm. Since you don''t, replace /dev/system/... with /dev/sda,
/dev/sdb, etc. as appropriate. And make sure the first ''root''
option is right.
''(hd0,1)'' as shown would be /dev/sda2, where /boot lives. If
/boot is not on a
separate partition from /, then ''/vmlinuz'' becomes
''/boot/vmlinuz'', etc.
> So I decided to uninstall that kernel-xen package and to compile the
> sources by myself.
> 
> On 9 November 2011 06:55, Fajar A. Nugraha <list@fajar.net> wrote:
> > I lost track of what Flavio is using.
> 
> I hope that my previous clarifications were useful to get you on the right
> way to understand what I am doing! ;-)
> 
> > Anyway, if it''s PV, using something like
> > "xen-fbfront.video=16,1280,1024" on kernel command line
should work
> > regardless whether its built-on or module. If it''s module,
you also
> > have the option of using /etc/modprobe.d
> > 
> > with stdvga=0, you''d get
> > 
> > 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
> > [VGA controller])
> > 
> >        Subsystem: XenSource, Inc. Device 0001
> >        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV-
> >        VGASnoop- ParErr-> 
> > Stepping- SERR- FastB2B- DisINTx-
> > 
> >        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> >        >TAbort-
> > 
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > 
> >        Latency: 0
> >        Region 0: Memory at f0000000 (32-bit, prefetchable)
> >        [size=32M]
> >        Region 1: Memory at f3000000 (32-bit, non-prefetchable)
> >        [size=4K]
> >        Expansion ROM at <unassigned> [disabled]
> >        Kernel modules: cirrusfb
> > 
> > and starting X directly would get you lots of entries like this on
> > Xorg.0.log
> > 
> > [    89.540] (II) CIRRUS(0): Not using default mode
"1280x1024" (bad
> > mode clock/interlace/doublescan)
> > [    89.540] (II) CIRRUS(0): Not using default mode
"1600x1200"
> > (insufficient memory for mode)
> > [    89.540] (II) CIRRUS(0): Not using default mode
"800x600" (bad
> > mode clock/interlace/doublescan)
> > 
> > ... and
> > 
> > [    89.541] (--) CIRRUS(0): Virtual size is 1024x768 (pitch 1024)
> > [    89.542] (**) CIRRUS(0): *Default mode "1024x768": 65.0
MHz, 48.4
> > kHz, 60.0 Hz
> > [    89.542] (II) CIRRUS(0): Modeline "1024x768"x60.0  
65.00  1024
> > 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
> > [    89.542] (**) CIRRUS(0): *Default mode "800x600": 40.0
MHz, 37.9
> > kHz, 60.3 Hz
> > [    89.542] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00
800 840
> > 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
> 
> OK, but it''s hvm. And I get nothing of that.
> 
> On 9 November 2011 09:27, jim burns <jim_burn@bellsouth.net> wrote:
> > Flavio - besides the lspci and modinfo output I asked for, post your
> > Xorg.0.log as well. Then I can compare it to what Fajar posted.
> 
> Of course, here we go: http://pastebin.com/d49wcUxD
Interesting - you definitely get the cirrus xorg module being selected, along 
with the other candidates fbdev and vesa. After the card is initialized, fbdev 
and vesa are unloaded, in favor of the better candidate cirrus. What surprises 
me if that the ''lspci'' output you posted didn''t have
the *kernel* module
driver cirrusfb. I didn''t think the xorg module cirrus would work
without the
kernel module driver cirrusfb. Also, Xorg.0.log is clearly only supporting 
800x600 and 640x480, as opposed to the extra resolution Fajar posted - 
1024x768. Hopefully, the modprobe I asked you to put in /etc/init.d/boot.local 
will sort this out. Post ''lspci -vvv -s 00:02.0'' after you
make that change.
> In conclusion, I am aware that what I am doing is not properly
> correct, and I would
> simply be able to install a rpm kernel without compiling a new one
> every time, because
> it is something insane.
> I''ve found this: http://forum.3tera.com/showthread.php?t=2161
Yeah - that''s pretty old.
> Maybe there is some rpm ready to use, and to solve the problem, but I
> would like to
> try with the kernel I am still compiling now.
> 
> Cheers,
> 
> --
> Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 10 November 2011 00:15, jim burns <jim_burn@bellsouth.net>
wrote:
> You probably want BALLOON set. In a dom0,
> you would have various BACKENDs set (not shown, probably because the names
are
> different in 2.6.37), and you would also want EVTCHN & GNTDEV set.
Yes, and they are actually compiled in the dom0 kernel. balloon is compiled too.
> You can
> probably get away without these in a domu. Not sure about PLATFORM_PCI -
> definitely required in a pv domu for pci passthrough to work. Not sure what
an
> hvm domu needs for passthrough.
Don''t worry about that, becouse I cannot do so much with the
passthrough.
>
> Your modprobe errors for xennet and xenblk are probably because opensuse
> expects those names (xenlinux) instead of the newer names (pvops). They can
be
> ignored if your FRONTENDS are builtin.
As a matter of fact, I don''t know if I can, because the network
doesn''t work. Or, even
better, the IP address is going to be assigned during the boot but I
can''t ping the two
hosts (domU and dom0) each other.
> Look in /etc/sysconfig/kernel, on the
> line with the variable DOMU_INITRD_MODULES. Another interesting file is
> /etc/sysconfig/bootloader, where you set defaults for menu.lst.
Yes, I''ve seen.

> Interesting - otherwise, it''s exactly the same as what Fajar
posted. Try this
> - edit /etc/init.d/boot.local, and add the line ''modprobe
cirrusfb'', and
> reboot. That will execute before any of the services start up.
Yes, the module is loaded, but the lspci result is still the same. No
driver mentioned.
>> 2) if I delete the kernel line and I leave only the two following
>> (i.e. the kernel and the
>> initrd lines) the domU doesn''t start.
>
> I''m assuming you changed ''module vmlinuz...'' to
''kernel vmlinuz...'', and
> ''module initrd.../initramfs...'' to ''initrd
initrd.../initramfs...''.
Yes.
> (Systems
> that use dracut to run the boot process use initramfs instead of initrd.
> Opensuse 11.4 (where 2.6.37 came from) doesn''t use dracut.) In
other words,
> with opensuse''s habit of providing the symlinks vmlinuz and initrd
pointing to
> the actual binaries in /boot, your grub entry would be similar to:
>
> title openSUSE
>    root (hd0,1)
>    kernel /vmlinuz root=/dev/system/root resume=/dev/system/swap showopts
> vga=0x31a CPUFREQ=no
>    initrd /initrd
>
> if you use lvm. Since you don''t, replace /dev/system/... with
/dev/sda,
> /dev/sdb, etc. as appropriate. And make sure the first
''root'' option is right.
> ''(hd0,1)'' as shown would be /dev/sda2, where /boot lives.
If /boot is not on a
> separate partition from /, then ''/vmlinuz'' becomes
''/boot/vmlinuz'', etc.
OK.
Then, what I have done now is:
1) install again kernel-xen package.
I noticed a strange fact: the new entry that has been created in the
menu.lst is the
following:
title Xen -- openSUSE 11.4 - 2.6.37.6-0.9
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.6-0.9-xen
root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
quiet showopts vga=0x314
    initrd /boot/initrd-2.6.37.6-0.9-xen

The last time I installed kernel-xen, there was also the xen.gz entry.

2) I tried to reboot with this new xen kernel but, after selecting the
kernel above Grub says:
Error 13: Invalid or unsupported executable format

And that is the same error I got previously when I made the change
described in a
previous e-mail, as regard the menu.lst file.

3) I booted again with the previous working kernel and made the
modification you
suggested to me, making the new grub xen entry like the following:

title Xen -- openSUSE 11.4 - 2.6.37.6-0.9
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.6-0.9-xen root=/dev/sda2
resume=/dev/sda2 splash=silent quiet showopts vga=0x314
    initrd /boot/initrd-2.6.37.6-0.9-xen

4) reboot with the kernel above and I get the same error at point 2.
> Interesting - you definitely get the cirrus xorg module being selected,
along
> with the other candidates fbdev and vesa. After the card is initialized,
fbdev
> and vesa are unloaded, in favor of the better candidate cirrus. What
surprises
> me if that the ''lspci'' output you posted didn''t
have the *kernel* module
> driver cirrusfb. I didn''t think the xorg module cirrus would work
without the
> kernel module driver cirrusfb.
Maybe it works thanks to the vesa generic driver.
> Also, Xorg.0.log is clearly only supporting
> 800x600 and 640x480, as opposed to the extra resolution Fajar posted -
> 1024x768. Hopefully, the modprobe I asked you to put in
/etc/init.d/boot.local
> will sort this out. Post ''lspci -vvv -s 00:02.0'' after
you make that change.
OK, I answered to this, before...
>
>> In conclusion, I am aware that what I am doing is not properly
>> correct, and I would
>> simply be able to install a rpm kernel without compiling a new one
>> every time, because
>> it is something insane.
>> I''ve found this: http://forum.3tera.com/showthread.php?t=2161
>
> Yeah - that''s pretty old.
And the downloads are no longer available :(

Thanks a lot,

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Sorry - I got busy.

On Thu November 10 2011, 11:58:36 AM, Flavio wrote:
> > Your modprobe errors for xennet and xenblk are probably because
opensuse
> > expects those names (xenlinux) instead of the newer names (pvops).
They
> > can be ignored if your FRONTENDS are builtin.
> 
> As a matter of fact, I don''t know if I can, because the network
> doesn''t work. Or, even
> better, the IP address is going to be assigned during the boot but I
> can''t ping the two
> hosts (domU and dom0) each other.
Ok - while the domu is running, let''s see the output of
in dom0: ls -alFR /sys/bus/xen* ; ifconfig ; brctl show ; & netstat -tlp | 
grep 59
in domu: ls -alFR /sys/bus/xen* ; ifconfig
> > Interesting - otherwise, it''s exactly the same as what Fajar
posted. Try
> > this - edit /etc/init.d/boot.local, and add the line
''modprobe
> > cirrusfb'', and reboot. That will execute before any of the
services
> > start up.
> 
> Yes, the module is loaded, but the lspci result is still the same. No
> driver mentioned.
Ok - in domu, post the output of:
lsmod|egrep ''vesa|cirrus''
egrep -i ''vesa|cirrus'' /boot/config*
ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
ls -alF /sys/bus/pci/drivers/{vesa,cirrus}*
modprobe cirrusfb

Let''s see which driver is servicing the video card. On my systems,
cirrusfb is
a module, vesa is builtin. Builtins will not show up as a kernel driver in 
lspci -vvv. Then we''ll see whether the cirrusfb module gets an error on
loading.
> OK.
> Then, what I have done now is:
> 1) install again kernel-xen package.
> I noticed a strange fact: the new entry that has been created in the
> menu.lst is the
> following:
> title Xen -- openSUSE 11.4 - 2.6.37.6-0.9
>     root (hd0,1)
>     kernel /boot/vmlinuz-2.6.37.6-0.9-xen
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet showopts vga=0x314
>     initrd /boot/initrd-2.6.37.6-0.9-xen
> 
> The last time I installed kernel-xen, there was also the xen.gz entry.
> 
> 2) I tried to reboot with this new xen kernel but, after selecting the
> kernel above Grub says:
> Error 13: Invalid or unsupported executable format
> 
> And that is the same error I got previously when I made the change
> described in a previous e-mail, as regard the menu.lst file.
Hmm - that''s an error I would expect with earlier versions of xen. Eg -
xen <
3.4.0 can''t boot a pvops domu, without backported patches. What
distribution
is your dom0, and what xen version?
> > Interesting - you definitely get the cirrus xorg module being
selected,
> > along with the other candidates fbdev and vesa. After the card is
> > initialized, fbdev and vesa are unloaded, in favor of the better
> > candidate cirrus. What surprises me if that the
''lspci'' output you
> > posted didn''t have the kernel module driver cirrusfb. I
didn''t think
> > the xorg module cirrus would work without the kernel module driver
> > cirrusfb.
> 
> Maybe it works thanks to the vesa generic driver.
Which is what we are checking above.

Finally, post your full dmesg from your domu. Maybe something will jump out at 
me.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 13 November 2011 01:13, jim burns <jim_burn@bellsouth.net>
wrote:
>
> Sorry - I got busy.
No problem!
> Ok - while the domu is running, let''s see the output of
> in dom0: ls -alFR /sys/bus/xen* ; ifconfig ; brctl show ; & netstat
-tlp |
> grep 59
These are the outputs produced when the new 3.1.0 kernel is running and the
network is not working:
http://pastebin.com/6yRqnzrh
> in domu: ls -alFR /sys/bus/xen* ; ifconfig
http://pastebin.com/eaiVdHz0

Now I came back to 2.6.37 (network working) so I can use ssh.
> Ok - in domu, post the output of:
> lsmod|egrep ''vesa|cirrus''
cirrusfb               32579  0
> egrep -i ''vesa|cirrus'' /boot/config*
/boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
/boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_CIRRUS=m
/boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_UVESA=m
/boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_VESA=y
/boot/config-2.6.37.1-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
/boot/config-3.1.0-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
/boot/config-3.1.0-1.2-desktop:CONFIG_FB_CIRRUS=m
/boot/config-3.1.0-1.2-desktop:CONFIG_FB_UVESA=m
/boot/config-3.1.0-1.2-desktop:CONFIG_FB_VESA=y
/boot/config-3.1.0-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
> ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
lrwxrwxrwx 1 root root 0 Nov 13 09:57
/sys/bus/pci/devices/0000:00:02.0 ->
../../../devices/pci0000:00/0000:00:02.0/
> ls -alF /sys/bus/pci/drivers/{vesa,cirrus}*
ls: cannot access /sys/bus/pci/drivers/vesa*: No such file or directory
/sys/bus/pci/drivers/cirrusfb:
total 0
drwxr-xr-x  2 root root    0 Nov 13 09:57 ./
drwxr-xr-x 23 root root    0 Nov 13 09:57 ../
--w-------  1 root root 4096 Nov 13 09:58 bind
lrwxrwxrwx  1 root root    0 Nov 13 09:58 module ->
../../../../module/cirrusfb/
--w-------  1 root root 4096 Nov 13 09:58 new_id
--w-------  1 root root 4096 Nov 13 09:58 remove_id
--w-------  1 root root 4096 Nov 13 09:57 uevent
--w-------  1 root root 4096 Nov 13 09:58 unbind
> modprobe cirrusfb
module is already loaded but no errors reported.
>
> Let''s see which driver is servicing the video card. On my systems,
cirrusfb is
> a module, vesa is builtin. Builtins will not show up as a kernel driver in
> lspci -vvv. Then we''ll see whether the cirrusfb module gets an
error on
> loading.
It seems not during loading even I''ve found this in the dmesg:
[   32.626308] cirrusfb 0000:00:02.0: BAR 0: can''t reserve [mem
0xf0000000-0xf1ffffff pref]
[   32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000, abort
[   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16
> Hmm - that''s an error I would expect with earlier versions of xen.
Eg - xen <
> 3.4.0 can''t boot a pvops domu, without backported patches. What
distribution
> is your dom0, and what xen version?
First of all, I say that my dom0 works like a charm with most of my domUs.
Gentoo Linux x86_64 kernel 3.1.0-gentoo
app-emulation/xen-4.1.2
app-emulation/xen-tools-4.1.2
I''m using xl toolstack.

> Which is what we are checking above.
Mmmh, I think it is not, after having seen the result above :|
Do you agree?
>
> Finally, post your full dmesg from your domu. Maybe something will jump out
at
> me.
Yes, here it is: http://pastebin.com/vNpumSik

Thanks a lot,
--
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Meanwhile I am performing a new suse installation (as a PV guest) using
this installation method:
http://bderzhavets.blogspot.com/2009/02/install-opensuse-11.html

It seems to work, even the mouse is not working at the moment.
Let''s see what happens.

Cheers

On 13 November 2011 10:12, Flavio <fbcyborg@gmail.com>
wrote:
> On 13 November 2011 01:13, jim burns <jim_burn@bellsouth.net> wrote:
>>
>> Sorry - I got busy.
> No problem!
>
>> Ok - while the domu is running, let''s see the output of
>> in dom0: ls -alFR /sys/bus/xen* ; ifconfig ; brctl show ; & netstat
-tlp |
>> grep 59
> These are the outputs produced when the new 3.1.0 kernel is running and the
> network is not working:
> http://pastebin.com/6yRqnzrh
>
>> in domu: ls -alFR /sys/bus/xen* ; ifconfig
> http://pastebin.com/eaiVdHz0
>
> Now I came back to 2.6.37 (network working) so I can use ssh.
>
>> Ok - in domu, post the output of:
>> lsmod|egrep ''vesa|cirrus''
> cirrusfb               32579  0
>
>> egrep -i ''vesa|cirrus'' /boot/config*
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_CIRRUS=m
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_UVESA=m
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_VESA=y
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_CIRRUS=m
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_UVESA=m
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_VESA=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
>
>> ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
> lrwxrwxrwx 1 root root 0 Nov 13 09:57
> /sys/bus/pci/devices/0000:00:02.0 ->
> ../../../devices/pci0000:00/0000:00:02.0/
>
>> ls -alF /sys/bus/pci/drivers/{vesa,cirrus}*
> ls: cannot access /sys/bus/pci/drivers/vesa*: No such file or directory
> /sys/bus/pci/drivers/cirrusfb:
> total 0
> drwxr-xr-x  2 root root    0 Nov 13 09:57 ./
> drwxr-xr-x 23 root root    0 Nov 13 09:57 ../
> --w-------  1 root root 4096 Nov 13 09:58 bind
> lrwxrwxrwx  1 root root    0 Nov 13 09:58 module ->
../../../../module/cirrusfb/
> --w-------  1 root root 4096 Nov 13 09:58 new_id
> --w-------  1 root root 4096 Nov 13 09:58 remove_id
> --w-------  1 root root 4096 Nov 13 09:57 uevent
> --w-------  1 root root 4096 Nov 13 09:58 unbind
>
>> modprobe cirrusfb
> module is already loaded but no errors reported.
>
>>
>> Let''s see which driver is servicing the video card. On my
systems, cirrusfb is
>> a module, vesa is builtin. Builtins will not show up as a kernel driver
in
>> lspci -vvv. Then we''ll see whether the cirrusfb module gets an
error on
>> loading.
> It seems not during loading even I''ve found this in the dmesg:
> [   32.626308] cirrusfb 0000:00:02.0: BAR 0: can''t reserve [mem
> 0xf0000000-0xf1ffffff pref]
> [   32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000,
abort
> [   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16
>
>> Hmm - that''s an error I would expect with earlier versions of
xen. Eg - xen <
>> 3.4.0 can''t boot a pvops domu, without backported patches.
What distribution
>> is your dom0, and what xen version?
> First of all, I say that my dom0 works like a charm with most of my domUs.
> Gentoo Linux x86_64 kernel 3.1.0-gentoo
> app-emulation/xen-4.1.2
> app-emulation/xen-tools-4.1.2
> I''m using xl toolstack.
>
>
>> Which is what we are checking above.
> Mmmh, I think it is not, after having seen the result above :|
> Do you agree?
>
>>
>> Finally, post your full dmesg from your domu. Maybe something will jump
out at
>> me.
> Yes, here it is: http://pastebin.com/vNpumSik
>
> Thanks a lot,
> --
> Flavio
>


-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 13 2011, 10:12:00 AM, Flavio wrote:
> On 13 November 2011 01:13, jim burns <jim_burn@bellsouth.net> wrote:
> > Sorry - I got busy.
> 
> No problem!
> 
> > Ok - while the domu is running, let''s see the output of
> > in dom0: ls -alFR /sys/bus/xen* ; ifconfig ; brctl show ; &
netstat -tlp
> > | grep 59
> 
> These are the outputs produced when the new 3.1.0 kernel is running and the
> network is not working:
> http://pastebin.com/6yRqnzrh
Mostly looks ok. Just double check - you don''t have a xen-netback
module
servicing vif2.0, as shown by /sys/bus/xen-backend/drivers/vif (as opposed to 
xen-blkback, which is shown servicing what appears to be qdisk-2-768 in 
/sys/bus/xen-backend/drivers/vbd). Just make sure that xen-netback is a 
builtin in your Gentoo dom0 - grep XEN /boot/config* | grep BACK | grep NET . 
You should come up with CONFIG_XEN_NETDEV_BACKEND=y for a 3.1 Gentoo kernel. 
I''m assuming this is going to work, since one hvm domu has a network,
and the
other doesn''t.

Eth0 & tap2.0 look good - they only have an ipv6 address, since they are on
a
bridge. Vif2.0 has no address, which is fine, since an hvm domu uses tap, not 
vif (unless you are using pv on hvm). Xenbr0 has both ipv6 and ipv4 addresses, 
for internet access. Not sure why you have a tun0 point to point interface, 
but since it is on a different private subnet, I''m going to ignore it.

Since you don''t specify vncdisplay / vncunused in your hvm config, you
are
defaulting to vncunused, which grabs the first unused vnc port, which appears 
to be 5900.
> > in domu: ls -alFR /sys/bus/xen* ; ifconfig
> 
> http://pastebin.com/eaiVdHz0
Looks good. Again, no xen frontend drivers shown. You said that you compiled 
the FRONTENDs in 3.1 as builtin, so that''s ok. Eth0 correctly has the
mac
address you specified in your hvm config, and a 192.168.1 subnet address to 
match the 192.168.1.100 address on your dom0 xenbr0.

Assuming everything is builtin that I asked about, this should be working. You 
have enough of a network working to have gotten an ipv4 address for your domu 
eth0. SuSE has a rather restrictive firewall. As a test, try doing 
''rcSuSEfirewall2 stop'', and see if that helps. If it does, we
can play with
the firewall config to allow all traffic on your 192.168.1 subnet. If one hvm 
domu works, and the other doesn''t. it could be that one kernel
doesn''t have a
kernel module that the firewall needs, so it is defaulting to lockdown.

If none of this works, you may have to break out tcpdump on the tap interface. 
I''m no expert with it, but I''d look for some kind of
restriction on the kind
of traffic that''s getting out of the interface - just arp and udp, but
no tcp,
or communication in one direction, but not the other.
> Now I came back to 2.6.37 (network working) so I can use ssh.
> 
> > Ok - in domu, post the output of:
> > lsmod|egrep ''vesa|cirrus''
> 
> cirrusfb               32579  0
Ok, now I''m confused again. Have I got this right - your compiled
kernel, 3.1,
has no network, and your 2.6.37 has the resolution problem? Because at one 
point, you said you tried to install the kernel-xen package from suse 
(2.6.37.6-0.9), and you got an ''Invalid or unsupported executable
format''
error. Which 2.6.37 kernel are you talking about now, that''s (mostly)
working?

Ok - I just looked at your dmesg, and your booting suse''s 2.6.37.1-1.2-
desktop. Let''s look at the file formats:

root@Dell4550 11/13/11 11:23AM:~
[545] > file /boot/vmlinu?-2*
/boot/vmlinux-2.6.37.6-0.9-xen.gz:  gzip compressed data, was 
"vmlinux-2.6.37.6-0.9-xen", from Unix, last modified: Wed Oct 26
11:57:21
2011, max compression /boot/vmlinuz-2.6.37.6-0.9-default: Linux/x86 Kernel, 
Setup Version 0x20a, bzImage, Version 2.6.37.6, RO-rootFS, swap_dev 0x3, 
Normal VGA
/boot/vmlinuz-2.6.37.6-0.9-xen:     gzip compressed data, from Unix, last 
modified: Wed Oct 26 11:39:23 2011, max compression

root@Dell4550 11/13/11 11:25AM:~
[546] > cp /boot/vmlinux-2.6.37.6-0.9-xen.gz .
root@Dell4550 11/13/11 11:27AM:~
[547] > cp /boot/vmlinuz-2.6.37.6-0.9-xen .  
root@Dell4550 11/13/11 11:27AM:~
[548] > gunzip vmlinux-2.6.37.6-0.9-xen.gz 
root@Dell4550 11/13/11 11:27AM:~
[549] > gunzip vmlinuz-2.6.37.6-0.9-xen   
gzip: vmlinuz-2.6.37.6-0.9-xen: unknown suffix -- ignored
[1]    27589 exit 2     gunzip vmlinuz-2.6.37.6-0.9-xen
root@Dell4550 11/13/11 11:27AM:~
[550] > mv vmlinuz-2.6.37.6-0.9-xen{,.gz}
root@Dell4550 11/13/11 11:29AM:~
[551] > gunzip vmlinuz-2.6.37.6-0.9-xen.gz 
root@Dell4550 11/13/11 11:29AM:~

[552] > file vmlin*
vmlinux-2.6.37.6-0.9-xen: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), statically linked, not stripped
vmlinuz-2.6.37.6-0.9-xen: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), statically linked, stripped

So suse''s desktop flavor of the kernel (which has no xen features for a
pv
domain) is a bzimage format, which is standard, and an hvm domain should have 
no problems with it, and your (earlier version) 2.6.37.1-1.2-desktop kernel 
does in deed boot. The 2.6.37.6-0.9-xen kernel(s) are ELF formats, as required 
by a pv domain. Don''t know why you are getting the bad executable
error, but
you can try substituting vmlinux (with an x) for vmlinuz (with a z), and see 
if your pv domain will boot now.

So my question remains: the 3.1 kernel is the one without a network, and the 
2.6.37.1-1.2-desktop is the one with the resolution problems, right?
> > egrep -i ''vesa|cirrus'' /boot/config*
> 
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_CIRRUS=m
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_UVESA=m
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_VESA=y
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_CIRRUS=m
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_UVESA=m
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_VESA=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
This is showing that vesa is builtin, and cirrusfb is a module, as on my 
systems.
> > ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
> lrwxrwxrwx 1 root root 0 Nov 13 09:57
> /sys/bus/pci/devices/0000:00:02.0 ->
> ../../../devices/pci0000:00/0000:00:02.0/
Sorry - I forgot about the soft link. I meant ls -alF 
/sys/bus/pci/devices/0000:00:02.0/ (with a trailing slash). Pls repost.
> > ls -alF /sys/bus/pci/drivers/{vesa,cirrus}*
> 
> ls: cannot access /sys/bus/pci/drivers/vesa*: No such file or directory
> /sys/bus/pci/drivers/cirrusfb:
> total 0
> drwxr-xr-x  2 root root    0 Nov 13 09:57 ./
> drwxr-xr-x 23 root root    0 Nov 13 09:57 ../
> --w-------  1 root root 4096 Nov 13 09:58 bind
> lrwxrwxrwx  1 root root    0 Nov 13 09:58 module ->
> ../../../../module/cirrusfb/ --w-------  1 root root 4096 Nov 13 09:58
> new_id
> --w-------  1 root root 4096 Nov 13 09:58 remove_id
> --w-------  1 root root 4096 Nov 13 09:57 uevent
> --w-------  1 root root 4096 Nov 13 09:58 unbind
> 
> > modprobe cirrusfb
> 
> module is already loaded but no errors reported.
So the drivers listing, and lsmod are showing that cirrusfb is loaded, but 
lspci -vvv is not? Contradictory - again, is this the domu with the resolution 
problem?
> > Let''s see which driver is servicing the video card. On my
systems,
> > cirrusfb is a module, vesa is builtin. Builtins will not show up as a
> > kernel driver in lspci -vvv. Then we''ll see whether the
cirrusfb module
> > gets an error on loading.
> 
> It seems not during loading even I''ve found this in the dmesg:
> [   32.626308] cirrusfb 0000:00:02.0: BAR 0: can''t reserve [mem
> 0xf0000000-0xf1ffffff pref]
> [   32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000,
> abort [   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16
> > Hmm - that''s an error I would expect with earlier versions of
xen. Eg -
> > xen < 3.4.0 can''t boot a pvops domu, without backported
patches. What
> > distribution is your dom0, and what xen version?
> 
> First of all, I say that my dom0 works like a charm with most of my domUs.
> Gentoo Linux x86_64 kernel 3.1.0-gentoo
> app-emulation/xen-4.1.2
> app-emulation/xen-tools-4.1.2
> I''m using xl toolstack.
> 
> > Which is what we are checking above.
> 
> Mmmh, I think it is not, after having seen the result above :|
> Do you agree?
> 
> > Finally, post your full dmesg from your domu. Maybe something will
jump
> > out at me.
> 
> Yes, here it is: http://pastebin.com/vNpumSik
> 
> Thanks a lot,
> --
> Flavio
Yeah - the BAR error bothers me. Something is preventing the cirrusfb from 
initializing. Normally you get a handoff from the builtin vesa driver to the 
installed card driver. This is from my baremetal suse system:

fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver

BAR errors are not something I have experience with. I''m going to
repost this
section of your post, and see if Fajar has something to say.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Fajar - do you know something about video BAR errors?

On Sun November 13 2011, 12:17:22 PM, jim burns wrote:
> > > Let''s see which driver is servicing the video card. On
my systems,
> > > cirrusfb is a module, vesa is builtin. Builtins will not show up
as
> > > a
> > > kernel driver in lspci -vvv. Then we''ll see whether the
cirrusfb
> > > module
> > > gets an error on loading.
> >
> > 
> >
> > It seems not during loading even I''ve found this in the
dmesg:
> > [   32.626308] cirrusfb 0000:00:02.0: BAR 0: can''t reserve
[mem
> > 0xf0000000-0xf1ffffff pref]
> > [   32.626312] cirrusfb 0000:00:02.0: cannot reserve region
0xf0000000,
> > abort [   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error
> > -16> 
> > > What distribution is your dom0, and what xen version?
> >
> > First of all, I say that my dom0 works like a charm with most of my
> > domUs. Gentoo Linux x86_64 kernel 3.1.0-gentoo
> > app-emulation/xen-4.1.2
> > app-emulation/xen-tools-4.1.2
> > I''m using xl toolstack.
> >
> > > Finally, post your full dmesg from your domu. Maybe something
will
> > > jump
> > > out at me.
> >
> > 
> >
> > Yes, here it is: http://pastebin.com/vNpumSik
> >
> > 
> >
> > Thanks a lot,
> > --
> > Flavio
> 
> Yeah - the BAR error bothers me. Something is preventing the cirrusfb from 
> initializing. Normally you get a handoff from the builtin vesa driver to
> the installed card driver. This is from my baremetal suse system:
> 
> fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic
> driver
> 
> BAR errors are not something I have experience with. I''m going to
repost
> this section of your post, and see if Fajar has something to say.
>From his dmesg output:
[    0.667812] vesafb: framebuffer at 0xf0000000, mapped to 
0xffffc90000580000, using 1875k, total 4096k
[    0.667815] vesafb: mode is 800x600x16, linelength=1600, pages=3
[    0.667817] vesafb: scrolling: redraw
[    0.667820] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[    0.668044] bootsplash 3.1.6-2004/03/31: looking for picture...
[    0.668047] bootsplash: silentjpeg size 124451 bytes
[    0.674284] bootsplash: ...found (800x600, 62872 bytes, v3).
[    0.688156] Console: switching to colour frame buffer device 96x33
[    0.701329] fb0: VESA VGA frame buffer device

[   32.626308] cirrusfb 0000:00:02.0: BAR 0: can''t reserve [mem 
0xf0000000-0xf1ffffff pref]
[   32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000, abort
[   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16

They are both reserving the same area of memory, and unlike on my system, vesa 
is not handing off to the selected card driver.

His system configuration is in the parent and grandparent of this post, and 
his domu config was posted on Nov. 8.

Thanx.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 13 2011, 1:23:32 PM, Flavio wrote:
> Meanwhile I am performing a new suse installation (as a PV guest) using
> this installation method:
> http://bderzhavets.blogspot.com/2009/02/install-opensuse-11.html
> 
> It seems to work, even the mouse is not working at the moment.
> Let''s see what happens.
If you are installing from a modern install disk, the xorg driver evdev should 
configure your mouse correctly. Check your Xorg.0.log for evdev.
> root@boris-desktop:/etc/xen/vm# cat suse11.1.cfg
> name="OpenSuse11.1PV"
> memory=2048
> disk =
[''phy:/dev/loop0,hdc:cdrom,r'',''phy:/dev/sda10,hda,w''
]
> vif = [ ''mac=00:16:3e:4a:f5:00, bridge=eth0'', ]
> vfb = [ ''type=vnc,vncunused=1'' ]
> bootloader = “/usr/bin/pygrub”
> kernel = “/boot/x86_64/vmlinuz-xen”
> ramdisk = “/boot/x86_64/initrd-xen”
> vcpus=1
> on_reboot = ‘restart’
> on_crash = ‘restart’
This is kind of old. You say the install worked, even though the config is 
using hdc/hda instead of xvdc/xvda. I''m assuming you changed
bridge=eth0, and
kernel= and ramdisk= to the names on your system.

How is this method working out for you? Network and resolution ok?

Keep answers for this install separate from the hvm problems we are working 
on. This gets confusing enough to keep track of as is. ;-)

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 13 November 2011 18:17, jim burns <jim_burn@bellsouth.net>
wrote:
> Just make sure that xen-netback is a
> builtin in your Gentoo dom0 - grep XEN /boot/config* | grep BACK | grep NET
.
> You should come up with CONFIG_XEN_NETDEV_BACKEND=y for a 3.1 Gentoo
kernel.
> I''m assuming this is going to work, since one hvm domu has a
network, and the
> other doesn''t.
This seems to be OK actually:
$ cat /boot/config-3.1.0-gentoo | grep BACK | grep NET
CONFIG_XEN_NETDEV_BACKEND=y

>
> Eth0 & tap2.0 look good - they only have an ipv6 address, since they
are on a
> bridge. Vif2.0 has no address, which is fine, since an hvm domu uses tap,
not
> vif (unless you are using pv on hvm). Xenbr0 has both ipv6 and ipv4
addresses,
> for internet access. Not sure why you have a tun0 point to point interface,
> but since it is on a different private subnet, I''m going to ignore
it
Yes, ignore it. It''s for the openvpn.

> Since you don''t specify vncdisplay / vncunused in your hvm config,
you are
> defaulting to vncunused, which grabs the first unused vnc port, which
appears
> to be 5900.
Yes, it is that port number.

> eth0. SuSE has a rather restrictive firewall.
Yes I know. Actually, in order to get also the ssh working I had to enable sshd
traffic in the firewall.
> As a test, try doing
> ''rcSuSEfirewall2 stop'', and see if that helps.
nope. I''ve already tried that and it doesn''t help. I think it
is all related to
those kernel modules that are missing.
> If it does, we can play with
> the firewall config to allow all traffic on your 192.168.1 subnet. If one
hvm
> domu works, and the other doesn''t. it could be that one kernel
doesn''t have a
> kernel module that the firewall needs, so it is defaulting to lockdown.
It''s not due to the firewall because if I boot with the default 2.6.37
kernel that
comes with the installation, the network works. Changing the kernel
with the 3.1.0
it doesn''t.
>
> If none of this works, you may have to break out tcpdump on the tap
interface.
> I''m no expert with it,
so am I.
> but I''d look for some kind of restriction on the kind
> of traffic that''s getting out of the interface - just arp and udp,
but no tcp,
> or communication in one direction, but not the other.
I repeat. I think it''s due to the kernel configuration. I have no idea
of what
could the problem be. I prefer to find an alternate solution. By the
way, I couldn''t
setup the PV guest at the end.
>> cirrusfb               32579  0
>
> Ok, now I''m confused again. Have I got this right - your compiled
kernel, 3.1,
> has no network, and your 2.6.37 has the resolution problem?
Both have the resolution problem. 2.6.37 is OK for the network. 3.1.0 is not OK.
> Because at one
> point, you said you tried to install the kernel-xen package from suse
> (2.6.37.6-0.9), and you got an ''Invalid or unsupported executable
format''
> error.
Yes, the kernel-xen doesn''t work to me. Anyway, I don''t think
it is a good
thing, to install a domU kernel if it won''t run on a PV guest.
> Which 2.6.37 kernel are you talking about now, that''s (mostly)
working?
2.6.37 is the kernel that comes with the distribution setup (suse 11.4).
It''s not a xen capable kernel, or even better it''s a
"normal" kernel.
3.1.0 is a kernel that has been compiled by myself.
kernel-xen, has been installed with zypper, the suse package manager.
>
> Ok - I just looked at your dmesg, and your booting suse''s
2.6.37.1-1.2-
> desktop. Let''s look at the file formats:
> [...]
>
> So suse''s desktop flavor of the kernel (which has no xen features
for a pv
> domain) is a bzimage format, which is standard, and an hvm domain should
have
> no problems with it, and your (earlier version) 2.6.37.1-1.2-desktop kernel
> does in deed boot. The 2.6.37.6-0.9-xen kernel(s) are ELF formats, as
required
> by a pv domain. Don''t know why you are getting the bad executable
error, but
> you can try substituting vmlinux (with an x) for vmlinuz (with a z), and
see
> if your pv domain will boot now.
It''s not pv, but hvm. Anyway, I can''t substitute a z with a x.
The
file is called
vmlinuz. Or maybe I didn''t understand exactly what you mean.
>
> So my question remains: the 3.1 kernel is the one without a network, and
the
> 2.6.37.1-1.2-desktop is the one with the resolution problems, right?
Right. As I''ve written above, both have the resolution problem,
otherwise,
the resolution problem would be solved now, and we would talk about a networking
problem! ;)

>
> This is showing that vesa is builtin, and cirrusfb is a module, as on my
> systems.
>
>> > ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
>
>> lrwxrwxrwx 1 root root 0 Nov 13 09:57
>> /sys/bus/pci/devices/0000:00:02.0 ->
>> ../../../devices/pci0000:00/0000:00:02.0/
>
> Sorry - I forgot about the soft link. I meant ls -alF
> /sys/bus/pci/devices/0000:00:02.0/ (with a trailing slash). Pls repost.
# ls -alF /sys/bus/pci/devices/0000:00:02.0/
total 0
drwxr-xr-x  3 root root        0 Nov 13 23:49 ./
drwxr-xr-x 12 root root        0 Nov 13 23:49 ../
-r--r--r--  1 root root     4096 Nov 13 23:49 boot_vga
-rw-r--r--  1 root root     4096 Nov 13 23:52 broken_parity_status
-r--r--r--  1 root root     4096 Nov 13 23:51 class
-rw-r--r--  1 root root      256 Nov 13 23:49 config
-r--r--r--  1 root root     4096 Nov 13 23:52 consistent_dma_mask_bits
-r--r--r--  1 root root     4096 Nov 13 23:52 device
-r--r--r--  1 root root     4096 Nov 13 23:52 dma_mask_bits
-rw-------  1 root root     4096 Nov 13 23:52 enable
-r--r--r--  1 root root     4096 Nov 13 23:52 irq
-r--r--r--  1 root root     4096 Nov 13 23:52 local_cpulist
-r--r--r--  1 root root     4096 Nov 13 23:52 local_cpus
-r--r--r--  1 root root     4096 Nov 13 23:52 modalias
-rw-r--r--  1 root root     4096 Nov 13 23:52 msi_bus
-r--r--r--  1 root root     4096 Nov 13 23:52 numa_node
drwxr-xr-x  2 root root        0 Nov 13 23:52 power/
--w--w----  1 root root     4096 Nov 13 23:52 remove
--w--w----  1 root root     4096 Nov 13 23:52 rescan
-r--r--r--  1 root root     4096 Nov 13 23:49 resource
-rw-------  1 root root 33554432 Nov 13 23:52 resource0
-rw-------  1 root root 33554432 Nov 13 23:49 resource0_wc
-rw-------  1 root root     4096 Nov 13 23:49 resource1
-r--------  1 root root   131072 Nov 13 23:52 rom
lrwxrwxrwx  1 root root        0 Nov 13 23:49 subsystem -> ../../../bus/pci/
-r--r--r--  1 root root     4096 Nov 13 23:52 subsystem_device
-r--r--r--  1 root root     4096 Nov 13 23:52 subsystem_vendor
-rw-r--r--  1 root root     4096 Nov 13 23:49 uevent
-r--r--r--  1 root root     4096 Nov 13 23:52 vendor

> So the drivers listing, and lsmod are showing that cirrusfb is loaded, but
> lspci -vvv is not? Contradictory - again, is this the domu with the
resolution
> problem?
Yes it is. I have the resolution problem in any case.
> Yeah - the BAR error bothers me. Something is preventing the cirrusfb from
> initializing. Normally you get a handoff from the builtin vesa driver to
the
> installed card driver. This is from my baremetal suse system:
>
> fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic
driver
>
> BAR errors are not something I have experience with. I''m going to
repost this
> section of your post, and see if Fajar has something to say.
OK



On 13 November 2011 18:57, jim burns <jim_burn@bellsouth.net>
wrote:
>
> If you are installing from a modern install disk, the xorg driver evdev
should
> configure your mouse correctly. Check your Xorg.0.log for evdev.
I am using the latest DVD release. No errors reported in the Xorg.0.log file
in the dom0.
> This is kind of old. You say the install worked,
It started... but as I''ve already said, it blocked.
It is really frustrating that there is not any guide to setup
a OpenSuse PV domU.
Anyway, the config file I use to start the installation is a little
bit different:
name="OpenSuse11"
memory=2048
disk =
[''phy:/dev/loop0,hdc:cdrom,r'',''file:/mnt/xen/vmstore/opensuse11/opensuse11.img,xvda,w''
]
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
vcpus=1
on_reboot = ''restart''
on_crash = ''restart''
> even though the config is
> using hdc/hda instead of xvdc/xvda. I''m assuming you changed
bridge=eth0, and
> kernel= and ramdisk= to the names on your system.
Of course.
>
> How is this method working out for you? Network and resolution ok?
You already know the answer now.. :(
>
> Keep answers for this install separate from the hvm problems we are working
> on. This gets confusing enough to keep track of as is. ;-)
Of course. Just in case, I will open another discussion on that.

Thank you so much.

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon November 14 2011, 12:02:13 AM, Flavio wrote:
> > As a test, try doing
> > ''rcSuSEfirewall2 stop'', and see if that helps.
> 
> nope. I''ve already tried that and it doesn''t help. I
think it is all related
> to those kernel modules that are missing.
> 
> > If it does, we can play with
> > the firewall config to allow all traffic on your 192.168.1 subnet. If
> > one hvm domu works, and the other doesn''t. it could be that
one kernel
> > doesn''t have a kernel module that the firewall needs, so it
is
> > defaulting to lockdown.
> It''s not due to the firewall because if I boot with the default
2.6.37
> kernel that
> comes with the installation, the network works. Changing the kernel
> with the 3.1.0
> it doesn''t.
> 
> > If none of this works, you may have to break out tcpdump on the tap
> > interface. I''m no expert with it,
> 
> so am I.
> 
> > but I''d look for some kind of restriction on the kind
> > of traffic that''s getting out of the interface - just arp and
udp, but
> > no tcp, or communication in one direction, but not the other.
> 
> I repeat. I think it''s due to the kernel configuration. I have no
idea of
> what could the problem be. I prefer to find an alternate solution. By the
> way, I couldn''t
> setup the PV guest at the end.
Ok - As I said, so long as the 3.1 domu config has 
CONFIG_XEN_NETDEV_FRONTEND=y (builtin) the network should theoretically work. 
Particularly since your Gentoo dom0 is also 3.1. The fact that your 2.6.37 
domu network works, and 2.6.37 is the old xenlinux style, as opposed to the 
newer 3.1 pvops style, shows that qemu-dm is capable of hiding the 
differences. The fact that /etc/sysconfig/kernel asks for the old xennet, 
xenblk names shouldn''t matter with the newer xen-netfront as a builtin.
And
again, your eth0 got an ipv4 address from the network - I assume you get 
addresses from dhcp?

None the less. post your dmesg for 3.1, and I''ll compare it to the
dmesg for
2.6.37 you previously posted. (Yeah, I remember - no network. Redirect it: 
dmesg > ~/something-in-your-homedir.)
> >> cirrusfb               32579  0
> > 
> > Ok, now I''m confused again. Have I got this right - your
compiled
> > kernel, 3.1, has no network, and your 2.6.37 has the resolution
> > problem?
> 
> Both have the resolution problem. 2.6.37 is OK for the network. 3.1.0 is
not
> OK.
Ok - that''s clearer.
> > Because at one
> > point, you said you tried to install the kernel-xen package from suse
> > (2.6.37.6-0.9), and you got an ''Invalid or unsupported
executable
> > format''
> > error.
> 
> Yes, the kernel-xen doesn''t work to me. Anyway, I don''t
think it is a good
> thing, to install a domU kernel if it won''t run on a PV guest.
> 
> > Which 2.6.37 kernel are you talking about now, that''s
(mostly) working?
> 
> 2.6.37 is the kernel that comes with the distribution setup (suse 11.4).
> It''s not a xen capable kernel, or even better it''s a
"normal" kernel.
> 3.1.0 is a kernel that has been compiled by myself.
> kernel-xen, has been installed with zypper, the suse package manager.
> 
> > Ok - I just looked at your dmesg, and your booting suse''s
2.6.37.1-1.2-
> > desktop. Let''s look at the file formats:
> > [...]
> > 
> > So suse''s desktop flavor of the kernel (which has no xen
features for a
> > pv domain) is a bzimage format, which is standard, and an hvm domain
> > should have no problems with it, and your (earlier version)
> > 2.6.37.1-1.2-desktop kernel does in deed boot. The 2.6.37.6-0.9-xen
> > kernel(s) are ELF formats, as required by a pv domain. Don''t
know why
> > you are getting the bad executable error, but you can try substituting
> > vmlinux (with an x) for vmlinuz (with a z), and see if your pv domain
> > will boot now.
> 
> It''s not pv, but hvm. Anyway, I can''t substitute a z with
a x. The
> file is called
> vmlinuz. Or maybe I didn''t understand exactly what you mean.
Look in /boot after you install kernel-xen (actually, any suse kernel, which 
is 2.6.37 in this case). Eg:

-rw-r--r--  1 root root  4359289 Oct 26 11:57 vmlinux-2.6.37.6-0.9-xen.gz
lrwxrwxrwx  1 root root       28 Nov  8 20:34 vmlinuz ->
vmlinuz-2.6.37.6-0.9-
default
-rw-r--r--  1 root root  4016864 Oct 26 11:37 vmlinuz-2.6.37.6-0.9-default
-rw-r--r--  1 root root  3709170 Oct 26 11:39 vmlinuz-2.6.37.6-0.9-xen
lrwxrwxrwx  1 root root       24 Nov 13 18:51 vmlinuz-xen -> 
vmlinuz-2.6.37.6-0.

See - there is a vmlinux *and* a vmlinuz xen kernel. You could try either 
spelling in your menu.lst. This goes back to when you were trying to boot 
kernel-xen as a pv domu. Your menu.lst stanza had no xen.gz entry - only 
''kernel vmlinuz...'' and ''initrd initrd...''
lines. I was just suggesting
testing whether the vmlinux has a more compatible executable format than the 
vmlinuz. (Although, since they are both ELF formats, there probably
won''t be
any difference.)
> > So my question remains: the 3.1 kernel is the one without a network,
and
> > the 2.6.37.1-1.2-desktop is the one with the resolution problems,
> > right?
> Right. As I''ve written above, both have the resolution problem,
otherwise,
> the resolution problem would be solved now, and we would talk about a
> networking problem!
On to the resolution problem.
> > This is showing that vesa is builtin, and cirrusfb is a module, as on
my
> > systems.
> > 
> >> > ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
> >> 
> >> lrwxrwxrwx 1 root root 0 Nov 13 09:57
> >> /sys/bus/pci/devices/0000:00:02.0 ->
> >> ../../../devices/pci0000:00/0000:00:02.0/
> > 
> > Sorry - I forgot about the soft link. I meant ls -alF
> > /sys/bus/pci/devices/0000:00:02.0/ (with a trailing slash). Pls
repost.
> 
> # ls -alF /sys/bus/pci/devices/0000:00:02.0/
> total 0
> drwxr-xr-x  3 root root        0 Nov 13 23:49 ./
> drwxr-xr-x 12 root root        0 Nov 13 23:49 ../
> -r--r--r--  1 root root     4096 Nov 13 23:49 boot_vga
> -rw-r--r--  1 root root     4096 Nov 13 23:52 broken_parity_status
> -r--r--r--  1 root root     4096 Nov 13 23:51 class
> -rw-r--r--  1 root root      256 Nov 13 23:49 config
> -r--r--r--  1 root root     4096 Nov 13 23:52 consistent_dma_mask_bits
> -r--r--r--  1 root root     4096 Nov 13 23:52 device
> -r--r--r--  1 root root     4096 Nov 13 23:52 dma_mask_bits
> -rw-------  1 root root     4096 Nov 13 23:52 enable
> -r--r--r--  1 root root     4096 Nov 13 23:52 irq
> -r--r--r--  1 root root     4096 Nov 13 23:52 local_cpulist
> -r--r--r--  1 root root     4096 Nov 13 23:52 local_cpus
> -r--r--r--  1 root root     4096 Nov 13 23:52 modalias
> -rw-r--r--  1 root root     4096 Nov 13 23:52 msi_bus
> -r--r--r--  1 root root     4096 Nov 13 23:52 numa_node
> drwxr-xr-x  2 root root        0 Nov 13 23:52 power/
> --w--w----  1 root root     4096 Nov 13 23:52 remove
> --w--w----  1 root root     4096 Nov 13 23:52 rescan
> -r--r--r--  1 root root     4096 Nov 13 23:49 resource
> -rw-------  1 root root 33554432 Nov 13 23:52 resource0
> -rw-------  1 root root 33554432 Nov 13 23:49 resource0_wc
> -rw-------  1 root root     4096 Nov 13 23:49 resource1
> -r--------  1 root root   131072 Nov 13 23:52 rom
> lrwxrwxrwx  1 root root        0 Nov 13 23:49 subsystem ->
../../../bus/pci/
> -r--r--r--  1 root root     4096 Nov 13 23:52 subsystem_device
> -r--r--r--  1 root root     4096 Nov 13 23:52 subsystem_vendor
> -rw-r--r--  1 root root     4096 Nov 13 23:49 uevent
> -r--r--r--  1 root root     4096 Nov 13 23:52 vendor
> 
Again, there is no directory entry for a  soft link called
''driver'' pointing
to a kernel module, such as cirrusfb, so vesa is probably still in charge. See 
if anything interesting comes from ''cat 
/sys/bus/pci/devices/0000:00:02.0/uevent''.
> > So the drivers listing, and lsmod are showing that cirrusfb is loaded,
> > but lspci -vvv is not? Contradictory - again, is this the domu with
the
> > resolution problem?
> 
> Yes it is. I have the resolution problem in any case.
> 
> > Yeah - the BAR error bothers me. Something is preventing the cirrusfb
> > from initializing. Normally you get a handoff from the builtin vesa
> > driver to the installed card driver. This is from my baremetal suse
> > system:
> > 
> > fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic
> > driver
> > 
> > BAR errors are not something I have experience with. I''m
going to repost
> > this section of your post, and see if Fajar has something to say.
> 
> OK
> 
> On 13 November 2011 18:57, jim burns <jim_burn@bellsouth.net> wrote:
> > If you are installing from a modern install disk, the xorg driver
evdev
> > should configure your mouse correctly. Check your Xorg.0.log for
evdev.
> I am using the latest DVD release. No errors reported in the Xorg.0.log
file
> in the dom0.
No, I mean do you see lines that evdev loaded? ''grep evdev 
/var/log/Xorg.0.log''
> > This is kind of old. You say the install worked,
> 
> It started... but as I''ve already said, it blocked.
I don''t know what you mean by blocked. Did the installer load, and you
got a
menu, but you couldn''t get it to start installing packages? Your link
to the
setup procedure mentioned setting up Apache to mount your cdrom. You could 
just as easily have used an nfs mount of the cdrom. The problem is you can get 
your dom0 to load a cd in a pv install, but once the installer is handed 
control, an inherent limitation of a pv domu or install, is it doesn''t
know
about cd devices.
> It is really frustrating that there is not any guide to setup
> a OpenSuse PV domU.
Yes it is. In fact, every distro has some utility to install a pv domu of its 
own kind, but limited ability to read install disks from a different distro. 
For instance, it is trivial to install an opensuse pv domu using Yast in an 
opensuse dom0. Of course, your dom0 is gentoo.
> Anyway, the config file I use to start the installation is a little
> bit different:
> name="OpenSuse11"
> memory=2048
> disk >
[''phy:/dev/loop0,hdc:cdrom,r'',''file:/mnt/xen/vmstore/opensuse11/opensuse11.
> img,xvda,w'' ]
> vif = [ ''type=ioemu, mac=00:16:3e:00:00:21,
bridge=xenbr0'' ]
> vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
> kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
> ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
> vcpus=1
> on_reboot = ''restart''
> on_crash = ''restart''
> 
Looks ok.
> > even though the config is
> > using hdc/hda instead of xvdc/xvda. I''m assuming you changed
> > bridge=eth0, and kernel= and ramdisk= to the names on your system.
> 
> Of course.
> 
> > How is this method working out for you? Network and resolution ok?
> 
> You already know the answer now..
> 
> > Keep answers for this install separate from the hvm problems we are
> > working on. This gets confusing enough to keep track of as is.
> 
> Of course. Just in case, I will open another discussion on that.
Good idea.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 14 November 2011 01:35, jim burns <jim_burn@bellsouth.net>
wrote:
>
> And
> again, your eth0 got an ipv4 address from the network - I assume you get
> addresses from dhcp?
Correct. The fact that the dhcp client works but the networking
doesn''t, seems
very strange even to me actually.
>
> None the less. post your dmesg for 3.1, and I''ll compare it to the
dmesg for
> 2.6.37 you previously posted. (Yeah, I remember - no network. Redirect it:
> dmesg > ~/something-in-your-homedir.)
Of course! ;-)
http://pastebin.com/ikKPe6n3
> See - there is a vmlinux *and* a vmlinuz xen kernel. You could try either
> spelling in your menu.lst. This goes back to when you were trying to boot
> kernel-xen as a pv domu. Your menu.lst stanza had no xen.gz entry - only
> ''kernel vmlinuz...'' and ''initrd
initrd...'' lines. I was just suggesting
> testing whether the vmlinux has a more compatible executable format than
the
> vmlinuz. (Although, since they are both ELF formats, there probably
won''t be
> any difference.)
OK, I did it. Anyway, as far as I can see, vmlinuz is only a symbolic link.
here''s the ls -l /boot after the kernel-xen installation:
http://pastebin.com/E0EkKXZF

If I boot using these entries:
kernel /boot/vmlinux-2.6.37.6-0.9-xen
root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
quiet showopts vga=0x314
    initrd /boot/initrd-2.6.37.6-0.9-xen
(I gunzipped the vmlinux file)
It still says: Error 13: Invalid or unsupported executable format.
Same thing if I use the .gz file of course.
> Again, there is no directory entry for a  soft link called
''driver'' pointing
> to a kernel module, such as cirrusfb, so vesa is probably still in charge.
See
> if anything interesting comes from ''cat
> /sys/bus/pci/devices/0000:00:02.0/uevent''.
With the 2.6.37 kernel booted:
PCI_CLASS=30000
PCI_ID=1013:00B8
PCI_SUBSYS_ID=5853:0001
PCI_SLOT_NAME=0000:00:02.0
MODALIAS=pci:v00001013d000000B8sv00005853sd00000001bc03sc00i00
> No, I mean do you see lines that evdev loaded? ''grep evdev
> /var/log/Xorg.0.log''
Yes, I see those lines.
domU: http://pastebin.com/emieNZxy
dom0: http://pastebin.com/WxSdq74i
> I don''t know what you mean by blocked. Did the installer load, and
you got a
> menu, but you couldn''t get it to start installing packages?
The package installation begins, but it''s very slow and it blocks.
> Your link to the
> setup procedure mentioned setting up Apache to mount your cdrom. You could
> just as easily have used an nfs mount of the cdrom.
I mounted the ISO image as loop in /var/www/localhost/htdocs/suse11. Maybe
the memory is going to run out if I launch both the dom0 and the mount
-o loop and
also the domU start.
> The problem is you can get
> your dom0 to load a cd in a pv install, but once the installer is handed
> control, an inherent limitation of a pv domu or install, is it
doesn''t know
> about cd devices.
The installer got frozen. No possibility to go ahead. Sometime even my dom0
got blocked, so I have to use sysrq magic keys to reboot. Maybe it''s
due to a memory
issue, even if the system is still accessible via ssh and is "alive".
It seems the
hypervisor die. Every xl command stucks without giving any reply in the console.

Thanks a lot again,

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun November 13 2011, 7:35:18 PM, jim burns wrote:
> Ok - As I said, so long as the 3.1 domu config has 
> CONFIG_XEN_NETDEV_FRONTEND=y (builtin) the network should theoretically
> work.  Particularly since your Gentoo dom0 is also 3.1. The fact that your
> 2.6.37 domu network works, and 2.6.37 is the old xenlinux style, as opposed
> to the newer 3.1 pvops style, shows that qemu-dm is capable of hiding the
> differences. The fact that /etc/sysconfig/kernel asks for the old xennet,
> xenblk names shouldn''t matter with the newer xen-netfront as a
builtin. And
> again, your eth0 got an ipv4 address from the network - I assume you get
> addresses from dhcp?
Oy - I just realized this morning that I''m going about your network
problem
all wrong. While it''s true that CONFIG_XEN_NETDEV_BACKEND=y in your
Gentoo
dom0 was a good thing, that''s because a dom0 is always a pv domain.
However,
we don''t really need to care about CONFIG_XEN_NETDEV_FRONTEND=y or =m
in an
hvm domu, because that also only matters to a pv domu. Qemu-dm (by default) 
provides an emulated Realtek 8139 network card, so we are looking for the 
kernel drivers 8139cp and/or 8139too. (Not sure which or both - your 2.6.37 
dmesg initializes both. Do a ''lsmod|grep 8139'' and tell me
which one(s) you
have.) This is just like we didn''t care about
CONFIG_XEN_FBDEV_FRONTEND,
because we are using cirrusfb, not xen-netfront.

According to your 2.6.37 dmesg, the the network card is initialized this way:

[    0.209416] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200
[    0.209789] pci 0000:00:04.0: reg 10: [io  0xc100-0xc1ff]
[    0.210096] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff]
[...]
[    8.550920] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[    8.551133] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) ->
IRQ 32
[    8.568729] xen_mem: Initialising balloon driver.
[    8.771269] 8139cp 0000:00:04.0: eth0: RTL-8139C+ at 0xffffc90000c40000, 
00:16:3e:00:00:21, IRQ 32
[    8.771366] 8139cp 0000:00:04.0: setting latency timer to 64
[    8.858934] netfront: Initialising virtual ethernet driver.
[    8.919407] xen-vbd: registered block device major 3
[    8.919450] blkfront: hda: barriers enabled
[    8.922799]  hda: hda1 hda2
[    8.931426] 8139too: 8139too Fast Ethernet driver 0.9.28
[...]
[   43.310820] eth0: link up, 100Mbps, full-duplex, lpa 0x05E1

My guess is the driver attached to the pci device 00:04.0, 8139cp, handles the 
device, and 8139too handles the protocol. This is similar to wireless devices 
being serviced by multiple kernel modules.

Your 3.1 dmesg says virtually the same thing (except for netfront &
blkfront):

[    0.685919] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200
[    0.688990] pci 0000:00:04.0: reg 10: [io  0xc100-0xc1ff]
[    0.692039] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff]
[...]
[    9.458707] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[    9.458839] xen: --> pirq=23 -> irq=32 (gsi=32)
[    9.458845] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) ->
IRQ 32
[    9.475499] 8139cp 0000:00:04.0: eth0: RTL-8139C+ at 0xffffc900004fc000, 
00:16:3e:00:00:21, IRQ 32
[    9.475653] 8139cp 0000:00:04.0: setting latency timer to 64
[...]
[    9.613185] 8139too: 8139too Fast Ethernet driver 0.9.28
[...]
[   24.322502] 8139cp 0000:00:04.0: eth0: link up, 100Mbps, full-duplex, lpa 
0x05E1

In other words, as far as the domu is concerned, for both kernels, eth0 has 
been initialized, and the link is up. So the problem is in the dom0 to domu 
frontend, backend communication, or the bridge. Can''t do anything more
with
this configuration, short of using tcpdump to troubleshoot.

(Btw, both kernels report the same BAR errors with cirrusfb, and fail, leaving 
(presumably) vesa in charge.)

There is a 2nd configuration possible, though. Qemu-dm also supports an Intel 
1000 Mbps card, which Pasi K. prefers to use in linux hvm domus. The vif= line 
has a model= suboption. Model=rtl8139, or no model= option, picks the Realtek 
emulation, model=e1000 picks the Intel emulation. Of course, if you change 
your hvm config, you change it for both kernels. You might want to configure 
both interfaces, giving you an eth0 and an eth1:

vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0,
model=rtl8139'',
''type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0,
model=e1000'' ]

Note each interface has a unique mac address. They are also both attached to 
xenbr0. This shouldn''t case network loops, but if it does, you can
always ifup
one, and ifdown the other.

And then there is a third possibility. Your kernel with the network problems, 
3.1, is fully capable of booting as a pv domu. You have already compiled all 
the xen frontends as builtin. Domu support has been available in mainline 
kernels for some time now.

Of course, changing from hvm to pv drivers will cause some configuration 
problems in your file system image. I''ve already mentioned how your 
/dev/disk/by-id soft links won''t be valid anymore. Not sure whether you
should
be using /dev/sda<n>, or /dev/xvda<n> in your menu.lst, since I use 
root=UUID=, but you will definitely be using /dev/xvda<n> in your
/etc/fstab,
at least until you see whether something stays constant, like /dev/disk/by-
uuid. Rather than changing your fstab every time you want to change from hvm 
to pv, if you have enough disk space, you might want to clone (copy) your file 
system image file, and use it for pv.

Your menu.lst stanza will look very similar to the one for your kernel-xen 
install.

Your head reeling yet? :-)

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Mon November 14 2011, 11:46:03 AM, Flavio wrote:
> If I boot using these entries:
Yes - this is what I meant.
> kernel /boot/vmlinux-2.6.37.6-0.9-xen
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet showopts vga=0x314
>     initrd /boot/initrd-2.6.37.6-0.9-xen
> (I gunzipped the vmlinux file)
> It still says: Error 13: Invalid or unsupported executable format.
> Same thing if I use the .gz file of course.
I was afraid of that. Worth a try.
> > Again, there is no directory entry for a  soft link called
''driver''
> > pointing to a kernel module, such as cirrusfb, so vesa is probably
> > still in charge. See if anything interesting comes from ''cat
> > /sys/bus/pci/devices/0000:00:02.0/uevent''.
> 
> With the 2.6.37 kernel booted:
> PCI_CLASS=30000
> PCI_ID=1013:00B8
> PCI_SUBSYS_ID=5853:0001
> PCI_SLOT_NAME=0000:00:02.0
> MODALIAS=pci:v00001013d000000B8sv00005853sd00000001bc03sc00i00
Yeah - on my system, the first line is DRIVER=<kernel module>. Further 
evidence that cirrusfb is missing in action.
> > No, I mean do you see lines that evdev loaded? ''grep evdev
> > /var/log/Xorg.0.log''
> 
> Yes, I see those lines.
> domU: http://pastebin.com/emieNZxy
> dom0: http://pastebin.com/WxSdq74i
> 
Your domu install with the nonfunctional mouse none the less has the message:

[   110.096] (**) ImExPS/2 Generic Explorer Mouse: Applying InputClass
"evdev
pointer catchall"

so I don''t know what happened there.
> > I don''t know what you mean by blocked. Did the installer
load, and you
> > got a menu, but you couldn''t get it to start installing
packages?
> 
> The package installation begins, but it''s very slow and it blocks.
> 
> > Your link to the
> > setup procedure mentioned setting up Apache to mount your cdrom. You
> > could just as easily have used an nfs mount of the cdrom.
> 
> I mounted the ISO image as loop in /var/www/localhost/htdocs/suse11. Maybe
> the memory is going to run out if I launch both the dom0 and the mount
> -o loop and
> also the domU start.
Maybe. The mount -o loop doesn''t take any significant memory, but each
domu
will. Check with ''xm/xl list''.
> > The problem is you can get
> > your dom0 to load a cd in a pv install, but once the installer is
handed
> > control, an inherent limitation of a pv domu or install, is it
doesn''t
> > know about cd devices.
> 
> The installer got frozen. No possibility to go ahead. Sometime even my dom0
> got blocked, so I have to use sysrq magic keys to reboot. Maybe
it''s
> due to a memory
> issue, even if the system is still accessible via ssh and is
"alive".
> It seems the
> hypervisor die. Every xl command stucks without giving any reply in the
> console.
Doing an hvm install is going to be slow anyway. I know the fedora installer 
does a lot of thinking picking packages, before it starts  installing them, 
and looks like it''s hung, and then hvm slows down things even more.
Suse
installers do some thinking, but it''s more obvious it''s doing
something.

Xen domus have has a problem with hung cpus for sometime now, on multi core 
cpus (SMP code). That''s why modern kernels start a khungtaskd process.

As I am writing this, I just got a:

Nov 14 18:26:41 Insp6400 kernel: [191104.568001] BUG: soft lockup - CPU#0 
stuck for 22s! [savapi:9977]

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 15 November 2011 00:16, jim burns <jim_burn@bellsouth.net>
wrote:
> Oy - I just realized this morning that I''m going about your
network problem
> all wrong. While it''s true that CONFIG_XEN_NETDEV_BACKEND=y in
your Gentoo
> dom0 was a good thing, that''s because a dom0 is always a pv
domain. However,
> we don''t really need to care about CONFIG_XEN_NETDEV_FRONTEND=y or
=m in an
> hvm domu, because that also only matters to a pv domu.
OK, in any case I have CONFIG_XEN_NETDEV_FRONTEND not set in the dom0 kernel
and the network is perfectly working both on other PV and hvm domUs.
> Qemu-dm (by default)
> provides an emulated Realtek 8139 network card, so we are looking for the
> kernel drivers 8139cp and/or 8139too. (Not sure which or both - your 2.6.37
> dmesg initializes both. Do a ''lsmod|grep 8139'' and tell
me which one(s) you
> have.)
# lsmod|grep 8139
8139too                30960  0
8139cp                 23939  0
> My guess is the driver attached to the pci device 00:04.0, 8139cp, handles
the
> device, and 8139too handles the protocol. This is similar to wireless
devices
> being serviced by multiple kernel modules.
>
> Your 3.1 dmesg says virtually the same thing (except for netfront &
blkfront):
[...]
>
> In other words, as far as the domu is concerned, for both kernels, eth0 has
> been initialized, and the link is up. So the problem is in the dom0 to domu
> frontend, backend communication, or the bridge. Can''t do anything
more with
> this configuration, short of using tcpdump to troubleshoot.
OK, even I''m not so practical with it.
>
> (Btw, both kernels report the same BAR errors with cirrusfb, and fail,
leaving
> (presumably) vesa in charge.)
So, this could be the point where the resolution problem is generated. Anyway,
I still think that something in the suse guest is very wrong, because other
domU work (windows for instance).

[CUT]
> vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0,
model=rtl8139'',
> ''type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0,
model=e1000'' ]
OK, I tried to set model=e1000 for the domU eth0.

kernel-2.6.37:
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
networking OK

kernel-3.1.0:
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
networking OK!!!! <----
Screenshot just after the domU launch: http://i.imgur.com/T6ICQ.png
It still complains about xennet and xenblk not found and other two
errors. I don''t know
what it is.

Well, now that the networking works, this problem has been solved.
Let''s go back
to the resolution problem. :)
> Your head reeling yet? :-)
LOL, a little bit. :)



On 15 November 2011 00:35, jim burns <jim_burn@bellsouth.net>
wrote:
> I was afraid of that. Worth a try.
No problem, every attempt is licit here!
> Yeah - on my system, the first line is DRIVER=<kernel module>.
Further
> evidence that cirrusfb is missing in action.
I don''t know what to say here :(
>
>> > No, I mean do you see lines that evdev loaded? ''grep
evdev
>> > /var/log/Xorg.0.log''
>>
>> Yes, I see those lines.
>> domU: http://pastebin.com/emieNZxy
>> dom0: http://pastebin.com/WxSdq74i
>>
>
> Your domu install with the nonfunctional mouse none the less has the
message:
Just a moment: there is a little bit of confusion now. It''s my fault
probably.
Get rid of the PV installation where the mouse is not working (it
failed). I abandoned such
setup for now, because it completely freezes my system causing an
emergency sysrq
keys use to reboot. The domU log above comes from the suse with the resolution
problem we are talking about in the main discussion here!
In any case I don''t know how to get the Xorg.0.log file from a system
which is
pretty unusable and during the installation phase.

Anyway I am planning to retry with this setup.
> Maybe. The mount -o loop doesn''t take any significant memory, but
each domu
> will. Check with ''xm/xl list''.
I know this, and this is actually strange for me. In any case I only
have one domU
running when performing the setup: the suse I am trying to install.

> Doing an hvm install is going to be slow anyway. I know the fedora
installer
> does a lot of thinking picking packages, before it starts  installing them,
> and looks like it''s hung, and then hvm slows down things even
more. Suse
> installers do some thinking, but it''s more obvious it''s
doing something.
I''ve noticed that too. This is not a great problem. My hope is to
finish the
installation and to run the pv domU.
>
> Xen domus have has a problem with hung cpus for sometime now, on multi core
> cpus (SMP code). That''s why modern kernels start a khungtaskd
process.
I''ve seen that. I guess this khungtaskd process is not so efficient,
because
I am obligued to reboot.

Thanks a lot

Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue November 15 2011, 11:10:25 AM, Flavio wrote:
> On 15 November 2011 00:16, jim burns <jim_burn@bellsouth.net> wrote:
> > Oy - I just realized this morning that I''m going about your
network
> > problem all wrong. While it''s true that
CONFIG_XEN_NETDEV_BACKEND=y in
> > your Gentoo dom0 was a good thing, that''s because a dom0 is
always a pv
> > domain. However, we don''t really need to care about
> > CONFIG_XEN_NETDEV_FRONTEND=y or =m in an hvm domu, because that also
> > only matters to a pv domu.
> 
> OK, in any case I have CONFIG_XEN_NETDEV_FRONTEND not set in the dom0
kernel
> and the network is perfectly working both on other PV and hvm domUs.
That''s fine. CONFIG_XEN_NETDEV_FRONTEND is totally irrelevant to a
dom0, which
only deal with BACKEND drivers.
> > Qemu-dm (by default)
> > provides an emulated Realtek 8139 network card, so we are looking for
> > the
> > kernel drivers 8139cp and/or 8139too. (Not sure which or both - your
> > 2.6.37 dmesg initializes both. Do a ''lsmod|grep
8139'' and tell me which
> > one(s) you have.)
> 
> # lsmod|grep 8139
> 8139too                30960  0
> 8139cp                 23939  0
Thought so.
> > My guess is the driver attached to the pci device 00:04.0, 8139cp,
> > handles the device, and 8139too handles the protocol. This is similar
> > to wireless devices being serviced by multiple kernel modules.
> 
> > vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0,
> > model=rtl8139'', ''type=ioemu, mac=00:16:3e:00:00:22,
bridge=xenbr0,
> > model=e1000'' ]
> OK, I tried to set model=e1000 for the domU eth0.
> 
> kernel-2.6.37:
> 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
> Ethernet Controller (rev 03)
> networking OK
> 
> kernel-3.1.0:
> 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
> Ethernet Controller (rev 03)
> networking OK!!!! <----
Cool beans! One less problem.
> Screenshot just after the domU launch: http://i.imgur.com/T6ICQ.png
> It still complains about xennet and xenblk not found and other two
> errors. I don''t know
> what it is.
Yeah - the xennet / xenblk errors are occurring early on on in the boot 
process, before the disks are mounted, so the only code it can be executing is 
the kernel, and initrd modules & config files. And the initrd creation is in
turn controlled by /etc/sysconfig/kernel. As I said, it can be ignored.

The other two errors are prevented in the 2.6.37 kernel by installing the rpm 
package preload-kmp-default, which installs /lib/modules/2.6.37.1-1.2-
default/systemtap/preloadtrace.ko. I don''t think there is a
corresponding
package for the 3.1 kernel. At least I can''t find one in f16, which
uses the
3.1 kernel. At any rate, it is a boot optimization routine, and the errors can 
be ignored without concern. From ''rpm -qi
preload-kmp-default'', the
Description field says:

This will work with preload hand in hand to make sure no unnecessary
files are preload.

and ''rpm -qi preload'' says:

Preload lists files to load into the system cache. This shortens system
boot time if used correctly.
> Well, now that the networking works, this problem has been solved.
Let''s go
> back to the resolution problem. :)
Yeah, no response from Fajar, yet. I''ll repost the problem with a
different
Subject line tomorrow, if no one responds.
> > Your head reeling yet? :-)
> 
> LOL, a little bit. :)
> 
> On 15 November 2011 00:35, jim burns <jim_burn@bellsouth.net> wrote:
> >> > No, I mean do you see lines that evdev loaded? ''grep
evdev
> >> > /var/log/Xorg.0.log''
> >> 
> >> Yes, I see those lines.
> >> domU: http://pastebin.com/emieNZxy
> >> dom0: http://pastebin.com/WxSdq74i
> > 
> > Your domu install with the nonfunctional mouse none the less has the 
message:
> Just a moment: there is a little bit of confusion now. It''s my
fault
> probably. Get rid of the PV installation where the mouse is not working (it
> failed). I abandoned such
> setup for now, because it completely freezes my system causing an
> emergency sysrq
> keys use to reboot. The domU log above comes from the suse with the
> resolution problem we are talking about in the main discussion here!
> In any case I don''t know how to get the Xorg.0.log file from a
system which
> is pretty unusable and during the installation phase.
Ok. Evdev has nothing to do with resolution, just input peripherals, like 
keyboard, mouse, USB. So I''ll forget about this.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue November 15 2011, 5:20:47 PM, jim burns wrote:
> > Well, now that the networking works, this problem has been solved.
Let''s
> > go back to the resolution problem.
> 
> Yeah, no response from Fajar, yet. I''ll repost the problem with a
different
> Subject line tomorrow, if no one responds.
Hmm - I''m reading the man page for qemu, and came across this
sub-option to
the -vga type option:

           std Standard VGA card with Bochs VBE extensions.  If your guest OS
               supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if
               you want to use high resolution modes (>= 1280x1024x16) then
               you should use this option.

Since changing the network card driver worked, and vesa seems to not want to 
unload / hand off to cirrusfb, maybe we should try stdvga=1 again, but with 
videoram=32. (Actually, as an experiment, try videoram=8 and 16 also. Then 
check with lspci -vvv for the video device, and see if the size= field in the 
first Region line changes.)

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 15 November 2011 23:20, jim burns <jim_burn@bellsouth.net>
wrote:
> At any rate, it is a boot optimization routine, and the errors can
> be ignored without concern. From ''rpm -qi
preload-kmp-default'', the
> Description field says:
>
> This will work with preload hand in hand to make sure no unnecessary
> files are preload.
In my case it says:
package preload-kmp-default is not installed
Actually, even if I try to install it, there is no package for 3.0.1 kernel.
>
> and ''rpm -qi preload'' says:
>
> Preload lists files to load into the system cache. This shortens system
> boot time if used correctly.
OK
> Yeah, no response from Fajar, yet. I''ll repost the problem with a
different
> Subject line tomorrow, if no one responds.
OK, maybe Fajar is very busy in this days. No pressure for him! :)

On 16 November 2011 00:45, jim burns <jim_burn@bellsouth.net>
wrote:
>
> Hmm - I''m reading the man page for qemu, and came across this
sub-option to
> the -vga type option:
>
>           std Standard VGA card with Bochs VBE extensions.  If your guest
OS
>               supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if
>               you want to use high resolution modes (>= 1280x1024x16)
then
>               you should use this option.
>
> Since changing the network card driver worked, and vesa seems to not want
to
> unload / hand off to cirrusfb, maybe we should try stdvga=1 again, but with
> videoram=32. (Actually, as an experiment, try videoram=8 and 16 also. Then
> check with lspci -vvv for the video device, and see if the size= field in
the
> first Region line changes.)
OK, this is what I see right now (without any change):
stdvga=0 && videoram=16 && kernel 3.0.1
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
Max Resolution: 800x600

stdvga=1 && videoram=8 && kernel 3.0.1 (I noticed the domU is
slightly faster)
Region 0: Memory at f1000000 (32-bit, prefetchable) [size=8M]
Expansion ROM at <unassigned> [disabled]
Max Resolution: 800x600

stdvga=1 && videoram=16 && kernel 3.0.1
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled]
Max Resolution: 800x600

stdvga=1 && videoram=32 && kernel 3.0.1
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled]
Max Resolution: 800x600

So, something changed for 8 and 16M! But I didn''t understand what has
changed. Now the
"size" increases but the max resolution is still 800x600. At least I
notice
a faster domU with these settings. Haven''t we already tried to set
different
videoram quantity in our previous attempt, without success? Maybe the
only attempt we did was for videoram=32.

Thanks a lot!

Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed November 16 2011, 10:47:32 AM, Flavio wrote:
> OK, this is what I see right now (without any change):
> stdvga=0 && videoram=16 && kernel 3.0.1
> Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
> Region 1: Memory at f3020000 (32-bit, non-prefetchable) [size=4K]
> Max Resolution: 800x600
> 
> stdvga=1 && videoram=8 && kernel 3.0.1 (I noticed the domU
is slightly
> faster) Region 0: Memory at f1000000 (32-bit, prefetchable) [size=8M]
> Expansion ROM at <unassigned> [disabled]
> Max Resolution: 800x600
> 
> stdvga=1 && videoram=16 && kernel 3.0.1
> Region 0: Memory at f0000000 (32-bit, prefetchable) [size=16M]
> Expansion ROM at <unassigned> [disabled]
> Max Resolution: 800x600
> 
> stdvga=1 && videoram=32 && kernel 3.0.1
> Region 0: Memory at f0000000 (32-bit, prefetchable) [size=16M]
> Expansion ROM at <unassigned> [disabled]
> Max Resolution: 800x600
> 
> So, something changed for 8 and 16M! But I didn''t understand what
has
> changed.
We are changing the amount of memory the emulated vesa capable video adapter 
is allowed to use. Considering modern video cards typically have 256M, I was 
hoping we could up the memory being used.

You''ll notice that the cirrus emulation (stdvga=0) already uses 32M
(and
ignores the videoram parameter),which is what I hoped we could assign to the 
vesa emulation (stdvga=1). 32M is more than enough to support the higher 
resolution. Unfortunately, the cirrus emulation is not working in this domu. 
(The more memory, the more resolutions supported.)
> Now the
> "size" increases but the max resolution is still 800x600.
Bummer! Except the size didn''t go up for videoram=32M. Curious.
> At least I notice
> a faster domU with these settings. Haven''t we already tried to set
different
> videoram quantity in our previous attempt, without success? Maybe the only
> attempt we did was for videoram=32.
If you tried it, you didn''t post the results. I only saw you use
videoram=16.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On 16 November 2011 23:35, jim burns <jim_burn@bellsouth.net>
wrote:
>> Now the
>> "size" increases but the max resolution is still 800x600.
>
> Bummer! Except the size didn''t go up for videoram=32M. Curious.
>
>> At least I notice
>> a faster domU with these settings. Haven''t we already tried to
set different
>> videoram quantity in our previous attempt, without success? Maybe the
only
>> attempt we did was for videoram=32.
>
> If you tried it, you didn''t post the results. I only saw you use
videoram=16.
OK ok.. maybe I made confusion due to the huge quantity of test we did! :)

Thanks! :)

Now I''m trying to setup the PV guest, unsuccessfully at the moment.

-- 
Flavio

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Flavio is having a problem getting a functional cirrus emulation (stdvga=0) in 
his opensuse 11.4 hvm domu. He has two kernels installed on the virtual disk - 
suse''s 2.6.37, and a hand compiled 3.1, with all the xen frontends
builtin.
Both kernels have the same problem with the cirrusfb driver.

Here are the relevant messages from the 2.6.37 kernel:

[    0.201973] pci 0000:00:02.0: [1013:00b8] type 0 class 0x000300
[    0.202546] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.203075] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff]
[...]
[    0.453890] vgaarb: device added: 
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.453894] vgaarb: loaded
[...]
[    0.492167] pci 0000:00:02.0: Boot video device
[...]
[    0.667812] vesafb: framebuffer at 0xf0000000, mapped to 
0xffffc90000580000, using 1875k, total 4096k
[    0.667815] vesafb: mode is 800x600x16, linelength=1600, pages=3
[    0.667817] vesafb: scrolling: redraw
[    0.667820] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[    0.668044] bootsplash 3.1.6-2004/03/31: looking for picture...
[    0.668047] bootsplash: silentjpeg size 124451 bytes
[    0.674284] bootsplash: ...found (800x600, 62872 bytes, v3).
[    0.688156] Console: switching to colour frame buffer device 96x33
[    0.701329] fb0: VESA VGA frame buffer device
[...]
[   32.626308] cirrusfb 0000:00:02.0: BAR 0: can''t reserve [mem 
0xf0000000-0xf1ffffff pref]
[   32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000, abort
[   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16

So cirrusfb is trying to reserve memory the pci device already has, and 
controlled by the builtin vesa kernel driver. I would think vesa should hand 
off the device to cirrusfb? Here''s what happens on my bare metal
opensuse 11.4
machine, with a radeon card:

<7>[    0.131665] pci 0000:01:00.0: [1002:5960] type 0 class 0x000300
<7>[    0.131682] pci 0000:01:00.0: reg 10: [mem 0xf0000000-0xf7ffffff
pref]
<7>[    0.131691] pci 0000:01:00.0: reg 14: [io  0xec00-0xecff]
<7>[    0.131700] pci 0000:01:00.0: reg 18: [mem 0xff8f0000-0xff8fffff]
<7>[    0.131726] pci 0000:01:00.0: reg 30: [mem 0x80000000-0x8001ffff
pref]
<7>[    0.131747] pci 0000:01:00.0: supports D1 D2
[...]
<6>[    0.162384] vgaarb: device added: 
PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
<6>[    0.162396] vgaarb: loaded
[...]
<6>[    0.222150] pci 0000:01:00.0: no compatible bridge window for [mem 
0x80000000-0x8001ffff pref]
<6>[    0.222224] pci 0000:01:00.0: BAR 6: assigned [mem
0xff800000-0xff81ffff
pref]
[...]
<7>[    0.225419] pci 0000:01:00.0: Boot video device
[...]
<4>[    0.629101] vesafb: cannot reserve video memory at 0xf0000000
<6>[    0.630029] vesafb: framebuffer at 0xf0000000, mapped to 0xf8080000,
using 5120k, total 262144k
<6>[    0.630038] vesafb: mode is 1280x1024x16, linelength=2560, pages=101
<6>[    0.630043] vesafb: protected mode interface info at c000:56f7
<6>[    0.630049] vesafb: pmi: set display start = c00c578b, set palette =
c00c57d7
<6>[    0.630054] vesafb: pmi: ports = e010 e016 e054 e038 e03c e05c e000
e004
e0b0 e0b2 e0b4 
<6>[    0.630069] vesafb: scrolling: redraw
<6>[    0.630075] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[...]
<6>[    0.814211] fb0: VESA VGA frame buffer device
[...]
<6>[  259.930780] [drm] radeon defaulting to kernel modesetting.
<6>[  259.952873] [drm] radeon kernel modesetting enabled.
<7>[  259.974306] checking generic (f0000000 10000000) vs hw (f0000000 
8000000)
<3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - 
removing generic driver

In other words, the kernel causes vesafb to relinquish control to radeon, 
which is not happening in Flavio''s cirrusfb case.

I''ve already had him try stdvga=1, videoram=8 & 16 & 32. lspci
-vvv tells us
the Region 0 memory size for the video device keeps increasing for 8 & 16,
but
stays at 16M for videoram=32, so stdvga=1 does not help him. It also says 
there is no kernel module - in other words, the builtin vesa driver is still 
in charge.

So, does anybody know how to correct BAR errors for an emulated device?
It''s
not like I can put it in a different virtual pci slot.

Thanx.

His 2.6.37 dmesg: http://pastebin.com/vNpumSik
His 3.1.0  dmesg: http://pastebin.com/ikKPe6n3

His hvm config:

kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 1024

shadow_memory = 8
name = "opensuse-11.4"
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
acpi = 1
apic = 1
disk = [
''file:/mnt/xen/vmstore/opensuse-11.4/opensuse-11.4.img,hda,w''
]

boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''''
vnclisten="192.168.1.100"
stdvga=0
videoram=16
keymap="it"

serial=''pty''
usbdevice=''tablet''


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

>>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net>
wrote:
Sounds more like a kernel problem.
> <4>[    0.629101] vesafb: cannot reserve video memory at 0xf0000000
This doesn''t tell what component did the reservation before this point,
but that''s what he/you will need to find out. And then compare with
the cirrusfb case.

One significant difference of course is the DRM base fb driver in the
radeon case - to compare apples with apples, DRM should really be
removed from the picture.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net>
wrote:
> Sounds more like a kernel problem.
> 
> > <4>[    0.629101] vesafb: cannot reserve video memory at
0xf0000000
> 
> This doesn''t tell what component did the reservation before this
point,
> but that''s what he/you will need to find out. And then compare
with
> the cirrusfb case.
I thought that''s what this meant:

[    0.667812] vesafb: framebuffer at 0xf0000000, mapped to 
0xffffc90000580000, using 1875k, total 4096k

Looks like vesafb reserved it.
> One significant difference of course is the DRM base fb driver in the
> radeon case - to compare apples with apples, DRM should really be
> removed from the picture.
True. I was just pointing out that there is a mechanism for vesafb handing off 
control to another video driver:

<3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - 
removing generic driver

Any ideas where to go from here? Thanx.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 17.11.11 at 09:31, jim burns <jim_burn@bellsouth.net>
wrote:
> On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
>> >>> On 17.11.11 at 00:28, jim burns
<jim_burn@bellsouth.net> wrote:
>> Sounds more like a kernel problem.
>> 
>> > <4>[    0.629101] vesafb: cannot reserve video memory at
0xf0000000
>> 
>> This doesn''t tell what component did the reservation before
this point,
>> but that''s what he/you will need to find out. And then compare
with
>> the cirrusfb case.
> 
> I thought that''s what this meant:
> 
> [    0.667812] vesafb: framebuffer at 0xf0000000, mapped to 
> 0xffffc90000580000, using 1875k, total 4096k
> 
> Looks like vesafb reserved it.
No - the absence of the former message means it reserved it. But its
presence does not provide information on what, in that case, managed
to reserve it before. But that''s what you want to hunt down.
>> One significant difference of course is the DRM base fb driver in the
>> radeon case - to compare apples with apples, DRM should really be
>> removed from the picture.
> 
> True. I was just pointing out that there is a mechanism for vesafb handing 
> off 
> control to another video driver:
> 
> <3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA
-
> removing generic driver
> 
> Any ideas where to go from here? Thanx.
You could have looked at this easily yourself - cirrusfb_register() (which
is what calls register_framebuffer(), which is where above message
originates from) gets called from cirrusfb_pci_register() only *after*
that function tried to reserve its resources via pci_request_regions().
(This is in 3.2-rc2, so even the most current driver isn''t capable of
doing this sort of handshake, and afaict that''s no different on native,
so not a Xen issue at all.)

Btw., looking at the title again - I don''t think you need cirrusfb to
get higher resolutions, at least not if you''re talking about X (only if
you merely care about the text consoles this would be the case),
as long as a respective X driver is present.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Flavio. I want to try a couple of more things.

1) ssh into your 2.6.37 domu. (Or, if your vncviewer allows you to send the 
key combo ctrl-alt-f2, you can do that, but more than likely the host os that 
vncviewer is running on will trap it first.) You want a non windowed shell 
prompt, because we are going to bring down the X-server and desktop. Now do 
(as root):

rcxdm stop
(check with ''ps a -H'' to make sure that all instances of
kdm/gdm and their
child processes (the indented ones under kdm or gdm in the
''ps'' listing) are
killed)
rmmod cirrusfb
modprobe cirrusfb
rcxdm start
(log out of your shell window)

If this doesn''t help, there is one more thing I haven''t looked
at yet. Post
the contents of ''gunzip -c /boot/initrd-2.6.37.1-1.2-desktop|cpio
-tv'', and
then ''more `ls /etc/udev/rules.d/*|grep -v sane`
/etc/modprobe.d/*''. Thanx.

On 20 November 2011 02:14, jim burns <jim_burn@bellsouth.net>
wrote:
> Hi Flavio. I want to try a couple of more things.
Hi Jim! No problem!

> rcxdm stop
> (check with ''ps a -H'' to make sure that all instances of
kdm/gdm and their
> child processes (the indented ones under kdm or gdm in the
''ps'' listing) are
> killed)
done
> rmmod cirrusfb
> modprobe cirrusfb
> rcxdm start
> (log out of your shell window)
done
>
> If this doesn''t help, there is one more thing I haven''t
looked at yet.
No, the resolution is the same.
> Post
> the contents of ''gunzip -c /boot/initrd-2.6.37.1-1.2-desktop|cpio
-tv'',
http://pastebin.com/46X2MyUD
> and
> then ''more `ls /etc/udev/rules.d/*|grep -v sane`
/etc/modprobe.d/*''. Thanx.
http://pastebin.com/f2GSspNu


Thanks a lot Jim,

-- 
Flavio

On Sun November 20 2011, 10:45:36 AM, Flavio wrote:
> On 20 November 2011 02:14, jim burns <jim_burn@bellsouth.net> wrote:
> > Hi Flavio. I want to try a couple of more things.
> 
> Hi Jim! No problem!
> 
> > rcxdm stop
> > (check with ''ps a -H'' to make sure that all
instances of kdm/gdm and
> > their child processes (the indented ones under kdm or gdm in the
''ps''
> > listing) are killed)
> 
> done
Sorry - that should have been ''ps a -HA'', to include ALL
processes. What I
wrote would only give you processes with a tty or pty - in other words, 
desktop or shell programs.
> > rmmod cirrusfb
> > modprobe cirrusfb
> > rcxdm start
> > (log out of your shell window)
> 
> done
> 
> > If this doesn''t help, there is one more thing I
haven''t looked at yet.
> 
> No, the resolution is the same.
Should have been explicit, but we are back to using the cirrus driver, right? 
(stdvga=0). If either of these two conditions were not met (stdvga=0, ps a -
HA), pls rerun. Also, see if any thing new shows up in /var/log/messages 
during this test.

And I''m assuming you actually tried to change the resolution.
> > Post
> > the contents of ''gunzip -c
/boot/initrd-2.6.37.1-1.2-desktop|cpio -tv'',
> 
> http://pastebin.com/46X2MyUD
> 
> > and
> > then ''more `ls /etc/udev/rules.d/*|grep -v sane`
/etc/modprobe.d/*''.
> > Thanx.
> http://pastebin.com/f2GSspNu
Ok, nothing here. Let me see the contents of /etc/X11/xorg.conf.

On Thu November 17 2011, 9:38:56 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 09:31, jim burns <jim_burn@bellsouth.net>
wrote:
> > On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >> >>> On 17.11.11 at 00:28, jim burns
<jim_burn@bellsouth.net> wrote:
> >> Sounds more like a kernel problem.
> >> 
> >> > <4>[    0.629101] vesafb: cannot reserve video memory
at
> >> > 0xf0000000
> >> 
> >> This doesn''t tell what component did the reservation
before this
> >> point,
> >> but that''s what he/you will need to find out. And then
compare with
> >> the cirrusfb case.
> > 
> > I thought that''s what this meant:
> > 
> > [    0.667812] vesafb: framebuffer at 0xf0000000, mapped to
> > 0xffffc90000580000, using 1875k, total 4096k
> > 
> > Looks like vesafb reserved it.
> 
> No - the absence of the former message means it reserved it. But its
> presence does not provide information on what, in that case, managed
> to reserve it before. But that''s what you want to hunt down.
Oops - didn''t catch this right away. The ''cannot reserve video
memory'' message
(and all messages in my post that have <num> in front) is actually from
the
bare metal case that worked (with radeon). No such message occurs in the 
cirrus case.

I generated the cirrus case extract by searching dmesg for anything about 
''0000:00:02.0'', ''cirrus'',
''vga'', or ''vesa''.
> >> One significant difference of course is the DRM base fb driver in
the
> >> radeon case - to compare apples with apples, DRM should really be
> >> removed from the picture.
> > 
> > True. I was just pointing out that there is a mechanism for vesafb
> > handing off
> > control to another video driver:
> > 
> > <3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs
VESA VGA -
> > removing generic driver
> > 
> > Any ideas where to go from here? Thanx.
> 
> You could have looked at this easily yourself - cirrusfb_register() (which
> is what calls register_framebuffer(), which is where above message
> originates from) gets called from cirrusfb_pci_register() only *after*
> that function tried to reserve its resources via pci_request_regions().
> (This is in 3.2-rc2, so even the most current driver isn''t capable
of
> doing this sort of handshake, and afaict that''s no different on
native,
> so not a Xen issue at all.)
I meant is a BAR 0: error a commonly understood problem with common steps to 
find and fix the *configuration* problem, not where can I tinker with kernel 
code. I would think suse''s 2.6.37.1-1.2-desktop kernel would work as is
in an
hvm domain. Or should he be using a different suse kernel
''flavor''? (-
default?) Although, since it doesn''t work for his hand-compiled 3.1
either,
this looks more like a filesystem / sysconfig configuration problem.
> Btw., looking at the title again - I don''t think you need cirrusfb
to
> get higher resolutions, at least not if you''re talking about X
(only if
> you merely care about the text consoles this would be the case),
> as long as a respective X driver is present.
Actually, he is loading the xorg cirrus module. It loads two candidates - vesa 
& cirrus. Then it unloads vesa in favor of the better cirrus candidate. 
Unfortunately, after running through all the possible modes, it only accepts:

[    33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
[    33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9
kHz, 60.3
Hz
[    33.240] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800 840
968 1056
600 601 605 628 +hsync +vsync (37.9 kHz)
[    33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2
kHz, 56.2
Hz
[    33.240] (II) CIRRUS(0): Modeline "800x600"x56.2   36.00  800 824
896 1024
600 601 603 625 +hsync +vsync (35.2 kHz)
[    33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5
kHz, 59.9
Hz
[    33.240] (II) CIRRUS(0): Modeline "640x480"x59.9   25.18  640 656
752 800
480 490 492 525 -hsync -vsync (31.5 kHz)
[    33.240] (==) CIRRUS(0): DPI set to (96, 96)

Xorg.0.log: http://pastebin.com/d49wcUxD

I would be grateful for nay clues you can give me & Flavio. Thanx.

>>> On 21.11.11 at 01:01, jim burns <jim_burn@bellsouth.net>
wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps
to
> find and fix the *configuration* problem, not where can I tinker with
kernel
> code. I would think suse''s 2.6.37.1-1.2-desktop kernel would work
as is in an
> hvm domain. Or should he be using a different suse kernel
''flavor''? (-
> default?) Although, since it doesn''t work for his hand-compiled
3.1 either,
> this looks more like a filesystem / sysconfig configuration problem.
Using any fb driver other than VESA and the DRM base ones is - afaik -
uncommon, if not unsupported.
> Actually, he is loading the xorg cirrus module. It loads two candidates - 
> vesa 
> & cirrus. Then it unloads vesa in favor of the better cirrus candidate.
> Unfortunately, after running through all the possible modes, it only 
> accepts:
> 
> [    33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
> [    33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz,
37.9 kHz,
> 60.3 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800
840 968
> 1056  
> 600 601 605 628 +hsync +vsync (37.9 kHz)
> [    33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz,
35.2 kHz,
> 56.2 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "800x600"x56.2   36.00  800
824 896
> 1024  
> 600 601 603 625 +hsync +vsync (35.2 kHz)
> [    33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz,
31.5 kHz,
> 59.9 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "640x480"x59.9   25.18  640
656 752
> 800  
> 480 490 492 525 -hsync -vsync (31.5 kHz)
> [    33.240] (==) CIRRUS(0): DPI set to (96, 96)
That''s something that may need looking at from the X side then. And
again, it may well be that 800x600 is all that''s supposed to be
supported for a HVM guest here (i.e. anything beyond might be
considered a feature request rather than a bug, but it may also be
that all you need is some extension to the default monitor definition
[which admittedly shouldn''t be really meaningful in a virtual
environment]).

Jan

On 21 November 2011 00:31, jim burns <jim_burn@bellsouth.net>
wrote:
>
> Sorry - that should have been ''ps a -HA'', to include ALL
processes. What I
> wrote would only give you processes with a tty or pty - in other words,
> desktop or shell programs.
Here''s the new ps output: http://pastebin.com/pNgAzFYR
> Should have been explicit, but we are back to using the cirrus driver,
right?
> (stdvga=0).
Excuse me but I forgot to set stdvga=0 this time.
The result of the ps command above is with stdvga=0.
> If either of these two conditions were not met (stdvga=0, ps a -
> HA), pls rerun. Also, see if any thing new shows up in /var/log/messages
> during this test.
I didn''t notice anything strange: http://pastebin.com/4knPUJLJ
>
> And I''m assuming you actually tried to change the resolution.
I cannot do it. The max resolution is 800x600.

> Ok, nothing here. Let me see the contents of /etc/X11/xorg.conf.
Sure!
I don''t have just the xorg.conf file. I have xorg.conf.install. I
don''t know
if it is considered by the system now or if it has been considered only
during the installation but:

Here it is: http://pastebin.com/pyABzEaa

I also have this file: /etc/X11/xorg.conf.d/50-screen.conf
but it contains only the following lines:

Section "Screen"
  Identifier "Default Screen"

  Device "Default Device"

  ## Doesn''t help for radeon/radeonhd drivers; use magic in
  ## 50-device.conf instead
  Monitor "Default Monitor"

EndSection

Thank you,
-- 
Flavio

On 21 November 2011 01:01, jim burns <jim_burn@bellsouth.net>
wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps
to
> find and fix the *configuration* problem, not where can I tinker with
kernel
> code. I would think suse''s 2.6.37.1-1.2-desktop kernel would work
as is in an
> hvm domain. Or should he be using a different suse kernel
''flavor''? (-
> default?) Although, since it doesn''t work for his hand-compiled
3.1 either,
> this looks more like a filesystem / sysconfig configuration problem.
Just to make some precisation here: I took the configuration file from /boot
(i.e. the config file of 2.6.37.1-1.2-desktop kernel which comes bundled with
the installation) and copied into the 3.1 source kernel directory and compiled
again the kernel. I even modified something about XEN, making it domU capable
(like if it was a PV domU and not a hvm domU).

Thank you so much for your support,

-- 
Flavio

On Mon November 21 2011, 10:36:42 AM, Flavio wrote:
> > Ok, nothing here. Let me see the contents of /etc/X11/xorg.conf.
> 
> Sure!
> I don''t have just the xorg.conf file. I have xorg.conf.install. I
don''t know
> if it is considered by the system now or if it has been considered only
> during the installation but:
> 
> Here it is: http://pastebin.com/pyABzEaa
It should be just during the install, but your Xorg.0.log had a lot of those 
modules loaded, so it just may be a standard probing approach.
> I also have this file: /etc/X11/xorg.conf.d/50-screen.conf
That directory is for corner cases and examples (that are commented out).

I''m out of ideas, so I''m going to do what I probably should
have from the
beginning, instead of guessing. This weekend, I''m going to do an hvm
install,
down to the same kernel 2.6.37.1-1.2-desktop, and see if I can duplicate your 
problem. The only reason I haven''t done it before is it involves
creating an
lvm logical volume, and exporting it via iscsi. Can''t take any more
time than
what I''ve already spent on this thread. :-)

On 22 November 2011 00:44, jim burns <jim_burn@bellsouth.net>
wrote:
> I''m out of ideas, so I''m going to do what I probably
should have from the
> beginning, instead of guessing. This weekend, I''m going to do an
hvm install,
By the way, why don''t you try to do also a PV guest? I posted another
message
in the list. Here''s the links to the archive:
http://goo.gl/LMl8o
http://goo.gl/pgCLK

You should have received some message.
If we solve this problem, we can totally get rid of the hvm.
> down to the same kernel 2.6.37.1-1.2-desktop, and see if I can duplicate
your
> problem. The only reason I haven''t done it before is it involves
creating an
> lvm logical volume, and exporting it via iscsi. Can''t take any
more time than
> what I''ve already spent on this thread. :-)
You can even use a img file, as well as I usually do, if you want to
make a test.

Thank you,

-- 
Flavio

On Tue November 22 2011, 9:19:24 AM, Flavio wrote:
> On 22 November 2011 00:44, jim burns <jim_burn@bellsouth.net> wrote:
> > I''m out of ideas, so I''m going to do what I probably
should have from
> > the beginning, instead of guessing. This weekend, I''m going
to do an hvm
> > install, 
> By the way, why don''t you try to do also a PV guest?
[...]
> If we solve this problem, we can totally get rid of the hvm.
> 
> > down to the same kernel 2.6.37.1-1.2-desktop, and see if I can
duplicate
> > your problem. The only reason I haven''t done it before is it
involves
> > creating an lvm logical volume, and exporting it via iscsi.
Can''t take
> > any more time than what I''ve already spent on this thread.
:-)
> 
> You can even use a img file, as well as I usually do, if you want to
> make a test.
Progress report.

I''ve provisioned the new lvm logical volume, and exported it from my
target to
my dom0. It involved re-reading some old musty man pages and READMEs that I 
didn''t remember. At least now, I have the procedure documented as
examples, so
the next time will go easier. (He says laughingly, since when ever I do a 
major distro upgrade, the rules keep changing. After I look at your problem, I 
have to upgrade from opensuse 11.4 to 12.1 (my target), AND from fedora 15 to 
16 (my dom0)).

And no, an img file wouldn''t work for me. I have no more space left in
my
existing LVs in either system - just unallocated space on my target.

Even if I do the suse install tonite, I won''t have time to play with /
examine
it till next weekend. My time will be looser then, and thru the following 
week.

And yes, I will look at the hvm to pv conversion, also. I haven''t
forgotten
you. :-)

On 28 November 2011 03:41, jim burns <jim_burn@bellsouth.net>
wrote:
> And yes, I will look at the hvm to pv conversion, also. I haven''t
forgotten
> you. :-)
Thank you so much, I appreciate your efforts a lot!
Do not worry because it''s not urgent.

Best regards,

-- 
Flavio

On Mon November 28 2011, 9:48:14 AM, Flavio wrote:
> On 28 November 2011 03:41, jim burns <jim_burn@bellsouth.net> wrote:
> > And yes, I will look at the hvm to pv conversion, also. I
haven''t
> > forgotten you.
> 
> Thank you so much, I appreciate your efforts a lot!
> Do not worry because it''s not urgent.
Ok - I''ve had partial success. I can get text mode up to 1280x1024, and
the
desktop up to 1024x768.

The text mode boost came from simply using vga=0x31a (1280x1024x24) in my 
menu.lst, on the kernel line. I remember you saying that didn''t work
for you,
but I now assume you meant for the desktop, not text mode. What also works is 
0x307 (1280x1024x8) and 0x319 (1280x1024x15).

You can get the installer to put 0x31a in for you from it''s main menu -
select
F3 to set the resolution. However, it''s just as easy to edit menu.lst.

With the following /etc/X11/xorg.conf, you can get a desktop up to 1024x768:

Section "Monitor"
  HorizSync    20-220
  Identifier   "Monitor[0]"
  VertRefresh  30-320
#  UseModes     "Modes[0]"
EndSection

#Section "Modes"
#  Identifier   "Modes[0]"
#  Modeline "1280x1024" 276.24 1280 1384 1528 1776 1024 1025 1028 1111
#  Modeline "1280x1024" 108.88 1280 1360 1496 1712 1024 1025 1028 1060
#  Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027
1034
1063 -hsync +vsync Doublescan
#  Modeline "1280x1024_75.00"  138.75  1280 1368 1504 1728  1024 1027
1034
1072 -hsync +vsync Interlace
#  Modeline "1280x1024_85.00"  159.50  1280 1376 1512 1744  1024 1027
1034
1078 -hsync +vsync Doublescan Interlace
#EndSection

Section "Device"
  BoardName    "Cirrus Logic GD 5446"
  Driver       "cirrus"
  Identifier   "Device[0]"
  VendorName   "XenSource Inc."
EndSection

Section "Screen"
  DefaultDepth 24
  SubSection "Display"
    Depth      15
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  SubSection "Display"
    Depth      16
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  SubSection "Display"
    Depth      24
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  SubSection "Display"
    Depth      8
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  Device       "Device[0]"
  Identifier   "Screen[0]"
  Monitor      "Monitor[0]"
EndSection

Section "ServerLayout"
  Identifier   "Layout[all]"
  Option       "Clone" "off"
  Option       "Xinerama" "off"
  Screen       "Screen[0]"
EndSection

The commented out Modelines were just an experiment with values obtained from 
the commands cvt and xmode. None of them made any difference. Maybe someone 
better than me at xorg can chime in, but at least I got the resolution up to 
the highest one Fajar said he got in his Nov. 9 post. This is about as far as 
I can go with this resolution problem.

Used to be that in earlier distro version of opensuse - 11.2 and lower - there 
were a couple of utilities called sax2 and isax that configured your xorg.conf 
for you, but the old rpms won''t install on suse 11.4, with dependency 
problems. The xorg devs must think that xorg is self configuring enough 
nowadays. I would say that isn''t true with older drivers like cirrusfb.

I also noticed that if you edit the INITRD_MODULES line of 
/etc/sysconfig/kernel, the modules in that line (that are put in the initrd) 
load sooner than even the ''modprobe cirrusfb'' line I had you
put in
/etc/init.d/boot.local. (After editing INITRD_MODULES, you must run
''mkinitrd''
again to recreate all the initrds in /boot. See the mkinitrd options if you 
want to only update a specific kernel''s initrd.) Unfortunately, it
still loads
after vesafb, and I still get those BAR 0: errors, and cirrusfb doesn''t
initialize properly. All the resolution obtained above come from the xorg 
cirrus module, not the kernel cirrusfb module. I never found a way around the 
BAR 0: errors, and I''m pretty sure that is what is preventing you from
getting
even higher resolutions.

On another problem - before I started looking at hvm to pv conversion for your 
domu, I decided to look at the PVonHVM drivers. The old wiki page actually has 
more info than the new one:

http://wiki.xensource.com/xenwiki/XenLinuxPVonHVMdrivers

On suse 11.4, these drivers are installed with the xen-kmp-desktop rpm for the 
-desktop flavor of the suse kernel. I noticed from the end of your dmesg that 
you got the messages that would be expected from the xen drivers, so
I''m
assuming you have it installed. You may have missed how to enable it in your 
domu config though.

This is your hvm config that you posted on Nov. 8, with the obvious changes 
for local differences in my setup, like memory=, disk= and keymap=. I call the 
file simply ''suse'':

kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 768
#device_model = ''qemu-dm''

shadow_memory = 8
name = "opensuse-11.4"
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
acpi = 1
apic = 1
disk = [ ''phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-2,hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]
#vif = [ ''mac=00:16:3e:00:00:21, bridge=xenbr0, model=e1000'' ]
#xen_platform_pci=1

boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''''
vnclisten="192.168.1.100"
stdvga=0
videoram=16
#keymap="it"
keymap=''en-us''

serial=''pty''
usbdevice=''tablet''

I noticed you didn''t use device_model= in your config, and the install
worked
quite well with out it. I simply executed ''xl create suse'',
and the dvd
installer came up and worked with no problems, and I picked all the defaults. 
I assume that is how you did it, and did not use something like virt-install 
or virt-manager.

After the install, I changed boot= to ''cd'', and played with
the Realtek
drivers the first few times I rebooted. Then I enabled the PVonHVM drivers by 
commenting out your vif=, and un-commenting the vif= with the e1000 model, and 
xen_platform-pci=, according to the url.

I had some minor problems, because the dvd installer setup udev and modprobe 
rules based on Realtek as eth0, and PVonHVM tried to setup an eth1 with the 
PVonHVM drivers, but then tries to rename eth1 to eth0, and move eth0 out of 
the way. If you do an ''ethtool -i eth0''. if it says the driver
is e1000,
you''re still using the qemu emulated device. If ''ethtool -i
eth0'' says the
driver is netfront, you are using the PVonHVM driver.

I found if I edited /etc/modprobe.d/xen_pvdrivers.conf to include a line for 
e1000 similar to the existing lines for 8139{cp,too}, I can get eth0 to have 
the netfront driver nearly every time:

# Install the paravirtualized drivers
install libata  /sbin/modprobe xen-vbd 2>&1 |:; /sbin/modprobe --ignore-
install libata

install 8139cp  /sbin/modprobe xen-vnif 2>&1 |:; /sbin/modprobe --ignore-
install 8139cp

install 8139too  /sbin/modprobe xen-vnif 2>&1 |:; /sbin/modprobe
--ignore-
install 8139too

install e1000  /sbin/modprobe xen-vnif 2>&1 |:; /sbin/modprobe --ignore-
install e1000

The results are impressive, at least on the network side. Benchmarking with 
''iperf'' gives net speeds around 1Gbps. Can''t say I
was as impressed with the
disk drivers, but all I tested with was ''hdparm -t
devicename'', where the
devicename is /dev/sda? for qemu and /dev/hda? for PVonHVM. The numbers were 
all the same, but I''m probably limited by my iscsi speed anyway.

That being said, there will be an annoying 1 min. pause on boot up, around the 
message:

[   36.114925] eth1 renamed to eth1-eth0 by udevd [347]
[   36.121708] udev[347]: renamed network interface eth1 to eth1-eth0

Over the next few days, I''ll look at full blown hvm to pv conversion. I
suspect it will be as simple as installing kernel-xen, but using a pv config 
file to boot with. If I boot with an hvm config, and select Xen in the menu, I 
also got the ''invalid executable format'' error. Then as I
mentioned, the
device names in menu.lst and /etc/fstab have to be changed. I''m already
booting up with my hvm config with /dev/disk/by-uuid names instead of 
/dev/disk/by-id names. When I get it all together, I''ll post it.

On 5 December 2011 00:37, jim burns <jim_burn@bellsouth.net>
wrote:
> Ok - I''ve had partial success. I can get text mode up to
1280x1024, and the
> desktop up to 1024x768.
Hello,

De default kernel command line in the menu.lst file shows 0x313.
Once Grub has started, I can choose between many different screen
resolution too,
as regard the text mode actually.
The default one (not according with the kernel command line above) is 0x314.
Putting vga=0x31a makes me a text mode resolution up to 1280x1024x24.
>
> The text mode boost came from simply using vga=0x31a (1280x1024x24) in my
> menu.lst, on the kernel line. I remember you saying that didn''t
work for you,
> but I now assume you meant for the desktop, not text mode. What also works
is
> 0x307 (1280x1024x8) and 0x319 (1280x1024x15).
Yes, I meant the desktop of course. Actually I''ve already tried to
change such text
mode resolution before and I''ve already seen that it works.
The max desktop resolution is still 800x600.
> With the following /etc/X11/xorg.conf, you can get a desktop up to
1024x768:
> [...]
OK THIS worked for me too!

> All the resolution obtained above come from the xorg
> cirrus module, not the kernel cirrusfb module. I never found a way around
the
> BAR 0: errors, and I''m pretty sure that is what is preventing you
from getting
> even higher resolutions.
You know these things even better than me! ;)
>
> On another problem - before I started looking at hvm to pv conversion for
your
> domu, I decided to look at the PVonHVM drivers. The old wiki page actually
has
> more info than the new one:
>
> http://wiki.xensource.com/xenwiki/XenLinuxPVonHVMdrivers
Why don''t try to setup suse directly as a PV guest? I think it would be
better.
I tried to do it, but I don''t know what to do after the first reboot
(the end of the setup
that requires a reboot).
> I assume that is how you did it, and did not use something like
virt-install
> or virt-manager.
No I didn''t use virt-* actually.
> Over the next few days, I''ll look at full blown hvm to pv
conversion. I
> suspect it will be as simple as installing kernel-xen, but using a pv
config
> file to boot with. If I boot with an hvm config, and select Xen in the
menu, I
> also got the ''invalid executable format'' error. Then as I
mentioned, the
> device names in menu.lst and /etc/fstab have to be changed. I''m
already
> booting up with my hvm config with /dev/disk/by-uuid names instead of
> /dev/disk/by-id names. When I get it all together, I''ll post it.
OK, thank you so much, even I still remain of the idea that it would be better
to setup a PV guest directly. It seems more simple for me.

So the problem of the screen resolution seems to be fixed now. It would be
a good thing to find out how to have success installing a PV guest without
starting from a hvm guest.

Cheers,

-- 
Flavio

On Mon December 5 2011, 10:49:19 AM, Flavio wrote:
> Why don''t try to setup suse directly as a PV guest? I think it
would be
> better. I tried to do it, but I don''t know what to do after the
first
> reboot (the end of the setup
> that requires a reboot).
Sorry. The net is full of methods that worked for ''them'' and
not for ''me'', and
some that work for both. I have no interest in exploring those methods. 
Theoretically, you can install xen in your hvm domu, reboot with a menu.lst 
stanza of the kernel xen/ module / module form (probably using kernel-xen), 
and use Yast to install a pv domu of a suse flavor. It will be slow as hell, 
but that sort of simple nested virtualization (pv inside an hvm) has been done 
(by Pasi or Fajar, or old timer Mark Williamson - I forget which). The only 
sure pv install method for a beginner is the distro''s own install
method. The
rest of the methods require some time, effort & experience to help figure
out
what went wrong.

One thought I have though: I''m not exactly sure what you mean by what
to do
after the first reboot. Suse does a kexec reload of the installer to get from 
the beginning of the install to the last configuration part. It does not 
require doing another ''xl create ...'' - it just reloads it
without ever losing
the vnc window. However, after the install is over, and you *want* to reboot, 
are you saying you don''t have a pv config file to xl create with?

If so, there is a trick that was posted last month (Konrad, 11/10): While your 
install routine is running, you can get the config for the domu with
''virsh
dumpxml domname >out-file'', and then ''virsh 
domxml-to-native xen-xm out-file''
to get a domu config. Or, with a little shell syntax magic, you can do it all 
in one step (as root):

virsh  domxml-to-native xen-xm =(virsh dumpxml domname)

Then, it''s *probably* as simple as removing any kernel= / ramdisk=
lines, and
putting in a "bootloader=''/usr/bin/pygrub''" line,
check your disk= line for
correctness (no cdrom), and maybe add an extra= line. (Although, there is 
nothing an extra= line can do that editing your menu.lst can''t do.)

On 5 December 2011 17:18, jim burns <jim_burn@bellsouth.net>
wrote:
> The only
> sure pv install method for a beginner is the distro''s own install
method. The
> rest of the methods require some time, effort & experience to help
figure out
> what went wrong.
Yes, and actually I was using the distro''s own install method to setup
a PV domU.
> However, after the install is over, and you *want* to reboot,
> are you saying you don''t have a pv config file to xl create with?
I am saying that I have a pv config file but if I answer Y to the
reboot request at the
end of the installation, that is very slow as you said, the domU reboots but
the setup process start again, like if it was the first install, not
detecting that
it has to finish the setup which required the reboot!
This is the config file I use to start the first install:

name="OpenSuse11"
memory=1024
disk =
[''phy:/dev/loop0,hdc:cdrom,r'',''file:/mnt/xen/vmstore/opensuse11/opensuse11.img,xvda,w''
]
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
stdvga=1
videoram=16
#bootloader = "/usr/bin/pygrub"
kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
vcpus=1
on_reboot = ''restart''
on_crash = ''destroy''
#usbdevice=''tablet''
#extra = ''xencons=tty''
extra = ''noapic ssh=1 sshpassword=lolrofl addswap=/dev/xvda2
install=http://192.168.1.100/suse11/''

Of course at http://192.168.1.100/suse11/ location the Suse DVD iso
image is mounted as loop.

Once the domU has rebooted, it asks again to ssh the domU and proceed
with the OS installation.
At this point I interrupt, since I don''t want to perform again another
installation over the one I''ve
just done.
> Then, it''s *probably* as simple as removing any kernel= / ramdisk=
lines, and
> putting in a "bootloader=''/usr/bin/pygrub''"
line, check your disk= line for
> correctness (no cdrom), and maybe add an extra= line. (Although, there is
> nothing an extra= line can do that editing your menu.lst can''t
do.)
Of course, I''ve also tried to uncomment the bootloader line and comment
the
two following, but it doesn''t work.
The domU doesn''t start.

-- 
Flavio

On Mon December 5 2011, 5:30:39 PM, Flavio wrote:
> On 5 December 2011 17:18, jim burns <jim_burn@bellsouth.net> wrote:
> > The only
> > sure pv install method for a beginner is the distro''s own
install
> > method. The rest of the methods require some time, effort &
experience
> > to help figure out what went wrong.
> 
> Yes, and actually I was using the distro''s own install method to
setup
> a PV domU.
No, I mean using a suse dom0 to install a suse pv domu (or a fedora dom0 to 
install a fedora domu, etc.) This is because only the distro in question (suse 
here) knows about the layout of their own install disk, and knows how to run 
the install for you without hiccups, like this. Since you are using a gentoo 
dom0, you are out of luck, trying to install a suse domu.
> > However, after the install is over, and you *want* to reboot,
> > are you saying you don''t have a pv config file to xl create
with?
> 
> I am saying that I have a pv config file but if I answer Y to the
> reboot request at the
> end of the installation, that is very slow as you said, the domU reboots
but
> the setup process start again, like if it was the first install, not
> detecting that
> it has to finish the setup which required the reboot!
> This is the config file I use to start the first install:
> 
> name="OpenSuse11"
> memory=1024
> disk >
[''phy:/dev/loop0,hdc:cdrom,r'',''file:/mnt/xen/vmstore/opensuse11/opensuse11.
> img,xvda,w'' ]
> vif = [ ''type=ioemu, mac=00:16:3e:00:00:21,
bridge=xenbr0'' ]
> vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
> stdvga=1
> videoram=16
> #bootloader = "/usr/bin/pygrub"
> kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
> ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
> vcpus=1
> on_reboot = ''restart''
> on_crash = ''destroy''
> #usbdevice=''tablet''
> #extra = ''xencons=tty''
> extra = ''noapic ssh=1 sshpassword=lolrofl addswap=/dev/xvda2
> install=http://192.168.1.100/suse11/''
> 
> Of course at http://192.168.1.100/suse11/ location the Suse DVD iso
> image is mounted as loop.
> 
> Once the domU has rebooted, it asks again to ssh the domU and proceed
> with the OS installation.
> At this point I interrupt, since I don''t want to perform again
another
> installation over the one I''ve
> just done.
> 
> > Then, it''s *probably* as simple as removing any kernel= /
ramdisk> > lines, and putting in a
"bootloader=''/usr/bin/pygrub''" line, check your
> > disk= line for correctness (no cdrom), and maybe add an extra= line.
> > (Although, there is nothing an extra= line can do that editing your
> > menu.lst can''t do.)
> Of course, I''ve also tried to uncomment the bootloader line and
comment the
> two following, but it doesn''t work.
> The domU doesn''t start.
Again, back to guessing here, since I don''t have Gentoo: First, I
don''t think
the ''phy:/dev/loop0,hdc:cdrom,r'' part of the disk= line is
doing anything. Pv
domus don''t understand cdroms. The install= line, and your loop mount
of the
dvd is telling gentoo where your install media is. (Similarly, stdvga= and 
videoram= are hvm options, and will be ignored.)

Here''s my guess: after replacing kernel / ramdisk with bootloader, also
comment out the install= line. That''s probably telling gentoo to
restart. If
that doesn''t work, I can''t help you with this method, but
I''ll keep working on
the hvm to pv conversion approach.

On 5 December 2011 18:16, jim burns <jim_burn@bellsouth.net>
wrote:
> No, I mean using a suse dom0 to install a suse pv domu (or a fedora dom0 to
> install a fedora domu, etc.) This is because only the distro in question
(suse
> here) knows about the layout of their own install disk, and knows how to
run
> the install for you without hiccups, like this. Since you are using a
gentoo
> dom0, you are out of luck, trying to install a suse domu.
Ah, OK, well. I did understand now. You are right. Maybe I could find some
instruction to build a suse pv domU for a suse dom0, hopefully.
> Again, back to guessing here, since I don''t have Gentoo: First, I
don''t think
> the ''phy:/dev/loop0,hdc:cdrom,r'' part of the disk= line
is doing anything.
No, actually, it doesn''t do anything, but even if I remove it, nothing
changes.
> Pv
> domus don''t understand cdroms.
Ok, right. My fault, even I''m pretty sure to have seen that on some
tutorial.
> The install= line, and your loop mount of the
> dvd is telling gentoo where your install media is. (Similarly, stdvga= and
> videoram= are hvm options, and will be ignored.)
Yes, and it actually works, in order to start the setup process. That was clear
enough to me.
>
> Here''s my guess: after replacing kernel / ramdisk with bootloader,
also
> comment out the install= line. That''s probably telling gentoo to
restart.
Yes, I forgot to tell you that I''ve also removed that line, but nothing
changed.
> If
> that doesn''t work, I can''t help you with this method, but
I''ll keep working on
> the hvm to pv conversion approach.
Thanks a lot, I appreciate your effort a lot.

Sincerely,
-- 
Flavio

On Mon December 5 2011, 6:25:29 PM, Flavio wrote:
> > If
> > that doesn''t work, I can''t help you with this
method, but I''ll keep
> > working on the hvm to pv conversion approach.
> 
> Thanks a lot, I appreciate your effort a lot.
Ok -  I got curious about your pv install method, and tried it myself. It 
actually did work, but you may not be aware of it.

First, given your config, it looks like all you did was an ''xl create
...'' to
start your install. You (again) didn''t use something like virt-install
/ virt-
manager to control your install. If so, you are only using xen tools, and 
nothing specific to Gentoo, and this approach would work on any
distro''s dom0.

Anyway, that''s what I did, with this config patterned after the one you
posted, with local differences, and hvm directives removed (and by the way, 
''vcpus'' was misspelled):

name="opensuse11"
memory=768
disk = [ ''phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-3,xvda,w'' ]
vif = [ ''mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=en-us" ]
#bootloader = "/usr/bin/pygrub"
kernel = "/home/jimb/Cmpq/boot/i386/vmlinuz-xenpae"
ramdisk = "/home/jimb/Cmpq/boot/i386/initrd-xenpae"
#kernel = "/boot/vmlinuz-3.1.0-7.fc16.x86_64"
#ramdisk = "/boot/initramfs-3.1.0-7.fc16.x86_64.img"
#kernel = "/boot/vmlinuz-2.6.41.1-1.fc15.x86_64"
#ramdisk = "/boot/initramfs-2.6.41.1-1.fc15.x86_64.img"
#kernel = "/boot/vmlinuz-2.6.32.39-175.xendom0.fc13.x86_64"
#ramdisk = "/boot/initramfs-2.6.32.39-175.xendom0.fc13.x86_64.img"
#kernel = "/home/jimb/Cmpq/boot/i386/vmlinuz-xenpae"
#ramdisk = "/home/jimb/Cmpq/boot/i386/initrd-xenpae"
vcpus=1
on_reboot = ''restart''
on_crash = ''destroy''
#extra = ''xencons=tty''
#extra = ''noapic ssh=1 sshpassword=lolrofl addswap=/dev/xvda2
#install=''nfs://192.168.1.100:/home/jimb/Cmpq/''

You''ll notice, I tried a few fedora pvops, xen enabled kernels, none of
which
worked. (Curious - I''m assuming the format of an initramfs, and how the
kernel
executes the scripts in it, is different from an initrd.) I mounted the DVD in 
the Cmpq sub-directory in my home dir, which is also a sub-dir that is nfs 
exported, and a sub-dir in a cifs export. The sub-dir /boot/i386 in the dvd 
contains a xen enabled kernel & initrd. (This is what I mean about details
of
the install dvd that only that distro''s own install routines, like
Yast, would
know, and a generic install routine, like virt-manager, from some other distro 
might not.) That kernel & initrd started the install, and then I had to pick
one of the Network install methods, after clicking on ''Back''
to get to a menu.
(Yes - it is a *pain* not having the mouse work. Fortunately, each option on 
each screen in Yast has an underlined letter. That letter, held down with the 
Alt key, selects that option.) I tried un-commenting the install= line above, 
and it did not save me any time. I still had to enter info into the Network 
install screens every time.

I had trouble using the nfs and smb (cifs) network install methods. Curiously, 
the installer, running in a domu, not the dom0, could use the Network install 
info I entered to go from the simple beginning menus to the full Yast menu, 
but once in Yast, it didn''t know how to access the mount by nfs or smb
anymore
(and no indication in my network monitoring tools that it was even trying). 
Fortunately, if you pick the smb method of Network install, when you get the 
error message in Yast, when it tried to initialize the install repo, it allows 
you to switch over to an http install. I just gave the url for 
download.opensuse.org. You, of course, wouldn''t have this problem,
since you
were using an http install from the beginning.

Anyway, two hours later, the vnc window disappeared. (This is about the point 
in the install where you started having problems.) I did an ''xm
list'', and
found out the domu had restarted. A simple ''xm vncviewer ...''
brought up the
last part of the install - the Automatic Configuration step. (Actually, it 
asked me to inset a dvd, I selected ''Back'', then
''Start Install'', then
(something like) Boot from the Installed Harddisk, to get to the Automatic 
Configuration step.)

After the install finished, I changed the config file - un-comment the 
bootloader= line, and comment out the kernel= & ramdisk= lines. I then did
an
''xm create ... -c'' to be sure that grub was setup right, and
then exited the
domu''s console, and did an ''xm vncviewer ...'', and I
am now staring at the KDE
desktop. This is the menu.lst it installed. Notice it has kernel-desktop, and 
kernel-xen installed, with the kernel-xen as the default menu item, so the
''xm
create'' with the ''-c'' option was not necessary. I
could have gone straight
into a vncviewer. (I don''t think menu.lst will be setup until you are
past the
Automatic Configuration step, so I didn''t switch comments on bootloader
and
kernel / ramdisk till after then.)

# Modified by YaST2. Last modification on Tue Dec  6 19:48:21 EST 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in
# /etc/sysconfig/bootloader

default 2
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don''t change this comment - YaST2 identifier: Original name:
linux###
title openSUSE 11.4 - 2.6.37.1-1.2 (default)
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/xvda2 
resume=/dev/xvda1 splash=silent quiet showopts
    initrd /boot/initrd-2.6.37.1-1.2-default

###Don''t change this comment - YaST2 identifier: Original name:
failsafe###
title Failsafe -- openSUSE 11.4 - 2.6.37.1-1.2
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.1-1.2-default root=/dev/xvda2 showopts apm=off 
noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off 
processor.max_cstate=1 nomodeset x11failsafe
    initrd /boot/initrd-2.6.37.1-1.2-default

###Don''t change this comment - YaST2 identifier: Original name:
linux###
title Xen -- openSUSE 11.4 - 2.6.37.1-1.2
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.1-1.2-xen root=/dev/xvda2 resume=/dev/xvda1 
splash=silent quiet showopts
    initrd /boot/initrd-2.6.37.1-1.2-xen

Unfortunately, the desktop I''m looking at is 800x600, so we are back to
one of
the original problems. I''ll try putting ''vga=0x31a''
in menu.lst, or Fajar''s
suggestions about setting resolution in a pv domu, in the next day or two, and 
tell you what I come up with.

On Wed December 7 2011, 1:15:37 AM, jim burns wrote:
> Unfortunately, the desktop I''m looking at is 800x600, so we are
back to one
> of  the original problems. I''ll try putting
''vga=0x31a'' in menu.lst, or
> Fajar''s suggestions about setting resolution in a pv domu, in the
next day
> or two, and tell you what I come up with.
Well, this is fairly useless. The mouse doesn''t work at all, so the
desktop is
unusable. I have to ''xm console ...'' in to give commands. I
turned on sshd,
and changed the SuSEfirewall rules so I can use ssh as well.

The resolution is unchangeable. The hvm tricks that worked - vga=0x31a, or 
defining an xorg.conf don''t work. And Fajar''s
xen-fbfront.video=32,1280,1024
option in menu.lst didn''t either. I wouldn''t be surprised if
suse renamed the
module, though, like it renamed xennet and xenblk. However, since 
XEN_FRAMEBUFFER is builtin, I can''t find the name of the module to
modify it''s
options.

Oh well.

On 7 December 2011 07:15, jim burns <jim_burn@bellsouth.net>
wrote:
> Ok -  I got curious about your pv install method, and tried it myself. It
> actually did work, but you may not be aware of it.
>
> First, given your config, it looks like all you did was an ''xl
create ...'' to
> start your install.
Yes, I actually did xl create opensuse11.cfg && xl vncviewer `xl domid
OpenSuse11`
Then in the vnc viewer at a certain point, a message appears and it
says to enter the
domU via ssh. So performing the following command, the graphical setup starts:
ssh -X root@<domU_IP> and then start yast (see screenshots below).

At this point, I proceed with the graphical setup up to the end, where
a reboot is
required. Actually it says: "The system will reboot now. After reboot,
reconnect
and run the following: /usr/lib/YaST2/startup/YaST2.ssh"

Here''s a screenshot: http://goo.gl/8DKSF

At this point I tried to boot as you said, using pygrub, and it actually worked!
I don''t know why it didn''t work for me before!

I tried to xl create with the following config file:
name="OpenSuse11"
memory=1024
disk =
[''file:/mnt/xen/vmstore/opensuse11/opensuse11.img,xvda,w'' ]
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
stdvga=1
videoram=16
bootloader = "/usr/bin/pygrub"
vcpus=1
on_reboot = ''restart''
on_crash = ''destroy''

xl create opensuse11.cfg -c
I see the pygrub with the following kernels:
openSUSE 11.4 - 2.6.37.1-1.2 (default)
Xen -- openSUSE 11.4 - 2.6.37.1-1.2

I try to hit on Xen and it finally started!
so xl vncviewer `xl domid OpenSuse11` gives me the vnc window that stops at
this screen: http://goo.gl/4qMaV

At this point I can ssh -X root@192.168.1.104 and issue the following command:
/usr/lib/YaST2/startup/YaST2.ssh, because I am now in the new system.

Finally the Automatic Configuration starts and I can finish the
installation process.
After that, the boot continues in the vnc viewer and I can proceed
with the login.
Of course the boot process continues on the domU console too (where
the pygrub started).
In this case, the mouse doesn''t work for me too! :(
Let''s investigate if some option is missing in the configuration file.
The pointer doesn''t move but click works.
See this:
http://xen.1045712.n5.nabble.com/OpenSuse-11-PV-domU-installation-problem-the-mouse-pointer-doesn-t-move-but-click-works-td4998460.html

I had this problem in the installation process before. The strange fact is that
the mouse works with yast but not with vnc.
Something tells me that it is a OpenSuse 11.4 issue, so I''m going to
download the
12.1 version of the DVD and to try a new PV setup (now that I know how
to complete
the setup!!!).
> You (again) didn''t use something like virt-install / virt-
> manager to control your install. If so, you are only using xen tools, and
> nothing specific to Gentoo, and this approach would work on any
distro''s dom0.
Yes, I''m pretty sure of that.
>
> Anyway, that''s what I did, with this config patterned after the
one you
> posted, with local differences, and hvm directives removed (and by the way,
> ''vcpus'' was misspelled):
Was it misspelled? I''ve checked. I didn''t notice that.
Anyway...
> [...]
> (This is what I mean about details of
> the install dvd that only that distro''s own install routines, like
Yast, would
> know, and a generic install routine, like virt-manager, from some other
distro
> might not.)
Yes, I''ve actually taken both the initrd and the kernel from the Suse
DVD:
boot/x86_64/vmlinuz-xen
boot/x86_64/initrd-xen
> That kernel & initrd started the install, and then I had to pick
> one of the Network install methods, after clicking on
''Back'' to get to a menu.
> (Yes - it is a *pain* not having the mouse work. Fortunately, each option
on
> each screen in Yast has an underlined letter. That letter, held down with
the
> Alt key, selects that option.)
Yes, but not in the first screen! http://goo.gl/6EymS in wich I don''t
know how to
press close!
:P
> I tried un-commenting the install= line above,
> and it did not save me any time. I still had to enter info into the Network
> install screens every time.
Not for me. I really don''t understand why this happens to you. The
network configuration
is quite automatic for me.

Now, coming back again on how to start the installation process:
here''s again the script I am using to launch the setup:

name="OpenSuse11"
memory=1024
disk =
[''file:/mnt/xen/vmstore/opensuse11/opensuse11.img,xvda,w'' ]
vif = [ ''type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0'' ]
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
stdvga=1
videoram=16
kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
vcpus=1
on_reboot = ''restart''
on_crash = ''destroy''
extra = ''noapic ssh=1 sshpassword=lolrofl addswap=/dev/xvda2
install=http://192.168.1.100/suse11/''

Then: xl create opensuse11.cfg && xl vncviewer `xl domid OpenSuse11`
When the boot has finished: ssh -X root@<domU_IP> and then start yast.
No problem with the mouse pointer here.
Maybe we did all things differently? Or maybe there is a misunderstanding.
Maybe I am talking about the setup process, and you are talking about the domU
once it is up and running. Anyway, I think it should be clear now that the
mouse pointer doesn''t work at the end, when it is running, not during
the setup process with yast.
> Anyway, two hours later, the vnc window disappeared. (This is about the
point
> in the install where you started having problems.)
In truth, I didn''t have this problem. My vncviewer window
didn''t
disappear. I simply closed it
because it is useless, since it is like this during the setup:
http://goo.gl/tfF9l
As you can see, once you do as the message suggests, the yast
installer starts in another
window: http://goo.gl/glvtK

Instead, it is the yast window that is going to disappear because it
has a countdown for the
reboot, and if you don''t get it on time at the end of the setup, you
may think that the window has disappeared without any
reason, or because of a crash for instance.
> After the install finished, I changed the config file - un-comment the
> bootloader= line, and comment out the kernel= & ramdisk= lines. I then
did an
> ''xm create ... -c'' to be sure that grub was setup right,
and then exited the
> domu''s console, and did an ''xm vncviewer ...'',
and I am now staring at the KDE
> desktop.
Well, thanks to your tip above, I was able to go ahead with the setup
where I was
blocked. Now, I''ve noticed that I could start KDE as root but not as a
normal user.
Maybe it is due to a permission issue, or a missing group membership. I have to
investigate also on it.
> This is the menu.lst it installed. Notice it has kernel-desktop, and
> kernel-xen installed, with the kernel-xen as the default menu item, so the
''xm
> create'' with the ''-c'' option was not necessary.
I could have gone straight
> into a vncviewer. (I don''t think menu.lst will be setup until you
are past the
> Automatic Configuration step, so I didn''t switch comments on
bootloader and
> kernel / ramdisk till after then.)
This is pretty good. Actually I think it detects that it is a PV domU
and it installs
also the kernel-xen setting it as the default kernel. Good!
> Unfortunately, the desktop I''m looking at is 800x600, so we are
back to one of
> the original problems. I''ll try putting
''vga=0x31a'' in menu.lst, or Fajar''s
> suggestions about setting resolution in a pv domu, in the next day or two,
and
> tell you what I come up with.
So, no higher resolution than 800x600 with some xorg.conf trick? Bad... Anyway,
the first problem to solve now is the mouse pointer. This has the highest
priority now.

On 7 December 2011 11:08, jim burns <jim_burn@bellsouth.net>
wrote:
> Well, this is fairly useless. The mouse doesn''t work at all, so
the desktop is
> unusable. I have to ''xm console ...'' in to give commands.
I turned on sshd,
> and changed the SuSEfirewall rules so I can use ssh as well.
I really don''t understand why the mouse doesn''t work.
I''m really frustrated.
>
> The resolution is unchangeable. The hvm tricks that worked - vga=0x31a, or
> defining an xorg.conf don''t work.
:-(
> And Fajar''s xen-fbfront.video=32,1280,1024
> option in menu.lst didn''t either. I wouldn''t be surprised
if suse renamed the
> module, though, like it renamed xennet and xenblk. However, since
> XEN_FRAMEBUFFER is builtin, I can''t find the name of the module to
modify it''s
> options.
Maybe one solution is to recompile the kernel and put it as module.
We should try. The problem is that it is a very long process if we use
the config
file provided by the distro.
Pheraps we could try an "external" domU kernel, and not using pygrub
but something
like the following line in the configuration file:
kernel = "/mnt/xen/kernel/vmlinuz-xen-3.1.0-domU"
I use that kernel to start a gentoo pv domU and it works.

Thanks!
-- 
Flavio

On Wed December 7 2011, 5:54:34 PM, Flavio wrote:
> On 7 December 2011 07:15, jim burns <jim_burn@bellsouth.net> wrote:
> > Ok -  I got curious about your pv install method, and tried it myself.
> > It actually did work, but you may not be aware of it.
> > 
> > First, given your config, it looks like all you did was an
''xl create
> > ...'' to start your install.
> 
> Yes, I actually did xl create opensuse11.cfg && xl vncviewer `xl
domid
> OpenSuse11`
The syntax on xl vncviewer is unnecessary, despite what xl help says.
''xl
vncviewer OpenSuse11'' works also.
> Then in the vnc viewer at a certain point, a message appears and it
> says to enter the
> domU via ssh. So performing the following command, the graphical setup
> starts: ssh -X root@<domU_IP> and then start yast (see screenshots
below).
I didn''t use any of your extra= lines in my install, so I never had
Yast in a
ssh -X window. Convenient though, since you ended up being able to use the 
mouse, instead of using the Alt-keystroke method I was using in vnc.
> Finally the Automatic Configuration starts and I can finish the
> installation process.
> After that, the boot continues in the vnc viewer and I can proceed
> with the login.
> Of course the boot process continues on the domU console too (where
> the pygrub started).
> In this case, the mouse doesn''t work for me too! :(
> Let''s investigate if some option is missing in the configuration
file.
> The pointer doesn''t move but click works.
> See this:
> http://xen.1045712.n5.nabble.com/OpenSuse-11-PV-domU-installation-problem-t
> he-mouse-pointer-doesn-t-move-but-click-works-td4998460.html
Doesn''t help much if you can''t move the cursor around to click
on something.
:-(
> I had this problem in the installation process before. The strange fact is
> that the mouse works with yast but not with vnc.
Right - because you are using the mouse, keyboard, and video on your client 
where you typed ''ssh -X ...'', not the drivers in the domu.
That''s why I said
using the extra= line with ssh was convenient.
> Something tells me that it is a OpenSuse 11.4 issue, so I''m going
to
> download the
> 12.1 version of the DVD and to try a new PV setup (now that I know how
> to complete
> the setup!!!).
Interesting. I haven''t even had time to upgrade my suse 11.4 bare-metal
system
yet.
> > Anyway, that''s what I did, with this config patterned after
the one you
> > posted, with local differences, and hvm directives removed (and by the
> > way,
> > ''vcpus'' was misspelled):
> Was it misspelled? I''ve checked. I didn''t notice that.
Anyway...
Sorry - I was editing and comparing several config files at the time. It was 
one of my old configs that had the misspell.
> > That kernel & initrd started the install, and then I had to pick
> > one of the Network install methods, after clicking on
''Back'' to get to a
> > menu. (Yes - it is a *pain* not having the mouse work. Fortunately,
> > each option on each screen in Yast has an underlined letter. That
> > letter, held down with the Alt key, selects that option.)
> 
> Yes, but not in the first screen! http://goo.gl/6EymS in wich I
don''t
> know how to press close!
See the dotted lines around ''openSUSE Build Service''?
That''s where the
''cursor'' is. Hit Tab several times until
''CLOSE'' has the box, then hit return.
(Just thought of something - since click works, you should be able to
''right
click'' on that screen, and arrow key down to ''close''.
On most keyboards, there
is a ''mouse click'' key on the bottom right side, between the
Alt & Ctrl keys.)
 
> > After the install finished, I changed the config file - un-comment the
> > bootloader= line, and comment out the kernel= & ramdisk= lines. I
then
> > did an ''xm create ... -c'' to be sure that grub was
setup right, and
> > then exited the domu''s console, and did an ''xm
vncviewer ...'', and I am
> > now staring at the KDE desktop.
> 
> Well, thanks to your tip above, I was able to go ahead with the setup
> where I was
> blocked. Now, I''ve noticed that I could start KDE as root but not
as a
> normal user.
> Maybe it is due to a permission issue, or a missing group membership. I
have
> to investigate also on it.
This may have something to do with your other extra= line. I had no trouble 
getting a desktop as an ordinary user, until I added extra=''xencons=tty
...''.
This interferes with the creation of /dev/tty0, which I''m guessing xorg
needs.
> > This is the menu.lst it installed. Notice it has kernel-desktop, and
> > kernel-xen installed, with the kernel-xen as the default menu item, so
> > the ''xm create'' with the ''-c''
option was not necessary. I could have
> > gone straight into a vncviewer. (I don''t think menu.lst will
be setup
> > until you are past the Automatic Configuration step, so I
didn''t switch
> > comments on bootloader and kernel / ramdisk till after then.)
> 
> This is pretty good. Actually I think it detects that it is a PV domU
> and it installs
> also the kernel-xen setting it as the default kernel. Good!
Correct. It wouldn''t be very useful for a virtual install routine to
install a
kernel that was not domu capable. :-)
> > Unfortunately, the desktop I''m looking at is 800x600, so we
are back to
> > one of the original problems. I''ll try putting
''vga=0x31a'' in menu.lst,
> > or Fajar''s suggestions about setting resolution in a pv domu,
in the
> > next day or two, and tell you what I come up with.
> 
> So, no higher resolution than 800x600 with some xorg.conf trick? Bad...
> Anyway, the first problem to solve now is the mouse pointer. This has the
> highest priority now.
> 
> On 7 December 2011 11:08, jim burns <jim_burn@bellsouth.net> wrote:
> > Well, this is fairly useless. The mouse doesn''t work at all,
so the
> > desktop is unusable. I have to ''xm console ...'' in
to give commands. I
> > turned on sshd, and changed the SuSEfirewall rules so I can use ssh as
> > well.
> 
> I really don''t understand why the mouse doesn''t work.
I''m really frustrated.
> > The resolution is unchangeable. The hvm tricks that worked -
vga=0x31a,
> > or defining an xorg.conf don''t work.
> :
> :-(
> :
> > And Fajar''s xen-fbfront.video=32,1280,1024
> > option in menu.lst didn''t either. I wouldn''t be
surprised if suse
> > renamed the module, though, like it renamed xennet and xenblk.
However,
> > since XEN_FRAMEBUFFER is builtin, I can''t find the name of
the module
> > to modify it''s options.
> 
> Maybe one solution is to recompile the kernel and put it as module.
> We should try. The problem is that it is a very long process if we use
> the config file provided by the distro.
That would be useful. I won''t do it - compile times on my system are
bad, too.
And I have several other projects stacked up.
> Pheraps we could try an "external" domU kernel, and not using
pygrub
> but something
> like the following line in the configuration file:
> kernel = "/mnt/xen/kernel/vmlinuz-xen-3.1.0-domU"
> I use that kernel to start a gentoo pv domU and it works.
The problem with that approach is you have to copy over the whole 
/lib/modules/<kernel version> tree to your domu, or you won''t be
able to load
any kernel modules that are not in your initrd. And you won''t be able
to keep
the modules updated with new versions of the kernel from within the domu. 
You''d have to update them on the source computer, then copy the modules
over
to the domu again. It would be useful for quick testing, though. If
it''s an
.rpm file, though, you can install it directly in your domu, if there are no 
dependency problems.

On 7 December 2011 20:43, jim burns <jim_burn@bellsouth.net>
wrote:
> The syntax on xl vncviewer is unnecessary, despite what xl help says.
''xl
> vncviewer OpenSuse11'' works also.
Thanks, good to know.
> Interesting. I haven''t even had time to upgrade my suse 11.4
bare-metal system
> yet.
Now I am trying to setup open suse 12.1...
I hope this release doesn''t have the mouse problem.
>
> This may have something to do with your other extra= line. I had no trouble
> getting a desktop as an ordinary user, until I added
extra=''xencons=tty ...''.
> This interferes with the creation of /dev/tty0, which I''m guessing
xorg needs.
No, I am trying to start the domU without any extra line and the X
session doesn''t
start as a normal user. It is strange actually, since in the hvm domU
it was starting
without any problem.

> That would be useful. I won''t do it - compile times on my system
are bad, too.
> And I have several other projects stacked up.
The problem is that the config file that you may find in the domU''s
/boot directory is
configured to have A LOT of modules to be compiled. It should be modified,
removing most of them, that are not necessary for sure. I don''t do it,
because
I don''t want to make mistakes, removing something necessary for the
domU.
In case I''ll compile as it is...
> The problem with that approach is you have to copy over the whole
> /lib/modules/<kernel version> tree to your domu, or you
won''t be able to load
> any kernel modules that are not in your initrd.
Oh yes, you are right, but this wouldn''t be a problem, since it is
sufficient for me
to go to the domU kernel source dir and issue the following command:
make modules_install INSTALL_MOD_PATH=/mnt/loop
after having mounted the img file in the loop dir.
> And you won''t be able to keep
> the modules updated with new versions of the kernel from within the domu.
Yes, I have to do it manually each time.

Bye,
-- 
Flavio

On Wed December 7 2011, 2:43:29 PM, jim burns wrote:
> > On 7 December 2011 11:08, jim burns <jim_burn@bellsouth.net>
wrote:
> > > Well, this is fairly useless. The mouse doesn''t work at
all, so the
> > > desktop is unusable. I have to ''xm console ...''
in to give commands.
> > > I
> > > turned on sshd, and changed the SuSEfirewall rules so I can use
ssh
> > > as
> > > well.
> >
> > 
> >
> > I really don''t understand why the mouse doesn''t
work. I''m really
> > frustrated.
Well, no fix, but some workarounds. I can use ssh, or xm console, to get in, 
copy some .desktop files to my user ~/Desktop directory, and then use the 
cursor keys to select an icon on the desktop, hit return, and launch it. I 
launched konsole this way, from which I can launch other programs, including X 
programs (but still can''t use a mouse in them.).

The odd thing is that Xorg.0.log clearly shows the evdev driver found an input 
driver for the mouse, but the desktop isn''t use it. KDE''s
systemsettings
program didn''t help, either:

[  7808.448] (II) config/udev: Adding input device Xen Virtual Pointer 
(/dev/input/event1)
[  7808.448] (**) Xen Virtual Pointer: Applying InputClass "evdev pointer 
catchall"
[  7808.448] (**) Xen Virtual Pointer: always reports core events
[  7808.448] (**) Xen Virtual Pointer: Device: "/dev/input/event1"
[  7808.448] (--) Xen Virtual Pointer: Found 12 mouse buttons
[  7808.448] (--) Xen Virtual Pointer: Found scroll wheel(s)
[  7808.448] (--) Xen Virtual Pointer: Found relative axes
[  7808.448] (--) Xen Virtual Pointer: Found x and y relative axes
[  7808.448] (--) Xen Virtual Pointer: Found absolute axes
[  7808.448] (--) Xen Virtual Pointer: Found x and y absolute axes
[  7808.448] (II) Xen Virtual Pointer: Configuring as mouse
[  7808.448] (II) Xen Virtual Pointer: Adding scrollwheel support
[  7808.448] (**) Xen Virtual Pointer: YAxisMapping: buttons 4 and 5
[  7808.448] (**) Xen Virtual Pointer: EmulateWheelButton: 4, 
EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[  7808.448] (II) XINPUT: Adding extended input device "Xen Virtual
Pointer"
(type: MOUSE)
[  7808.448] (**) Xen Virtual Pointer: (accel) keeping acceleration scheme 1
[  7808.448] (**) Xen Virtual Pointer: (accel) acceleration profile 0
[  7808.448] (**) Xen Virtual Pointer: (accel) acceleration factor: 2.000
[  7808.448] (**) Xen Virtual Pointer: (accel) acceleration threshold: 4
[  7808.448] (II) Xen Virtual Pointer: initialized for relative axes.
[  7808.448] (WW) Xen Virtual Pointer: ignoring absolute axes.

On Wed December 7 2011, 10:09:02 PM, Flavio wrote:
> > This may have something to do with your other extra= line. I had no
> > trouble getting a desktop as an ordinary user, until I added
> > extra=''xencons=tty ...''. This interferes with the
creation of
> > /dev/tty0, which I''m guessing xorg needs.
> No, I am trying to start the domU without any extra line and the X
> session doesn''t
> start as a normal user. It is strange actually, since in the hvm domU
> it was starting
> without any problem.
Did you define a user in the Yast install? That''s the only thing I can
think
of that may be different between your install and mine.

On 7 December 2011 22:20, jim burns <jim_burn@bellsouth.net>
wrote:
> The odd thing is that Xorg.0.log clearly shows the evdev driver found an
input
> driver for the mouse, but the desktop isn''t use it. KDE''s
systemsettings
> program didn''t help, either:
Very strange actually.
I really don''t have any idea now.
I hope that it would be possible to solve, using OpenSuse 12.

-- 
Flavio

On 7 December 2011 22:25, jim burns <jim_burn@bellsouth.net>
wrote:
> Did you define a user in the Yast install? That''s the only thing I
can think
> of that may be different between your install and mine.
Of course yes, and I can log in as such user.
Then, typing the startx command says it can''t write the Xorg.0.log file
or something like that.. but it does exist.

By the way: in the hvm domU, xdm starts automatically. Why it doesn''t
start automatically here too?

-- 
Flavio

On Wed December 7 2011, 10:27:53 PM, Flavio wrote:
> On 7 December 2011 22:25, jim burns <jim_burn@bellsouth.net> wrote:
> > Did you define a user in the Yast install? That''s the only
thing I can
> > think of that may be different between your install and mine.
> 
> Of course yes, and I can log in as such user.
> Then, typing the startx command says it can''t write the Xorg.0.log
file
> or something like that.. but it does exist.
> 
> By the way: in the hvm domU, xdm starts automatically. Why it
doesn''t
> start automatically here too?
It does for me. ''startx'' usually will give you some problems.
You could try
''startkde'', but first: Do a ''chkconfig xdm
--list'', and make sure there are
''on'' entries in the output. If not, you can do (as root)
''chkconfig xdm on'',
then ''rcxdm start'', which is preferable to even startkde.
(Actually, as root,
do ''rcxdm stop'', then ''/bin/ps a -HA|grep
kdm'', and check for a pid to use
with kill. Sometimes kdm doesn''t exit cleanly. Then do ''rcxdm
start''.)

On Wed December 7 2011, 10:25:40 PM, Flavio wrote:
> On 7 December 2011 22:20, jim burns <jim_burn@bellsouth.net> wrote:
> > The odd thing is that Xorg.0.log clearly shows the evdev driver found
an
> > input driver for the mouse, but the desktop isn''t use it.
KDE''s
> > systemsettings
> > program didn''t help, either:
> Very strange actually.
> I really don''t have any idea now.
> I hope that it would be possible to solve, using OpenSuse 12.
Ok - back to the hvm install, and converting it to a pv domu. Actually, all 
the heavy lifting has already been done in the hvm install and the pv install. 
Only three things need to be done for the conversion:

1) As I said, all the /dev/disk/by-id references in menu.lst and fstab have to 
be changed to /dev/disk/by-uuid. By way of example, look at the end of my 
/dev/disk tree, and then my menu.lst:


/dev/disk/by-id:
total 0
drwxr-xr-x 2 root root 220 Dec  3 14:34 ./
drwxr-xr-x 6 root root 120 Dec  3 14:34 ../
lrwxrwxrwx 1 root root   9 Dec  3 14:34 ata-QEMU_DVD-ROM_QM00003 -> ../../sr0
lrwxrwxrwx 1 root root   9 Dec  3 14:34 ata-QEMU_HARDDISK_QM00001 ->
../../sda
lrwxrwxrwx 1 root root  10 Dec  3 14:34 ata-QEMU_HARDDISK_QM00001-part1 -> 
../../sda1
lrwxrwxrwx 1 root root  10 Dec  3 14:34 ata-QEMU_HARDDISK_QM00001-part2 -> 
../../sda2
lrwxrwxrwx 1 root root  10 Dec  3 14:34 ata-QEMU_HARDDISK_QM00001-part3 -> 
../../sda3
lrwxrwxrwx 1 root root   9 Dec  3 14:34 scsi-SATA_QEMU_HARDDISK_QM00001 -> 
../../sda
lrwxrwxrwx 1 root root  10 Dec  3 14:34 scsi-SATA_QEMU_HARDDISK_QM00001-part1 
-> ../../sda1
lrwxrwxrwx 1 root root  10 Dec  3 14:34 scsi-SATA_QEMU_HARDDISK_QM00001-part2 
-> ../../sda2
lrwxrwxrwx 1 root root  10 Dec  3 14:34 scsi-SATA_QEMU_HARDDISK_QM00001-part3 
-> ../../sda3

/dev/disk/by-uuid:
total 0
drwxr-xr-x 2 root root 100 Dec  3 14:34 ./
drwxr-xr-x 6 root root 120 Dec  3 14:34 ../
lrwxrwxrwx 1 root root  10 Dec  3 14:34 0b95b2ca-ffc6-486c-a11e-8c1086b88d50
-
> ../../sda1
lrwxrwxrwx 1 root root  10 Dec  3 14:34 2dcfb1a2-876d-4b36-86a5-d34641331c9e
-
> ../../sda2
lrwxrwxrwx 1 root root  10 Dec  3 14:34 3ed78b97-5da1-4b3c-a1f0-4a38ba388d78
-
> ../../sda3
# Modified by YaST2. Last modification on Sun Dec  4 12:42:04 EST 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in 
/etc/sysconfig/bootloader

default 3
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don''t change this comment - YaST2 identifier: Original name:
linux###
title openSUSE 11.4 - 2.6.37.6-0.9 (default)
    root (hd0,1)
#    kernel /boot/vmlinuz-2.6.37.6-0.9-default root=/dev/disk/by-id/ata-
QEMU_HARDDISK_QM00001-part2 resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-
part1 showopts vga=0x31a
    kernel /boot/vmlinuz-2.6.37.6-0.9-default root=/dev/sda2 resume=/dev/sda1  
splash=silent showopts vga=0x31a
    initrd /boot/initrd-2.6.37.6-0.9-default

###Don''t change this comment - YaST2 identifier: Original name:
failsafe###
title Failsafe -- openSUSE 11.4 - 2.6.37.6-0.9 (default)
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.6-0.9-default root=/dev/sda2 showopts apm=off 
noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off 
processor.max_cstate=1 nomodeset x11failsafe vga=0x314
    initrd /boot/initrd-2.6.37.6-0.9-default

###Don''t change this comment - YaST2 identifier: Original name: xen###
title Xen -- openSUSE 11.4 - 2.6.37.6-0.9
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.6-0.9-xen root=/dev/disk/by-
uuid/2dcfb1a2-876d-4b36-86a5-d34641331c9e resume=/dev/disk/by-uuid/0b95b2ca-
ffc6-486c-a11e-8c1086b88d50 showopts vga=0x31a
    initrd /boot/initrd-2.6.37.6-0.9-xen

###Don''t change this comment - YaST2 identifier: Original name:
linux###
title Desktop -- openSUSE 11.4 - 2.6.37.6-0.9
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.6-0.9-desktop root=/dev/disk/by-
uuid/2dcfb1a2-876d-4b36-86a5-d34641331c9e resume=/dev/disk/by-uuid/0b95b2ca-
ffc6-486c-a11e-8c1086b88d50  splash=silent showopts vga=0x31a
    initrd /boot/initrd-2.6.37.6-0.9-desktop

###Don''t change this comment - YaST2 identifier: Original name:
failsafe###
title Failsafe -- openSUSE 11.4 - 2.6.37.6-0.9 (desktop)
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.37.6-0.9-desktop root=/dev/sda2 showopts apm=off 
noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off 
processor.max_cstate=1 nomodeset x11failsafe vga=0x314
    initrd /boot/initrd-2.6.37.6-0.9-desktop

I left the stanza for the -default kernel as it was originally from the hvm 
install. (Yeah, the hvm install only installed the -desktop version of the 
kernel. I installed the other two with zypper, and upgraded the -desktop 
kernel. This doesn''t change the discussion about /dev/disk/by-uuid.)

Eg - see how my ata-QEMU_HARDDISK_QM00001-part2 points to /dev/sda2 (the root 
filesystem). The UUID 2dcfb1a2-876d-4b36-86a5-d34641331c9e also points to 
/dev/sda2, so all three are equivalent in the hvm domu. However, the 
/dev/disk/by-id links completely go away when you boot up with a pv config. 
(Yeah, I used the pv config I posted, patterned on your pv install config.) 
Also, the /dev/sdan drives change into /dev/xvdan drives. The preferred 
standard way of representing the drives then becomes /dev/disk/by-uuid, and I 
changed that in the -desktop and -xen stanzas. The -desktop stanza boots with 
the hvm config, and the -xen stanza boots with the pv config. You also need to 
do the same thing in /etc/fstab.

2) You don''t have an X desktop at this point, or an ''xm
console ...'' login,
but you do have a login in the vnc window. Two files need to be edited to get 
an xm console login. You must edit /etc/inittab, find the line that looks 
like:

#S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102

and add a line above it that looks like:

x0:12345:respawn:/sbin/agetty -L 9600 xvc0 xterm

Then edit /etc/securetty, and add xvc0 to the end of the list, to allow root 
to login on the agetty defined above. Then give the command ''telinit
q'' to
tell init to re-read the inittab file, and create the agetty login process for 
xm console.

There is only one drawback to this: When you boot back in with an hvm config, 
/dev/xvc0 doesn''t exist, and you get a lot of annoying error messages
in
syslog. Just comment out the ''x0'' line in inittab, and execute
telinit q.

I expect this step to be done completely differently in suse 12.1, since the 
old systemV init system is supposed to be replaced by the systemd daemon, 
according to the opensuse web site. I''ve worked with systemd in fedora
15 -
it''s a bit stiff. ;-(

3) And, finally, this is my xorg.conf:

# 
# This file contains the device names of tty lines (one per line,
# without leading /dev/) on which root is allowed to login.
#
tty1
tty2
tty3
tty4
tty5
tty6
xvc0
root@linux-w421 12/07/11 11:40PM:~
[508] > cat /etc/X11/xorg.conf
Section "Monitor"
  HorizSync    20-220
  Identifier   "Monitor[0]"
  VertRefresh  30-320
  UseModes     "Modes[0]"
EndSection

Section "Modes"
  Identifier   "Modes[0]"
  Modeline "1280x1024" 276.24 1280 1384 1528 1776 1024 1025 1028 1111
  Modeline "1280x1024" 108.88 1280 1360 1496 1712 1024 1025 1028 1060
  Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027
1034 1063
-hsync +vsync Doublescan
  Modeline "1280x1024_75.00"  138.75  1280 1368 1504 1728  1024 1027
1034 1072
-hsync +vsync Interlace
  Modeline "1280x1024_85.00"  159.50  1280 1376 1512 1744  1024 1027
1034 1078
-hsync +vsync Doublescan Interlace
EndSection

Section "Device"
  BoardName    "Cirrus Logic GD 5446"
  Driver       "cirrus"
  Identifier   "Device[0]"
  VendorName   "XenSource Inc."
EndSection

Section "Screen"
  DefaultDepth 24
  SubSection "Display"
    Depth      15
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  SubSection "Display"
    Depth      16
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  SubSection "Display"
    Depth      24
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  SubSection "Display"
    Depth      8
    Modes      "1280x1024" "1152x864" "1024x768"
"800x600"
  EndSubSection
  Device       "Device[0]"
  Identifier   "Screen[0]"
  Monitor      "Monitor[0]"
EndSection

Section "Device"
  Identifier "fbdev"
  Driver  "fbdev"
EndSection
Section "Screen"
  Identifier "fbdev"
  Device "fbdev"
EndSection

Section "ServerLayout"
  Identifier   "Layout[all]"
  Option       "Clone" "off"
  Option       "Xinerama" "off"
  Screen       "Screen[0]"
  Screen       "fbdev"
EndSection

The only difference from what I gave you before is at the end: the extra 
Device and Screen sections for fbdev, and adding that Screen definition to 
ServerLayout. I got the idea from the xorg.conf.install file that the suse 
install left behind.

This ServerLayout tells xorg to try both fbdev and cirrus, and decide which 
one is best.

The end result is exactly the same as the pv install we''ve been talking
about.
The resolution is just 800x600, and there is no mouse, despite Xorg.0.log 
saying the evdev driver found one. Oh, well - at least it''s an
interesting
technical exercise. ;-)

I''m out of ideas on the mouse, and the pv resolution. If anyone has any
ideas,
feel free to chime in. :-)

On 7 December 2011 22:59, jim burns <jim_burn@bellsouth.net>
wrote:
> It does for me. ''startx'' usually will give you some
problems. You could try
> ''startkde'', but first: Do a ''chkconfig xdm
--list'', and make sure there are
> ''on'' entries in the output. If not, you can do (as root)
''chkconfig xdm on'',
> then ''rcxdm start'', which is preferable to even startkde.
(Actually, as root,
> do ''rcxdm stop'', then ''/bin/ps a -HA|grep
kdm'', and check for a pid to use
> with kill. Sometimes kdm doesn''t exit cleanly. Then do
''rcxdm start''.)
OK, thanks

On 8 December 2011 05:56, jim burns <jim_burn@bellsouth.net>
wrote:
> Ok - back to the hvm install, and converting it to a pv domu. Actually, all
> the heavy lifting has already been done in the hvm install and the pv
install.
> Only three things need to be done for the conversion:
> [...]
OK, in this moment though, I don''t want to put myself in the hvm to pv
conversion hell! :P If I can have success with a "plain" PV setup it
is better
for me. Anyway, I want to do things once at time. I want to resort to this
conversion as a last hope, when the PV setups attempts failed them all.
>
> I left the stanza for the -default kernel as it was originally from the hvm
> install. (Yeah, the hvm install only installed the -desktop version of the
> kernel. I installed the other two with zypper, and upgraded the -desktop
> kernel. This doesn''t change the discussion about
/dev/disk/by-uuid.)
Ok, actually it is the same kernel-xen I''ve tried to setup with zypper
as well,
on my previous hvm install. Of course it''s not the same thing as the
PV.
>
> 3) And, finally, this is my xorg.conf:
Maybe I''ll keep this, just in case it would be necessary in my new PV
setup.
> This ServerLayout tells xorg to try both fbdev and cirrus, and decide which
> one is best.
ok
>
> The end result is exactly the same as the pv install we''ve been
talking about.
> The resolution is just 800x600, and there is no mouse, despite Xorg.0.log
> saying the evdev driver found one. Oh, well - at least it''s an
interesting
> technical exercise. ;-)
:D
>
> I''m out of ideas on the mouse, and the pv resolution. If anyone
has any ideas,
> feel free to chime in. :-)
I''m still in the long setup process.
35% now.
I will let you know.


-- 
Flavio

On 8 December 2011 11:23, Flavio <fbcyborg@gmail.com>
wrote:
> I''m still in the long setup process.
> 35% now.
> I will let you know.
OK, I''ve finished the installation but KDM (and so KDE)
doesn''t start.
What I can see in the vnc viewer is this: http://goo.gl/z9CaX
But the system starts... if I do xl create opensuse12.cfg -c and I
can get the login screen.
Then if I want to "startkde", I have to perform the following command
into a shell on the dom0:
Xephyr -ac:1 -screen 1024x768

then in the domU:
export DISPLAY="domU_IP:1"
startkde

In this case, the mouse is working and the screen resolution is the
resolution I''ve set with Xephyr! Maybe this trick can be used even for
the
hvm domU.

The only problem is that is very slow. But I think there are many other reasons
for that.

Cheers,
-- 
Flavio

On Thu December 8 2011, 2:40:06 PM, Flavio wrote:
> On 8 December 2011 11:23, Flavio <fbcyborg@gmail.com> wrote:
> > I''m still in the long setup process.
> > 35% now.
> > I will let you know.
> 
> OK, I''ve finished the installation but KDM (and so KDE)
doesn''t start.
> What I can see in the vnc viewer is this: http://goo.gl/z9CaX
> But the system starts... if I do xl create opensuse12.cfg -c and I
> can get the login screen.
> Then if I want to "startkde", I have to perform the following
command
> into a shell on the dom0:
> Xephyr -ac:1 -screen 1024x768
Interesting approach. I was going to suggest grabbing a vnc server package, 
and install it in your domu. Then when you want to connect, instead of
''xl
vncviewer ...'' (which connects to xen''s builtin vnc server via
the dom0''s ip
addr), you instead do ''vncviewer domu-ip-addr'' to talk to the
server in the
domu. In my experience, this is slower than xen''s builtin approach
(other
people on the list have said just the opposite), and a little glitchy in 
updating the display. I''ll have to try this (Xephyr).

Another approach, if you ever get kde working on the domu, is to enable xdmcp 
logins from a remote computer. Then on the client, you do a ''switch
user'', in
in the splash / login screen, click on the menu, and pick xdmcp login, and 
enter the domu ip addr in the box. If the domu has xdmcp enabled,
you''ll login
at the full resolution of the client''s screen.

Suse is kind of stiff in allowing enabling xdmcp. I''ll have to review
how to
do it. Probably something in Yast.
> then in the domU:
> export DISPLAY="domU_IP:1"
> startkde
I think you mean "dom0_IP:1".
> In this case, the mouse is working and the screen resolution is the
> resolution I''ve set with Xephyr! Maybe this trick can be used even
for the
> hvm domU.
Well, we''ve already gotten the hvm resolution up to 1024x768, which is
what
you are using with Xephyr above. But yes, it should work the same way except, 
kde is already working on the hvm install. You''d have to do a
''rcxdm stop'',
then ''export DISPLAY ...'' and startkde.

And yes, the mouse would work. It''s just like when you used ssh to
login to
the Yast install: you''re using the mouse, keyboard & screen on the
computer
you login from with ssh (or Xephyr), not the ones on the domu. (X is a 
networking protocol. The program runs and does calculations on the domu, but 
sends display info over to the client - the dom0 in your case - and gets input 
- keyboard and mouse - from the client.)
> The only problem is that is very slow. But I think there are many other
> reasons for that.
One step forward, one step back. ;-)

On 8 December 2011 18:28, jim burns <jim_burn@bellsouth.net>
wrote:
> Another approach, if you ever get kde working on the domu, is to enable
xdmcp
> logins from a remote computer. Then on the client, you do a
''switch user'', in
> in the splash / login screen, click on the menu, and pick xdmcp login, and
> enter the domu ip addr in the box. If the domu has xdmcp enabled,
you''ll login
> at the full resolution of the client''s screen.
Oh, yes I know. It''s the same mechanism that allows LTSP to work.
It would be a good idea.
> I think you mean "dom0_IP:1".
Yes, you are right! My fault during typing.
> Well, we''ve already gotten the hvm resolution up to 1024x768,
which is what
> you are using with Xephyr above. But yes, it should work the same way
except,
> kde is already working on the hvm install. You''d have to do a
''rcxdm stop'',
> then ''export DISPLAY ...'' and startkde.
Yes you have to stop xdm and start again. Anyway that trick could be used to
have higher resolution than 1024x768, performing the following command
on the dom0
for instance: Xephyr -ac :1 -screen 1280x1024
and the domU''s KDE should keep all the available screen space,
autoresizing the
screen (resolution).
>
> And yes, the mouse would work. It''s just like when you used ssh to
login to
> the Yast install: you''re using the mouse, keyboard & screen on
the computer
> you login from with ssh (or Xephyr), not the ones on the domu. (X is a
> networking protocol. The program runs and does calculations on the domu,
but
> sends display info over to the client - the dom0 in your case - and gets
input
> - keyboard and mouse - from the client.)
Yes, it actually uses a Xorg nested server (BTW: Xephyr is the
evolution of the old
Xnest) so, no problem with the mouse and keyboard.
> One step forward, one step back. ;-)
Damn! :D

-- 
Flavio

On Thu December 8 2011, 7:05:38 PM, Flavio wrote:
> Yes you have to stop xdm and start again. Anyway that trick could be used
to
> have higher resolution than 1024x768, performing the following command on
> the dom0
> for instance: Xephyr -ac :1 -screen 1280x1024
> and the domU''s KDE should keep all the available screen space,
autoresizing
> the screen (resolution).
Also, if you load the xrandr system tray applet in kde, you can change 
resolutions to what ever your client computer can support, on the fly, without 
stopping and restarting startkde.

I just got thru playing with this - neat! One warning though: I would stop kde 
(rcxdm stop) as root if it is running, but then log out and re-login as a user 
before startkde. Running a desktop as root is generally a bad idea. It took me 
awhile staring at the desktop, wondering why I didn''t see the changes I
had
managed to make, till I realized that I was logged in as root.

On Thu December 8 2011, 1:30:31 PM, jim burns wrote:
> I just got thru playing with this - neat!
And it is a bit slow. ''marble --timedemo'' gives 3 fps in
Xephyr, and 28 fps
running natively on my Xephyr client.

On Thu December 8 2011, 1:32:59 PM, jim burns wrote:
> On Thu December 8 2011, 1:30:31 PM, jim burns wrote:
> > I just got thru playing with this - neat!
> 
> And it is a bit slow. ''marble --timedemo'' gives 3 fps in
Xephyr, and 28 fps
> running natively on my Xephyr client.
Well, I played some more with my hvm installed suse domu, and found out 
something interesting.

I installed xen (and libvirt, etc.) in the hvm domu, created a menu.lst stanza 
for booting into the hvm domu with a hypervisor, setup a bridge, and created a 
cfg file for installing a suse pv guest on a suse dom0. (Yeah, I know - since 
I''m only installing a pv domu, I could have done all this on my bare
metal
suse system, but I''ve always been intrigued by the possibility of
nested
virtualization. :-) ) I''m stretching thin the amount of memory on my
system as
is, so it was a small domu - just 233MB of memory, but it was enough to bring 
the Yast installer up.

GUESS WHAT? Yast has a mouse in a suse domu under a suse dom0!!! My guess -  
suse up to now has been using the old style architecture xenlinux, and even in 
2.6.37, it looks like xenlinux with some back-ported new features. I think the 
mouse in a suse domu is depending on something in the suse dom0 kernel that 
isn''t present in my normal fedora dom0 kernel!

I also found out the syntax for your install= line under suse (and fedora) by 
playing around with suse''s vm-install, to create a cfg file. With this
line, I
go straight to the Yast installer, without stopping at the initial blue 
screens to enter my network info:

extra=" install=nfs://192.168.1.100:/home/jimb/Cmpq "

On 10 December 2011 01:52, jim burns <jim_burn@bellsouth.net>
wrote:
> I go straight to the Yast installer, without stopping at the initial blue
> screens to enter my network info:
>
> extra=" install=nfs://192.168.1.100:/home/jimb/Cmpq "
Great!
Good to know that.

;-)

-- 
Flavio

On Fri December 9 2011, 7:52:55 PM, jim burns wrote:
> Well, I played some more with my hvm installed suse domu, and found out 
> something interesting.
[...]
> GUESS WHAT? Yast has a mouse in a suse domu under a suse dom0!!! My guess
> -   suse up to now has been using the old style architecture xenlinux, and
> even in 2.6.37, it looks like xenlinux with some back-ported new features.
> I think the mouse in a suse domu is depending on something in the suse dom0
> kernel that isn''t present in my normal fedora dom0 kernel!
I don''t know if you''ve played with suse 12.1 yet, but I just
upgraded my bare
metal suse 11.4 system to 12.1. That actually was problematical as far as xen 
goes, since suse has stopped supporting 32 bit xen. See my thread
''openSUSE
12.1 does not have complete xen rpms''. I recompiled the .src.rpm, and 
installed xen 4.1.2.

My pv suse 11.4 domu starts just fine, but has no mouse. Apparently, even
tho''
suse 12.1 is still naming its pv drivers xennet & xenblk, it has retained 
enough of the pvops 3.1 kernel architecture that the mouse in an old xenlinux 
arch pv domu like 11.4 is no longer supported. Sign of the times.

On 14 December 2011 23:17, jim burns <jim_burn@bellsouth.net>
wrote:
> I don''t know if you''ve played with suse 12.1 yet,
Yes, I''ve used it a little bit.
Anyway, I didn''t do any more test after trying the Xephyr application.
The fact that I cannot start my X session in the VNC screen, is also
frustrating.

-- 
Flavio

On Thu December 15 2011, 9:46:17 AM, Flavio wrote:
> On 14 December 2011 23:17, jim burns <jim_burn@bellsouth.net> wrote:
> > I don''t know if you''ve played with suse 12.1 yet,
> 
> Yes, I''ve used it a little bit.
> Anyway, I didn''t do any more test after trying the Xephyr
application.
> The fact that I cannot start my X session in the VNC screen, is also
> frustrating.
Whenever my extra= line has xencons=tty, I don''t get a desktop. If you
omit
it, or use xencons=xvc0, I get a desktop. This works for me:

extra = ''console=xvc0 console=hvc0 console=tty''

(The hvc0 is the pvops name for xvc0. I''m just covering all bases.)

On 15 December 2011 10:18, jim burns <jim_burn@bellsouth.net>
wrote:
>
> Whenever my extra= line has xencons=tty, I don''t get a desktop. If
you omit
> it, or use xencons=xvc0, I get a desktop. This works for me:
>
> extra = ''console=xvc0 console=hvc0 console=tty''
None of both solutions work for me instead.
I still get this: http://goo.gl/z9CaX

Nothing more, even the domU has started.


-- 
Flavio