Here's the second picture:
Ah yes ... I remember that one well. We had another customer with a similar problem in a different spot in that same BIOS of theirs. Went back and forth with the BSD people for months over those as they wanted it fixed as much as we did. In the end, Toshiba took the stance of "we ONLY support Windows and installation of any other OS violates our warrantee and we will hold the customer accountable for doing it" and they completely refused to cooperate with BSD over it. Supposedly there's something to that effect in their customer literature back then too.
Since then, Toshiba has softened their stance, but they've never fixed the problem as far as I know. I have a note in once again now with my ACPI guys at BSD about that model but haven't heard back from them as yet. Over the years, we've encountered a few obstinate manufacturers and we've been able to work around all of them (including even Broadcom) by generating special builds for those specific machines. However it's not possible in our "generic build" to do so as it requires special code to step over specific BIOS bugs which would cause the generic KNOS not to function properly on other machines.
So let me put on my "geek hat" and explain the technicals first, since other folks will be reading this and know the technical aspects of it all - this will help them to understand what "our" malfunction might be here ...
The problem is the result of Toshiba using a single BIOS design for many different models, and those machines that don't have those specific features are loaded with specific custom OEM builds of Windows with code to not even query those "dead zones" when they install Windows at the factory. The way Windows works, BIOS hardware location internals are only used for installation, they're never queried again once Windows has been installed since the hardware drivers are separately installed and called from the hard disk by using the Windows registry to point to where the devices are instead of using BIOS. And those locations can be hard-coded into the registry without ever tickling the tiger to begin with at the factory.
Therefore, no need to fix BIOS errors as far as device detection goes since that's only done once at the time of installation. KNOS (and BSD) however, have to query BIOS every time it's booted since we don't "believe" in BIOS and need to access hardware itself instead of trusting BIOS. By talking directly to the hardware locations, KNOS is able to avoid using any potential embedded malware in BIOS, but situations like this in trying to poll all of the physical addresses for hardware instead of trusting BIOS leads to this unfortunate situation when BIOS itself has serious bugs that Windows will ignore, or the manufacturer can ignore by modifying the Windows OEM kernel drivers to step past those errors.
Unfortunately, we can't. When KNOS boots, we're only interested in "what hardware exists? And where IS it?" Once we are given an address for a device, we ask BIOS to exit that definition, and then we take that address and probe it ourselves. When BIOS is exited, a "pointer" is given to re-enter BIOS for the next device at the next address. We then probe the hardware, find it and then move on to the next device. Defective BIOS will give us an address to look for and if it doesn't exist, then we say "not found" and move on.
However, BIOS may not cycle to its next location and give us the NEXT valid address to probe because it gets hung up in its own inability to find a device as it the case here with that "TV thing" gone missing. So when we say "next!" it then goes and gives us the same bad address over and over again until BSD's boot stuff says "enough of this, I'm stuck in a loop."
Once that happens and there is no more valid information, we give up with a kernel panic. That's what's going on here because BIOS is not releasing and we keep seeing the same bad loop. No point in booting further if all we're seeing is garbage.
There's no way to work around it that I know of other than to create a custom build of KNOS for that specific machine unfortunately in which we know that location is bad, and upon encountering it, not even step in it in the first place. That we have done in the past, but it's a bit costly for us to generate a "one-shot KNOS" for specific hardware. Not a problem when amortized over a corporate build of a few hundred machines, but insane for just one or two pricewise.
I've tweaked some noses about this back at BSD, they did do a raft of changes in their "toshiba_acpi" module that I truly hoped might work, but what's going on there with the fatal trap 12 is a "loop" occurring within BIOS itself that won't exit, even when forced ... that's why the kernel panic.
Give me a couple of days, maybe there's an easy workaround that wasn't in the application notes for that code on the BSD side of the realm ... I still don't want to give up on this one though there's not much I can do without coming up with acustom build.
