On Tuesday 20 September 2005 04:14, Dave Nebinger wrote:
> > fourth, check your board and cards for 'funny looking' condensators -
> > like deformation, round tops, or even some brown 'dirt' at their base.
>
> This I think will be hard for him, Volker, as I believe he's running a
> laptop.
In tha
well, at first, let memtest86(+) run for some hours.
Volker's got a good point here...
second, check that your box does not get too hot. Crashes on stress are
mostly
overheating or PSU going bad.
Mentioned that to him about the heat... Kris, were you able to get
lm_sensors running on the b
On Tuesday 20 September 2005 00:56, Kris Kerwin wrote:
> Dave,
>
> Yup. Had a feeling that you might be right about that one.
>
> It seems that the computer will still crash, but certainly not as often. My
> guess: there is a bigger problem that is aggravated when the computer is
> under more stres
Dave,
Yup. Had a feeling that you might be right about that one.
It seems that the computer will still crash, but certainly not as often. My
guess: there is a bigger problem that is aggravated when the computer is
under more stress; ie: tracking excessive amounts of kernel complaints, etc.
I'v
Before the crash, the following three lines appeared (in this order)
nearly
53,000 times for a total of 16MB of text:
Sep 17 13:45:51 kerwin [4314362.567000] ip_local_deliver: bad skb:
PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING
Sep 17 13:45:51 kerwin [4314362.567000] skb: pf=2 (unowned) dev=
Alright! Thanks to Jonathan Wright and his program, I think that I may have
found something. See what you guys think:
Before the crash, the following three lines appeared (in this order) nearly
53,000 times for a total of 16MB of text:
> Sep 17 13:45:51 kerwin [4314362.567000] ip_local_deliver:
Kris Kerwin wrote:
Thanks Jonathan.
Anyone have any thoughts on this? I'm not a bash or any other programmer, and
was wondering if this would work. And how might I code that while loop?
Actually - the while loop was fine. I wrote that line and thought I can't
do that! I'll have to look it up
1) The problem appears to be independant of the kernel version, as I've
had it
occur on a 2.6.10 and 2.6.12 kernel.
2) How might I check for flakey hardware?
I would guess hardware problem (unless 3 applies below), but actually
finding the errant component can be quite a task. For a desktop
Thanks Jonathan.
Anyone have any thoughts on this? I'm not a bash or any other programmer, and
was wondering if this would work. And how might I code that while loop?
Thanks again, all, for your help.
Kris
On Saturday 17 September 2005 14:10, Jonathan Wright wrote:
> Kris Kerwin wrote:
> > I'v
Thanks Dave.
1) The problem appears to be independant of the kernel version, as I've had it
occur on a 2.6.10 and 2.6.12 kernel.
2) How might I check for flakey hardware?
3) I have had my BIOS respond after 3 crashes that the computer crashed due to
excessive heat. I think that this maybe inde
Kris Kerwin wrote:
I've tried catting the output from dmesg and running it regularly with
crontab, as was advised below. This, unfortunately doesn't work because cron
can only run as often as once a minute. This means that if a crash happens in
between these dmesg snapshots, the debugging infor
I've been experiencing some random kernel crashes, and need a way of
finding
out what happened.
Kris, I'd start by answering the following:
1. What version of the kernel are you using? Your OP is quite old, and many
releases of the kernel have come out since then. Have you tried a newer
ke
All,
I apologize for getting back so late. It's tough being a college student. ;-)
Thanks to Arturo and gentux for helping out so far.
I've tried catting the output from dmesg and running it regularly with
crontab, as was advised below. This, unfortunately doesn't work because cron
can only ru
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arturo 'Buanzo' Busleiman wrote:
> You may snapshot dmesg's output in a timely manner, ala crontab.
Additionally, you my wish to play with the log_buf_len kernel parameter:
log_buf_len=n Sets the size of the printk ring buffer, in bytes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kerwin wrote:
>Hey all,
>
>I've been experiencing some random kernel crashes, and need a way of
finding
>out what happened.
>
>I can't find any information in /var/log/lastlog or
>in /var/log/messages.*.bz2.
>
>Is there any way that I can monitor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kerwin wrote:
> Is there any way that I can monitor kernel messages during a crash and
> recover
> this information on the next boot?
You may snapshot dmesg's output in a timely manner, ala crontab.
- --
Arturo "Buanzo" Busleiman - www.buanzo.
Hey all,
I've been experiencing some random kernel crashes, and need a way of finding
out what happened.
I can't find any information in /var/log/lastlog or
in /var/log/messages.*.bz2.
Is there any way that I can monitor kernel messages during a crash and recover
this information on the next
17 matches
Mail list logo
