-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AoE support seems to have problems #2
Comments
sigh scratch most of that. I've just wasted a large part of my day...very frustrating. At some point earlier today I tested the original aoe32 driver WinVBlk was based on (to confirm it doesn't work in text mode) - and I disabled the WvBlk32.sys driver whilst doing so...and forgot to re-enable it afterwards. I could have sworn that it didn't error last time I tried the latest revision of of yours, it just didn't seem to do anything. Anyway. Having re-enabled WvBlk32.sys I have returned to the behaviour I was expecting - no debug messages about the AoE code, nothing, just sits there waiting on the SAN disk. I've just reverted back to revision 72ed155 (Date: 22/09/2011 06:39:45), and it too just seems to sit there, but I at least get messages suggesting it's not picking up responses?
...as mentioned above, this works in earlier revisions of the code. I'll have to try and find where this breaks...again. sigh |
I am a bit lost. Is this the log from a GRUB4DOS RAM-disk boot? (Regardless of the presence of an aBFT established by iPXE, before-hand.) |
Yes. Post iPXE, booted from G4D, loaded the ISO into RAM, then booted it. Relevant equivalent bit of log from 2ebc053:
|
Had another poke at it this evening. Still no joy, but thought I'd mention that when I turn on IRP debugging (to see if that shines any light on things) it seems to BSOD. So I left that off. Trace from 7eed6ad:
|
I think you have too many drivers in the mix. If there is a Microsoft iSCSI driver installed in the image, please remove it. If mcb30's sanbootconf driver is in the mix, please remove it. Some of the messages in this log are not from WinVBlock, including those which might be related to hanging the system. |
If you think it will help, I'll certainly do as you ask. Though I should mention, I just tried again (both on VMWare and on a physical machine) with 2ebc053 and had zero problems, iSCSI, SanBootConf, and Firadisk included (abet I disabled G4D detection in WVB to prevent clashing), so I don't think they're a problem. I'll let you know how the stripped-down build turns out... |
Alrighty then, as requested, here's a trace from my build with those other drivers stripped out: ...and for completeness, here's a trace from the working revision with those drivers disabled as well: Looking at the trace of your latest revision, it BSODs because it loses the boot volume, which I suspect is because the WinVBlock driver is being unloaded. This didn't BSOD before as Firadisk was providing the boot volume, but because I've disabled it, WinVBlock unloading becomes fatal as we don't just lose the AoE support, we lose the RAMdisk as well...? Same setup as before: Boot VMWare from iPXE floppy, hook AoE target, follow-through to boot USB disk mapped to a VMware IDE device, use G4D to load ISO into RAM, boot ISO RAMdisk. |
Hello again. This message is not from WinVBlock, meaning that another driver is still present: NIC Boot Configuration Driver finalizing If you would kindly remove that driver, perhaps we'll observe different results. Please use the "stable" WinVBlock from here: http://reboot.pro/topic/8168-winvblock/page-9#entry101308 |
...the stable version works fine (AoE-wise, and with all the other drivers). I'm just trying to help you out with some testing by letting you know your changes since 2ebc053 seem to have broken something that was working previously... Is that stable version you've linked to a checked build with debug messages enabled? |
Ok, threw the stable version into my test build anyway (and disabled the nic boot driver), and I'm not getting any messages now - the system just hangs on the startup (Setup is starting Windows) screen. If I break into the target the stack trace shows it's just in an idle loop. So I've taken the liberty of building a checked version of the revision tagged as 0.0.1.8 with debugging enabled, and to my surprise, it explains the apparent hang - it's just stalling the same as the latest revision. I swear the stable build worked when I tested it in my "normal" setup (before I started any compiling of my own). I'll try it again with the NIC Boot Config driver enabled and see if that "unsticks" it, and I'll try the revision I know works fine normally but without the NIC Boot Config driver to see if removing it causes it to stop working. |
Ok, adding the NIC Boot Config driver back in makes 0.0.1.8 work - no hanging: http://pastebin.com/apMUwrPT It may be of relevance that I should mention the load order I'm using in my txtsetup.sif (I've removed the defaults and left in the disabled drivers to give a bit more context):
...and based upon the information in this post: http://www.msfn.org/board/topic/146541-xp-preventing-a-scsiload-txtsetupsif-entry-from-being-installed/?do=findComment&comment=977050 ...I determine the load order to be:
...which should all be fine? |
I'm afraid that nobody should build WinVBlock from the current master, as it's not expected to be fully working. WinVBlock development is in a transitional period between an older strategy and a newer strategy. Yes, if WinVBlock AoE is boot-enabled but the NIC driver isn't driving the NIC, then the system will hang. I'd suggest only starting the AoE driver after the system has booted to the RAM disk. (And after the NIC driver is driving the NIC.) This behaviour is expected. |
Main reason for me building from source was to get file-backed disk support working as my ISO is (or at least, will be) bigger than 4GB, and this doesn't work in 0.0.1.8, so I had to try later revisions...(which unfortunately broke AoE for my use case, which is more important to me!) Given I can disable all the RAM disk support and use alternatives (like Firadisk) and just utilise the AoE support in 0.0.1.8 that's fine, but I don't want to miss out on your bug fixes and any performance improvements by having a fork, hence why I'm here to offer any help I can to you to try and ensure it all works in the eventual 0.0.1.9 (or 0.0.2.0!) :) I would imagine having a driver that works all the way through from text mode (aka. an AoE counterpart to the Microsft iSCSI driver) is a reasonable goal to have as it means the driver is as robust and feature complete as it can be, and given it already worked at an earlier point in development, I suspect the majority of what is needed is already there - just needs to make sure it doesn't get broken accidentally by the architecture changes you've been working on, which is what I suspect has happened, (possibly due to the new messages/threading/mini driver separation creating a runtime initialisation dependency of some sort?) If it introduces an optional dependency for setup on the NIC Boot Config driver if you want to install to it, then that seems reasonable enough use case to support? (Just as you can use the MS iSCSI driver without it if you don't care about installing to an iSCSI target) |
What I intended to convey is that the behaviour that you have observed is by design and not an accident. If the AoE driver is enabled at boot-time, then it will discover any established aBFT and inform Windows that there is an AoE disk available. Windows demands to be able to read from every disk and will hang until it is able to read from every disk. If the NIC driver isn't operating, then the AoE disk cannot operate, so reads cannot happen, so Windows will hang. I believe that your scenario does not require an AoE disk to be present at boot-time, so I'd suggest delaying the AoE driver until after you've booted from your RAM- or file-backed disk. Alternatively, you can ensure that the NIC driver is boot-enabled, so that the AoE disk will be able to operate and to satisfy Windows that it is present. Since you could be booting on a variety of hardware, I doubt that you want to include many NIC drivers and have them all boot-enabled, however. If I've misunderstood something, you are welcome to continue to help me to understand. |
(Thanks for hanging around on this thread, btw) My scenario is that I want to be able to install directly to an AoE disk, and then reboot and continue installation from the AoE target, and then reboot and boot the AoE target without it ever needing a local disk, so I agree that the NIC drivers need to be boot drivers, (and indeed they are, for the iSCSI support). The file-backed disk is purely the installation ISO. The system disk is the remote AoE target. With all that in mind, 2ebc053 works for me with all my drivers enabled - I can start text mode, select my AoE target, copy the files to it, reboot, boot from the AoE target and continue setup, reboot, and boot from the AoE target into XP. I have to copy the ISO into a Grub4DOS RAM disk though - if I want to use the ISO in file-backed mode I have to disable WinVBlock's Grub4DOS support so I can use Firadisk. Revisions after that don't seem to work - the NIC is initialised fine as normal (as can be seen in the logs) and the only change is in the build of WinVBlock - there are no changes to any other files. You're the expert on why that would be - I don't understand enough about how the various components interact to make any kind of informed judgement beyond what I can see in the logs. |
15e7df1 is the last commit for the last released version, if I recall correctly. "Revisions after that" aren't expected to work. I have put all development into the "master" branch instead of a "hidden" branch, so I apologize for the confusion. If 15e7df1 doesn't work with GRUB4DOS ISOs, I'm sorry, but WinVBlock 0.0.1.8 can't drive your RAM disk. It almost appears that you could use V.'s original WinAoE driver with Firadisk and forget about WinVBlock. I'd obviously like for the next release of WinVBlock to address your needs. |
Cool, as long as you're happy to consider that use case then we can leave this until you need some testing done, then I'll be happy to help if you want anything. :) |
I appreciate that, very much. I hope to get back into a WinVBlock groove... Just have to balance with paid work. |
Long story short, I've been tinkering with this for a week or so now, and I'm not really informed enough to fix the code myself, sadly. My use case is to use iPXE to hook an AoE disk to BIOS drive 0x81, then boot a USB stick with GRUB4DOS on it, and use that to load an ISO into RAM, then boot from that. This enables me to install XP from an ISO to an AoE target.
My testbed for all of this is a VMWare host with a floppy image of iPXE (sanhook -d 0x81 aoe:e0.0), my USB stick mapped as a physical IDE drive (VMWare doesn't do USB booting), and the Win32 build of VBlade acting as AoE target.
Now, revision 2ebc053 (Date: 24/12/2010 15:30:09) is the newest revision of WinVBlock that works for me - I am able to install XP end to end using that code (abet I have to load the ISO into memory though). Beyond that point though I suffer a variety of BSODs until a point after revision: ebc7158 (Date: 04/01/2011 08:34:53), where it no longer crashes, but I instead get errors about firstly being unable to add the AoE bus to the WinVBlock bus, and a bit later (Revision: bb6f3af - Date: 07/01/2011 06:50:16), being unable to create the AoE bus PDO, and this persists to the most recent revision (7eed6ad - Date: 25/01/2016 00:31:00).
Aside from this, I ideally want to be able to use sector-mapped ISOs. I have this working fine with Firadisk, but this does not seem to work so well with the old revision of WinVBlock that AoE works with...but works fine in the latest revisions, as far as I can tell. My next attempted workaround for the time being is going to be to try disabling WinVBlock's GRUB4DOS handling in a branch from revision 2ebc053 so I can use Firadisk for the mappings and WinVBlock for AoE, as I figure disabling stuff is a lot more likely to work than trying to fix something you don't understand!
I created my own fork on Github and have grabbed full debug logs (edited into the notes for each commit) and tagged revisions I've tested. Dunno if you would find that information useful, but I'll push it up at some point.
The text was updated successfully, but these errors were encountered: