Re: something wrong when I read infomation from portG ,s3c44b0

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

Why don't you try to interpret what the kernel is telling you?

On Thu, Mar 29, 2007 at 03:14:14PM +0800, zhang guocheng wrote:
> Unhandled fault: alignment exception (93) at 0x00000001
> fault-common.c(97): start_code=0xc5c0040, start_stack=0xc5fff84)
> Internal error: Oops: 0
> CPU: 0
> pc : [<0c01ee6c>] lr : [<00030001>] Not tainted
> sp : 0c607e1c ip : 00000004 fp : 0c607eb0
> r10: 0c5ad000 r9 : 20000013 r8 : 00000060
> r7 : ffffffea r6 : 0c5a6000 r5 : e1d230b0 r4 : 20000013
> r3 : 00000000 r2 : 0c60601c r1 : 0c607e1c r0 : 00000004
> Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment user
> Control: 0
> Process insmod (pid: 25, stackpage=0c607000)
> Stack:
> ...
> Backtrace:
> Function entered at [<0c01ee2c>] from [<0c01fc98>]
> r5 = 0C607EE8 r4 = E1D230B0
> Function entered at [<0c5ac9c0>] from [<0c02466c>]
> r5 = 0C5AC000 r4 = 00000000
> Function entered at [<0c023ff0>] from [<0c01a980>]

Why aren't these being decoded to kernel symbols?  My guess is that this
is a 2.4 kernel, and our attitude here to 2.4 kernel bug reports is well
documented.

> Code: e50be08c e3cd2d7f (e594303c) e3c2203f e50b3088

Do this:
cat > t.s
.word 0xe50be08c
.word 0xe3cd2d7f
.word 0xe594303c
.word 0xe3c2203f
.word 0xe50b3088
^D
arm-linux-as -o t.o t.s
arm-linux-objdump -d t.o

This gives you the following disassembly:

   0:   e50be08c        str     lr, [fp, #-140]
   4:   e3cd2d7f        bic     r2, sp, #8128   ; 0x1fc0
   8:   e594303c        ldr     r3, [r4, #60]
   c:   e3c2203f        bic     r2, r2, #63     ; 0x3f
  10:   e50b3088        str     r3, [fp, #-136]

>From the register dump, r4=20000013, add on the 0x3c and you get an
address of 0x2000004f - not what the oops dump was telling you.

On Thu, Mar 29, 2007 at 03:14:14PM +0800, zhang guocheng wrote:
> #define PCONC   (unsigned int *)0x01D20010
> #define PUPC      (unsigned int *)0x01D20018
> #define PCONG   (unsigned int *)0x01D20040
> #define PUPG      (unsigned int *)0x01D20048
> 
> I also tried to do like this:
> u32 save_C __attribute__((aligned(4)));
> u16 save_G __attribute__((aligned(4)));
> but it seems ineffective .
> 
> save_C=inl(PCONC);
> save_PC=inw(PUPC);

None of your statements above seem to correspond with an access being
performed.  Moreover, the access which seems to actually be performed
has nothing to do with the oops dump - in that the oops dump seems
to be inconsistent with itself.

No idea.

My guess is that this is a heavily (and inappropriately) modified vendor
kernel.  So even if it was a recent 2.6, those modifications causing
corruption of the oops reporting effectively make it an absolutely
worthless bug report to this community.

Alternatively, maybe the oops reporting was buggy; and since it's 2.4
it's too long ago for anyone to remember if it was.  This again makes it
absolutely worthless to this community.

Sorry.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php