Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
Hi, > > Actually, I spoke too soon. The problematic 24 bpp mode that Windows > > picks right now is 118 and that's within the standard range so I can't > > move 144 above it and renumber. What would be considered safer, > > keeping the same mode numbers or partially renumbering to keep them > > monotonically increasing except for the standard range? > > I wouldn't renumber anything at 0x11B or below - those are defined in > the vbe3 spec. Ordering and the numbering of all the other modes can > be changed. Despite the comment in the source, modes 0x11C-0x11F do > not appear to be standard modes. > > Thinking on this further, there's a good chance other systems (in > addition to Windows) choose the first valid mode found. So, > reordering the 32bit modes above the 24bit modes could cause changes > in other systems as well. Indeed, there is a risk that this reordering uncovers hidden bugs. I think at least for modern software the risk is pretty small though. Real hardware apparently already lists 32bpp before 24bpp (or stopped supporting 24bpp altogether), otherwise this windows bug wouldn't have managed to hide long enough to make it to the RTM media ... For oldish 90ies DOS games the risk might be higher. It might also make use software use 32bpp instead of 24bpp (without breaking stuff), which would be a useful change as qemu uses 32bpp internally so it'll avoid a conversion step and give a small performance benefit. > So, I think it may be too risky to push > this into the pending SeaBIOS release. I expect in case we uncover bugs with this we will probably not notice before we update the seabios version shipped with qemu ... cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On 10/19/16 17:56, Kevin O'Connor wrote: > On Wed, Oct 19, 2016 at 05:20:08PM +0200, Laszlo Ersek wrote: >> On 10/19/16 15:16, Ladi Prosek wrote: >>> Another hypothetical alternative would be to try to find an API >>> invocation pattern reasonably unique to Windows that would trigger the >>> new behavior, to minimize the risk. >> >> How about a new CONFIG_xxx knob? > > I doubt QEMU would want to ship two stdvga vgabios binaries for this - > one with the flag and one without. Likely not, but with the config option present, downstreams that care about a well-defined set of guest OSes could exhaustively test the behavior of those guests, and if the change worked fine for all of the OSes, they could just flip the config option in the downstream package (rather than carrying a downstream patch). It was just an idea anyway; if it's too late for the pending release, I guess a more robust method could be devised, in time for the next release. Thanks Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Wed, Oct 19, 2016 at 05:20:08PM +0200, Laszlo Ersek wrote: > On 10/19/16 15:16, Ladi Prosek wrote: > > Another hypothetical alternative would be to try to find an API > > invocation pattern reasonably unique to Windows that would trigger the > > new behavior, to minimize the risk. > > How about a new CONFIG_xxx knob? I doubt QEMU would want to ship two stdvga vgabios binaries for this - one with the flag and one without. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Wed, Oct 19, 2016 at 03:16:48PM +0200, Ladi Prosek wrote: > On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor wrote: > > On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote: > >> Actually, I spoke too soon. The problematic 24 bpp mode that Windows > >> picks right now is 118 and that's within the standard range so I can't > >> move 144 above it and renumber. What would be considered safer, > >> keeping the same mode numbers or partially renumbering to keep them > >> monotonically increasing except for the standard range? > > > > I wouldn't renumber anything at 0x11B or below - those are defined in > > the vbe3 spec. Ordering and the numbering of all the other modes can > > be changed. Despite the comment in the source, modes 0x11C-0x11F do > > not appear to be standard modes. > > Got it. My point is that given how the standard modes are fixed, it's > not possible to renumber so all modes are in an increasing order. So I > wonder if renumbering is worth it at all. In fact, the issue would be > solved just by changing the order of the two 1024x768 modes mentioned > above: 118 and 144. I'm not sure what the best approach is. If it's really just that one mode, perhaps moving it above 118 and adding a comment is the best approach. If you're moving whole blocks around, I'd renumber. > > Thinking on this further, there's a good chance other systems (in > > addition to Windows) choose the first valid mode found. So, > > reordering the 32bit modes above the 24bit modes could cause changes > > in other systems as well. So, I think it may be too risky to push > > this into the pending SeaBIOS release. > > Understood. Would be ok to get it into the next release (assuming this > is how it gets some test exposure - apologies for not being familiar > with the SeaBIOS release process) or would you be opposed to the > change at all? I'm not opposed to the change - just wary of pushing it out into a release in under a week. > Another hypothetical alternative would be to try to find an API > invocation pattern reasonably unique to Windows that would trigger the > new behavior, to minimize the risk. That sounds complex. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On 10/19/16 15:16, Ladi Prosek wrote:
> On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor wrote:
>> On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote:
>>> On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek wrote:
On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor wrote:
> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
>> of death rendering logic which prevents it from generating crash dumps.
>>
>> The bug does not manifest if Windows sees a suitable 32 bpp video mode
>> before a suitable 24 bpp video mode in the list of modes returned from
>> vgabios. This commit moves all 32 bpp modes to the front of the list to
>> make sure that this is always the case.
>>
>> Signed-off-by: Ladi Prosek
>> ---
>> vgasrc/bochsvga.c | 39 ---
>> 1 file changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
>> index ec5d101..c5d1511 100644
>> --- a/vgasrc/bochsvga.c
>> +++ b/vgasrc/bochsvga.c
>> @@ -28,6 +28,25 @@ static struct bochsvga_mode
>> u16 mode;
>> struct vgamode_s info;
>> } bochsvga_modes[] VAR16 = {
>> +/* 32 bpp BOCHS modes */
>> +{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
>> /* standard modes */
>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } },
>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } },
>> @@ -56,50 +75,32 @@ static struct bochsvga_mode
>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
>> -/* BOCHS modes */
>> -{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>> +/* 8, 15, 16, and 24 bpp BOCHS modes */
>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } },
>> -{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>
> Thanks. Instead of moving all of the 32bit modes to the top of the
> list, can the 32bit modes be kept next to the other modes with the
> same resolution, just above the 24bpp mode?
Yes, that would work too. As long as 32 bpp come before 24 bpp for the
same resolution, it will be fine.
> Also, all of the mode numbers above 0x11b are arbitrary, so it would
> be preferable to renumber the mode numbers as lines are moved.
Will do.
> We were about to make a SeaBIOS release - does this need to go into
> that release?
It would be highly desired as the problematic Windows builds have
already RTM'ed.
I'll send a v2 with the changes as suggested above.
>>>
>>> Actually, I spoke too soon. The problematic 24 bpp mode that Windows
>>> picks right now is 118 and that's within the standard range so I can't
>>> move 144 above it and renumber. What would be considered safer,
>>> keeping the same mode numbers or partially renumbering to keep them
>>> monotonically increasing except for the standard range?
>>
>> I wouldn't renumber anything at 0x11B or below - those are defined in
>> the vbe3 spec. Ordering and the numbering of all the other modes can
>> be changed. Despi
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor wrote:
> On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote:
>> On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek wrote:
>> > On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor wrote:
>> >> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
>> >>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
>> >>> of death rendering logic which prevents it from generating crash dumps.
>> >>>
>> >>> The bug does not manifest if Windows sees a suitable 32 bpp video mode
>> >>> before a suitable 24 bpp video mode in the list of modes returned from
>> >>> vgabios. This commit moves all 32 bpp modes to the front of the list to
>> >>> make sure that this is always the case.
>> >>>
>> >>> Signed-off-by: Ladi Prosek
>> >>> ---
>> >>> vgasrc/bochsvga.c | 39 ---
>> >>> 1 file changed, 20 insertions(+), 19 deletions(-)
>> >>>
>> >>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
>> >>> index ec5d101..c5d1511 100644
>> >>> --- a/vgasrc/bochsvga.c
>> >>> +++ b/vgasrc/bochsvga.c
>> >>> @@ -28,6 +28,25 @@ static struct bochsvga_mode
>> >>> u16 mode;
>> >>> struct vgamode_s info;
>> >>> } bochsvga_modes[] VAR16 = {
>> >>> +/* 32 bpp BOCHS modes */
>> >>> +{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
>> >>> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
>> >>> /* standard modes */
>> >>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } },
>> >>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } },
>> >>> @@ -56,50 +75,32 @@ static struct bochsvga_mode
>> >>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
>> >>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
>> >>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
>> >>> -/* BOCHS modes */
>> >>> -{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>> >>> -{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>> >>> -{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>> >>> -{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>> >>> -{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>> >>> -{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>> >>> +/* 8, 15, 16, and 24 bpp BOCHS modes */
>> >>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } },
>> >>> -{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>> >>
>> >> Thanks. Instead of moving all of the 32bit modes to the top of the
>> >> list, can the 32bit modes be kept next to the other modes with the
>> >> same resolution, just above the 24bpp mode?
>> >
>> > Yes, that would work too. As long as 32 bpp come before 24 bpp for the
>> > same resolution, it will be fine.
>> >
>> >> Also, all of the mode numbers above 0x11b are arbitrary, so it would
>> >> be preferable to renumber the mode numbers as lines are moved.
>> >
>> > Will do.
>> >
>> >> We were about to make a SeaBIOS release - does this need to go into
>> >> that release?
>> >
>> > It would be highly desired as the problematic Windows builds have
>> > already RTM'ed.
>> >
>> > I'll send a v2 with the changes as suggested above.
>>
>> Actually, I spoke too soon. The problematic 24 bpp mode that Windows
>> picks right now is 118 and that's within the standard range so I can't
>> move 144 above it and renumber. What would be considered safer,
>> keeping the same mode numbers or partially renumbering to keep them
>> monotonically increasing except for the standard range?
>
> I wouldn't renumber anything at 0x11B or below - those are defined in
> the vbe3 spec. Ordering and the numbering of all the other modes can
> be changed. Despite the comment in the source, modes 0x11C-0x11F do
>
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote:
> On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek wrote:
> > On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor wrote:
> >> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
> >>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
> >>> of death rendering logic which prevents it from generating crash dumps.
> >>>
> >>> The bug does not manifest if Windows sees a suitable 32 bpp video mode
> >>> before a suitable 24 bpp video mode in the list of modes returned from
> >>> vgabios. This commit moves all 32 bpp modes to the front of the list to
> >>> make sure that this is always the case.
> >>>
> >>> Signed-off-by: Ladi Prosek
> >>> ---
> >>> vgasrc/bochsvga.c | 39 ---
> >>> 1 file changed, 20 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
> >>> index ec5d101..c5d1511 100644
> >>> --- a/vgasrc/bochsvga.c
> >>> +++ b/vgasrc/bochsvga.c
> >>> @@ -28,6 +28,25 @@ static struct bochsvga_mode
> >>> u16 mode;
> >>> struct vgamode_s info;
> >>> } bochsvga_modes[] VAR16 = {
> >>> +/* 32 bpp BOCHS modes */
> >>> +{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
> >>> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> >>> /* standard modes */
> >>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } },
> >>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } },
> >>> @@ -56,50 +75,32 @@ static struct bochsvga_mode
> >>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
> >>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
> >>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
> >>> -/* BOCHS modes */
> >>> -{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
> >>> -{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
> >>> -{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
> >>> -{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
> >>> -{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
> >>> -{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
> >>> +/* 8, 15, 16, and 24 bpp BOCHS modes */
> >>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } },
> >>> -{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
> >>
> >> Thanks. Instead of moving all of the 32bit modes to the top of the
> >> list, can the 32bit modes be kept next to the other modes with the
> >> same resolution, just above the 24bpp mode?
> >
> > Yes, that would work too. As long as 32 bpp come before 24 bpp for the
> > same resolution, it will be fine.
> >
> >> Also, all of the mode numbers above 0x11b are arbitrary, so it would
> >> be preferable to renumber the mode numbers as lines are moved.
> >
> > Will do.
> >
> >> We were about to make a SeaBIOS release - does this need to go into
> >> that release?
> >
> > It would be highly desired as the problematic Windows builds have
> > already RTM'ed.
> >
> > I'll send a v2 with the changes as suggested above.
>
> Actually, I spoke too soon. The problematic 24 bpp mode that Windows
> picks right now is 118 and that's within the standard range so I can't
> move 144 above it and renumber. What would be considered safer,
> keeping the same mode numbers or partially renumbering to keep them
> monotonically increasing except for the standard range?
I wouldn't renumber anything at 0x11B or below - those are defined in
the vbe3 spec. Ordering and the numbering of all the other modes can
be changed. Despite the comment in the source, modes 0x11C-0x11F do
not appear to be standard modes.
Thinking on this further, there's a good chance other systems (in
addition to Windows) choose the first valid mode fo
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek wrote:
> On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor wrote:
>> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
>>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
>>> of death rendering logic which prevents it from generating crash dumps.
>>>
>>> The bug does not manifest if Windows sees a suitable 32 bpp video mode
>>> before a suitable 24 bpp video mode in the list of modes returned from
>>> vgabios. This commit moves all 32 bpp modes to the front of the list to
>>> make sure that this is always the case.
>>>
>>> Signed-off-by: Ladi Prosek
>>> ---
>>> vgasrc/bochsvga.c | 39 ---
>>> 1 file changed, 20 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
>>> index ec5d101..c5d1511 100644
>>> --- a/vgasrc/bochsvga.c
>>> +++ b/vgasrc/bochsvga.c
>>> @@ -28,6 +28,25 @@ static struct bochsvga_mode
>>> u16 mode;
>>> struct vgamode_s info;
>>> } bochsvga_modes[] VAR16 = {
>>> +/* 32 bpp BOCHS modes */
>>> +{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
>>> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
>>> /* standard modes */
>>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } },
>>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } },
>>> @@ -56,50 +75,32 @@ static struct bochsvga_mode
>>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
>>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
>>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
>>> -/* BOCHS modes */
>>> -{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>>> -{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>>> -{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>>> -{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>>> -{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>>> -{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>>> +/* 8, 15, 16, and 24 bpp BOCHS modes */
>>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } },
>>> -{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>>
>> Thanks. Instead of moving all of the 32bit modes to the top of the
>> list, can the 32bit modes be kept next to the other modes with the
>> same resolution, just above the 24bpp mode?
>
> Yes, that would work too. As long as 32 bpp come before 24 bpp for the
> same resolution, it will be fine.
>
>> Also, all of the mode numbers above 0x11b are arbitrary, so it would
>> be preferable to renumber the mode numbers as lines are moved.
>
> Will do.
>
>> We were about to make a SeaBIOS release - does this need to go into
>> that release?
>
> It would be highly desired as the problematic Windows builds have
> already RTM'ed.
>
> I'll send a v2 with the changes as suggested above.
Actually, I spoke too soon. The problematic 24 bpp mode that Windows
picks right now is 118 and that's within the standard range so I can't
move 144 above it and renumber. What would be considered safer,
keeping the same mode numbers or partially renumbering to keep them
monotonically increasing except for the standard range?
> Thanks!
> Ladi
___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor wrote:
> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
>> of death rendering logic which prevents it from generating crash dumps.
>>
>> The bug does not manifest if Windows sees a suitable 32 bpp video mode
>> before a suitable 24 bpp video mode in the list of modes returned from
>> vgabios. This commit moves all 32 bpp modes to the front of the list to
>> make sure that this is always the case.
>>
>> Signed-off-by: Ladi Prosek
>> ---
>> vgasrc/bochsvga.c | 39 ---
>> 1 file changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
>> index ec5d101..c5d1511 100644
>> --- a/vgasrc/bochsvga.c
>> +++ b/vgasrc/bochsvga.c
>> @@ -28,6 +28,25 @@ static struct bochsvga_mode
>> u16 mode;
>> struct vgamode_s info;
>> } bochsvga_modes[] VAR16 = {
>> +/* 32 bpp BOCHS modes */
>> +{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
>> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
>> /* standard modes */
>> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } },
>> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } },
>> @@ -56,50 +75,32 @@ static struct bochsvga_mode
>> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
>> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
>> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
>> -/* BOCHS modes */
>> -{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
>> -{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>> +/* 8, 15, 16, and 24 bpp BOCHS modes */
>> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } },
>> -{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>
> Thanks. Instead of moving all of the 32bit modes to the top of the
> list, can the 32bit modes be kept next to the other modes with the
> same resolution, just above the 24bpp mode?
Yes, that would work too. As long as 32 bpp come before 24 bpp for the
same resolution, it will be fine.
> Also, all of the mode numbers above 0x11b are arbitrary, so it would
> be preferable to renumber the mode numbers as lines are moved.
Will do.
> We were about to make a SeaBIOS release - does this need to go into
> that release?
It would be highly desired as the problematic Windows builds have
already RTM'ed.
I'll send a v2 with the changes as suggested above.
Thanks!
Ladi
___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug
On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
> of death rendering logic which prevents it from generating crash dumps.
>
> The bug does not manifest if Windows sees a suitable 32 bpp video mode
> before a suitable 24 bpp video mode in the list of modes returned from
> vgabios. This commit moves all 32 bpp modes to the front of the list to
> make sure that this is always the case.
>
> Signed-off-by: Ladi Prosek
> ---
> vgasrc/bochsvga.c | 39 ---
> 1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
> index ec5d101..c5d1511 100644
> --- a/vgasrc/bochsvga.c
> +++ b/vgasrc/bochsvga.c
> @@ -28,6 +28,25 @@ static struct bochsvga_mode
> u16 mode;
> struct vgamode_s info;
> } bochsvga_modes[] VAR16 = {
> +/* 32 bpp BOCHS modes */
> +{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
> +{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
> +{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
> +{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
> +{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
> +{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
> +{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
> +{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
> +{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
> +{ 0x17d, { MM_DIRECT, 1280, 960, 32, 8, 16, SEG_GRAPH } },
> +{ 0x180, { MM_DIRECT, 1440, 900, 32, 8, 16, SEG_GRAPH } },
> +{ 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
> +{ 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
> +{ 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
> +{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
> +{ 0x18f, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> /* standard modes */
> { 0x100, { MM_PACKED, 640, 400, 8, 8, 16, SEG_GRAPH } },
> { 0x101, { MM_PACKED, 640, 480, 8, 8, 16, SEG_GRAPH } },
> @@ -56,50 +75,32 @@ static struct bochsvga_mode
> { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
> { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
> { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
> -/* BOCHS modes */
> -{ 0x140, { MM_DIRECT, 320, 200, 32, 8, 16, SEG_GRAPH } },
> -{ 0x141, { MM_DIRECT, 640, 400, 32, 8, 16, SEG_GRAPH } },
> -{ 0x142, { MM_DIRECT, 640, 480, 32, 8, 16, SEG_GRAPH } },
> -{ 0x143, { MM_DIRECT, 800, 600, 32, 8, 16, SEG_GRAPH } },
> -{ 0x144, { MM_DIRECT, 1024, 768, 32, 8, 16, SEG_GRAPH } },
> -{ 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
> +/* 8, 15, 16, and 24 bpp BOCHS modes */
> { 0x146, { MM_PACKED, 320, 200, 8, 8, 16, SEG_GRAPH } },
> -{ 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
Thanks. Instead of moving all of the 32bit modes to the top of the
list, can the 32bit modes be kept next to the other modes with the
same resolution, just above the 24bpp mode?
Also, all of the mode numbers above 0x11b are arbitrary, so it would
be preferable to renumber the mode numbers as lines are moved.
We were about to make a SeaBIOS release - does this need to go into
that release?
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://www.coreboot.org/mailman/listinfo/seabios
