home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8135 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  1.5 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!daffy!uwvax!uchinews!quads!ace3
  2. From: ace3@quads.uchicago.edu (Tony 'LLama' Acero)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Buffer corruption problems.
  5. Summary: is this behavior related?
  6. Keywords: linux, kernel, 0.97p1
  7. Message-ID: <1992Aug13.163854.21617@midway.uchicago.edu>
  8. Date: 13 Aug 92 16:38:54 GMT
  9. Article-I.D.: midway.1992Aug13.163854.21617
  10. References: <16078@ucdavis.ucdavis.edu>
  11. Sender: news@uchinews.uchicago.edu (News System)
  12. Reply-To: ace3@midway.uchicago.edu
  13. Followup-To: comp.os.linux
  14. Organization: University of Chicago Computing Organizations
  15. Lines: 25
  16.  
  17. I have a 486/33 w/ 10MB of RAM, RLL hard disk controller.  I
  18. have self-compiled version 0.97p1 of the kernel (with the 
  19. grow-buffer fix).  No swap space.  The GCC provided in the
  20. MCC 0.96 interim release.
  21.  
  22. As a crude benchmark I timed the recompile of the kernel several
  23. times. (ie make clean; make dep; make all)
  24.  
  25. I was very, very pleasantly surprised when the first compile took less
  26. than 12 minutes -- more than 3x faster than under 0.96c!
  27.  
  28. However, imagine my surprise when each subsequent recompilation was slower than
  29. the previous one!  About the third or fourth time make quit with
  30. an error.  Each time the conditions were precisely the same -- no other VCs were
  31. in use -- my assumption is that the only change was caused by the previous
  32. compilations.
  33.  
  34. I have no idea what's going on and would appreciate any input! :-)
  35. (The smiley is to indicate I'm not complaining and half-expecting
  36. that I've done something bone-headed)
  37.  
  38. thanks to all
  39.  
  40. tony acero
  41. ace3@midway.uchicago.edu
  42.