Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>
To: linux-mips@linux-mips.org
Subject: Re: new type of crash report?
Date: Sun, 03 Feb 2008 23:59:34 +0100	[thread overview]
Message-ID: <1202079574.18109.6.camel@scarafaggio> (raw)
In-Reply-To: <47A5F580.8080300@mips.com>

Hi Kevin,

Il giorno dom, 03/02/2008 alle 18.10 +0100, Kevin D. Kissell ha scritto:
> Giuseppe Sacco wrote: 
[...]
> > Thanks for your reply. I will try to understand how to use gdb on this
> > context. (Any URI would be really appreciated.)
> > Anyway I now understood that a dbe is a data bus error, so probably this
> > is an error on the physical address, i.e. a kernel problem related to
> > the mapping between vertical and physical addresses. Is this correct?
> >   
> That's correct.  You didn't say what processor you were running on, so
> it's hard to be more specific - there are some which have a bus error
> input pin that can be asserted by the system for other reasons - but
> in general it means that there's a data reference at 0x2ac2bffc whose
> valid translation goes to a bad address.  Generally, that address
> range is where shared libraries are mapped, so to find the instruction
> you want to run the program that caused the crash under gdb, set a
> breakpoint very early (e.g. main), run to the breakpoint, and
> disassemble the virtual address.  I find it interesting that the
> register value reported for register $10 is a reasonable data address
> shifted up by 32 bits.  It's possible that code would have a real
> reason to do that, but I can't help wonder if that isn't part of the
> problem. We may be looking at a 2-level bug here:  User(?) code
> screwing up a base register used for a load or store, and the OS
> failing to handle the upper reaches of the 64-bit address space
> correctly.

The complete bug report is available at http://bugs.debian.org/463808.
The cpu is an "R5000 V2.1  FPU V1.0".

The system is Debian stable, running mainly with courier-imap-ssl and
exim4 (often in TLS mode).

I cannot find a single program to debug, but I know for sure that if I
leave the machine with those two daemons, it will hung in about 30
minutes. If I run a kernel build (using gcc-4.2 from dDebian testing),
then the machine hungs in a few minutes. One time out of three gcc get a
segmentation fault, other two times the machine stop.

Thanks for your help,
Giuseppe

      reply	other threads:[~2008-02-03 22:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03 14:56 new type of crash report? Giuseppe Sacco
2008-02-03 15:52 ` [SPAM] " Markus Gothe
2008-02-03 16:01   ` Giuseppe Sacco
2008-02-03 17:10     ` Kevin D. Kissell
2008-02-03 22:59       ` Giuseppe Sacco [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1202079574.18109.6.camel@scarafaggio \
    --to=giuseppe@eppesuigoccas.homedns.org \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox