>>> On 09.05.19 at 02:22, wrote:
> On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote:
>> >>> On 06.05.19 at 16:50, wrote:
>> > --- a/xen/drivers/video/vesa.c
>> > +++ b/xen/drivers/video/vesa.c
>> > @@ -84,6 +84,7 @@ void __init vesa_early_init(void)
>> > void __init vesa_init(void)
>>
On Tue, May 07, 2019 at 03:07:27AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 16:50, wrote:
> > --- a/xen/drivers/video/vesa.c
> > +++ b/xen/drivers/video/vesa.c
> > @@ -84,6 +84,7 @@ void __init vesa_early_init(void)
> > void __init vesa_init(void)
> > {
> > struct lfb_prop lfbp;
> > +
>>> On 08.05.19 at 14:06, wrote:
> On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote:
>> >>> On 07.05.19 at 18:43, wrote:
>> > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
>> >> But what's wrong with backporting your change as is?
>> >
>> > If this commit would be backp
On Wed, May 08, 2019 at 03:54:45AM -0600, Jan Beulich wrote:
> >>> On 07.05.19 at 18:43, wrote:
> > On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
> >> >>> On 07.05.19 at 17:38, wrote:
> >> > What do you think about adding something that could be backported?
> >> > Xen is quite insi
>>> On 07.05.19 at 18:43, wrote:
> On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
>> >>> On 07.05.19 at 17:38, wrote:
>> > What do you think about adding something that could be backported?
>> > Xen is quite insistent on initializing framebuffer, even with
>> > console=com1 or conso
On Tue, May 07, 2019 at 10:12:13AM -0600, Jan Beulich wrote:
> >>> On 07.05.19 at 17:38, wrote:
> > What do you think about adding something that could be backported?
> > Xen is quite insistent on initializing framebuffer, even with
> > console=com1 or console=none. Which means, there is no workar
>>> On 07.05.19 at 17:38, wrote:
> What do you think about adding something that could be backported?
> Xen is quite insistent on initializing framebuffer, even with
> console=com1 or console=none. Which means, there is no workaround for
> this problem.
When the system is in a simple text mode th
On Tue, May 07, 2019 at 03:10:06AM -0600, Jan Beulich wrote:
> >>> On 06.05.19 at 17:32, wrote:
> > On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
> >> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> >> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> >
>>> On 06.05.19 at 16:50, wrote:
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -84,6 +84,7 @@ void __init vesa_early_init(void)
> void __init vesa_init(void)
> {
> struct lfb_prop lfbp;
> +unsigned long lfb_base;
>
> if ( !font )
> return;
> @@ -
>>> On 06.05.19 at 17:32, wrote:
> On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
>> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
>> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> > index ccdffc0..b0f0f7e 100644
>> > --- a/xen/include/public/xen.h
>
On 06/05/2019 17:32, Marek Marczykowski-Górecki wrote:
> On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
>> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
>>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>>> index ccdffc0..b0f0f7e 100644
>>> --- a/xen/incl
On Mon, May 06, 2019 at 05:15:19PM +0200, Juergen Gross wrote:
> On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > index ccdffc0..b0f0f7e 100644
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@
On 06/05/2019 15:50, Marek Marczykowski-Górecki wrote:
> diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
> index c92497e..f22cf7f 100644
> --- a/xen/drivers/video/vesa.c
> +++ b/xen/drivers/video/vesa.c
> @@ -84,6 +84,7 @@ void __init vesa_early_init(void)
> void __init vesa_init(
On 06/05/2019 16:50, Marek Marczykowski-Górecki wrote:
> On some machines (for example Thinkpad P52), UEFI GOP reports
> framebuffer located above 4GB (0x40 on that machine). This
> address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
> field, which is 32bit. The overflow
On some machines (for example Thinkpad P52), UEFI GOP reports
framebuffer located above 4GB (0x40 on that machine). This
address does not fit in {xen,dom0}_vga_console_info.u.vesa_lfb.lfb_base
field, which is 32bit. The overflow here cause all kind of memory
corruption when anything tries t
15 matches
Mail list logo
