I would be happy to try anything to get Parallels working (under Windows or preferably Mac) with any form of SLIC injector (not that I need it, just like meddling) sebus
I have modified a Pro1000 MT but my Windows 2008 Server installation crashes when the server is set to boot from the card. The server uses an Intel Server motherboard and I know the Pro1000 is programmed correctly as I have tested it in a PC with Windows 7' The crash happens after the inital part of the OS loads as it offers the opportunity to boot into safe mode etc. It is only after that point that the server crashes (no error just reboots). Any suggestions? Thanks, Tom
WindSLIC is currently being re-written to get rid of the Int15H handler, which should fix a lot of stuff. I'll see if I can also create a floppy-disk-image-creator version of it. That should work theoretically. It should at least be testable in non-Parallels (VMWare/QEMU/VirtualBox) environments, though you'll have to do the actual Parallels testing, of course. -tij-
I have now read through the entire thread Before I pop out and go get myself a life, can I just ask if the problem with >4GB of memory was fixed as I can see a post from truthinjection about the problem but couldn't find a post that said it was fixed (I have 16GB memory).
It hasn't been addressed, but I'm not actually sure if it is a real problem or simply a theoretical one. I've never actually seen an E820 map from a machine with more than 4GB of memory. Also, with the hopeful removal of the Int15H handler in the near future (I'm still not sure if putting everything into the EBDA is a good idea or not), it wouldn't be a problem any longer, either. It's a long thread. Congratulations on reading through it. When I get a new version I'm happy with, I'm thinking I'll start a new thread so that all the latest-news will be on the first page of the thread, so a lot of the read-the-whole-thread can be minimized. -tij-
It's a bit tedious but you can pick up some useful tips and a better understanding of a product if you wade through it all. That said, there is a thread in another forum that I have followed from the start that is now up to 4700 posts - not sure I would go through all that if I was new to the subject!! Any suggestions what I should do about my specific problem (post #528)? Or is it a case of wait for the version without the Int15H handler to see if that works? Thanks, Tom
Well, I have created a version of WindSLIC that uses the EBDA instead of the Int15H mechanism. It seems to work fine, except that I just realized that other things could theoretically move the EBDA, which would break WindSLIC if it happens. I'm not sure if anything much out there does move the EBDA, so it might be a non-issue. If I eventually make a PCI Firmware 3.0 version, it would use PMM to get a static memory allocation instead, so the EBDA would be the fallback in that situation anyway. I'm not sure whether to post the EBDA-using version I have now, or work on a PCI-FW 3.0 version and post that when it's done instead. If I made a PCI-FW 3.0 version, it would only work on PCI-FW 3.0 capable machines unless I included the EBDA fallback. Right now I don't have a great way to explain to users how to figure out what PCI-FW version their PC supports, though. Frustration, -tij-
Can I suggest that you should make the EBDA version available to get some feedback on it before you complicate things by bringing out version 3 with two different methods. Of course this has nothing to do with the fact that I haven't got a working solution and I'd like to give the EBDA version a go
I've been working on it pretty steadily lately. I made a non-Int15H version, but then I realized that although I could allocate the EBDA area successfully, other things could *also* allocate (move) it, which would leave the ACPI tables in a bad/wrong state, which would just be asking for trouble. I might still use that code to store the various housekeeping info that currently resides in stolen Interrupt Descriptor Table entries, since it would be safer (although I am not aware of anything that really conflicts with our current usage of those, so it's low priority). So, that left me with either writing a PCI 3.0 version or fixing the Int15H version. I was all set to try to write a PCI 3.0 version, since that would fun/new/clever/etc., but then I discovered that neither QEMU or VMWare (Workstation v7.0.1) claim to support PCI 3.0, so although most new 'real' machines would benefit, it would be pesky to test. Parenthetically, I do whatever development testing I can on QEMU, falling back to VMWare only if there's something I can't test in QEMU. So, I've been fixing the Int15H handler. It wasn't written very well, to be frank. I've got a new version that seems much cleaner. I've learned a ton since I first wrote it, so that's good. What I've learned there is that using the frame pointer (EBP) is your friend when you have to do goofy caller's flag-manipulation tricks (which the Int15H E820h calls have to do to alter the caller's Carry Flag). The v2010.02.04 code was too difficult to use to determine the flaw that screwed up XP booting, so I abandoned it and rolled back to the v2010.01.20 code as the basis. Since it was the last version that worked to boot WinXP for me,I've been having to re-add a lot of (presumably) 'good' changes that happened after that time. I'm also trying to go slower and test XP after every change, so I can avoid breaking that and not knowing when/why this time. As for the Floppy / (Parallels-usable) version, I've made a start on that (basically using the same 'wrapper' method that I made for the wscomfil.asm DOS COM file version of WindSLIC). Unfortunately, unlike the normal "ROM" method, the BIOS doesn't load the entire WindSLIC into memory when booting from a floppy, so I'm going to have to code an actual boot-sector/boot-loader that loads WindSLIC from an Int13H disk. There's Floppy "Toy"-level "Write your own OS!" assembly code, so I don't see/anticipate any real special difficulty writing that once I get WindSLIC itself back to fighting shape. I can't think of any reason why I'd have to implement any FAT-reading mess on the floppy image, just have the boot-sector load the next sectors into the proper memory location and transfer control there to get it going. Gonna need a montage... -tij-
With PXE on Disk Which option should the windslic.bin be? I tried with 1 - 2 - 6 and 1- 2 - 7, can see WS loading, but it does now show in RW 1.47 sebus
I haven't tried the PXE on Disk program, but that seems like the right two things to try, just from the naming of them. Not sure about the whole 'List of Lists' concept though. As for seeing WindSLIC, Do you see both halves of WindSLIC loading (INIT and BEV) ? Lots of times I forget that the INIT part (Press F5 to skip) doesn't do anything at all without the later PXE/BEV "WindSLIC has to be first in the Boot Order" part. WindSLIC's second-half disappearing from the boot order (for example, it often gets removed by the VM BIOSes after a code-change that the BIOS interprets as it being a 'different' bootable-device like: if, for example, you change the name 'WindSLIC' to something else) gets me all the time, and then later people point out that XP isn't working. -tij-
Yeah, the v2010.02.04 *_ivt_* code didn't do a good job protecting the state of the flags across calls to it, which could have something to do with why the new _ivt_ stuff made the problem a lot worse even if the int handler itself wasn't changed. I definitely found a bug or ten with the Int15H handler itself as it has been written. I think my new unreleased version is a lot cleaner, and it's definitely a bit better documented where/what it's doing and why. Time will tell, I suppose -tij-
It seems that it is only the INIT part that gets loaded. Then there is a message that there is no OS & it carries on booting from HD Do you mean to change WindSLIC to something else? sebus
Hm. Do you see any settings that would cause it to both load WindSLIC (which it appears to be doing) and also execute the BEV (which is apparently isn't doing)? I meant change the text declaration of the name "WindSLIC" in the WindSLIC source. It was just an example of how you can set a BIOS to boot from WindSLIC first, only to have that setting silently dumped when you, for example, load a version of WindSLIC that doesn't identify itself with the Code: PnPIC_Prod_STR db "WindSLIC",00h line in the source. The BIOS thinks you've pulled out the one NIC and replaced it with a different NIC, and thus the BIOS removes the BBS entry from the nvram. VMWare and physical PCs do this. That's just the example I run into most often during testing. I usually just look to see that WindSLIC flickers by during boot, but if something is not working, I've learned to slow down and make sure part 2 is loaded. Someday, I will make an Int13H hook that lets WindSLIC not have to use the BEV, and instead use the BCV, and hopefully that will make it much harder to "lose". New release coming soon, -tij-