Re: [ros-svn] [ion] 20580: - New ERESOURCE implementation: fixes the return value of some functions (VOID vs NTSTATUS, USHORT vs ULONG), as well as optimized the code loops and general structure of the code. Additionnaly, functions do not simply call other functions with similar names; the exact implementation of each function has now been properly separated (see the DDK for more information on this) to have the most optimized scenarios.
ion@svn.reactos.org wrote:
- New ERESOURCE implementation: fixes the return value of some functions (VOID vs NTSTATUS, USHORT vs ULONG), as well as optimized the code loops and general structure of the code. Additionnaly, functions do not simply call other functions with similar names; the exact implementation of each function has now been properly separated (see the DDK for more information on this) to have the most optimized scenarios.
- Also, the spinlock is not actually acquired on non-SMP builds; instead, interrupts are blocked and unblocked for acquire/release, this optimizes locking.
- Added many asserts and bugcheck scenarios.
- Added thread priority boosting.
- Added some debugging helpers and deadlock detection.
- Added RESOURCE_NOT_OWNED bugcehck message.
- Thanks again to Waxdragon (Andrew) for testing this build.
It seems, that your implementation is broken. On a non SMP machine during 'make clean' on the ros source:
KeBugCheckEx at ./ntoskrnl/ex/resource.c:1847 A problem has been detected and ReactOS has been shut down to prevent damage to your computer.
Technical information:
*** STOP: 0x000000E3 (0x81a5eb0c,0x81a55c70,0x00000000,0x00000002)
Frames: <ntoskrnl.exe:2599 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:27ac4 (./ntoskrnl/ex/resource.c:1843 (ExReleaseResourceLite))> <vfatfs.sys:3ee2 (drivers/fs/vfat/dir.c:471 (DoQuery))> <vfatfs.sys:416f (drivers/fs/vfat/dir.c:486 (VfatDirectoryControl))> <vfatfs.sys:dc06 (drivers/fs/vfat/misc.c:119 (VfatDispatchRequest))> <vfatfs.sys:dd8f (drivers/fs/vfat/misc.c:167 (VfatBuildRequest))> <ntoskrnl.exe:4369b (./ntoskrnl/io/irp.c:1076 (IofCallDriver))> <ntoskrnl.exe:53a3a (ntoskrnl/io/file.c:2607 (NtQueryDirectoryFile))> <ntoskrnl.exe:a0daa (ntoskrnl\ke\i386\syscall.S:372 (KiSystemService))> <kernel32.dll:9b22 (./lib/kernel32/file/find.c:143 (InternalFindNextFile))>
The same on a SMP machine (no back trace available):
KeBugCheckEx at ./ntoskrnl/ex/resource.c:1868 (./ntoskrnl/mm/mm.c:292 CPU0) Page fault at high IRQL was 2, address c2410 A problem has been detected and ReactOS has been shut down to prevent damage to your computer.
Technical information:
*** STOP: 0x000000E3 (0x8131d0d8,0x81620d68,0x81376640,0x00000002)
- Hartmut
Hartmut Birr wrote:
It seems, that your implementation is broken. On a non SMP machine during 'make clean' on the ros source:
KeBugCheckEx at ./ntoskrnl/ex/resource.c:1847 A problem has been detected and ReactOS has been shut down to prevent damage to your computer.
Technical information:
*** STOP: 0x000000E3 (0x81a5eb0c,0x81a55c70,0x00000000,0x00000002)
Frames: <ntoskrnl.exe:2599 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:27ac4 (./ntoskrnl/ex/resource.c:1843 (ExReleaseResourceLite))> <vfatfs.sys:3ee2 (drivers/fs/vfat/dir.c:471 (DoQuery))> <vfatfs.sys:416f (drivers/fs/vfat/dir.c:486 (VfatDirectoryControl))> <vfatfs.sys:dc06 (drivers/fs/vfat/misc.c:119 (VfatDispatchRequest))> <vfatfs.sys:dd8f (drivers/fs/vfat/misc.c:167 (VfatBuildRequest))> <ntoskrnl.exe:4369b (./ntoskrnl/io/irp.c:1076 (IofCallDriver))> <ntoskrnl.exe:53a3a (ntoskrnl/io/file.c:2607 (NtQueryDirectoryFile))> <ntoskrnl.exe:a0daa (ntoskrnl\ke\i386\syscall.S:372 (KiSystemService))> <kernel32.dll:9b22 (./lib/kernel32/file/find.c:143 (InternalFindNextFile))>
The same on a SMP machine (no back trace available):
KeBugCheckEx at ./ntoskrnl/ex/resource.c:1868 (./ntoskrnl/mm/mm.c:292 CPU0) Page fault at high IRQL was 2, address c2410 A problem has been detected and ReactOS has been shut down to prevent damage to your computer.
Technical information:
*** STOP: 0x000000E3 (0x8131d0d8,0x81620d68,0x81376640,0x00000002)
- Hartmut
Hi,
I will check this out... I thought Andrew had done a build test, but he might've skipped the make clean. Thanks.
Best regards, Alex Ionescu
Alex Ionescu wrote:
Hi,
I will check this out... I thought Andrew had done a build test, but he might've skipped the make clean. Thanks.
I'm using a modified make.exe which can start multiple threads. I used the parameter '-j2' on both machines. Possible, it makes more stress for the ERESOURCE implementation.
- Hartmut
Hartmut Birr wrote:
I'm using a modified make.exe which can start multiple threads. I used the parameter '-j2' on both machines. Possible, it makes more stress for the ERESOURCE implementation.
- Hartmut
Am currently checking the wait bug at the moment, so I haven't looked at the resource code, but one thing strikes me -- the bugcheck is a new one that I've added to detect with a non-acquired resource is being freed. This check did not exist in the previous code(IIRC), so it's possible that my implementation is fine, it's simply detecting incorrect usage. Can you check Vfat and make sure that it actually DOES own the resource?
Best regards, Alex Ionescu
Alex Ionescu wrote:
Hartmut Birr wrote:
I'm using a modified make.exe which can start multiple threads. I used the parameter '-j2' on both machines. Possible, it makes more stress for the ERESOURCE implementation.
- Hartmut
Am currently checking the wait bug at the moment, so I haven't looked at the resource code, but one thing strikes me -- the bugcheck is a new one that I've added to detect with a non-acquired resource is being freed. This check did not exist in the previous code(IIRC), so it's possible that my implementation is fine, it's simply detecting incorrect usage. Can you check Vfat and make sure that it actually DOES own the resource?
Best regards, Alex Ionescu
I've looked to DoQuery from vfat. I'm sure it does only release the resource, if it was acquired previously.
- Hartmut
-
Alex Ionescu -
Hartmut Birr