[ros-kernel] Q2 Bug (210 in bugzilla) Fix or bigger bug?

[Waldo Alvarez Cañizares]

Hi David:

________________________________

From: ros-kernel-bounces at reactos.com on behalf of David Welch
Sent: Wed 3/3/2004 6:34 PM
To: ReactOS Kernel List
Subject: Re: [ros-kernel] Q2 Bug (210 in bugzilla) Fix or bigger bug?



On Wed, Mar 03, 2004 at 05:46:52PM -0500, Waldo Alvarez Cañizares wrote:
> Hi Aleksey:
> 
> It prints something like "loading <something I can't remember> timeout" And it stays there very long (Provably I didn't waited too long to see it). Actually is does not crash, it hangs. Does it takes that long to start playing? I'm going to try and leave it for 30 min after starting a new game but there is not disk activity for a long time. Why don't you try it now? Something
> 
> Sometimes I get reactos Frozen with RC1 running quake 2 (but that is because it is big)
> 
> Look:
> 
> (misc.c:135) Vfat is entered at irql = 1
> Bug detected (code 29a param 0 0 0 0)    <---- I putted this in order to get the stack trace because I'm inside a driver
>   No message text found!
> Pid: 9 <quake2> Thrd: c13d7988 Tid: 30
> Frames: <ntoskrnl.exe: 971b> KeBugCheck ( I did this :) )
> <vfatfs: b326>        VfatBuildRequest        <----------
> <ntoskrnl.exe: 30417> IofCallDriver                      |
> <ntoskrnl.exe: 3133c> IoPageRead                         |
> <ntoskrnl.exe: 45b43> MmReadFromSwapPage                 |
> <ntoskrnl.exe: 5306b> MmNotPresentFaultVirtualMemory     |
> <ntoskrnl.exe: 43084> MmNotPresentFault                  |
> <ntoskrnl.exe: 7d2d>  ExAllocatePagedPoolWithTag         |
> <ntoskrnl.exe: 1df1>  KiTrapHandler                      |---- Hmmm 2 times?!
> <ntoskrnl.exe: 3031>  KiTrapProlog                       |
> <ntoskrnl.exe: 5bc1>  MmSafeCopyToUserUnsafeStart        |
> <ntoskrnl.exe: 2a997> IoSecondStageCompletion            |    
> <ntoskrnl.exe: 3082c> IofCompleteRequest                 |
> <ntoskrnl.exe: 3085c> IoCompleteRequest                  |
> <vfatfs: 9eac>        VfatRead                           |
> <vfatfs: b2cd>        VfatBuildRequest        <----------
> <ntoskrnl.exe: 30417> IofCallDriver
> <ntoskrnl.exe: 3042d> IoCallDriver
> <ntoskrnl.exe: 35acd> NtReadFile
> <ntoskrnl.exe: 32ac>  new_serviceInRange
> When it is copied to the Buffer in the paged pool the IRQL is still the same! And seems there was a page not present in memory while the file was being loaded. This got to be a bug. Any Ideas where is this bug? CVS may contain it too.
> 
I think the ExAllocatePagedPoolWithTag should be MmPageFault. 

Maybe I did that wrong (Maybe it appears near in the map)

What seems to
have happended is that the UserIosb field of the IRP for a file read points to
user memory that has been paged out; when updating the content of UserIosb
after completing the IRP we took a page fault for that reason and called back
into the file system to get the paged out memory from the swap file.

Are you sure the system deadlocked inside the second call to VfatBuildRequest?
If a lot of things are getting paged out then it could be that we have run
out of memory and are spinning somewhere for that reason.

without the KeBugCheck it keeps printing constantly

 (misc.c:135) Vfat is entered at irql = 1
 (misc.c:135) Vfat is entered at irql = 1
 (misc.c:135) Vfat is entered at irql = 1
...

It is at random when there is heavy memory load and little RAM used (I don't remember very well was 16-32 in VMware )

Well There is a condition in the source on the Vfat driver in VfatBuildRequest that prints that message (I just putted a bugcheck there)

Best Regards

Waldo Alvarez


_______________________________________________
Ros-kernel mailing list
Ros-kernel at reactos.com
http://reactos.com/mailman/listinfo/ros-kernel <http://reactos.com/mailman/listinfo/ros-kernel> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8333 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040303/f73ec13d/attachment-0001.bin