home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / programming / forthmacs / htmldocs / !Forthmacs / docs / html / debugging < prev    next >
Encoding:
Text File  |  1996-02-23  |  4.2 KB  |  119 lines
  1. <!-- Forthmacs Formatter generated HTML output -->
  2. <html>
  3. <head>
  4. <title>System Debugging Techniques</title>
  5. </head>
  6. <body>
  7. <h1>System Debugging Techniques</h1>
  8. <hr>
  9. <p>
  10. This chapter relates some of my techniques for debugging computer system 
  11. problems, both hardware and software.  In many cases, the hardest problem is to 
  12. decide whether hardware or software is at fault.  
  13. <p>
  14. The discussion focuses on debugging "generic" problems that happen on more than 
  15. one system.  Fixing individual bad boards is a different problem.  
  16. <p>
  17. There are no rules or procedures, because every problem is different.  Instead, 
  18. this a "bag of tricks".  
  19. <p>
  20. <p>
  21. <h2>Find the WORST system and hang on to it</h2>
  22. <p>
  23. The system which fails the MOST frequently is your best clue.  
  24. <p>
  25. <p>
  26. <h2>Eliminate irrelevant factors</h2>
  27. <p>
  28. Simply the setup; try to find the simplest setup that will still fail; remove 
  29. boards that don't seem to be related to the problem.  Turn off test processes 
  30. that don't affect the problem.  
  31. <p>
  32. <p>
  33. <h2>Make it fail stand-alone</h2>
  34. <p>
  35. It is very difficult to debug hardware problems under Unix because Unix takes a 
  36. long time to boot, exercises a whole lot of the system all the time, and often 
  37. crashes when the hardware is broken.  
  38. <p>
  39. Running RiscOS makes life much easier.  
  40. <p>
  41. Try to cause the failure running stand-alone Forth.  Write a Forth program to 
  42. exercise the interesting parts of the system (or better yet, adapt an existing 
  43. program).  Even when running stand-alone, turn off tests that seem to be 
  44. irrelevant.  
  45. <p>
  46. Forth can still run when the hardware is crippled, and only touches a small 
  47. amount of the hardware unless you tell it to.  
  48. <p>
  49. <p>
  50. <h2>Try to increase the failure rate</h2>
  51. <p>
  52. The faster it fails, the easier it is to see on a scope and the easier it is to 
  53. trigger a logic analyzer 
  54. <p>
  55. If it only fails once an hour, you aren't likely to solve it, so try to make it 
  56. fail faster.  
  57. <p>
  58. Try out lots of ideas for making it fail faster.  Forth is good for this because 
  59. you can try out stuff directly from the keyboard.  
  60. <p>
  61. The things you have to do to make it fail faster give you important clues to the 
  62. problem.  
  63. <p>
  64. After you have figured out the cause of the problem, the test program that makes 
  65. it fail quickly is a good testbed for proposed fixes.  
  66. <p>
  67. <p>
  68. <h2>Attack with both software and hardware weapons</h2>
  69. <p>
  70. Excessive reliance on a logic analyzer will slow you down.  The logic analyzer 
  71. is most useful after you have already narrowed down the problem pretty far.  
  72. <p>
  73. Try software first.  Increasing the failure frequency is the number one 
  74. priority.  After you can get it to fail quickly and repeatable, then you can get 
  75. out the logic analyzer, or, if it fails quickly enough, a scope may be 
  76. sufficient.  
  77. <p>
  78. Try simple tests first.  Often a problem can be triggered by simply repeating a 
  79. command over and over.  
  80. <p>
  81. Sometimes it is very difficult to get the logic analyzer to trigger on the right 
  82. event.  Software can be very useful here.  Think of ways to make a very specific 
  83. event happen concurrently with the problem.  Special data patterns may be 
  84. helpful.  
  85. <p>
  86. Don't be content with "quick answers" 
  87. <p>
  88. If you haven't discovered EXACTLY what is going wrong, at the lowest level, the 
  89. problem will come back to haunt you.  
  90. <p>
  91. "Well, if we do this and this, the problem seems to go away".  This is not a 
  92. problem solution, it is hand-waving.  
  93. <p>
  94. <p>
  95. <h2>Assumptions are your enemy.  Collect data, not assumptions</h2>
  96. <p>
  97. "We think the problem is thus-and-so" is not data.  
  98. <p>
  99. "I performed this test under these conditions and the result was x" is data.  
  100. <p>
  101. <p>
  102. <h2> Be wary when giving status reports!!!</h2>
  103. <p>
  104. Before the problem is really solved, if you tell people what you think it MIGHT 
  105. be, the rumor mill will sometimes twist your words.  You can end up spending 
  106. more time combating twisted rumors than on solving the problem.  
  107. <p>
  108. Every few hours, your boss will ask you what the solution is.  Say "I don't know 
  109. yet".  He will ask again, using different wording.  Say "I don't know yet, but I 
  110. will tell you as soon as I know".  
  111. <p>
  112. <p>
  113. <h2>Last Resort</h2>
  114. <p>
  115. If all else fails, try to push the problem off onto someone else.  
  116. <p>
  117. </body>
  118. </html>
  119.