[ros-dev] ext2 status (a bit long)

[art yerkes]

I've been doing some looking at why winext2fsd doesn't work on reactos.
This has been a pet project of mine for a while, but sadly I'm not very
skilled in the parts of reactos that it touches.

On the ext2 branch, I've got filips changes and some small changes of
my own so that I can make a bootcd that will try to install reactos on
a fresh ext2 partition.

ext2 starts writing the first file to the empty filesystem but stalls
when a call to WriteCacheSegment causes ext2 to do a paging write of
several pages to class2, which uses ScsiClassSplitRequests to send
several blocks to scsiport for writing.  The interesting thing is, in
the case where my diff prints DEADLY WAIT, SpiProcessRequests receives
the IRPs but does not enter the while loop that would process them,
nor receive any further completions.  At this point i'm totally stuck
and so I'll try to isolate the relevant debug output.

If somebody is interested and has some spare time I'd appreciate a
bit of wisdom about how the DeviceExtension->Flags, NextIrp,
ActiveIrpCount and PendingIrpCount fit together.  I think that if
the IRPs are completed then the rest will work, since the split
IRP code in class2 seems reasonable.

http://64.81.145.152/~arty/ext2.diff  <-- Lots of annotation
http://64.81.145.152/~arty/ext2.log   <-- Last part of execution
http://64.81.145.152/~arty/rosbin.zip <-- Binaries from my tree

In the log it is writing atapi.sys to \ReactOS\system32\drivers on the
disk.  DEADLY WAIT(0) is the place where ext2 can't progress from.  It's
at line 200 or so in drivers/fs/ext2/src/io.c.

The fatal invocation of SpiProcessRequest looks like this before the
while loop:

(scsiport.c:2864) DeviceExtension->Flags & IRP_FLAG_COMPLETE 0
(scsiport.c:2866) DeviceExtension->SrbExtensionSize 0
(scsiport.c:2869) DeviceExtension->CurrentSrbExtensions 0 Max 0
(scsiport.c:2871) DeviceExtension->PendingIrpCount 4
(scsiport.c:2873) DeviceExtension->Flags & (N|NLU) 0
(scsiport.c:2875) DeviceExtension->NextIrp c0457db0

The wierd thing is that it seems that atapi relies on the ide controller
raising an interrupt after IDEWriteBlock, which never happens for me
under qemu after this point.  This is where I get totally lost 
unfortunately.

I'll try to learn more as I go but any help understanding scsiport is
appreciated.

Art
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman