linux-mips
[Top] [All Lists]

crash in first printk of start_kernel

To: linux-mips@linux-mips.org
Subject: crash in first printk of start_kernel
From: Attila Kinali <attila@kinali.ch>
Date: Fri, 9 Mar 2007 19:13:54 +0100
Organization: NERV
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Hi,

I'm currently to bring up a new embedded system we build
using the Alchemy Au1550 CPU. The board itself looks like
a downsized version of the DB1550 evaluation board from AMD,
with 64MB DRAM and a 32MB NOR flash, plus PC-Card controller,
one ethernet port used.

I'm using a 2.6.16.11 (an old snapshot from about last august,
when we started development of another board) that has slight
adjustments in various drivers to accomodate for our platform
specific stuff.

While booting from u-boot works fine, ie it can load the kernel
from tftp, checksum is ok, uncompression is ok. It then jumps
into the kernel but ends up in an exception handler when executing
the first printk in start_kernel (ie the printk(KERN_NOTICE);
at init/main.c:451).

While in the "exception handler" endless loop from u-boot 
ra points to vscnprintf() (lib/vsprintf.c:512)
where it calls vsnprintf() (at line 517).

If i set a breakpoint at lib/vsprintf.c:517 and follow it
into vsnprintf, i get the follwing gdb log:

---
Breakpoint 3, vscnprintf (buf=0x80411548 "", size=0x803b1fac,
    fmt=0x8036f10c "<5>", args=0x803b1fac) at lib/vsprintf.c:517
517             i=vsnprintf(buf,size,fmt,args);
(gdb) step
vsnprintf (buf=0x80411548 "", size=0x400, fmt=0x8036f10c "<5>", args=0xff0000)
    at lib/vsprintf.c:276
276             if (unlikely((int) size < 0)) {
(gdb) next
285             end = buf + size - 1;
(gdb) next
287             if (end < buf - 1) {
(gdb) p end
$1 = 0x80411947 ""
(gdb) p buf
$2 = 0x80411548 ""
---

if i go here further (either next/step or continue), then i end up
in the exception handler. So, it must be something in the asm
of this line:

---
(gdb) disassemble $pc $pc+100
Dump of assembler code from 0x8026612c to 0x80266190:
0xffffffff8026612c <vsnprintf+68>:      addiu   v0,a0,-1
0xffffffff80266130 <vsnprintf+72>:      sltu    v0,s2,v0
0xffffffff80266134 <vsnprintf+76>:      beqz    v0,0x80266144 <vsnprintf+92>
0xffffffff80266138 <vsnprintf+80>:      bltz    a0,0x802461c0 
<jffs2_remount_fs+144>
0xffffffff8026613c <vsnprintf+84>:      li      s2,-1
0xffffffff80266140 <vsnprintf+88>:      negu    s6,a0
0xffffffff80266144 <vsnprintf+92>:      lb      v0,0(a2)
0xffffffff80266148 <vsnprintf+96>:      beqz    v0,0x80266190 <vsnprintf+168>
0xffffffff8026614c <vsnprintf+100>:     move    a0,a2
0xffffffff80266150 <vsnprintf+104>:     lb      v1,0(a0)
0xffffffff80266154 <vsnprintf+108>:     li      v0,37
0xffffffff80266158 <vsnprintf+112>:     beq     v1,v0,0x802661dc <vsnprintf+244>
0xffffffff8026615c <vsnprintf+116>:     lbu     a0,4(a0)
0xffffffff80266160 <vsnprintf+120>:     sltu    v0,s2,s0
0xffffffff80266164 <vsnprintf+124>:     bnez    v0,0x80266174 <vsnprintf+140>
0xffffffff80266168 <vsnprintf+128>:     sllv    zero,zero,zero
0xffffffff8026616c <vsnprintf+132>:     sb      a0,0(s0)
0xffffffff80266170 <vsnprintf+136>:     lw      a2,80(sp)
0xffffffff80266174 <vsnprintf+140>:     addiu   s0,s0,1
0xffffffff80266178 <vsnprintf+144>:     addiu   v0,a2,1
0xffffffff8026617c <vsnprintf+148>:     sw      v0,80(sp)
0xffffffff80266180 <vsnprintf+152>:     lb      v1,0(v0)
0xffffffff80266184 <vsnprintf+156>:     move    a0,v0
0xffffffff80266188 <vsnprintf+160>:     bnez    v1,0x80266150 <vsnprintf+104>
0xffffffff8026618c <vsnprintf+164>:     move    a2,v0
End of assembler dump.
---

But if i use stepi from here on, then it looks like that the
BDI2000's breakpoint (both soft and hard) somehow interferes
with the execution of the code:

---
(gdb) display/i $pc
1: x/i $pc  0x8026612c <vsnprintf+68>:  addiu   v0,a0,-1
(gdb) stepi
0xffffffff80266130      287             if (end < buf - 1) {
1: x/i $pc  0x80266130 <vsnprintf+72>:  sltu    v0,s2,v0
(gdb) stepi
287             if (end < buf - 1) {
1: x/i $pc  0x80266134 <vsnprintf+76>:  beqz    v0,0x80266144 <vsnprintf+92>
(gdb) stepi
287             if (end < buf - 1) {
1: x/i $pc  0x80266134 <vsnprintf+76>:  beqz    v0,0x80266144 <vsnprintf+92>
(gdb) stepi
287             if (end < buf - 1) {
1: x/i $pc  0x80266134 <vsnprintf+76>:  beqz    v0,0x80266144 <vsnprintf+92>
(gdb) stepi
287             if (end < buf - 1) {
1: x/i $pc  0x80266134 <vsnprintf+76>:  beqz    v0,0x80266144 <vsnprintf+92>
(gdb) stepi
---

Yes, the next instruction (bltz    a0,0x802461c0 <jffs2_remount_fs+144>)
looks fishy and should be most probably a NOP. If i patch this point
by hand and continue it crashes at another point.

The only two reasons why the instruction at this point could be
wrong, is either a gcc bug or a bug in u-boot's gunzip function.
And i somewhat doubt both. gcc is a 3.3.1 from Montavista and both
gcc and u-boot work on our other board which has a similar layout.

Has anyone an idea what the problem here could be or how i could
narrow it down?

Thanks in advance

                        Attila Kinali

-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred

<Prev in Thread] Current Thread [Next in Thread>