[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Stability issues

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 
- 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

Reply to: