On 10/19/16 15:16, Ladi Prosek wrote: > On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor <[email protected]> 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 <[email protected]> wrote: >>>> On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <[email protected]> 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 <[email protected]> >>>>>> --- >>>>>> 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. > > 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. > >> 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? > > 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? Thanks Laszlo _______________________________________________ SeaBIOS mailing list [email protected] https://www.coreboot.org/mailman/listinfo/seabios
