usbsamp WdfRequestRetrieveOutputWdmMdl failure question
in [Device Drivers]
|
From: Doron Holan [MSFT] on 6 Jan 2010 18:35 use a spinlock to synchronize read/write access to the buffer in your device context between the EvtIoRead routine and your read completion routine d -- This posting is provided "AS IS" with no warranties, and confers no rights. "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message news:8E2AEFBD-F92A-40DD-A855-43A218E8DCE8(a)microsoft.com... > Hi Doron, > > I have implemented the iso continuous reader by issueing multipe read > requests and resending the request inside the completion routine. > > Now I have another question: In my completion routine, I copy all the data > acquired to a buffer in my device context. When the read request comes, it > will just read back the data in that buffer. What kind of synchronization > technique should I use to make sure I don't read the data from the buffer > when my completion routine is updating it? > > I checked both waitlock and spinlock and found waitlock is only for > PASSIVE_LEVEL and spinlock is for DISPATCH_LEVEL or higher. Is there > anything > else that I can use to sync between the IoRead and DPC (completion > routine)? > > > Thanks. > > G. > > > > "Doron Holan [MSFT]" wrote: > >> format the request, send it down and set the WDFMEMORY you are using in >> the >> read as the context for your io completion routine >> >> d >> >> -- >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message >> news:E2B28013-C677-4F2A-AF6D-979159CF1EBC(a)microsoft.com... >> > Thanks Doron, that make sense. >> > >> > My question now is: in this case, what should I do in order to read iso >> > pipe >> > from a read thread? I am just trying to implement something like the >> > continuous reader for BULK and INT pipe. >> > >> > Frank. >> > >> > >> > >> > >> > >> > "Doron Holan [MSFT]" wrote: >> > >> >> WdfRequestRetrieveOutputWdmMdl only works for requests presented to >> >> you >> >> via >> >> a WDFQUEUE. it does not work with requests you create yourself >> >> (because >> >> there is no current stack location which is formatted) >> >> >> >> >> > >> . >>
From: gti4ever on 7 Jan 2010 05:12 Hi Doron, The spinlock worked. However, now I am facing another issue. It seems like my way of implementing the ISO continuous reader is not cencel-safe. Since I am using driver created requests to read ISO stream, can I create a manual queue and forward all the driver created requests to it and let framework handles all the cancellation stuff? Thanks. G. "Doron Holan [MSFT]" wrote: > use a spinlock to synchronize read/write access to the buffer in your device > context between the EvtIoRead routine and your read completion routine > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message > news:8E2AEFBD-F92A-40DD-A855-43A218E8DCE8(a)microsoft.com... > > Hi Doron, > > > > I have implemented the iso continuous reader by issueing multipe read > > requests and resending the request inside the completion routine. > > > > Now I have another question: In my completion routine, I copy all the data > > acquired to a buffer in my device context. When the read request comes, it > > will just read back the data in that buffer. What kind of synchronization > > technique should I use to make sure I don't read the data from the buffer > > when my completion routine is updating it? > > > > I checked both waitlock and spinlock and found waitlock is only for > > PASSIVE_LEVEL and spinlock is for DISPATCH_LEVEL or higher. Is there > > anything > > else that I can use to sync between the IoRead and DPC (completion > > routine)? > > > > > > Thanks. > > > > G. > > > > > > > > "Doron Holan [MSFT]" wrote: > > > >> format the request, send it down and set the WDFMEMORY you are using in > >> the > >> read as the context for your io completion routine > >> > >> d > >> > >> -- > >> > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> > >> > >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message > >> news:E2B28013-C677-4F2A-AF6D-979159CF1EBC(a)microsoft.com... > >> > Thanks Doron, that make sense. > >> > > >> > My question now is: in this case, what should I do in order to read iso > >> > pipe > >> > from a read thread? I am just trying to implement something like the > >> > continuous reader for BULK and INT pipe. > >> > > >> > Frank. > >> > > >> > > >> > > >> > > >> > > >> > "Doron Holan [MSFT]" wrote: > >> > > >> >> WdfRequestRetrieveOutputWdmMdl only works for requests presented to > >> >> you > >> >> via > >> >> a WDFQUEUE. it does not work with requests you create yourself > >> >> (because > >> >> there is no current stack location which is formatted) > >> >> > >> >> > >> > > >> . > >> > . >
From: Doron Holan [MSFT] on 7 Jan 2010 12:57 if you created the request, only you can cancel them. the app will never cancel request you created. if you want to cancel a request you sent down the stack, call WdfRequestCancelSentRequest. you cannot put driver created requests into a WDFQUEUE d -- This posting is provided "AS IS" with no warranties, and confers no rights. "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message news:FD680F4D-19AD-4843-9CD8-1A6AA991D66F(a)microsoft.com... > Hi Doron, > > The spinlock worked. However, now I am facing another issue. It seems like > my way of implementing the ISO continuous reader is not cencel-safe. > > Since I am using driver created requests to read ISO stream, can I create > a > manual queue and forward all the driver created requests to it and let > framework handles all the cancellation stuff? > > Thanks. > > G. > > "Doron Holan [MSFT]" wrote: > >> use a spinlock to synchronize read/write access to the buffer in your >> device >> context between the EvtIoRead routine and your read completion routine >> >> d >> >> -- >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message >> news:8E2AEFBD-F92A-40DD-A855-43A218E8DCE8(a)microsoft.com... >> > Hi Doron, >> > >> > I have implemented the iso continuous reader by issueing multipe read >> > requests and resending the request inside the completion routine. >> > >> > Now I have another question: In my completion routine, I copy all the >> > data >> > acquired to a buffer in my device context. When the read request comes, >> > it >> > will just read back the data in that buffer. What kind of >> > synchronization >> > technique should I use to make sure I don't read the data from the >> > buffer >> > when my completion routine is updating it? >> > >> > I checked both waitlock and spinlock and found waitlock is only for >> > PASSIVE_LEVEL and spinlock is for DISPATCH_LEVEL or higher. Is there >> > anything >> > else that I can use to sync between the IoRead and DPC (completion >> > routine)? >> > >> > >> > Thanks. >> > >> > G. >> > >> > >> > >> > "Doron Holan [MSFT]" wrote: >> > >> >> format the request, send it down and set the WDFMEMORY you are using >> >> in >> >> the >> >> read as the context for your io completion routine >> >> >> >> d >> >> >> >> -- >> >> >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. >> >> >> >> >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message >> >> news:E2B28013-C677-4F2A-AF6D-979159CF1EBC(a)microsoft.com... >> >> > Thanks Doron, that make sense. >> >> > >> >> > My question now is: in this case, what should I do in order to read >> >> > iso >> >> > pipe >> >> > from a read thread? I am just trying to implement something like >> >> > the >> >> > continuous reader for BULK and INT pipe. >> >> > >> >> > Frank. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > "Doron Holan [MSFT]" wrote: >> >> > >> >> >> WdfRequestRetrieveOutputWdmMdl only works for requests presented to >> >> >> you >> >> >> via >> >> >> a WDFQUEUE. it does not work with requests you create yourself >> >> >> (because >> >> >> there is no current stack location which is formatted) >> >> >> >> >> >> >> >> > >> >> . >> >> >> . >>
From: gti4ever on 8 Jan 2010 10:05 Sorry Doron, one last question. I implemented the cancel function to cancel all the iso read requests and everything seems to be ok and all the request objects got deleted at the end. Now I found one critical issue. when I unplug my USB device when my iso continuous reader is still reading, I can use D0Exit to cancel all the pending read request and that seems to work ok and Windbg lm command shows the driver got unloaded. However, after this, if I plug back in my USB device and start the iso read again, my driver crashes immediately. The minidump shows the driver crashed either when my continuous reader trying to save the iso stream to the buffer in device context or when the IoRead is trying to read the data from that buffer. I have only managed to reproduce this once or twice. According to Windbg, all the buffer pointers seems to be reasonable, definitely not NULL. What could cause this problem? Is it possible my driver is not unloaded correctly and driver end up using some invalid/old context? Thanks. G. "Doron Holan [MSFT]" wrote: > if you created the request, only you can cancel them. the app will never > cancel request you created. if you want to cancel a request you sent down > the stack, call WdfRequestCancelSentRequest. you cannot put driver created > requests into a WDFQUEUE > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message > news:FD680F4D-19AD-4843-9CD8-1A6AA991D66F(a)microsoft.com... > > Hi Doron, > > > > The spinlock worked. However, now I am facing another issue. It seems like > > my way of implementing the ISO continuous reader is not cencel-safe. > > > > Since I am using driver created requests to read ISO stream, can I create > > a > > manual queue and forward all the driver created requests to it and let > > framework handles all the cancellation stuff? > > > > Thanks. > > > > G. > > > > "Doron Holan [MSFT]" wrote: > > > >> use a spinlock to synchronize read/write access to the buffer in your > >> device > >> context between the EvtIoRead routine and your read completion routine > >> > >> d > >> > >> -- > >> > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> > >> > >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message > >> news:8E2AEFBD-F92A-40DD-A855-43A218E8DCE8(a)microsoft.com... > >> > Hi Doron, > >> > > >> > I have implemented the iso continuous reader by issueing multipe read > >> > requests and resending the request inside the completion routine. > >> > > >> > Now I have another question: In my completion routine, I copy all the > >> > data > >> > acquired to a buffer in my device context. When the read request comes, > >> > it > >> > will just read back the data in that buffer. What kind of > >> > synchronization > >> > technique should I use to make sure I don't read the data from the > >> > buffer > >> > when my completion routine is updating it? > >> > > >> > I checked both waitlock and spinlock and found waitlock is only for > >> > PASSIVE_LEVEL and spinlock is for DISPATCH_LEVEL or higher. Is there > >> > anything > >> > else that I can use to sync between the IoRead and DPC (completion > >> > routine)? > >> > > >> > > >> > Thanks. > >> > > >> > G. > >> > > >> > > >> > > >> > "Doron Holan [MSFT]" wrote: > >> > > >> >> format the request, send it down and set the WDFMEMORY you are using > >> >> in > >> >> the > >> >> read as the context for your io completion routine > >> >> > >> >> d > >> >> > >> >> -- > >> >> > >> >> This posting is provided "AS IS" with no warranties, and confers no > >> >> rights. > >> >> > >> >> > >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message > >> >> news:E2B28013-C677-4F2A-AF6D-979159CF1EBC(a)microsoft.com... > >> >> > Thanks Doron, that make sense. > >> >> > > >> >> > My question now is: in this case, what should I do in order to read > >> >> > iso > >> >> > pipe > >> >> > from a read thread? I am just trying to implement something like > >> >> > the > >> >> > continuous reader for BULK and INT pipe. > >> >> > > >> >> > Frank. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > "Doron Holan [MSFT]" wrote: > >> >> > > >> >> >> WdfRequestRetrieveOutputWdmMdl only works for requests presented to > >> >> >> you > >> >> >> via > >> >> >> a WDFQUEUE. it does not work with requests you create yourself > >> >> >> (because > >> >> >> there is no current stack location which is formatted) > >> >> >> > >> >> >> > >> >> > > >> >> . > >> >> > >> . > >> > . >
From: Doron Holan [MSFT] on 8 Jan 2010 13:17
no idea what is going here unless you have stale pointers floating around in your code and you are touching the old context from the now unplugged device. do you have any global variables where you are storing WDF objects or pointers? -- This posting is provided "AS IS" with no warranties, and confers no rights. "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message news:B385710F-56E3-4DDA-8BCC-7B49B14CB137(a)microsoft.com... > Sorry Doron, one last question. > > I implemented the cancel function to cancel all the iso read requests and > everything seems to be ok and all the request objects got deleted at the > end. > > Now I found one critical issue. when I unplug my USB device when my iso > continuous reader is still reading, I can use D0Exit to cancel all the > pending read request and that seems to work ok and Windbg lm command shows > the driver got unloaded. > > However, after this, if I plug back in my USB device and start the iso > read > again, my driver crashes immediately. The minidump shows the driver > crashed > either when my continuous reader trying to save the iso stream to the > buffer > in device context or when the IoRead is trying to read the data from that > buffer. > > I have only managed to reproduce this once or twice. According to Windbg, > all the buffer pointers seems to be reasonable, definitely not NULL. What > could cause this problem? Is it possible my driver is not unloaded > correctly > and driver end up using some invalid/old context? > > Thanks. > > G. > > "Doron Holan [MSFT]" wrote: > >> if you created the request, only you can cancel them. the app will never >> cancel request you created. if you want to cancel a request you sent >> down >> the stack, call WdfRequestCancelSentRequest. you cannot put driver >> created >> requests into a WDFQUEUE >> >> d >> >> -- >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message >> news:FD680F4D-19AD-4843-9CD8-1A6AA991D66F(a)microsoft.com... >> > Hi Doron, >> > >> > The spinlock worked. However, now I am facing another issue. It seems >> > like >> > my way of implementing the ISO continuous reader is not cencel-safe. >> > >> > Since I am using driver created requests to read ISO stream, can I >> > create >> > a >> > manual queue and forward all the driver created requests to it and let >> > framework handles all the cancellation stuff? >> > >> > Thanks. >> > >> > G. >> > >> > "Doron Holan [MSFT]" wrote: >> > >> >> use a spinlock to synchronize read/write access to the buffer in your >> >> device >> >> context between the EvtIoRead routine and your read completion routine >> >> >> >> d >> >> >> >> -- >> >> >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. >> >> >> >> >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message >> >> news:8E2AEFBD-F92A-40DD-A855-43A218E8DCE8(a)microsoft.com... >> >> > Hi Doron, >> >> > >> >> > I have implemented the iso continuous reader by issueing multipe >> >> > read >> >> > requests and resending the request inside the completion routine. >> >> > >> >> > Now I have another question: In my completion routine, I copy all >> >> > the >> >> > data >> >> > acquired to a buffer in my device context. When the read request >> >> > comes, >> >> > it >> >> > will just read back the data in that buffer. What kind of >> >> > synchronization >> >> > technique should I use to make sure I don't read the data from the >> >> > buffer >> >> > when my completion routine is updating it? >> >> > >> >> > I checked both waitlock and spinlock and found waitlock is only for >> >> > PASSIVE_LEVEL and spinlock is for DISPATCH_LEVEL or higher. Is there >> >> > anything >> >> > else that I can use to sync between the IoRead and DPC (completion >> >> > routine)? >> >> > >> >> > >> >> > Thanks. >> >> > >> >> > G. >> >> > >> >> > >> >> > >> >> > "Doron Holan [MSFT]" wrote: >> >> > >> >> >> format the request, send it down and set the WDFMEMORY you are >> >> >> using >> >> >> in >> >> >> the >> >> >> read as the context for your io completion routine >> >> >> >> >> >> d >> >> >> >> >> >> -- >> >> >> >> >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> >> rights. >> >> >> >> >> >> >> >> >> "gti4ever" <gti4ever(a)discussions.microsoft.com> wrote in message >> >> >> news:E2B28013-C677-4F2A-AF6D-979159CF1EBC(a)microsoft.com... >> >> >> > Thanks Doron, that make sense. >> >> >> > >> >> >> > My question now is: in this case, what should I do in order to >> >> >> > read >> >> >> > iso >> >> >> > pipe >> >> >> > from a read thread? I am just trying to implement something like >> >> >> > the >> >> >> > continuous reader for BULK and INT pipe. >> >> >> > >> >> >> > Frank. >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > "Doron Holan [MSFT]" wrote: >> >> >> > >> >> >> >> WdfRequestRetrieveOutputWdmMdl only works for requests presented >> >> >> >> to >> >> >> >> you >> >> >> >> via >> >> >> >> a WDFQUEUE. it does not work with requests you create yourself >> >> >> >> (because >> >> >> >> there is no current stack location which is formatted) >> >> >> >> >> >> >> >> >> >> >> > >> >> >> . >> >> >> >> >> . >> >> >> . >> |