Date: Tue, 18 May 2004 15:24:06 +0200 From: platanthera <platanthera@web.de> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, freebsd-questions@freebsd.org Subject: Re: ls(1) crashes Message-ID: <200405181524.06610.platanthera@web.de> In-Reply-To: <20040518122615.GA46147@happy-idiot-talk.infracaninophile.co.uk> References: <200405180003.12652.platanthera@web.de> <200405180025.10307.platanthera@web.de> <20040518122615.GA46147@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 18 May 2004 14:26, Matthew Seaman wrote:
> On Tue, May 18, 2004 at 12:25:09AM +0200, platanthera wrote:
> > On Tuesday 18 May 2004 00:05, Dan Nelson wrote:
> > > In the last episode (May 18), platanthera said:
> > > > ls(1) crashed (exited on signal 10) for the second time within
> > > > a few days today. Could you please have a look at the core file
> > > > and tell me what's going on? Or even better yet - point me to a
> > > > beginners guide on how to interpret core files
> > >
> > > Signal 10 is a Bus Error and is usually due to bad memory or
> > > improper overclocking.
> >
> > I've checked the memory using memtest86, and _not_ overclocked the
> > cpu.
>
> That's the right thing to do in the first instance, but getting an
> "all clear" from memtest86 doesn't guarantee you are 100% clear of
> problems. (In technical terms, memtest86 doesn't produce false
> positives (saying there's an error when there isn't one) but it does
> have a low rate of false negatives (saying there's no error when
> there is one))
>
> However, I'd start to look at other aspects of the system now -- the
> first thing to eliminate would be hard drive problems. Can you
> reboot the system into single user mode, and run fsck(8) on all the
> partitions? That's
>
> # fsck -f
>
> (Nb. only the root fs should be mounted, and that should be mounted
> read-only while you're doing that. Not coincidentally, that's the
> state booting into single user mode provides).
>
> If there are any errors reported by fsck(8), and especially if
> repeated fsck'ing doesn't clear them then your hard drive is probably
> about to give up the ghost.
fsck -f didn't report any errors. Additionally I've checked my disks
using the scsi controlers verify disk utility. Seems they're OK.
>
> Other causes of the problem could be overheating -- not necessarily
> of the main CPU (as that just results in the screen going black, and
> whole system rebooting itself after a while) but of some of the
> bridge chipsets on the motherboard. Sometimes those chips will have
> a fan assisted heatsink but that's not very common. If they do,
> verify that the fan is working properly, and in any case, verify that
> the main case and power supply fans are working correctly, vents are
> not obstructed (either by stuff around your machine, or by dust on
> the inside) and that internal ribbon cables and so forth aren't
> preventing the free movement of air around the inside of the case.
I don't think it's a heat problem since there are no problems compiling
large ports which means _many_ hours of 100% cpu load on my a bit
elderly system.
Just an idea - some time ago I exchanged my aha19160 scsi controller for
a Tekram DC-390U2 (I wanted to play with Linux which didn't work with
the Adaptec card). Although the DC-390U2 seems to work fine, might it
eventually be that this is the reason for my recent problems?
> Even if you can't nail down exactly what the problem is, you might
> want to consider doing a cvsup + {build,install}{world,kernel} cycle.
> It will either make any deficiencies in your hardware glaringly
> obvious, or could very well make your trouble go away.
I've already tried this to overcome Signal 10 errors with cfs-1.4.1_1 -
without any success, only downgrading to 1.4.1 helped in that case.
> Cheers,
>
> Matthew
thanks a lot for your hints
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405181524.06610.platanthera>