Xen devel - Jun 2011 - Screen corruption and crash at boot with Xen 4.1.0 & linux 2.6.39 on some systems

I have a custom built system based on LFS 6.6 with xen 4.1.0 & linux 2.6.39
built from source. The system boots correctly on one system (after a problem
with the USB disk has been worked around), however when I try to boot the same
system on another machine the screen corrupts shortly after handover from the
bootloader. This happens on 2 out of the 3 machines I have tried it on.

I was originally using xen 4.1.0 & linux 2.6.38.7, and with this combination
the bootloader would work correctly, xen would work correctly and it would crash
and the screen corrupt on the handover from xen to linux. I had a hunt around
and found http://wiki.xensource.com/xenwiki/XenPVOPSDRM which talks about the
graphics subsystem and says "What is boils down to is: if you want to use a
stock kernel from ftp.kernel.org wait till 2.6.39 gets released". As a
result I have switched to xen 4.1.0 & linux 2.6.39 but get the same result.

The motherboard is a Gigabit GA-MA69VM-S2.

The lspci -vvv output is attached.

What I did notice is the way the screen resolution changes during boot is
different for the two main machines that I test on. On the machine that works,
instead of the 80x25 console that I''m used to with xen 3.4.1, I get a
much higher resolution output with two penguins at the top with 4.1.0. When I
boot the system without the xen hypervisor linux starts at the 80x25 resolution
but then quickly puts the screen into high resolution. On the machine that
fails, when I boot the system without the xen hypervisor, linux starts at 80x25
resolution, appears to do a resolution change (whole screen flickers) a few
seconds later but leaves the resolution at 80x25.

Am I doing something wrong? Is this a bug? Is there a workaround? Should I try a
different kernel version?

I''m happy to live with the 80x25 resolution screen but none of the
screen resolution options that I''ve tried have had any effect.

Thanks,

Anthony.

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

On Thu, Jun 02, 2011 at 02:08:03PM +0100, Anthony Wright
wrote:
> I have a custom built system based on LFS 6.6 with xen 4.1.0 & linux
2.6.39 built from source. The system boots correctly on one system (after a
problem with the USB disk has been worked around), however when I try to boot
the same system on another machine the screen corrupts shortly after handover
from the bootloader. This happens on 2 out of the 3 machines I have tried it on.
> 
> I was originally using xen 4.1.0 & linux 2.6.38.7, and with this
combination the bootloader would work correctly, xen would work correctly and it
would crash and the screen corrupt on the handover from xen to linux. I had a
hunt around and found http://wiki.xensource.com/xenwiki/XenPVOPSDRM which talks
about the graphics subsystem and says "What is boils down to is: if you
want to use a stock kernel from ftp.kernel.org wait till 2.6.39 gets
released". As a result I have switched to xen 4.1.0 & linux 2.6.39 but
get the same result.
We missed a couple of patches and had to revert some.
> 
> The motherboard is a Gigabit GA-MA69VM-S2.
> 
> The lspci -vvv output is attached.
> 
> What I did notice is the way the screen resolution changes during boot is
different for the two main machines that I test on. On the machine that works,
instead of the 80x25 console that I''m used to with xen 3.4.1, I get a
much higher resolution output with two penguins at the top with 4.1.0. When I
boot the system without the xen hypervisor linux starts at the 80x25 resolution
but then quickly puts the screen into high resolution. On the machine that
fails, when I boot the system without the xen hypervisor, linux starts at 80x25
resolution, appears to do a resolution change (whole screen flickers) a few
seconds later but leaves the resolution at 80x25.
> 
> Am I doing something wrong? Is this a bug? Is there a workaround? Should I
try a different kernel version?
Try git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/2.6.39.x

and if that does not work, on top of that branch, also try reverting these two
patches:

03a80665341bbb9a57064c2ddeca13b554d56893
("drm/radeon/nouveau: fix build regression on alpha due to Xen changes.)
and 
d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d.
("Revert "ttm: Utilize the DMA API for pages that have
TTM_PAGE_FLAG_DMA32 set.")
> 
> I''m happy to live with the 80x25 resolution screen but none of the
screen resolution options that I''ve tried have had any effect.
> 
> Thanks,
> 
> Anthony.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

Hi Konrad,

Sorry to ask the same question again, but does 2.6.39.1 include the
patches from stable/2.6.39.x  that fixed this problem?

thanks,

Anthony.
[I''ve cc''d xen-devel as I think I hit reply rather than
reply-all a
little while back]

On 07/06/2011 15:52, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 07, 2011 at 12:42:27PM +0100, Anthony Wright wrote:
>> I ran with the stable/2.6.39.x version and that''s fixed the
problem
>> (didn''t need to do the revert).
>>
>> The first build failed because mm/swapfile.c had an undefined reference
>> to frontswap_init and by default FRONTSWAP is not set.
> <nods>That is fixed now.
>> Are these patches in mainline 2.6.39.1 or will I have to wait for 3.0.0
?
> No. The VGA support one might show up in 3.0 depending on Linus. I sent an
> email asking him to pull it: https://lkml.org/lkml/2011/6/6/391
> but it could be considered a feature and the merge window for features
elapsed :-(
>
> It could also be considered a bug ...  anyhow leaving it up to Linus
> and I would recommend you use 2.6.39.1 and I can respond to this email
thread
> whether Linus has pulled the patch or not.
>
>> thanks,
>>
>> Anthony
>>
>> On 02/06/2011 15:51, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jun 02, 2011 at 02:08:03PM +0100, Anthony Wright wrote:
>>>> I have a custom built system based on LFS 6.6 with xen 4.1.0
& linux 2.6.39 built from source. The system boots correctly on one system
(after a problem with the USB disk has been worked around), however when I try
to boot the same system on another machine the screen corrupts shortly after
handover from the bootloader. This happens on 2 out of the 3 machines I have
tried it on.
>>>>
>>>> I was originally using xen 4.1.0 & linux 2.6.38.7, and with
this combination the bootloader would work correctly, xen would work correctly
and it would crash and the screen corrupt on the handover from xen to linux. I
had a hunt around and found http://wiki.xensource.com/xenwiki/XenPVOPSDRM which
talks about the graphics subsystem and says "What is boils down to is: if
you want to use a stock kernel from ftp.kernel.org wait till 2.6.39 gets
released". As a result I have switched to xen 4.1.0 & linux 2.6.39 but
get the same result.
>>> We missed a couple of patches and had to revert some.
>>>> The motherboard is a Gigabit GA-MA69VM-S2.
>>>>
>>>> The lspci -vvv output is attached.
>>>>
>>>> What I did notice is the way the screen resolution changes
during boot is different for the two main machines that I test on. On the
machine that works, instead of the 80x25 console that I''m used to with
xen 3.4.1, I get a much higher resolution output with two penguins at the top
with 4.1.0. When I boot the system without the xen hypervisor linux starts at
the 80x25 resolution but then quickly puts the screen into high resolution. On
the machine that fails, when I boot the system without the xen hypervisor, linux
starts at 80x25 resolution, appears to do a resolution change (whole screen
flickers) a few seconds later but leaves the resolution at 80x25.
>>>>
>>>> Am I doing something wrong? Is this a bug? Is there a
workaround? Should I try a different kernel version?
>>> Try git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/2.6.39.x
>>>
>>> and if that does not work, on top of that branch, also try
reverting these two patches:
>>>
>>> 03a80665341bbb9a57064c2ddeca13b554d56893
>>> ("drm/radeon/nouveau: fix build regression on alpha due to Xen
changes.)
>>> and 
>>> d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d.
>>> ("Revert "ttm: Utilize the DMA API for pages that have
TTM_PAGE_FLAG_DMA32 set.")
>>>
>>>> I''m happy to live with the 80x25 resolution screen but
none of the screen resolution options that I''ve tried have had any
effect.
>>>>
>>>> Thanks,
>>>>
>>>> Anthony.
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel

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

On Thu, Jun 09, 2011 at 01:59:26PM +0100, Anthony Wright
wrote:
> Hi Konrad,
> 
> Sorry to ask the same question again, but does 2.6.39.1 include the
That is OK.
> patches from stable/2.6.39.x  that fixed this problem?
No. And it looks as Linus did not pull the VGA support for 3.0 so
that will have to wait till 3.1.

In the meatime as an internim solution I would recommend you use
stable/2.6.39.x tree. Not sure why I said "recommend you use 2.6.39.1"
in the previous email - I meant stable/2.6.39.x ..

.. snip.
> >> Are these patches in mainline 2.6.39.1 or will I have to wait for
3.0.0 ?
> > No. The VGA support one might show up in 3.0 depending on Linus. I
sent an
> > email asking him to pull it: https://lkml.org/lkml/2011/6/6/391
> > but it could be considered a feature and the merge window for features
elapsed :-(
> >
> > It could also be considered a bug ...  anyhow leaving it up to Linus
> > and I would recommend you use 2.6.39.1 and I can respond to this email
thread
> > whether Linus has pulled the patch or not.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/06/2011 15:52, Konrad Rzeszutek Wilk wrote:
> No. The VGA support one might show up in 3.0 depending on Linus. I sent an
> email asking him to pull it: https://lkml.org/lkml/2011/6/6/391
> but it could be considered a feature and the merge window for features
elapsed :-(
>
> It could also be considered a bug ...  anyhow leaving it up to Linus
> and I would recommend you use 2.6.39.1 and I can respond to this email
thread
> whether Linus has pulled the patch or not.
I''ve been using the stable/vga.support branch reference in the lkml
email on 3.0.0-rc3 and it worked perfectly. I''ve just upgraded to rc4,
and all I get now is a blank screen. Is there any chance of a fix?

thanks,

Anthony.

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

On Tue, Jun 28, 2011 at 01:10:48PM +0100, Anthony Wright
wrote:
> On 07/06/2011 15:52, Konrad Rzeszutek Wilk wrote:
> > No. The VGA support one might show up in 3.0 depending on Linus. I
sent an
> > email asking him to pull it: https://lkml.org/lkml/2011/6/6/391
> > but it could be considered a feature and the merge window for features
elapsed :-(
> >
> > It could also be considered a bug ...  anyhow leaving it up to Linus
> > and I would recommend you use 2.6.39.1 and I can respond to this email
thread
> > whether Linus has pulled the patch or not.
> I''ve been using the stable/vga.support branch reference in the
lkml
> email on 3.0.0-rc3 and it worked perfectly. I''ve just upgraded to
rc4,
> and all I get now is a blank screen. Is there any chance of a fix?
You can respond to this thread: https://lkml.org/lkml/2011/6/6/391

and tell Linus that you are seriously hampered by the lack of the
stable/vga.support
and you urge him to pull it in.

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