0

We have intermittant problems with writing DVDs where the writing process fails. We suspect that the problem is happening when the DVD driver switches from DMA mode to PIO mode and then in this mode due to the stress in the CPU, writing fails. We want to test this hypothesis by manually changing the writing mode to PIO and then stressing the kernal* to reproduce the error.

Any idea how to achieve this? Can we write some kind of program ourselves or are there any existing tools to achieve this?

*What I mean by 'stressing the kernal' is: See the 'kernal times' in the task manager. A red graph is displayed along with the CPU usage history. I want to make this activity higher. With the usual stress tools, only the CPU usage goes high, not the 'kernal times' graph.

5
  • Start a game at high resolution. :) Are you 100% sure it's not the DVD drive? Or the power supply may not be enough/may be old and needs replacement? Try borrowing one from a friend or.. burn at low speeds. Oct 9, 2013 at 13:10
  • The kernel is not a process as you would typically think about it, thought it does run several processes like the System process. you can stress your CPU with tools like Prime95, but that doesn't put any special load on kernel processes. see this page for likely reasons you may have been switched to PIO mode: winhlp.com/node/10 Oct 9, 2013 at 13:10
  • @FrankThomas : Yes. I was not sure how to understand the word 'kernal times'. For CPU stress, I could just write a long loop with some number addition etc, but this doesn't bring up the 'kernal times' graph. I read somewhere after posting the question (also hint from @medigeek) that system calls might take it up. Let me try with some win32 calls (file write, or graphics update) in a loop and see if that helps. Oct 9, 2013 at 13:18
  • @medigeek : We think it is not the drive since the issue is not reproducible and since the issue is present in more than one machine of a particular family. We suspect some of our processes interfering with the writing. And as of yesterday, the frequency of occurance of this has reduced very drastically. We need a way to increase its frequency to do any meaningful analysis. (It is not only about this machine. We sell a HW+SW bundle and needs to be sure about the root-cause) Oct 9, 2013 at 13:28
  • @PermanentGuest I'm building and selling Hardware+Software as well. Not so long ago I installed a bunch of MadeInChina SATA cables and I just want to forget all this. I delivered computers with four days delay, as I just couldn't believe that 47 out of 72 were bad. Same issue DMA -> PIO. And cables were the last on my check list. These are all brand new and nicely packed in a blister. Doesn't cost you to check this as well Oct 9, 2013 at 18:41

1 Answer 1

1

You can try with Driver Verifier. The Driver Verifier is built-in to the kernel to allow stress testing of driver code. It is to some extent configurable in relation to what functions are bypassed, and what bypasess to perform. It is setup to bypass specific functions to other predetermined functions, which provides an aggressive environment for the target driver.

In the Run dialog box type the command "verifier" (w/o quotes)

On how to use it check the Knowledge Base article Q244617

Just one note: Once the Driver Verifier manager is enabled, it stays active until you disable it. To do so, type in Run dialog box "verifier /reset" (w/o quotes)

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .