"Unsupported Data Configuration" error on first WIN launch issue, continued.

[lss4]

I originally posted about this in #20 but considering my issue is different I'm putting it here. For now the problem is not critical but it seems to suggest some problems during driver initialization that only manifest under certain circumstances.

As of the latest version at the time of writing (0.2.3) things appear improved a bit as I found my system can succeed booting to Windows on first WIN launch in most cases, with only a few situations that can still trigger it.

• Calmira (I'm using XP 4.0 beta) has the ability to directly reboot the computer without exiting to DOS, and it seems if I rebooted my system this way, on next WIN launch I'll 100% get this "Unsupported Data Configuration" error, and the message will not happen on next WIN launch.
• During Windows startup, if the "Unsupported Data Configuration" error does not occur, the driver may occasionally hang, and the system has to be rebooted or powered off manually via buttons when it happens. In that case the next WIN launch will also almost certainly trigger the error, and the next WIN launch will either hang (which will again lead to the error message on next launch), or succeed.

Note that if I use "Exit Windows" to return to DOS, and reboot/shutdown the system from there, the error will not occur on next WIN launch. Tried this several times ("Exit Windows" then rebooted/shut down the system using various means), and none triggered the error message.

Maybe the error happens whenever the system was not shut down cleanly? If so, it seems Calmira's "Reboot Computer" logic was done in a dirty way.

[PluMGMK]

Maybe it's worth trying v0.2.4, in which I removed some int 3 instructions? They should be harmless but I found that they seem to cause Windows to hang under VMware when there is no debugger attached… Maybe they can cause craziness in some other no-debugger-attached situations?

As for Calmira, I looked at the source code, and it looks like it just calls ExitWindows to reboot the machine, so it is Windows itself which is responsible for dirty reboots…

[lss4]

Just tested 0.2.4 and it seems to have mitigated the hang issues. Turned out my system can use PMIDcheck=sanity just fine.

The "Unsupported Data Configuration" error still happens like usual, though.

[PluMGMK]

OK that's interesting. So even if it's using the protected-mode interface, the error occurs. (Of course, it's also possible that there is no protected-mode interface, and there was some other moving part in the driver that was hanging upon discovering that fact…)

Remind me what card / firmware this is with?

[lss4]

I'm using an AMD FirePro W4100 (Cape Verde), actually.

My current video card and monitor setup can output 1080p using VBE drivers just fine, be it yours (Win3.x), VBEMP (NT 3.51, also Win9x), as well as vga.sys (the basic driver from newer Windows since XP).

For Win3.x, the default, 16-color VGA driver works fine, but the patched SVGA driver appears distorted, such as showing a lot of black vertical bars over white backgrounds. With your driver, all 8/16/24bpp modes work fine, just that with 8bpp modes things are shown in wrong colors, possibly #14. 8bpp colors were correct on patched SVGA driver despite other issues, however.

I originally started testing your driver (0.1.1) with PMIDcheck=sanity but wasn't successful (hung) so I thought I should use PMIDcheck=disable. However, as of your current builds, it seems Windows can start with protected-mode interface enabled. I briefly tested PMIDcheck=none with 0.2.3 and it worked, and it also works using PMIDcheck=sanity with 0.2.4.

Though I don't think the state of PMIDcheck is related to this "Unsupported Data Configuration" error. I wonder what might have triggered the issue in case of a "dirty" state like rebooting while hung, as well as using Calmira's "Reboot Computer"...

[PluMGMK]

Would it be worth my while adding a function that takes a checksum of the graphics firmware (i.e. segment C000h)? I could print the checksum on failure and save it to a file on success, and then you could check if there's a difference. I know firmware shouldn't change but there might be something funny in the way your BIOS shadows it into RAM...

[lss4]

Just grepped the code and to my surprise, I could not find any mention of this "Unsupported Data Configuration" error.

I'm not sure, maybe either the error message is not stored in code as plaintext, or this message comes from a certain standard error code with which the driver aborted under the circumstances.

Knowing all possibilities that would lead to that error message may be helpful in looking for the most likely causes...

[PluMGMK]

Aaaahhh sorry, I didn't pay sufficient attention to the issue title! I thought this was the same "unsuitable settings" message as #20

It looks like "ERROR: Unsupported data configuration." is a string in WIN386.EXE. So the problem is more likely to be in VDDVBE.386 than VBESVGA.DRV – my gut tells me somewhere in the Real Mode init code… I'll have a ferret around…

[lss4]

A little update on behaviors as of 0.2.6. While this error still persists (as nothing changed on VDDVBE.386 side yet), there are something worth noting.

• Windows logo now shows only for a brief moment then the screen turns completely black until entering desktop, or the error message in question (everything else is good and no significant difference or regression). The new message in #20 said about LCD showing burnout but I'm not sure if this is the same thing underneath.
• 8bpp colors are still in wrong colors on my system with no difference from before, so my issue regarding that is different from Palette not set correctly when using 8-bit output under QEMU #14 and more like something to do with the hardware (e.g. VGA BIOS).

[PluMGMK]

• Windows logo now shows only for a brief moment then the screen turns completely black until entering desktop, or the error message in question (everything else is good and no significant difference or regression). The new message in #20 said about LCD showing burnout but I'm not sure if this is the same thing underneath.

This may be due to some of my experiments for #10 – at one stage I added -DIBMXGA to my Makefile without pushing the changes to the repo, which enabled some more detection code in the published VDDVBE.386. This may or may not be the reason, but either way I should have been more careful with the binaries I pushed!

• 8bpp colors are still in wrong colors on my system with no difference from before, so my issue regarding that is different from Palette not set correctly when using 8-bit output under QEMU #14 and more like something to do with the hardware (e.g. VGA BIOS).

Does this change depending on the dacdepth setting? Or is it a case of blues and reds being swapped? If the latter, then it seems some firmware swaps them while other firmware doesn't, in which case this is gonna be a nightmare…

As for the error message itself, I still need to poke around in how WIN386 works and will report back if I come up with any insight…

[PluMGMK]

So apparently this cryptic error message arises when a DOS driver or TSR requests instance data that extends beyond the first megabyte of address space, in its response to int 2Fh 1605h. It seems whatever dirty state the firmware is left in following a Windows-triggered reboot is causing this to happen on your system, though I have trouble imagining how…

[lss4]

So apparently this cryptic error message arises when a DOS driver or TSR requests instance data that extends beyond the first megabyte of address space, in its response to int 2Fh 1605h. It seems whatever dirty state the firmware is left in following a Windows-triggered reboot is causing this to happen on your system, though I have trouble imagining how…

Actually, I'm running Win3.x from a FAT32 partition with the help of a patched Win98SE IO.SYS as well as a patched WIN386.EXE (for addressing issues that may arise with FAT32). It's called 3xStart/OSR2FIX which can be found online.

The boot option I set up for starting Win3.x has very few other TSRs, and for better compatibility I'm using strictly Win3.x's HIMEM, IFSHLP and SMARTDRV (for both cache and double buffering). Other than this not-so-critical issue everything works good.

Guess this is not going to be easy to diagnose. I'm not an expert about virtual memory though I do have suspicion that something stored in the swap file (WIN386.SWP) may be triggering this, as the state that may or may not trigger this error message appears to persist across cold startups as well as after using another OS on the same system.

[PluMGMK]

So I spent much of today trying to write a tool to call int 2Fh 1605h itself, and print out the instance data to the console, and indicate which ones are invalid. But it seems that this function is incredibly flaky, because depending on what I did in the program, it would hang, return lots of data, or return no data. I have no idea how Windows makes it behave consistently, or else I'm doing something really stupid.

Overall, this seems unlikely to be related to the graphics driver, at least not directly…

EDIT: And when I say "what I did in the program", I don't mean natural things like what register values I passed to the function. I mean random stuff, like doing a Windows installation check beforehand, printing a segment value to the screen, moving around some lines, or running it through DEBUGX. It's some of the strangest behaviour I've ever seen…