RE: ntdev digest: April 20, 2000

Re: Questions about interrupt response!
The other thing to try is to see if the board can queue up the
information needed by the ISR/DPC. Then when the DPC is dispatched
you can retrieve all of the information from the board for multiple
interrupts.

If the board cannot queue the information and you are currently using
shared interrupts I would first try to acquire a non-shared interrupt.
If this fails then try to acquire a shared interrupt. If you are
on a shared interrupt other boards drivers that are using the same
interrupt may be called first.

Marty Corbett
Principal Software Engineer
Integrated Computing Engines(ICE)
Waltham, MA 02451-1908
xxxxx@iced.com

-----Original Message-----
From: NT Developers Interest List digest [mailto:xxxxx@lists.osr.com]
Sent: Friday, April 21, 2000 1:00 AM
To: ntdev digest recipients
Subject: ntdev digest: April 20, 2000

NT Developers Interest List Digest for Thursday, April 20, 2000.

  1. Questions about interrupt response!
  2. STATUS_REPARSE
  3. 2 FDOs on top of 1 PDO; writing a DVD-RAM driver
  4. Re: Questions about interrupt response!
  5. Bug in IOCTL_CDROM_RAW_READ / CDROM.SYS ?
  6. Re: Blue screen
  7. [NTDEV] Serial port Debugging on Windows 9x
  8. Re: Questions about interrupt response!
  9. Re: Questions about interrupt response!
  10. Re: Blue screen
  11. Re: Blue screen
  12. Re: Blue screen
  13. Re: Blue screen
  14. Re: Blue screen
  15. Re: Blue screen
  16. CreateProcess and consoles
  17. PsCreateSystemThread Question
  18. RE: PsCreateSystemThread Question
  19. RE: PsCreateSystemThread Question
  20. Soft Affinity of Thread
  21. Re: Blue screen

Subject: Questions about interrupt response!
From: Jingcao Hu
Date: Thu, 20 Apr 2000 17:13:18 +0800
X-Message-Number: 1

Hello Gurus,
The PCI card that I have designed would signal interrupt every 6ms. I
just wonder whether it is possible for my winNT4.0 (on a HPLH3000
Server) to response to the interrupt without skipping over any
interrupt.
In order to shorten the response time, what should I pay attention to
when I am writing the driver?
Thanks in advance.

Best regards,
Jingcao mailto:xxxxx@chinaren.com

----------------------------------------------------------------------

Subject: STATUS_REPARSE
From: Joseph Arun
Date: Thu, 20 Apr 2000 17:13:53 +0530
X-Message-Number: 2

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------
=NextPart_001_01BFAABD.B3FAF740
Content-Type: text/plain

Hi,
Can anybody please explain the meaning of STATUS_REPARSE ?
I am getting this return value for IRP_MJ_CREATE is issued immediately after
ejecting and then re-inserting the floppy into the drive.

After ejecting the floppy, I had got return value denoting disk error.
I reinserted the floppy and again tried to refresh the listing of files in
NT explorer. The first IRP_MJ_CREATE returned STATUS_REPARSE. Next
IRP_MJ_CREATE got STATUS_SUCCESS.

Thanks in advance.

Josie

------
=NextPart_001_01BFAABD.B3FAF740
Content-Type: text/html;
charset=“iso-8859-1”
Content-Transfer-Encoding: quoted-printable




charset=3Diso-8859-1">
5.5.2650.12">
STATUS_REPARSE




Hi, =


=A0=A0=A0=A0=A0=A0=A0 FACE=3D"Arial">Can anybody please explain the meaning of STATUS_REPARSE =
?

I am getting this return value for =
IRP_MJ_CREATE is issued immediately after ejecting and then =
re-inserting the floppy into the drive.




After ejecting the floppy, I had got =
return value denoting disk error.

I reinserted the floppy and again =
tried to refresh the listing of files in NT explorer. The =
first FACE=3D"Arial">IRP_MJ_CREATE returned STATUS_REPARSE. Next =
IRP_MJ_CREATE got STATUS_SUCCESS.




Thanks in advance.FACE=3D"Arial">




Josie =








------
=NextPart_001_01BFAABD.B3FAF740–

----------------------------------------------------------------------

Subject: 2 FDOs on top of 1 PDO; writing a DVD-RAM driver
From: xxxxx@gmx.de
Date: Thu, 20 Apr 2000 8:30:22
X-Message-Number: 3

Hello,

we have a NT 4 driver for DVD-RAM drives. This driver creates a CdRom and a
removeable disk device for each physical DVD-RAM device. This seems to be
necessary to mount either disk based file systems or CD/DVD-ROM file
systems, depending on the actual type of media in the drive.

Now in Win2K the world looks a bit different, so that I’d like to ask some
questions. These questions may not make sense in this order, but I am still
in the design phase.

1. Is it possible/allowed to layer two FDOs on top of port drivers PDO?

2. The legacy/NT4 version of the driver runs on Win2K, but I don’t get any
mount requests for the disk device. Are legacy disk drivers just not
supported in Win2K or are we doing something wrong?

3. Does anyone outside of my driver know if a particular device object is a
FDO or a PDO? If no one really cares about it, I could add a cd/dvd type
“partition” beneath the disk partitions, allowing CD/UDFS to mount on the
cd/dvd device and the disk file systems mount on the disk partitions.

4. Is there a chance to install a storage device driver without any user
interaction? One way could be to copy my .inf and the driver to inf\ and
drivers, respectively and let Win2K install them when attaching the drive.
But the drive is usually already there when our software is installed,
that’s why I need a way to do the “Change driver…” in my setup program.

5. Is there a way to tell pnp mgr in which order it should start the
devices? The problem is, that CDROM.SYS assumes that it is the only one who
creates \Device\CdRomX objects, so that he fails if someone already created
a device with the same number. Because the disk driver handles this
correctly, I guess Win2K SPn will fix this, but I afraid I can’t wait.

If you have some answers, hints or want to tell me that I should do it a
total different way, please let me know.

Thanks and best regards,
Detlef

----------------------------------------------------------------------

Subject: Re: Questions about interrupt response!
From: “Dominick Cafarelli”
Date: Thu, 20 Apr 2000 08:33:24 -0400
X-Message-Number: 4

Based upon what all developers are supposed to do for ISR routines is for
them to simply acknowledge the interrupt and then queue a Deferred Procedure
Call. Therefore when an Interrupt occurs, your ISR should execute fairly
quickly probably within 10-20 microseconds at the worst. However, you will
need to queue a DPC during your ISR (just like everyone else so that all
Interrupts play fair) and that DPC will do the extended processing of the
interrupt event. That DPC gets placed into a queue and could take several
hundred microseconds to execute while it waits its turn in the Queue. You
should read the DDK and/or some Windows NT driver books about ISR and
DIRQL_LEVEL, DISPATCH_LEVEL and PASSIVE_LEVEL kernel processor levels. Most
Windows NT driver books to a very good job of describing this mechanism.

If you want others to play fair, then you should too!

Dominick

----- Original Message -----
From: “Jingcao Hu”
To: “NT Developers Interest List”
Sent: Thursday, April 20, 2000 5:13 AM
Subject: [ntdev] Questions about interrupt response!

> Hello Gurus,
> The PCI card that I have designed would signal interrupt every 6ms. I
> just wonder whether it is possible for my winNT4.0 (on a HPLH3000
> Server) to response to the interrupt without skipping over any
> interrupt.
> In order to shorten the response time, what should I pay attention to
> when I am writing the driver?
> Thanks in advance.
>
>
>
> Best regards,
> Jingcao mailto:xxxxx@chinaren.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@flashcom.net
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>

----------------------------------------------------------------------

Subject: Bug in IOCTL_CDROM_RAW_READ / CDROM.SYS ?
From: xxxxx@gmx.de
Date: Thu, 20 Apr 2000 8:49:27
X-Message-Number: 5

Hello,

yet onother problem:

Does anyone know how Win2K reads audio data for the digital CD audio
feature? I ask this question because there is one thing in the
IOCTL_CDROM_RAW_READ path in CDROM.SYS which I think is a bug:

==== CDROM.C =========
if ((((ULONGLONG) startingOffset.QuadPart) + transferBytes)
>
(ULONGLONG) commonExtension->PartitionLength.QuadPart) {

DebugPrint((1,"CdRomDeviceControl: Invalid I/O parameters for
XA "
“Read (Request Out of Bounds)\n”));

//
// Fail request with status of invalid parameters.
//

status = STATUS_INVALID_PARAMETER;
break;
}
======================

At this point startingOffset and PartitionLength are something like
"SectorNr
2048", while transferBytes is “NumSectors*2352”. This definitely
prevents me from raw reading the last sector. Given that I read more than
one sector at a time, the whole last block fails.

On NT 4 we installed our own CD-ROM driver to fix this and we other known
problems. Now on Win2K I’ll try to work around this, hoping that someone
from microsoft tells me that I am wrong or that this will be fixed some
day.

Best regards,
Detlef Golze

----------------------------------------------------------------------

Subject: Re: Blue screen
From: Neelay Das
Date: Thu, 20 Apr 2000 18:16:19 +0530
X-Message-Number: 6

Hi,
The problem is that you can call the KeAcquireSpinLock() and
KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
process of acquiring the lock first the IRQL is raised to dispatch level
from the old IRQL and then the lock is acquired. Since in your DPC routine
you’ll already be runing at dispatch level IRQL you should use the routines
KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
respectively acquire and release spin locks from your DPC routines. Hope
this is of some help.

Thanks,
-Neelay

“Fareeduddin A. Mohammed” wrote:

> Hi All.,
>
> I am getting a blue screen with the following message:
>
> A wait operation, attach process, or yield was attempted from a DPC
> routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
> Any idea about it? I do have a DPC routine and I am calling
> KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
> KeReleaseSpinLock() functions in that routine.
>
> Please help!
> Thanks in advance.
> -Fareed.

----------------------------------------------------------------------

Subject: [NTDEV] Serial port Debugging on Windows 9x
From: Ajitabh Prakash
Date: Thu, 20 Apr 2000 18:29:36 +0530
X-Message-Number: 7

Hi all,
I know that we can do a serial port debugging on NT …how can i
do it on 9x platforms…
do i have to change boot.ini.
what is the change that has to be made to enable the serial port debugging.

thanks
ajitabh

Ajitabh Prakash
Sr.Software Engineer
Future Software
480/481 Nandnam,Chennai

----------------------------------------------------------------------

Subject: Re: Questions about interrupt response!
From: Stephen Williams
Date: Thu, 20 Apr 2000 08:29:11 -0700
X-Message-Number: 8

xxxxx@chinaren.com said:
> The PCI card that I have designed would signal interrupt every 6ms. I
> just wonder whether it is possible for my winNT4.0 (on a HPLH3000
> Server) to response to the interrupt without skipping over any
> interrupt.

Probably. In general, that will probably be fine, but I think you will
find that interrupts will be occasionally missed. If your hardware cannot
cope with that, you’re sunk.

Some of the best things you can do to improve interrupt latency are
to avoid ISE disk drives (though a bad SCSI driver can mess you up too)
and watch out for cheap consumer quality video cards. In situations
similar to yours, I’ve seen NT occasionally block interrupts for fright-
fully long periods of time when accessing certain of these devices.

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”

----------------------------------------------------------------------

Subject: Re: Questions about interrupt response!
From: Taed Nelson
Date: Thu, 20 Apr 2000 08:40:42 -0700
X-Message-Number: 9

> Some of the best things you can do to improve interrupt latency are
> to avoid ISE disk drives (though a bad SCSI driver can mess
> you up too)

I agree! However, the IDE disk drive issue is easily fixed by running the
bus-master version of the ATAPI driver, assuming your motherboard supports
it. (If it was made in the past 2 years, it should.) Look in the MS
Knowledge Base if you don’t know how to set that up.

----------------------------------------------------------------------

Subject: Re: Blue screen
From: “COX,DAVID (HP-Roseville,ex1)” <david_cox2>
Date: Thu, 20 Apr 2000 10:02:48 -0700
X-Message-Number: 10

KeAcquireSpinLock() MAY be called at DISPATCH_LEVEL, it is not necessary
to be below. It may NOT be called from above DISPATCH_LEVEL.

Assuming you’ve done things right up until that point, if you are
holding a spin lock, you are at DISPATCH_LEVEL, so KeReleaseSpinLock()
can be called only at DISPATCH_LEVEL, and not below.

If you are at DISPATCH_LEVEL prior to acquiring a spin lock, then
KeAcquire/ReleaseSpinLock() are doing additional unnecessary work. The
routines KeAcquire/ReleaseSpinLockAt/FromDpcLevel() are offered for
optimization – they cut out the unnecessary steps of changing the IRQL.

-----------------------------------------------------------------------
Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Neelay Das [mailto:xxxxx@netlab.hcltech.com]
Sent: Thursday, April 20, 2000 5:46 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Blue screen

Hi,
The problem is that you can call the KeAcquireSpinLock() and
KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
process of acquiring the lock first the IRQL is raised to dispatch level
from the old IRQL and then the lock is acquired. Since in your DPC routine
you’ll already be runing at dispatch level IRQL you should use the routines
KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
respectively acquire and release spin locks from your DPC routines. Hope
this is of some help.

Thanks,
-Neelay

“Fareeduddin A. Mohammed” wrote:

> Hi All.,
>
> I am getting a blue screen with the following message:
>
> A wait operation, attach process, or yield was attempted from a DPC
> routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
> Any idea about it? I do have a DPC routine and I am calling
> KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
> KeReleaseSpinLock() functions in that routine.
>
> Please help!
> Thanks in advance.
> -Fareed.


You are currently subscribed to ntdev as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

----------------------------------------------------------------------

Subject: Re: Blue screen
From: “Roddy, Mark”
Date: Thu, 20 Apr 2000 14:32:11 -0400
X-Message-Number: 11

No, it is not a problem to call KeAcquireSpinLock at DISPATCH_LEVEL, it is
simply a performance optimization to use KeAcquireSpinLockAtDpcLevel
instead. There is some other problem in his dpc routine.

> -----Original Message-----
> From: Neelay Das [mailto:xxxxx@netlab.hcltech.com]
> Sent: Thursday, April 20, 2000 8:46 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Blue screen
>
>
> Hi,
> The problem is that you can call the KeAcquireSpinLock() and
> KeReleaseSpinLock() only at IRQLs less than dispatch level
> since in the
> process of acquiring the lock first the IRQL is raised to
> dispatch level
> from the old IRQL and then the lock is acquired. Since in
> your DPC routine
> you’ll already be runing at dispatch level IRQL you should
> use the routines
> KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
> respectively acquire and release spin locks from your DPC
> routines. Hope
> this is of some help.
>
> Thanks,
> -Neelay
>
> “Fareeduddin A. Mohammed” wrote:
>
> > Hi All.,
> >
> > I am getting a blue screen with the following message:
> >
> > A wait operation, attach process, or yield was attempted from a DPC
> > routine. with bugcheck code as 0x000000b8 and all four
> parameters as 0.
> > Any idea about it? I do have a DPC routine and I am calling
> > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
> > KeReleaseSpinLock() functions in that routine.
> >
> > Please help!
> > Thanks in advance.
> > -Fareed.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

----------------------------------------------------------------------

Subject: Re: Blue screen
From: Shweta Dubey
Date: Thu, 20 Apr 2000 15:28:42 -0400 (EDT)
X-Message-Number: 12

The problem is that you CANNOT wait on an event/object for a non-zero
interval of time at a raised IRQL. Any IRQL >= DISPATCH_LEVEL is considered
raised IRQL. Calling KeAcquireSpinLock() in code running already at
DISPATCH_LEVEL is OK. It’s just that if you call
KeAcquireSpinLockAtDispatchLevel(), the IRQL will not have to be raised, and
hence is more efficient. But you have to be very sure that you indeed will
be running at DISPATCH_LEVEL in such cases. In codes that “might be” running
at < DISPATCH_LEVEL in some cases, you should always use
KeAcquireSpinLock().

NB: DPCs are always running at DISPATCH LEVEL. So you can safely call
KeAcquireSpinLockAtDispatchLevel, but that won’t solve the problem.

If possible, remove the Stall() function, OR, queue the request to a worker
thread, and call stall there. (These threads always run at PASSIVE_LEVEL)

That should help.
Shweta.

Hi,
The problem is that you can call the KeAcquireSpinLock() and
KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
process of acquiring the lock first the IRQL is raised to dispatch level
from the old IRQL and then the lock is acquired. Since in your DPC routine
you’ll already be runing at dispatch level IRQL you should use the routines
KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
respectively acquire and release spin locks from your DPC routines. Hope
this is of some help.

Thanks,
-Neelay

“Fareeduddin A. Mohammed” wrote:

> Hi All.,
>
> I am getting a blue screen with the following message:
>
> A wait operation, attach process, or yield was attempted from a DPC
> routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
> Any idea about it? I do have a DPC routine and I am calling
> KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
> KeReleaseSpinLock() functions in that routine.
>
> Please help!
> Thanks in advance.
> -Fareed.


You are currently subscribed to ntdev as: xxxxx@techie.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)


FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

----------------------------------------------------------------------

Subject: Re: Blue screen
From: “Fareeduddin A. Mohammed”
Date: Thu, 20 Apr 2000 14:56:28 -0500
X-Message-Number: 13

This is a multi-part message in MIME format.
--------------3B0B0A298262A4B4FDF029F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thank you very much to all of those who answered to my query.
The problem was that I was calling another function from within my dpc
routine
and that function was waiting using a KeWaitforsingleobject() function. In
the
DDK documentation it is given that KeWaitXXX shouldn’t be call from DPC
routine. When I removed this wait it is not crashing.

Thanks
-Fareed

“Roddy, Mark” wrote:

> No, it is not a problem to call KeAcquireSpinLock at DISPATCH_LEVEL, it is
> simply a performance optimization to use KeAcquireSpinLockAtDpcLevel
> instead. There is some other problem in his dpc routine.
>
> > -----Original Message-----
> > From: Neelay Das [mailto:xxxxx@netlab.hcltech.com]
> > Sent: Thursday, April 20, 2000 8:46 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Blue screen
> >
> >
> > Hi,
> > The problem is that you can call the KeAcquireSpinLock() and
> > KeReleaseSpinLock() only at IRQLs less than dispatch level
> > since in the
> > process of acquiring the lock first the IRQL is raised to
> > dispatch level
> > from the old IRQL and then the lock is acquired. Since in
> > your DPC routine
> > you’ll already be runing at dispatch level IRQL you should
> > use the routines
> > KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
> > respectively acquire and release spin locks from your DPC
> > routines. Hope
> > this is of some help.
> >
> > Thanks,
> > -Neelay
> >
> > “Fareeduddin A. Mohammed” wrote:
> >
> > > Hi All.,
> > >
> > > I am getting a blue screen with the following message:
> > >
> > > A wait operation, attach process, or yield was attempted from a DPC
> > > routine. with bugcheck code as 0x000000b8 and all four
> > parameters as 0.
> > > Any idea about it? I do have a DPC routine and I am calling
> > > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
> > > KeReleaseSpinLock() functions in that routine.
> > >
> > > Please help!
> > > Thanks in advance.
> > > -Fareed.
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@sigmatel.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

--------------3B0B0A298262A4B4FDF029F1
Content-Type: text/x-vcard; charset=us-ascii;
name=“fareed.vcf”
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fareeduddin A. Mohammed
Content-Disposition: attachment;
filename=“fareed.vcf”

begin:vcard
n:Mohammed;Fareeduddin
tel;home:512 836 8636
tel;work:512 381 3749
x-mozilla-html:FALSE
org:SigmaTel Inc.
adr:;;;;;;
version:2.1
email;internet:xxxxx@sigmatel.com
fn:Fareeduddin A. Mohammed
end:vcard

--------------3B0B0A298262A4B4FDF029F1–

----------------------------------------------------------------------

Subject: Re: Blue screen
From: “Roddy, Mark”
Date: Thu, 20 Apr 2000 15:45:02 -0400
X-Message-Number: 14

>
> If possible, remove the Stall() function, OR, queue the
> request to a worker
> thread, and call stall there. (These threads always run at
> PASSIVE_LEVEL)
>
> That should help.

Why?

My ddk says: “Callers of KeStallExecutionProcessor can be running at any
IRQL.”

----------------------------------------------------------------------

Subject: Re: Blue screen
From: Shweta Dubey
Date: Thu, 20 Apr 2000 17:20:57 -0400 (EDT)
X-Message-Number: 15

I am sorry, I messed up KeWait() and Stall() functions. As it turned out, he
was eventually calling KeWait() function. Stall() does not “wait” for any
object/event, but freezes the processor, and can be running at any irql.

You are right, sorry for mix-up.

Shweta.

>
> If possible, remove the Stall() function, OR, queue the
> request to a worker
> thread, and call stall there. (These threads always run at
> PASSIVE_LEVEL)
>
> That should help.

Why?

My ddk says: “Callers of KeStallExecutionProcessor can be running at any
IRQL.”


You are currently subscribed to ntdev as: xxxxx@techie.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

_
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

----------------------------------------------------------------------

Subject: CreateProcess and consoles
From: Phillip Susi
Date: Thu, 20 Apr 2000 19:50:06 -0400
X-Message-Number: 16

What is the difference between using CREATE_NEW_CONSOLE and
DETACHED_PROCESS flags to CreateProcess?

----------------------------------------------------------------------

Subject: PsCreateSystemThread Question
From: xxxxx@usa.net
Date: Thu, 20 Apr 2000 20:17:49
X-Message-Number: 17

Hello,

Can I call PsCreateSystemThread in my AddDevice() routine instead of
DriverEntry() ? (DDK seems to say that threads are created during Driver
Initialization)

The reason I need to do this is because I need to pass the FDO_DevExtn to
the thread_func as the argument (i.e. “StartContext” argument to
PsCreateSystemThread). And the FDO_DevExtn is created only in AddDevice()
[it doesn’t exist in DriverEntry()].

Thanks in advance for your help.

Puja

----------------------------------------------------------------------

Subject: RE: PsCreateSystemThread Question
From: “COX,DAVID (HP-Roseville,ex1)” <david_cox2>
Date: Thu, 20 Apr 2000 17:30:17 -0700
X-Message-Number: 18

Sure you can delay creating the thread. But there are other ways you
can pass structures to a thread after it is already running. The
simplest would be to have it wait on an event until you signal an
event indicating you’ve placed the relevant data in some shared
memory location.

-----------------------------------------------------------------------
Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: xxxxx@usa.net [mailto:xxxxx@usa.net]
Sent: Thursday, April 20, 2000 1:18 PM
To: NT Developers Interest List
Subject: [ntdev] PsCreateSystemThread Question

Hello,

Can I call PsCreateSystemThread in my AddDevice() routine instead of
DriverEntry() ? (DDK seems to say that threads are created during Driver
Initialization)

The reason I need to do this is because I need to pass the FDO_DevExtn to
the thread_func as the argument (i.e. “StartContext” argument to
PsCreateSystemThread). And the FDO_DevExtn is created only in AddDevice()
[it doesn’t exist in DriverEntry()].

Thanks in advance for your help.

Puja


You are currently subscribed to ntdev as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

----------------------------------------------------------------------

Subject: RE: PsCreateSystemThread Question
From: “Jamey Kirby”
Date: Thu, 20 Apr 2000 18:11:14 -0700
X-Message-Number: 19

you can create a system thread any time you like as long as you are at
passive level.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@usa.net
> Sent: Thursday, April 20, 2000 8:18 PM
> To: NT Developers Interest List
> Subject: [ntdev] PsCreateSystemThread Question
>
>
> Hello,
>
> Can I call PsCreateSystemThread in my AddDevice() routine instead of
> DriverEntry() ? (DDK seems to say that threads are created during Driver
> Initialization)
>
> The reason I need to do this is because I need to pass the FDO_DevExtn to
> the thread_func as the argument (i.e. “StartContext” argument to
> PsCreateSystemThread). And the FDO_DevExtn is created only in AddDevice()
> [it doesn’t exist in DriverEntry()].
>
> Thanks in advance for your help.
>
> Puja
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

----------------------------------------------------------------------

Subject: Soft Affinity of Thread
From: xxxxx@usa.net
Date: Thu, 20 Apr 2000 22:8:19
X-Message-Number: 20

Hello,

How can one set the soft-affinity (and hard-affinity) of a Driver-created
thread to a particular processor ?

Thank you for your help!
Puja

----------------------------------------------------------------------

Subject: Re: Blue screen
From: Neelay Das
Date: Fri, 21 Apr 2000 09:15:09 +0530
X-Message-Number: 21

Hi,
Thanks for correcting me out here. Actually, from the information Fareed
had
given it appeared surely to be an IRQL problem. Before replying, I checked
up
the DDK documentation for KeStallExecutionProcessor(), KeAcquireSpinLock()
and
KeReleaseSpinLock() and since KeStallExecutionProcessor() can be called at
any
IRQL, KeAcquireSpinLock() seemed to be the only culprit. But I was not too
sure
on that, as the DDK docs clearly say that KeAcquireSpinLock() can be called
at
IRQL <= DISPATCH_LEVEL.
Anyway, sorry for any mix-up, it might have caused.

Thanks,
Neelay

Shweta Dubey wrote:

> The problem is that you CANNOT wait on an event/object for a non-zero
> interval of time at a raised IRQL. Any IRQL >= DISPATCH_LEVEL is
considered
> raised IRQL. Calling KeAcquireSpinLock() in code running already at
> DISPATCH_LEVEL is OK. It’s just that if you call
> KeAcquireSpinLockAtDispatchLevel(), the IRQL will not have to be raised,
and
> hence is more efficient. But you have to be very sure that you indeed will
> be running at DISPATCH_LEVEL in such cases. In codes that “might be”
running
> at < DISPATCH_LEVEL in some cases, you should always use
> KeAcquireSpinLock().
>
> NB: DPCs are always running at DISPATCH LEVEL. So you can safely call
> KeAcquireSpinLockAtDispatchLevel, but that won’t solve the problem.
>
> If possible, remove the Stall() function, OR, queue the request to a
worker
> thread, and call stall there. (These threads always run at
PASSIVE_LEVEL)
>
> That should help.
> Shweta.
>
> Hi,
> The problem is that you can call the KeAcquireSpinLock() and
> KeReleaseSpinLock() only at IRQLs less than dispatch level since in the
> process of acquiring the lock first the IRQL is raised to dispatch level
> from the old IRQL and then the lock is acquired. Since in your DPC routine
> you’ll already be runing at dispatch level IRQL you should use the
routines
> KeAcquireSpinLockAtDpcLevel() and KeReleaseSpinLockFromDpcLevel() to
> respectively acquire and release spin locks from your DPC routines. Hope
> this is of some help.
>
> Thanks,
> -Neelay
>
> “Fareeduddin A. Mohammed” wrote:
>
> > Hi All.,
> >
> > I am getting a blue screen with the following message:
> >
> > A wait operation, attach process, or yield was attempted from a DPC
> > routine. with bugcheck code as 0x000000b8 and all four parameters as 0.
> > Any idea about it? I do have a DPC routine and I am calling
> > KeStallExecutionProcessor(50L) and also KeAcquireSpinLock() and
> > KeReleaseSpinLock() functions in that routine.
> >
> > Please help!
> > Thanks in advance.
> > -Fareed.
>
> —
> You are currently subscribed to ntdev as: xxxxx@techie.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> ______________________________________________
> FREE Personalized Email at Mail.com
> Sign up at http://www.mail.com/?sr=signup



END OF DIGEST


You are currently subscribed to ntdev as: xxxxx@ICED.COM
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</david_cox2></david_cox2>