"Peter Davoust" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 14 May 2007 02:04:30 -0400:
> I agree, it could be the heat, and that was the first thing that came to > my mind, but Vista boots and runs for long periods of time with no > issues. I'll check it out with the new kernel in the morning and see > what it does. Note that Gentoo tends to use hardware to its limits rather more than most OSs, MSWormOS and other Linux distributions alike. Vista is so new, and /does/ stress at least the video hardware rather more (if aero is on, anyway), so I don't know if anyone can rightly say with it, but certainly with older MS platforms, it hasn't been uncommon at /all/ for Gentoo to cause problems where MS didn't, and even other Linux distributions didn't. Part of the reason is that Gentoo tends to be compiled/optimized for the specific CPU it's running on, so it makes more efficient use of it, including use of functionality distributions (and MS) compiled for use on generic hardware simply don't use, plus simply the fact that when the CPU is busy, it's often getting more done in the same time, so it IS working harder and therefore stressing out the hardware more. Anyway, just because another OS doesn't have problems on a computer doesn't mean Gentoo won't, and there are quite a number of folks on the forums and on the gentoo-user list that will tell you the same thing -- learned from hard experience. Meanwhile, you mention specifically that one of the crashes was during a bz2 decompress. As someone who has HAD memory issues in the past, I can DEFINITELY tell you that bz2 DOES often trigger memory errors, if ANYTHING will! If the issues with BZ2 turn out to be common, CHECK THAT MEMORY, and check it again! You mentioned you have 2 gigs. Hopefully it's in the form of 2 or more sticks. If so, you should be able to take part of it out and see if the problem persists. Then test the other memory. If the problem happens with one set but not the other, you have your problem. Do note, however, that just because the problem continues to occur with either memory set doesn't necessarily mean it's not the memory, particularly if they are the same brand and size, purchased from the same place at the same time, so are likely in the same lot. In my case, I had purchased generic memory that couldn't quite do its rated pc3200 (clock at 200 MHz x 2, since it was DDR). I ran memtest and it passed with flying colors, because the memory worked fine, and memtest apparently doesn't really stress the memory timings, only testing the memory cells. However, I was crashing in operation, sometimes just the app, sometimes the entire kernel would panic. I turned on the kernel's MCE (machine check exception) reporting, and the memory was indeed the problem (google MCEs, there's an app available that you can run, feeding it the numbers, and it'll spit out the error in English), only wasn't quite sure whether it was the memory itself, or the mobo, causing perfectly good memory to generate errors upon data delivery because it couldn't reliably get the data to the CPU. While I didn't have the necessary BIOS settings at the time, sometime later a BIOS update gave me additional memory settings, and I found that reducing the memory timings by a single notch, to 183 MHz (DDR doubled to 366), effectively PC3000 memory, did the trick. I was even able to tweak some of the individual wait-state settings to get back a bit of the performance I lost with the under-clocking. The memory and entire machine was rock-stable at the 183 MHz PC3000 memory setting. Later I upgraded from my then two 512 MB sticks to four 2 GB sticks, 8 gigs memory total. It was indeed the memory, not the board, as the new memory was just as stable at PC3200 as the old memory had been at the under-clocked PC3000 speed. Anyway, the way bzip2 works is apparently extremely stressful on memory, as more than anything else, that would trigger the errors. Compiles were frustrating too, but sometimes I could compile for quite some time without issues. That's why I didn't think it was the CPUs even before I got the program to read the MCE numbers and tell me what they were. They confirmed, it was memory related, the errors were on data as the CPU got it. I just didn't know until I actually changed memory whether it was the mobo generating errors on the data in transit, or the memory itself. It turned out to be the memory. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
