Hi everybody,
In the meantime, I have found the culprit for the problem: it
was indeed a hardware problem and the IDE connector cable (the
one between the harddrive and the IDE card) seems to be
defect. After replacing it, everything works fine!
I first thought, it was the RAM but this does not
Another (and hopefully final) discovery: having played around with
smartmontools, I think now that you first have to enable SMART on
a device before it records errors. I have done this and started
the cp-process again (the one which initially resulted in the
crash). And indeed,
smartctl -a /de
On Sat, 1 Apr 2006, Kaspar Fischer wrote:
> I see that I have 190MB RAM, and running memtest on some 160MB
> of these works fine:
>
> bumbum:/tmp/ramtest/memtester-4.0.5# ./memtester 160
> memtester version 4.0.5 (32-bit)
> Copyright (C) 2005 Charles Cazabon.
> Licensed under the GNU General Publ
First of all, thanks a lot to Rick and Thomas for your advice
and background information!
On 18.03.2006, at 07:03, Rick Thomas wrote:
On Mar 17, 2006, at 9:49 PM, Kaspar Fischer wrote:
On 17.03.2006, at 19:35, Michael Schmitz wrote:
Bad RAM, perhaps? Or other hardware dying?
As to RAM, how
On Mar 17, 2006, at 9:49 PM, Kaspar Fischer wrote:
On 17.03.2006, at 19:35, Michael Schmitz wrote:
Bad RAM, perhaps? Or other hardware dying?
As to RAM, how can I test it? http://www.memtest86.com/ seems
to be for Intel architectures only.
I wish I knew.
I guess this need not be a lin
On 17.03.2006, at 19:35, Michael Schmitz wrote:
Bad RAM, perhaps? Or other hardware dying?
The harddrives themselves are fine: they are less than two
months old and smartmontools' smartctl reports no errors
at all.
The BadCRC seems to indicate otherwise. Though this error should
also be
lo
> > Bad RAM, perhaps? Or other hardware dying?
>
> The harddrives themselves are fine: they are less than two
> months old and smartmontools' smartctl reports no errors
> at all.
The BadCRC seems to indicate otherwise. Though this error should also be
logged in the disk SMART log.
> As to RAM, ho
> The machine then crashed and restarted into read-only mode
> (not in the log because of the read-only, I guess) and fsck
> found the /dev/hdb2 ext2-filesytem to be severally damaged
> (some 1 duplicate blocks).
>
> Do you have any idea what this could be?
Bad RAM, perhaps? Or other hardware
On 17.03.2006, at 18:19, Michael Schmitz wrote:
The machine then crashed and restarted into read-only mode
(not in the log because of the read-only, I guess) and fsck
found the /dev/hdb2 ext2-filesytem to be severally damaged
(some 1 duplicate blocks).
Do you have any idea what this could be
Hi list,
My machine crashed after /dev/hdb encoutered a "lost interrupt"
and, some hours later (and maybe unrelated) a "page allocation
failure" and a "Oops: kernel access of bad area" occurred.
The details are in the log file below.
What I know is that at 23:00:00 a cronjob started to copy from
10 matches
Mail list logo