9 Apr
2005
9 Apr
'05
3:59 a.m.
Hi!
This is svn build 14542,
(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi
32.dll
(KERNEL32:mem/global.c:412) Memory Load: 23
(KERNEL32:mem/global.c:412) Memory Load: 23
(KERNEL32:mem/global.c:412) Memory Load: 23
(KERNEL32:mem/global.c:412) Memory Load: 23
(MSVCRT:io/open.c:103) not valid fd 0, g_fdend 5, fdinfo 7802d2f0, bucket 7802d2
f0, fdflags 0
(MSVCRT:io/open.c:700) _setmode: inval fd (0)
(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi
32.dll
ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
KeBugCheck at ex/handle.c:909
A problem has been detected and ReactOS has been shut down to prevent damage to
your computer.
The bug code is undefined. Please use an existing code instead.
Technical information:
*** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000)
Frames:
<ntoskrnl.exe:dbe3 (ke/bug.c:459 (KeBugCheckEx))>
<ntoskrnl.exe:dc03 (ke/bug.c:479 (KeBugCheck))>
<ntoskrnl.exe:3dcee (ex/handle.c:909 (ExMapHandleToPointer))>
<ntoskrnl.exe:92b23 (ob/handle.c:768 (ObReferenceObjectByHandle))>
<ntoskrnl.exe:3b3f2 (ex/event.c:476 (NtSetEvent))>
<ntoskrnl.exe:3c22 (/tmp/ccAGlOXR.s:178 (KiSystemService))>
<ntdll.dll:a414 (rtl/critical.c:502 (RtlpUnWaitCriticalSection))>
Entered debugger on embedded INT3 at 0x0008:0x800064be.
kdb:>
No keyboard,
James
9 Apr
9 Apr
7:38 a.m.
James Tabor wrote:
Hi!
This is svn build 14542,
(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000)
C:\ReactOS\System32\gdi
32.dll
ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
KeBugCheck at ex/handle.c:909
This is a little bit stupid. Why is 0 greater than APC_LEVEL? Do you use
an optimized build where oarch is set to i586 or better?
- Hartmut
7:43 a.m.
Hi!
Hartmut Birr wrote:
James Tabor wrote:
Hum?
NO, OARCH := i486, KDBG := 1 and DBG := 1.
James
Hi!
This is svn build 14542,
(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000)
C:\ReactOS\System32\gdi
32.dll
ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
KeBugCheck at ex/handle.c:909
This is a little bit stupid. Why is 0 greater than APC_LEVEL? Do you use
an optimized build where oarch is set to i586 or better?
- Hartmut
8:04 a.m.
James Tabor wrote:
Hi!
Hartmut Birr wrote:
I get weird crashs if I set OARCH to pentium4. Looking to te PAGED_CODE
macro in ExMapHandleToPointer:
PHANDLE_TABLE_ENTRY
ExMapHandleToPointer(IN PHANDLE_TABLE HandleTable,
IN LONG Handle)
{
80027801: 55 push %ebp
80027802: 89 e5 mov %esp,%ebp
80027804: 83 ec 08 sub $0x8,%esp
PHANDLE_TABLE_ENTRY HandleTableEntry;
PAGED_CODE();
80027807: e8 84 3c 06 00 call 8008b490 <_KeGetCurrentIrql@0>
8002780c: 3c 01 cmp $0x1,%al
8002780e: 76 49 jbe 80027859
<_ExMapHandleToPointer+0x58>
80027810: e8 7b 3c 06 00 call 8008b490 <_KeGetCurrentIrql@0>
80027815: 25 ff 00 00 00 and $0xff,%eax
8002781a: 50 push %eax
8002781b: 68 8d 03 00 00 push $0x38d
80027820: 68 70 13 0b 80 push $0x800b1370
80027825: 68 7c 13 0b 80 push $0x800b137c
8002782a: e8 21 b7 ff ff call 80022f50 <_DbgPrint>
...
The first call to KeGetCurrentIrql returns an irql which is higher than
APC level. The second call returns PASSIVE_LEVEL. This can't occur
because there is no function which raise or lower the irql. It may be
possible , that a task switch occur before and after the first call to
KeGetCurrentIrql and which has set the irql to a wrong value.
- Hartmut
James Tabor wrote:
Hum?
NO, OARCH := i486, KDBG := 1 and DBG := 1.
James
Hi!
This is svn build 14542,
(NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000)
C:\ReactOS\System32\gdi
32.dll
ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0)
KeBugCheck at ex/handle.c:909
This is a little bit stupid. Why is 0 greater than APC_LEVEL? Do you use
an optimized build where oarch is set to i586 or better?
- Hartmut
9:50 a.m.
Hi,
Hartmut Birr wrote:
I get weird crashs if I set OARCH to pentium4. Looking to te PAGED_CODE
macro in ExMapHandleToPointer:
PHANDLE_TABLE_ENTRY
ExMapHandleToPointer(IN PHANDLE_TABLE HandleTable,
IN LONG Handle)
{
80027801: 55 push %ebp
80027802: 89 e5 mov %esp,%ebp
80027804: 83 ec 08 sub $0x8,%esp
PHANDLE_TABLE_ENTRY HandleTableEntry;
PAGED_CODE();
80027807: e8 84 3c 06 00 call 8008b490 <_KeGetCurrentIrql@0>
8002780c: 3c 01 cmp $0x1,%al
8002780e: 76 49 jbe 80027859
<_ExMapHandleToPointer+0x58>
80027810: e8 7b 3c 06 00 call 8008b490 <_KeGetCurrentIrql@0>
80027815: 25 ff 00 00 00 and $0xff,%eax
8002781a: 50 push %eax
8002781b: 68 8d 03 00 00 push $0x38d
80027820: 68 70 13 0b 80 push $0x800b1370
80027825: 68 7c 13 0b 80 push $0x800b137c
8002782a: e8 21 b7 ff ff call 80022f50 <_DbgPrint>
...
The first call to KeGetCurrentIrql returns an irql which is higher than
APC level. The second call returns PASSIVE_LEVEL. This can't occur
because there is no function which raise or lower the irql. It may be
possible , that a task switch occur before and after the first call to
KeGetCurrentIrql and which has set the irql to a wrong value.
- Hartmut
Was it in idle? I left my system running, just idling. Come back ~12 hours later
and find it in a blue state of mind.
BTW, Csrss eats 3 to 5% of the system just setting there.
James
11:40 p.m.
Hartmut Birr wrote:
I get weird crashs if I set OARCH to pentium4. Looking
to te PAGED_CODE
macro in ExMapHandleToPointer:
I suggest changing the macro to something like:
#define PAGED_CODE() \
{ const KIRQL irql = KeGetKurrentIrql(); /* use 'irql' for the debug print
*/ }
If not, it's simply impossible to get correct and intended functionality,
should preemtion occur.
/Mike
1:35 a.m.
Thomas Weidenmueller wrote:
I very much doubt the irql should change at all...
Youre right
Mike Nordell wrote:
> Hartmut Birr wrote:
>
>
>
> If not, it's simply impossible to get correct and intended functionality,
> should preemtion occur.
Irql must obviously stay the same no matter if we were preempted and/or
taskswitched a trillion times. The case here is probably a bug in the
task switcher, where it "restores" the thread at a irql different from
what was current when it was "suspended", and after 11 hours(!) this bug
just happends to materialize in-between two related KeGetKurrentIrql
calls. It doesnt sound very likely, does it... Still, i cant think of
anything else that may cause this behaviour.
Best Regards,
Thomas
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
4:53 a.m.
WOOOO!
Thomas Weidenmueller wrote:
Mike Nordell wrote:
It did not click in my pee brain, "Preemption"? How could it preempt inside
kernel space? I thought atm that was imposable.
8^o,
James
Hartmut Birr wrote:
If not, it's simply impossible to get correct and intended functionality,
should preemtion occur.
I very much doubt the irql should change at all...
Best Regards,
Thomas 
5:13 a.m.
James Tabor wrote:
WOOOO!
Thomas Weidenmueller wrote:
Yeah, we don't really preempt on UP as far as I know with the current
scheduler. I think this only happens on MP, and I agree that the IRQL
probably doesn't get restored properly. Hopefully it'll work fine in my
scheduler...I had a similar problem but I found the bug and fixed it.
Best regards,
Alex Ionescu
Mike Nordell wrote:
It did not click in my pee brain, "Preemption"? How could it preempt
inside
kernel space? I thought atm that was imposable. Hartmut Birr wrote:
If not, it's simply impossible to get correct and intended
functionality,
should preemtion occur.
I very much doubt the irql should change at all...
Best Regards,
Thomas
7105
days inactive
7106
days old
9 comments
6 participants
participants (6)
-
Alex Ionescu -
Gunnar Dalsnes -
Hartmut Birr -
James Tabor -
Mike Nordell -
Thomas Weidenmueller