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

[Hartmut Birr]

Hi,

I've merged the ext2, usetup and freeldr files in my local source tree. 
If I start the installation, I get crash at the begin of the copy process:

...
    *** Attempting to acquire FCBpaging Exclusively [Write]  IRQL = 0    
[src/write.c] Line No = 463
    *** FCBpaging Acquired [Write]  IRQL = 0    [src/write.c] Line No = 473
    [File Write] Paging IO or NonBufferedIo   IRQL = 0    [src/write.c] 
Line No = 777

Determining the write IRPs that have to be passed down...  IRQL = 0    
[src/write.c] Line No = 1250
      Index = (11)  IRQL = 0    [src/write.c] Line No = 1317
      Logical Block = (0x538F)  IRQL = 0    [src/write.c] Line No = 1318
      Start = (0x307)  IRQL = 0    [src/write.c] Line No = 1319
      End = (0x1000)    IRQL = 0    [src/write.c] Line No = 1320
      Bytes written (0xCF9)  IRQL = 0    [src/write.c] Line No = 1321
    Passing down the Write IRPs to the disk driver...  IRQL = 0    
[src/write.c] Line No = 1358PASSING DOWN IRP 0 TO TARGET DEVICE
DEADLY WAIT (0)

Freeing  = C05FC498 [io]  IRQL = 2    [src/io.c] Line No = 
486Assertion Mdl->MdlFlags & MDL_MAPPED_TO_SYSTEM_VA failed at mm/mdl.c:246
Bug detected (code 0 param 0 0 0 0)
  The bug code is undefined. Please use an existing code instead.

Frames: <ntoskrnl.exe: bdee>
<ntoskrnl.exe: be26>
<ntoskrnl.exe: 5a6cc>
<ntoskrnl.exe: 41677>
<ntoskrnl.exe: 40662>
<ntoskrnl.exe: 408cc>
<scsiport.sys: 49f9>
<scsiport.sys: 38ac>
<ntoskrnl.exe: c8ce>
<hal.dll: 40e8>
<hal.dll: 43db>
<ntoskrnl.exe: 262e>
<ntoskrnl.exe: 2edb>
<ntoskrnl.exe: 3690>

I think that the buffer locking is wrong for the partial mdls. I've 
changed this a little bit:

--- E:\Sandbox\ros_ext2\ext2\reactos\drivers\fs\ext2\src\io.c    Thu Jan 
20 20:17:44 2005
+++ E:\Sandbox\ros_mp\reactos\drivers\fs\ext2\src\io.c    Thu Jan 20 
20:05:32 2005
@@ -50,6 +50,7 @@
     PKEVENT                PtrSyncEvent = NULL;
     ULONG                LogicalBlockSize;
     ULONG                ReadWriteLength;
+    PVOID Buffer;

NTSTATUS RC = STATUS_SUCCESS;

@@ -69,6 +70,8 @@
         {
             Ext2LockCallersBuffer( PtrMasterIrp, TRUE, 
TotalReadWriteLength );
         }
+        MmGetSystemAddressForMdlSafe(PtrMasterIrp->MdlAddress, 
HighPagePriority);
+        Buffer = MmGetMdlVirtualAddress(PtrMasterIrp->MdlAddress);

if( SynchronousIo )
         {
@@ -117,14 +120,14 @@
             //
             //    Allocating a Memory Descriptor List...
             //
-            PtrMdl = IoAllocateMdl( (PCHAR) PtrMasterIrp->UserBuffer + 
BufferOffset, //    Virtual Address
+            PtrMdl = IoAllocateMdl( (PCHAR) 
/*PtrMasterIrp->UserBuffer*/Buffer + BufferOffset, //    Virtual Address
                 ReadWriteLength,    FALSE, FALSE, PtrAssociatedIrp );

//
             //    and building a partial MDL...
             //
             IoBuildPartialMdl( PtrMasterIrp->MdlAddress,
-                PtrMdl, (PCHAR)PtrMasterIrp->UserBuffer + BufferOffset, 
ReadWriteLength );
+                PtrMdl, /*(PCHAR)PtrMasterIrp->UserBuffer*/Buffer + 
BufferOffset, ReadWriteLength );

//
             //    Create an Irp stack location for ourselves...

The installer starts the copy process. After some files (#125, 
rpcrt4.dll), ros does crash anywher in the cache manager. My test 
machine is PIII 550MHz with an adaptec scsi controller. I do not use the 
atapi driver.

- Hartmut