new type of crash report?

new type of crash report?

[Giuseppe Sacco]

Hi all,
with latest kernel I started getting problem like this one. How may I
understand what part of the kernel produced the problem? Is it possible
to get a stack trace from this report?

Thank you very much,
Giuseppe

Got dbe at 0x2ac2bffc
Cpu 0
$ 0   : 0000000000000000 0000000000000014 0000000000000000 000000002acf1758
$ 4   : 0000000000000000 00000000000073b0 0000000000000000 0000000000000000
$ 8   : 000000007fd06a64 0000000000000000 47a5ca5900000000 0000100000000000
$12   : 0000000000000000 0000000047a5ca59 0000000047a5ca59 0000000000000000
$16   : 0000000000000000 000000002acef588 000000002accbd68 0000000000000000
$20   : 0000000000546408 0000000000545e68 0000000000000000 0000000000530bb8
$24   : 0000000000000000 000000002abf8e58                                  
$28   : 000000002acf7960 000000007fd069e0 000000007fd069f0 000000002ac2bfdc
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : 000000002ac2bffc 0x2ac2bffc     Not tainted
ra    : 000000002ac2bfdc 0x2ac2bfdc
Status: 8001fcf3    KX SX UX USER EXL IE 
Cause : 0000041c
PrId  : 00002321 (R5000)
Index:  1 pgmask=4kb va=c00000ffc0126000 asid=6b
        [pa=00053946000 c=3 d=1 v=1 g=1] [pa=000538da000 c=3 d=1 v=1 g=1]
Index:  2 pgmask=4kb va=c00000ffc003a000 asid=6b
        [pa=00054e25000 c=3 d=1 v=1 g=1] [pa=00000000000 c=0 d=0 v=0 g=1]
Index:  4 pgmask=4kb va=c00000ffc00d8000 asid=6b
        [pa=00000000000 c=0 d=0 v=0 g=1] [pa=00053921000 c=3 d=1 v=1 g=1]
Index:  7 pgmask=4kb va=c00000ffc0042000 asid=6b
        [pa=00054cf7000 c=3 d=1 v=1 g=1] [pa=00054eaa000 c=3 d=1 v=1 g=1]
Index:  8 pgmask=4kb va=c00000ffc012c000 asid=6b
        [pa=000539e5000 c=3 d=1 v=1 g=1] [pa=00000000000 c=0 d=0 v=0 g=1]
Index: 10 pgmask=4kb va=c00000ffc00fa000 asid=6b
        [pa=000539ae000 c=3 d=1 v=1 g=1] [pa=000539af000 c=3 d=1 v=1 g=1]
[...]

Re: [SPAM] new type of crash report?

[Markus Gothe]

[-- Attachment #1.1: Type: text/plain, Size: 2392 bytes --]

You can always start with running run gdb at the read address (ra:  
0x2ac2bfdc), I'd also try listing 0x2ac2bffc.

//Markus

On 3 Feb 2008, at 15:56, Giuseppe Sacco wrote:

> Hi all,
> with latest kernel I started getting problem like this one. How may I
> understand what part of the kernel produced the problem? Is it  
> possible
> to get a stack trace from this report?
>
> Thank you very much,
> Giuseppe
>
> Got dbe at 0x2ac2bffc
> Cpu 0
> $ 0   : 0000000000000000 0000000000000014 0000000000000000  
> 000000002acf1758
> $ 4   : 0000000000000000 00000000000073b0 0000000000000000  
> 0000000000000000
> $ 8   : 000000007fd06a64 0000000000000000 47a5ca5900000000  
> 0000100000000000
> $12   : 0000000000000000 0000000047a5ca59 0000000047a5ca59  
> 0000000000000000
> $16   : 0000000000000000 000000002acef588 000000002accbd68  
> 0000000000000000
> $20   : 0000000000546408 0000000000545e68 0000000000000000  
> 0000000000530bb8
> $24   : 0000000000000000 000000002abf8e58
> $28   : 000000002acf7960 000000007fd069e0 000000007fd069f0  
> 000000002ac2bfdc
> Hi    : 0000000000000000
> Lo    : 0000000000000000
> epc   : 000000002ac2bffc 0x2ac2bffc     Not tainted
> ra    : 000000002ac2bfdc 0x2ac2bfdc
> Status: 8001fcf3    KX SX UX USER EXL IE
> Cause : 0000041c
> PrId  : 00002321 (R5000)
> Index:  1 pgmask=4kb va=c00000ffc0126000 asid=6b
>        [pa=00053946000 c=3 d=1 v=1 g=1] [pa=000538da000 c=3 d=1 v=1  
> g=1]
> Index:  2 pgmask=4kb va=c00000ffc003a000 asid=6b
>        [pa=00054e25000 c=3 d=1 v=1 g=1] [pa=00000000000 c=0 d=0 v=0  
> g=1]
> Index:  4 pgmask=4kb va=c00000ffc00d8000 asid=6b
>        [pa=00000000000 c=0 d=0 v=0 g=1] [pa=00053921000 c=3 d=1 v=1  
> g=1]
> Index:  7 pgmask=4kb va=c00000ffc0042000 asid=6b
>        [pa=00054cf7000 c=3 d=1 v=1 g=1] [pa=00054eaa000 c=3 d=1 v=1  
> g=1]
> Index:  8 pgmask=4kb va=c00000ffc012c000 asid=6b
>        [pa=000539e5000 c=3 d=1 v=1 g=1] [pa=00000000000 c=0 d=0 v=0  
> g=1]
> Index: 10 pgmask=4kb va=c00000ffc00fa000 asid=6b
>        [pa=000539ae000 c=3 d=1 v=1 g=1] [pa=000539af000 c=3 d=1 v=1  
> g=1]
> [...]
>
>

_______________________________________

Mr Markus Gothe
Software Engineer

Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)70 348 44 35
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com




[-- Attachment #1.2: Type: text/html, Size: 5644 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: new type of crash report?

[Giuseppe Sacco]

Hi Markus,

Il giorno dom, 03/02/2008 alle 16.52 +0100, Markus Gothe ha scritto:
> You can always start with running run gdb at the read address
> (ra: 0x2ac2bfdc), I'd also try listing 0x2ac2bffc.
[...]

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?

Thanks,
Giuseppe

Re: new type of crash report?

[Kevin D. Kissell]

[-- Attachment #1: Type: text/html, Size: 2159 bytes --]

Re: new type of crash report?

[Giuseppe Sacco]

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