Re: Help me for a typical problem regarding KeAquireSpinLock which is not Locking other Thread in Same CPU

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Skywing


///
multiprocesor hal:

lkd> uf hal!KeRaiseIrqlToSynchLevel
hal!KeRaiseIrqlToSynchLevel:
80a78938 8b158000feff mov edx,[fffe0080]
** 80a7893e c7058000feffc1000000 mov dword ptr [fffe0080],0xc1 **
80a78948 c1ea04 shr edx,0x4
80a7894b 0fb6821032a880 movzx eax,byte ptr [edx+0x80a83210]
80a78952 c3 ret

uniprocessor hal:

lkd> u hal!KeRaiseIrqlToSynchLevel
hal!KeRaiseIrqlToSynchLevel:
806d02b4 8b158000feff mov edx,[fffe0080]
** 806d02ba c7058000feff41000000 mov dword ptr ddd],0x41 **
806d02c4 c1ea04 shr edx,0x4
806d02c7 0fb68288b06d80 movzx eax,byte ptr [edx+0x806db088]
806d02ce c3 ret
806d02cf 90 nop
//////

The second function is, in actuality, KeRaiseIrqlToDpcLevel(), rather than
KeRaiseIrqlToSynchLevel(). No wonder -
KeRaiseIrqlToSynchLevel() IMMEDIATELY follows KeRaiseIrqlToDpcLevel()in HAL.
DLL, so that you just copied a wrong function (KeRaiseIrqlToSynchLevel()
writes 0xd1, rather than 0x41, to the Task Priority Register). Never mind.

This is the reason why I said "values are always the same", but never
questioned your statement of different implications. VALUE is something that
is declared in ntddk.h, and equals (IPI_LEVEL-1), which is 0xc1, i.e.
CLOCK1_LEVEL and CLOCK2_LEVEL. Therefore, it does not depend on the number
of processors. Concerning the implications, you have demonstrated them
yourselves.

Don't worry - there is no problem with calling KeRaiseIrqlToSynchLevel()
whatsoever. What you should NOT do is to to call KeRaiseIrql(SYNCH_LEVEL,
&irql) - if you do it this way, your call will have different implications
on UP and MP kernels.

Look at what I said in my message - I never said to raise IRQL to
SYNCH_LEVEL with KeRaiseIrql(), did I??
Instead, I said to raise it to the level above the one ISR may run at.

Anton Bassov
.

Relevant Pages