On Sat, Jul 21, 2007 at 08:22:47AM -0400, Mike Robinson wrote: > I've been running Debian testing for about a year-and-a-half. It's been > quite stable. I performed a dist-upgrade about two weeks ago. It's been > unstable since. By unstable I mean that applications may crash (disappear) > and the system may freeze. The system is freezing about once a day. Did the upgrade include the kernel? > My processor is an Athlon 64 3200+, but I'm running the 686 kernel > (2.6.18-4). I've posted a few logs here: > > http://robinsonhome.org/logs1/dmesg.txt According to this, you're using the NVidia kernel module, which is closed source. If (and that's a _big_ if so far) the cause of your instability is a kernel problem, see if you can reproduce it without loading the nvidia module; the kernel maintainers tend to ignore kernel bug reports when closed-source modules are loaded... You're also using the ivtv modules - is this a mythbox by any chance? I noticed lirc too somewhere... I'm running roughly the same configuration without problems (AMD 1.8Ghz, 2.6.18 kernel, 512Mb memory, ivtv 0.8.2), but I'm using the -k7 kernel. > http://robinsonhome.org/logs1/kern.log > http://robinsonhome.org/logs1/messages According to this you're running out of memory!? At least the oom-killer is (disturbingly) active before the reboot, but the messages are pretty definite: your 2G swap is maxed out. That's bad and will cause all sorts of problems... > One thing I noticed while recompiling various applications is that gcc would > display the following error: > > dsputil.c: In function 'pix_abs8_y2_c': > dsputil.c:3048: internal compiler error: Segmentation fault This *could* be an unhandled out-of-memory error... > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. > For Debian GNU/Linux specific bug reporting instructions, > see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. > The bug is not reproducible, so it is likely a hardware or OS problem. > > > But if I just continued the build by typing 'make' again, it would pick up > where it left off and eventually complete. For a large application, I may > run into this problem a few times. Upon further view of the build logs I > noticed this snippet: > > gcc -c -pipe -march=k8 MythTV again? It has it's own processor detection code. And it does take a while to compile... > Does this mean that it's building the application as 64-bit? Could my > distribution somehow now be mixed 32 and 64 bit? Could this possibly be the > source of my problems? If so, how can I recover? If not, any suggestions > as to how I should continue troubleshooting? Next time you compile things, start a couple of sessions (=separate windows): - vmstat 5 - to keep track of free memory and swapping - top - sorted so the most memory hungry processes are on top - tail -f /var/log/syslog - to see when oom-killer fires up - a compile session and keep an eye on what happens in the other sessions when gcc fails Hope this helps -- Karl E. Jorgensen karl@jorgensen.org.uk http://www.jorgensen.org.uk/ karl@jorgensen.com http://karl.jorgensen.com ==== Today's fortune: Diplomacy is the art of saying "nice doggy" until you can find a rock.
Attachment:
signature.asc
Description: Digital signature