Date: Sat, 27 Jun 1998 20:26:24 -0700 From: Mike Smith <mike@smith.net.au> To: Matthew Thyer <thyerm@camtech.net.au> Cc: Matthew Thyer <Matthew.Thyer@dsto.defence.gov.au>, Terry Lambert <tlambert@primenet.com>, Jonathan Lemon <jlemon@americantv.com>, current@FreeBSD.ORG Subject: Re: 'fatal trap 12' on boot (smp and up) Message-ID: <199806280326.UAA16965@antipodes.cdrom.com> In-Reply-To: Your message of "Sun, 28 Jun 1998 11:09:45 %2B0930." <35959EE1.197BE9D5@camtech.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> I dont know where you lost track of the logic Mike. I haven't lost track of any logic anywhere. You say "you can't boot FreeBSD from inside Windows, or having run Windows". I say "so what?". This isn't our problem; it's either yours or Microsoft's, depending on how you look at it. Windows provides an environment for Windows applications. FreeBSD is not a Windows application. > I'll type it slower this time: Thanks for the condescention. As you may have missed me saying, I know all about this because _I've_been_testing_it_. As you may have noticed several people pointing out, starting FreeBSD from within the DOS environment is not generally supported, and we document this fact copiously. We support the standard PC boot environment, as documented in the Phoenix/Compaq/Intel BIOS Boot Standard 1.0(1994 with amendments). We support booting via the 'netboot' program which is loaded from an EPROM on a network card (in compliance with the original PC/AT BIOS documentation). Work is underway to support the new PXE (Preeboot eXecution Environment) standard, which provides an open standard for network workstation bootstraps. We also support the El Torito CDROM bootstram environment, which is a superset of the BBS mentioned above. We do our best, where possible, to work around bugs in the common implementations of the above environments. > 1) Win95 restart to MS-DOS results in DOS with modified vectors. > 2) Win98 restart to MS-DOS results in DOS with modified vectors. > 3) Win98 "command line only" boot results in DOS with modified vectors. > 4) It's possible that a boot of a DOS floppy made on future versions > of Microsoft products will result in DOS with modified vectors. Like I said before, "so what?". FreeBSD is an operating system; you boot it like any other operating system - using a bootstrap loaded by the BIOS. If you choose to corrupt your system first, that's your own fault, and you shouldn't expect anything other than an application designed for that environment to function under those circumstances. Just for whatever it's worth, Windows also corrupts the vectors for a wide range of other critical services, none of which we can afford to "just optionally" support. > STOP PRESS > --- I have just confirmed that you CAN use fbsdboot.exe from a > bootable floppy made with Windows 98. i.e. the vectors in > question are NOT modified. No shit. In case you missed me saying it in this message, as well as in the last one, I HAVE BEEN TESTING THIS. WE KNOW ABOUT IT. > Conclusion) FreeBSD should not be relying on these vectors being > unmodified. Particularly when the broken code in question is going to > become mandatory. Attempting to come to "conclusions" when it's clear you're not in possession of the facts, have not tried to obtain the facts yourself, and have ignored them when they are thrust in your face really doesn't do anything for your cause. Operating systems (clue #1: FreeBSD is an _operating_system_) on the PC* platform expect to be able access certain BIOS-related services. These services are obtained using a couple of techniques; the first is signature searches through the ROM space, and these are normally uncorruptible (although I bet that Microsoft would if they could). The second, and more common for older standards, is through vectors stored in low memory. These services are *mandatory* (clue #2: 'mandatory' means that we can't work without them) in order to support required functionality for the system; examples include ESCD, APM, ACPI, DMI, PnP, etc. If these vectors are corrupted (clue #3: it is not possible to determine what is 'corrupted' on a given system), you cannot expect the operating system to function correctly; if you are attempting to boot an operating system when these vectors have been corrupted, you are effectively booting a faulty system. If Windows corrupts these vectors, it means that it is not possible to start another PC*-compliant operating system from within Windows. End of story. > When I say "floppies have been formatted with Windows 98" I obviously > mean "formatted to be bootable." since I was replying to your > suggestion of "boot from a floppy". Dont try to cloud the issue by > stating the obvious "the formatter doesn't matter a damn". There was nothing "obvious" about your misunderstanding. Since we are talking about booting FreeBSD, I was attempting to make it painfully clear that I meant a FreeBSD boot floppy. I have yet to see any point where you have suggested that this is not a viable option. Note that you subsequently "discovered" that a bare DOS 8.0 boot floppy doesn't clobber these vectors either. > I know personal attack is your style Mike but it's not helpful. Is it? Where am I "personally attacking" you? If I tell you that you left your clothes behind this morning is that a "personal attack", or is it simply pointing out that you're a bit chilly? > All I'm saying is we should think twice before making "options VM86" > mandatory while it still contains broken code. It's not broken. Read the documentation; there are *reams* of it, and they all *require* the vectors to be intact. Start with: http://www.acpi.org/ http://www.dmtf.org/ http://www.microsoft.com/hwdev for just a few samples. Then try the Smart Battery people, Intel, and how could I forget Ralf Brown? The list is voluminous, and most of it freely available for your edification. Have you studied it? > If we are going down this path, it should be documented that certain > uses of fbsdboot.exe are no longer supported. Fbsdboot.exe was a quick hack when it was released; even then it didn't work properly on the majority of configured systems. It's likely that it will not survive into the 3.x family. > Again Mike, I take offense to your personal attacks. You'd make a > lot more friends if you change your style. You're imagining things. I don't know who or what has suggested to you that anything I've said is a "personal attack", but you are sadly misinformed. As to whether I would care to change my style just to pick up "friends", I hardly think that's something you're in any position to judge. If you're trying to slur me in front of either of the other recipients of this message, I hope they have the sense to ignore the insult. Consider this; I have more work on my plate than I can reasonably handle. Thus, I am primarily interested in pursuing issues which yield worthwhile results. Pointless attempts to educate people that have previously demonstrated that they don't want to learn rarely yield results. I've attempted to point out to you that a) the problem you're whining about isn't our problem, and b) it's not really a problem at all, other than that it demonstrates that a certain software component (fbsdboot) is inadequate for the situation. In a desperate attempt to actually achieve something useful out of this discussion, and if you're interested in helping rather than whining, here's a (relatively simple) task for you. Write a small program which captures the vector set very shortly after DOS is loaded; you will have to work out how Windows boots to do this. You may benefit from an MSDN subscription for this; I am not at liberty (nor do I have the time) to make disclosure from ours for you. Save the vector state into a file. Modify fbsdboot to load this file and restore the original vector state before invoking the FreeBSD kernel. Note that this requires you to install the program and then restart Windows - most Windows users are prettymuch used to this though, so it's not a problem. (Of course, if you're going to reboot anyway, you can just reboot from either the CDROM or a floppy, which kind of negates the usefulness of the whole issue, hmm?) There are a few other things you need to do as well, though. You need to teach fbsdboot about XMS; it should allocate a slab big enough for the kernel, load the kernel into *that*, and then copy the kernel down to the load address after it's no longer going to use the filesystem. This is necessary because XMS is often used for disk cache; if you start loading the kernel at the normal load address, you plaster the cache and/ or other important bits of the system (eg. DOS in the HMA). You also need to teach it about how to get out of vm86 mode when something like EMM386 or QEMM is running, because it doesn't work properly there either. If you want to consider this in the framework of the bootstrap for 3.0, you might want to start with the NetBSD bootstrap code, and then my (substantial) rework of it at http://www.freebsd.org/~msmith/boot. In particular, you'll need to modify the startup for 'dosboot' to make it boot under DOS, then deal with the vector restoration problem using eg. the solution above, and then integrate that into the mainline. I would be very happy to see diffs for this. And one more time, before you respond again, please consider carefully what I mean when I say: FreeBSD is an operating system. FreeBSD is not a Windows application. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806280326.UAA16965>