DRIVER_IRQL_NOT_LESS_OR_EQUAL usbehci.sys
in [Device Drivers]
|
From: Don Burn on 6 Jul 2005 07:57 When you say usbehci.sys crashes the system, unless you are doing a ton of analysis you are saying that the system crashes in usbehci.sys. I suspect is you check things carefully you may find that your driver is to blame. I'm not saying it isin't usbehci.sys, but in a long time of system programming, the claims the system is causing a crash, are wrong 99.9% of the time it is the user supplied driver. -- Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting Remove StopSpam from the email to reply <v_mirgorodsky(a)yahoo.com> wrote in message news:1120649490.290168.154940(a)g47g2000cwa.googlegroups.com... > Hi, > > Some time ago I experienced the same problem with usbehci.sys. I need > to admit that USB 2.0 stack implementation by Microsoft is very > efficient in the sense of pefomance/throughput, but not bug-free. > > I had very close loop with only my completion routine involved and with > the same URBs recycling all the time with once and forewer memory > buffers fixed with every URB with the same allocated IRPs and so on. I > *commented out* ALL data processing inside completion routine and the > rest of my driver. I started Driver Verifier and assured that the Init > part of it does not corrupt any memory in the system. Then I started > the stream not by sending commands to my USB device, but toggling > hardware switch. > > Depending on data throughput usbehci.sys crashes the system at random > times. As more data transfered across USB link as more likely system > will crash sooner. It will crash system quickly for sure if you have > more than two URBs queued in the same time. With two URBs active crash > is very unlikely, but still possible. At least system did not crashed > during over-weekend testing (more than 50 hours). The only difference > between my case and yours that my device may transfer about 45MB/s > across USB link. > > Microsoft folks always advocate usbehci.sys all the time. And all the > time news-groups mentioning the random crashes in the usbehci.sys. All > these cases have the only common thing - in every case driver writters > are targeting maximum perfomance, minimum latency or whatever edge > condition from usbehci.sys. > > With best regards, > Vladimir S. Mirgorodsky > > zantetsu wrote: >> Thank you for your rensponse. >> >> I thought that I might fix the problem while I was changing the source >> file to serialize. >> So I returned to the source file wasn't serialized. >> And I checked the difference and made some modifications to the source >> file. >> But the problem occured again. >> >> I saw the topic as follows. >> USB2.0 EHCI (usbehci.sys) behaviour on XP SP1 >> http://groups.google.co.jp/group/microsoft.public.development.device.drivers/browse_frm/thread/5d19708257497b3f/e79817de4dc089b1?q=usb2.0+ehci&rnum=1#e79817de4dc089b1 >> Do you think that the topic relates to the problem? >
From: v_mirgorodsky on 6 Jul 2005 08:17 Hello Don, I totally agree with you. In all cases, except mentioned, I was able to track error down in my code, even BSOD screen was blaming some other part of the system doing wrong things. In the described case I spent a week or so trying to trace down the issue. As a result, I created the limited sand-box, where only usbehci.sys and completion routine were involved. The crash was still there, consequently, usbehci.sys has a bug, which may be reproduced only within some high-load circumstances. BTW, crash probability gets even higher on SMP machine. As I wrote in my previous post, I found work-around for this issue. I submit only two IRP's to USB stack and I get acceptable trade-off between created latency and desired throughput. Now my driver is able to transfer about 45MBytes/s and works stable with variety of USB stacks and USB hardware. With best regards, Vladimir S. Mirgorodsky Don Burn wrote: > When you say usbehci.sys crashes the system, unless you are doing a ton of > analysis you are saying that the system crashes in usbehci.sys. I suspect > is you check things carefully you may find that your driver is to blame. > I'm not saying it isin't usbehci.sys, but in a long time of system > programming, the claims the system is causing a crash, are wrong 99.9% of > the time it is the user supplied driver. > > > -- > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > <v_mirgorodsky(a)yahoo.com> wrote in message > news:1120649490.290168.154940(a)g47g2000cwa.googlegroups.com... > > Hi, > > > > Some time ago I experienced the same problem with usbehci.sys. I need > > to admit that USB 2.0 stack implementation by Microsoft is very > > efficient in the sense of pefomance/throughput, but not bug-free. > > > > I had very close loop with only my completion routine involved and with > > the same URBs recycling all the time with once and forewer memory > > buffers fixed with every URB with the same allocated IRPs and so on. I > > *commented out* ALL data processing inside completion routine and the > > rest of my driver. I started Driver Verifier and assured that the Init > > part of it does not corrupt any memory in the system. Then I started > > the stream not by sending commands to my USB device, but toggling > > hardware switch. > > > > Depending on data throughput usbehci.sys crashes the system at random > > times. As more data transfered across USB link as more likely system > > will crash sooner. It will crash system quickly for sure if you have > > more than two URBs queued in the same time. With two URBs active crash > > is very unlikely, but still possible. At least system did not crashed > > during over-weekend testing (more than 50 hours). The only difference > > between my case and yours that my device may transfer about 45MB/s > > across USB link. > > > > Microsoft folks always advocate usbehci.sys all the time. And all the > > time news-groups mentioning the random crashes in the usbehci.sys. All > > these cases have the only common thing - in every case driver writters > > are targeting maximum perfomance, minimum latency or whatever edge > > condition from usbehci.sys. > > > > With best regards, > > Vladimir S. Mirgorodsky > > > > zantetsu wrote: > >> Thank you for your rensponse. > >> > >> I thought that I might fix the problem while I was changing the source > >> file to serialize. > >> So I returned to the source file wasn't serialized. > >> And I checked the difference and made some modifications to the source > >> file. > >> But the problem occured again. > >> > >> I saw the topic as follows. > >> USB2.0 EHCI (usbehci.sys) behaviour on XP SP1 > >> http://groups.google.co.jp/group/microsoft.public.development.device.drivers/browse_frm/thread/5d19708257497b3f/e79817de4dc089b1?q=usb2.0+ehci&rnum=1#e79817de4dc089b1 > >> Do you think that the topic relates to the problem? > >
From: Alexander Grigoriev on 6 Jul 2005 23:45 I've seen very nasty race condition in USBEHCI, in power management part, but it seems to be gone with post-SP1 USB update. I wonder is SP2 screwed up something again. My opinion about USBEHCI/USBPORT is not good, I've been burned by its genuine bugs several times. "Don Burn" <burn(a)stopspam.acm.org> wrote in message news:DGPye.119$zA.88(a)fe04.lga... > When you say usbehci.sys crashes the system, unless you are doing a ton of > analysis you are saying that the system crashes in usbehci.sys. I suspect > is you check things carefully you may find that your driver is to blame. > I'm not saying it isin't usbehci.sys, but in a long time of system > programming, the claims the system is causing a crash, are wrong 99.9% of > the time it is the user supplied driver. > > > -- > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > <v_mirgorodsky(a)yahoo.com> wrote in message > news:1120649490.290168.154940(a)g47g2000cwa.googlegroups.com... >> Hi, >> >> Some time ago I experienced the same problem with usbehci.sys. I need >> to admit that USB 2.0 stack implementation by Microsoft is very >> efficient in the sense of pefomance/throughput, but not bug-free. >> >> I had very close loop with only my completion routine involved and with >> the same URBs recycling all the time with once and forewer memory >> buffers fixed with every URB with the same allocated IRPs and so on. I >> *commented out* ALL data processing inside completion routine and the >> rest of my driver. I started Driver Verifier and assured that the Init >> part of it does not corrupt any memory in the system. Then I started >> the stream not by sending commands to my USB device, but toggling >> hardware switch. >> >> Depending on data throughput usbehci.sys crashes the system at random >> times. As more data transfered across USB link as more likely system >> will crash sooner. It will crash system quickly for sure if you have >> more than two URBs queued in the same time. With two URBs active crash >> is very unlikely, but still possible. At least system did not crashed >> during over-weekend testing (more than 50 hours). The only difference >> between my case and yours that my device may transfer about 45MB/s >> across USB link. >> >> Microsoft folks always advocate usbehci.sys all the time. And all the >> time news-groups mentioning the random crashes in the usbehci.sys. All >> these cases have the only common thing - in every case driver writters >> are targeting maximum perfomance, minimum latency or whatever edge >> condition from usbehci.sys. >> >> With best regards, >> Vladimir S. Mirgorodsky >> >> zantetsu wrote: >>> Thank you for your rensponse. >>> >>> I thought that I might fix the problem while I was changing the source >>> file to serialize. >>> So I returned to the source file wasn't serialized. >>> And I checked the difference and made some modifications to the source >>> file. >>> But the problem occured again. >>> >>> I saw the topic as follows. >>> USB2.0 EHCI (usbehci.sys) behaviour on XP SP1 >>> http://groups.google.co.jp/group/microsoft.public.development.device.drivers/browse_frm/thread/5d19708257497b3f/e79817de4dc089b1?q=usb2.0+ehci&rnum=1#e79817de4dc089b1 >>> Do you think that the topic relates to the problem? >> > >
From: zantetsu on 7 Jul 2005 00:54 Thank you for your response. I have a question. How many device do you connect? I have only one queue now. So I submit only one IRP to USB stack. But my devices may be connected to same computer. Does the crash depend on the number of connected devices?
From: v_mirgorodsky on 7 Jul 2005 08:02 No, the crush does not depend on number of devices as soon as you connect them to different physical controllers. If you connect the to the same physical controller, then yes, probability of crash gets higher. I have much more sophisticated system, since I need to transfer twice as more data. I have seven URBs and two queues: SubmitQueue and ReceiveQueue. In the beginning five URBs queued into SubmitQueue and two others submited to USB stack. In my completion routine I put received URB into ReceiveQueue and take a new one from SubmitQueue and submit it to USB stack. I track number of URBs submited and keep this number equal two at all times. Then I have a high-priority thread, that processes my data and puts them to my frame buffer. At the moment P4M 2GHz receives about 40MBytes of data without any problems. During work-time I get CPU usage indicator showing about 12-17% load. Hence, this approach works for me, try it for your case, may be it will work for you too. With best regards, Vladimir S. Mirgorodsky zantetsu wrote: > Thank you for your response. > > I have a question. > How many device do you connect? > I have only one queue now. > So I submit only one IRP to USB stack. > But my devices may be connected to same computer. > Does the crash depend on the number of connected devices?
First
|
Prev
|
Pages: 1 2 3 Prev: How to capture avshws(AVStream sample) Next: DrvQueryFontTree fails with Splwow64.exe |