Re: WinXPSP2, Intel Core2Duo, Kernel drivers

Sorry, it was early the instance I was thinking of was
KeAcquireSpinLockAtDpc. This code was done by a very good developer who is
now a respected member of the Windows driver community (and not me).


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply


<soviet_bloke@xxxxxxxxxxx> wrote in message
news:1157640287.046142.16480@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Don

For instance, if you forget that a routine uses
spinlocks and then accidently call it from your ISR, it may very well
work
on an SMP system because the spinlock is an actual test and set, but it
has
terrible consequences on a UP system where it becomes a NOP since the
IRQL
is above DISPATCH_LEVEL.

Trying to call the routine that uses spinlocks from ISR is not going to
work fine on
MP system either. Let's look at how MP HAL obtains spinlocks - the code
below is implementation of KeAcquireSpinLock() from halmacpi.dll


80012830: mov edx,dword ptr ds:[FFFE0080h]
80012836: mov dword ptr ds:[FFFE0080h],41h
80012840: shr edx,4
80012843: movzx eax,byte ptr [edx+8001D218h]

8001284A: lock bts dword ptr [ecx],0
8001284F: jb 80012854
80012851: ret

As you can see, the very first step KeAcquireSpinLock() does is
UNCONDITIONALLY(!!!)writing 0x41 to the Task Priority Register, i.e.
setting IRQL to DISPATCH_LEVEL, and then proceeds to set and test.
KeAcquireQueuedSpinLock() behaves in similar fashion. Therefore,
calling these functions at IRQL>DISPATCH_LEVEL is quite unwise thing to
do - even on MP HAL.

Anton Bassov




Don Burn wrote:
<soviet_bloke@xxxxxxxxxxx> wrote in message
Well, you can think of my examples as of ones of the bugs if you wish -
no matter how you call them, these are the examples of doing something
you are not supposed to do, which may have undesirable effects (unless
you are 100% sure you know what you are doing)

Yes they are doing something you are not supposed to do, that is a pretty
good definition of a bug. For instance, if you forget that a routine
uses
spinlocks and then accidently call it from your ISR, it may very well
work
on an SMP system because the spinlock is an actual test and set, but it
has
terrible consequences on a UP system where it becomes a NOP since the
IRQL
is above DISPATCH_LEVEL.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



.

Relevant Pages

  • Re: WinXPSP2, Intel Core2Duo, Kernel drivers
    ... the routine, called by ISR, deals with spinlocks. ... Windows 2k/XP/2k3 Filesystem and Driver Consulting ...
    (microsoft.public.development.device.drivers)
  • Re: how can i disble irq15 through C/assembly programming.
    ... about spinlocks in documents that are related to NT 3.51 ... Arkady was right and I was wrong..... ... different archtecture and even for for x86 drivers are user mode dlls. ... first version of Windows that was capable of recognizing more than one ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WinXPSP2, Intel Core2Duo, Kernel drivers
    ... on an SMP system because the spinlock is an actual test and set, ... Trying to call the routine that uses spinlocks from ISR is not going to ... the very first step KeAcquireSpinLock() does is ...
    (microsoft.public.development.device.drivers)
  • Re: Getting owner thread of a spinlock
    ... Spinlocks are not owned by threads, ... The owning CPU cannot be extracted, Windows does not support such a ... Maxim Shatskih, Windows DDK MVP ... earlier on windbg news group, but this group looks more active. ...
    (microsoft.public.development.device.drivers)
  • Re: Power Management in PASSTHRU
    ... Is it Windows? ... power management. ... > protected by any spinlocks? ...
    (microsoft.public.development.device.drivers)
Loading