headers
Russell King - ARM Linux | 12 Nov 16:19
Picon

Re: [AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clock, IPSec)

On Mon, Nov 12, 2007 at 03:45:04PM +0100, Guennadi Liakhovetski wrote:
> 2. There has been an Oops once in vi...
> 
> Unable to handle kernel paging request at virtual address e5dcc3ec
> pgd = c135c000
> [e5dcc3ec] *pgd=00000000
> Internal error: Oops: 5 [#1]
> Modules linked in:
> CPU: 0    Not tainted  (2.6.23.1-ga63c3b88-dirty #52)
> PC is at __update_rq_clock+0x4c/0x140
> LR is at __update_rq_clock+0x28/0x140
> pc : [<c0033e38>]    lr : [<c0033e14>]    psr: 60000093
> sp : c1517b08  ip : e5dcc010  fp : c0117b3c
> r10: c025125c  r9 : 00000001  r8 : 00000000
> r7 : 00000000  r6 : c1cc9720  r5 : e5dcc3ec  r4 : e2be3800
> r3 : 00989680  r2 : ffffd430  r1 : 00989665  r0 : e2be3800
> Flags: nZCv  IRQs off nt user
> Control: c000717f  Table: 2135c000  DAC: 00000015
> Process vi (pid: 2017, stack limit = 0xc1516258)
> Stack: (0xc1517b08 to 0xc1518000)
> Backtrace: frame pointer underflow
^^^^^^^^^^^^^^ hint.

> Backtrace aborted due to bad frame pointer <c0117b3c>
> Code: e0c88005 e51bc034 e3580000 e28c5ff7 (e8950060)
> 
> __update_rq_clock:
>         @ args = 0, pretend = 0, frame = 12
>         @ frame_needed = 1, uses_anonymous_args = 0
>         mov     ip, sp  @,
(Continue reading)

Permalink | Reply |
headers
Guennadi Liakhovetski | 12 Nov 17:17
Picon
Picon
Favicon

Re: [AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clock, IPSec)

On Mon, 12 Nov 2007, Russell King - ARM Linux wrote:

[snip]
> That means 'fp' after the first 'sub' instruction should be 0xc1517b3c.
> However, it is actually 0xc0117b3c.  Note that these two values look
> very similar.  The difference is only 0x01400000.  Two bit errors in
> SDRAM?

Thanks for the analysis, Russell! So, you are hinting at SDRAM timing, 
right? Now, I do not find yet where in u-boot SDRAM timing is 
configured... Andrew, any hints?

(David, you might want to correct MAINTAINERS record for jffs2 - mailing 
list address seems to be dead).

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office <at> denx.de

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

Permalink | Reply |
headers
Coleman Brumley | 12 Nov 18:14
Picon

Re: [AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clock, IPSec)


Guennadi Liakhovetski wrote:
> On Mon, 12 Nov 2007, Russell King - ARM Linux wrote:
>
> [snip]
>   
>> That means 'fp' after the first 'sub' instruction should be 0xc1517b3c.
>> However, it is actually 0xc0117b3c.  Note that these two values look
>> very similar.  The difference is only 0x01400000.  Two bit errors in
>> SDRAM?
>>     
>
> Thanks for the analysis, Russell! So, you are hinting at SDRAM timing, 
> right? Now, I do not find yet where in u-boot SDRAM timing is 
> configured... Andrew, any hints?
>   

Sorry to chime in, but IIRC, the memory timings are setup in the low 
level bootloader (dataflashboot or the equivalent from Atmel). 
> (David, you might want to correct MAINTAINERS record for jffs2 - mailing 
> list address seems to be dead).
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
>
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office <at> denx.de
(Continue reading)

Permalink | Reply |
headers
Guennadi Liakhovetski | 12 Nov 18:24
Picon
Picon
Favicon

Re: [AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clock, IPSec)

On Mon, 12 Nov 2007, Coleman Brumley wrote:

> Sorry to chime in, but IIRC, the memory timings are setup in the low level
> bootloader (dataflashboot or the equivalent from Atmel). 

Thanks, yes, as I've written a few minutes ago, I've found it indeed in 
the first-stage loader before u-boot...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office <at> denx.de

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply |
headers
Guennadi Liakhovetski | 12 Nov 18:01
Picon
Picon
Favicon

Re: [AT91RM9200] further run-time problems (jffs2, Oops in __update_rq_clock, IPSec)

On Mon, 12 Nov 2007, Guennadi Liakhovetski wrote:

> On Mon, 12 Nov 2007, Russell King - ARM Linux wrote:
> 
> [snip]
> > That means 'fp' after the first 'sub' instruction should be 0xc1517b3c.
> > However, it is actually 0xc0117b3c.  Note that these two values look
> > very similar.  The difference is only 0x01400000.  Two bit errors in
> > SDRAM?
> 
> Thanks for the analysis, Russell! So, you are hinting at SDRAM timing, 
> right? Now, I do not find yet where in u-boot SDRAM timing is 
> configured... Andrew, any hints?

Ok, found that. 

Thought it might have been a problem with the cache, with 
ONFIG_CPU_DCACHE_WRITETHROUGH on the board doesn't boot at all.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office <at> denx.de

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
(Continue reading)

Permalink | Reply |

Gmane