On Thu, Apr 02, 1998 at 10:59:12PM +0200, Klaus Wacker wrote: > I am using a script which compiles the kernel 100 times to test my > hardware. I had a probability of a signal 11 crash of gcc about every > 3 or 4 times. When a crash happened, further invocations of gcc would > usually crash immediately, so the remainder of the loop ran through > very quickly. To get better statistics, I added a program like you > describe after each compilation. This has the effect of forcing the > (presumably damaged) gcc executable out of the memory buffer and a > reload of a fresh copy from disk, so the loop could continue. > Hugh! This can be really stressful effectively... I don't think NT can do the same (if you ever seen it just recovery from a PANIC... it's most of the time just PANIC again ;). > BTW, can someone explain the difference between "buffers" and "cached" > to me? May be this pointer can help a little bit (sorry if not): /usr/src/linux/Documentation/memory-tuning.txt For sure, this doesn't help for hardware problems but I have quiet better performance on my linux after following this little guide. > -- > Klaus Wacker wacker@Physik.Uni-Dortmund.DE > 51°29'9"N 7°25'9"E http://www.physik.uni-dortmund.de/~wacker > -- ------------------------------------------------------------------------ Fabien Ninoles E-mail: fab@tzone.org WebPage: http://www.callisto.si.usherb.ca/~94246757 You can get my public key from your nearest public keys server! RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 ------------------------------------------------------------------------
Attachment:
pgpv6h2P23jzF.pgp
Description: PGP signature