[ros-kernel] Q2 Bug (210 in bugzilla) Fix or bigger bug?
welch at cwcom.net
Wed Mar 3 23:34:12 CET 2004
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)
> (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. 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.
More information about the Ros-kernel