Write to file on an interrupt
in [Device Drivers]
|
Prev: Amcap (USBPCCamPlus) doesn't seem to work, does it work for you?
Next: Time between sending and receiving of Ethernet Packets
From: Simon Richter on 16 Jun 2010 05:10 Hi, On 2010å¹´06æ16æ¥ 05:44, Mohit Gupta wrote: > While dedicated thread is reading from a dedicated non-paged memory, it may > get interrupted again by the same interrupt. Interrupt routine can then > overwrite data in dedicated memory. So use a buffer that has an appropriate amount of space for several entries. If the buffer ever gets full, events will be lost, there is no way to avoid that. Simon
From: Krzysztof Uchronski on 16 Jun 2010 07:45 One of the solutions for your problem might be to schedule DPC from your ISR and then from DPC insert new item to a queue that is processed by a worker thread. Access to the queue has to synchronized to avoid "corruption" (e.g. by spin lock). Worker thread is responsible for dequeuing and file access. Btw. to be precise SynchCritSection routine (KeSynchronizeExecution) runs at the same IRQL as ISR with which it is associated. Same for interrupt spin locks. Kris -----Original Message----- From: Mohit Gupta [mailto:MohitGupta(a)discussions.microsoft.com] Posted At: Wednesday, June 16, 2010 4:45 AM Posted To: microsoft.public.development.device.drivers Conversation: Write to file on an interrupt Subject: Re: Write to file on an interrupt If I use dedicated thread which will perform write operations at PASSIVE_LEVEL, then following problem can arise: While dedicated thread is reading from a dedicated non-paged memory, it may get interrupted again by the same interrupt. Interrupt routine can then overwrite data in dedicated memory. When thread execution is restored it could end-up writing inconsistent data in the file, that is data from 2nd interrupt rather than 1st. If KeSynchronizeInterrupt routiune is used to synchronise read/write operation, thread IRQL will raise to DISPATCH_LEVEL, but that would cause another problem becasue file operations can't be performed at DISPATCH_LEVEL. More help required :) "x64" wrote: > > How can I write to file if my interrupt function is fired? I know > > can't write > > to file from an interrupt function because it's running at DIRQL. > > What's the > > way around? > > Use dedicated thread in conjunction with non-paged buffer for data > which you want to write. > . >
From: Doron Holan [MSFT] on 16 Jun 2010 17:16 a better option would be to use ETW. you fire the ETW event from your DPCForIsr and then your user mode application can listen for the ETW event and react any way it wants to it (log to a file, log to memory, send it over the network) d "Mohit Gupta" wrote in message news:8081FC51-E3A2-4230-ABF5-270E7357B4C7(a)microsoft.com... Thanks Tim. KdPrint or DbgPrint is definitely a better option, however, my requirement at this moment is to write it to file :) "Tim Roberts" wrote: > Mohit Gupta <MohitGupta(a)discussions.microsoft.com> wrote: > > > >How can I write to file if my interrupt function is fired? I know can't > >write > >to file from an interrupt function because it's running at DIRQL. What's > >the > >way around? > > > >This is what I want to do: > > > >Whenever an interrupt is fired, I want to log the event to a file in my > >own > >format (for debugging and testing purposes). > > The RIGHT way to do this is to use KdPrint or DbgPrint to send the message > to the kernel debug buffer. Then, you can use the DebugView tool to > capture the messages to memory or log them to file. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc. > . >
From: eagersh on 17 Jun 2010 12:59 On Jun 15, 9:44 pm, Mohit Gupta <MohitGu...(a)discussions.microsoft.com> wrote: > If I use dedicated thread which will perform write operations at > PASSIVE_LEVEL, then following problem can arise: > > While dedicated thread is reading from a dedicated non-paged memory, it may > get interrupted again by the same interrupt. Interrupt routine can then > overwrite data in dedicated memory. When thread execution is restored it > could end-up writing inconsistent data in the file, that is data from 2nd > interrupt rather than 1st. > > If KeSynchronizeInterrupt routiune is used to synchronise read/write > operation, thread IRQL will raise to DISPATCH_LEVEL, but that would cause > another problem becasue file operations can't be performed at DISPATCH_LEVEL. > > More help required :) > And if file operations can't perform at DISPATCH_LEVEL they definitely could not be performed at your ISR. Think in this way. To perform any Disk I/O operations a storage device driver needs to work with its interrupt and its ISR must be called. But when your driver gets an interrupt all other interrupts, including the storage driver which should perform Disk I/O, masked or disable. This is very concise explanation and there are more others reasons why you could not do this. You should change your design. Igor Sharovar
From: Tim Roberts on 18 Jun 2010 01:10
Mohit Gupta <MohitGupta(a)discussions.microsoft.com> wrote: > >KdPrint or DbgPrint is definitely a better option, however, my requirement >at this moment is to write it to file :) DebugView can write the DbgPrint logs to file. Use the tools that are at your disposal. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |