RE: Debugng the flash watchdog problem

["Mikael Starvik" <starvik@xxxxxxxx>]

jffs2_scan_medium probably causes a lot of page faults for the pages it
traverses and
therefor you see mtd stuff and zlib stuff. I've made a modified
watchog_brp implementation
which dumps the stack to be able to retrieve the callstack to find the
culprit who
disables the interrupts.

void watchdog_brp(struct pt_regs * regs)
{
  int i;
  char buf[100];
  unsigned* sp;
  asm volatile("move.d $sp, %0" : "=rm"(sp));
  reset_watchdog();
  stop_watchdog();
  sprintf(buf, "ERP %X\n", regs->irp);
  force_serial(buf);
  for (i = 0; i < 1000; i++)
  {
    sprintf(buf, "%X ", sp[i]);
    force_serial(buf);
    if (!((i + 1)%16))
      force_serial("\n");
  }
  while(1);
}

/Mikael

-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com">mailto:owner-dev-etrax@xxxxxxx.com] On
Behalf Of Pieter Grimmerink
Sent: Wednesday, March 29, 2006 2:59 PM
To: Mikael Starvik
Cc: dev-etrax
Subject: Re: Debugng the flash watchdog problem


On Thursday 23 March 2006 14:43, Mikael Starvik wrote:
> Ok, here is an instruction for anyone interrested in helping out
finding
> why the watchdog kicks us.

It works, I get a dump on the debugport:

BRP 6007FDFC

But now, how to find the responsible code... ;-)

objdump-cris -t os/linux/vmlinux | grep 6007f

6007f298 l     F .text  000000e6 mtd_read_proc
6007f380 l     F .text  000000ae concat_read
6007f42e l     F .text  000000cc concat_write
6007f4fa l     F .text  0000000e concat_erase_callback
6007f508 l     F .text  000000b2 concat_dev_erase
6007f5ba l     F .text  00000206 concat_erase
6007f7c0 l     F .text  000000aa concat_lock
6007f86a l     F .text  000000a8 concat_unlock
6007f912 l     F .text  00000036 concat_sync
6007f948 l     F .text  00000044 concat_suspend
6007f98c l     F .text  00000038 concat_resume
6007fdc0 l     F .text  00000074 part_read
6007fe34 l     F .text  00000074 part_point
6007fea8 l     F .text  00000034 part_unpoint
6007fedc l     F .text  00000084 part_read_ecc
6007ff60 l     F .text  00000074 part_read_oob
6007ffd4 l     F .text  0000002e part_read_user_prot_reg
6007f9c4 g     F .text  000003d0 mtd_concat_create
6007fd94 g     F .text  00000026 mtd_concat_destroy
6007f03a g     F .text  000000b2 unregister_mtd_user
6007f17c g     F .text  0000008e default_mtd_writev
6007f20a g     F .text  0000008e default_mtd_readv
6007f0ec g     F .text  00000090 __get_mtd_device


And a second time:

BRP 6007C956

objdump-cris -t os/linux/vmlinux | grep 6007c

6007c1ae l     F .text  00000064 cfi_build_cmd
6007c242 l     F .text  00000036 cfi_write
6007c212 l     F .text  00000030 cfi_read
6007c07e l     F .text  00000124 cfi_chip_setup
6007c668 l     F .text  000002e6 cfi_amdstd_setup
6007c94e l     F .text  0000018e cfi_amdstd_read
6007cadc l     F .text  0000008e cfi_amdstd_secsi_read
6007cb6a l     F .text  000004e8 do_write_oneword
6007c280 g     F .text  000003e8 cfi_cmdset_0002
6007c1a2 g     F .text  0000000c cfi_probe

And a third attempt:

BRP 600E5D3E

objdump-cris -t os/linux/vmlinux | grep 600e5

600e5b26 l     F .text  000000d2 copy_block
600e5ac8 l     F .text  0000005e set_data_type
600e5738 l     F .text  00000390 compress_block
600e5012 g     F .text  00000084 zlib_tr_stored_block
600e5c88 g     F .text  0000005a __ashldi3
600e5eb0 g     F .text  00000178 __Div
600e5096 g     F .text  000000ac zlib_tr_stored_type_only
600e5608 g     F .text  00000130 zlib_tr_tally
600e5c2c g     F .text  0000005a __lshrdi3
600e5ce4 g     F .text  0000005e __ashrdi3
600e5c00 g     F .text  0000002c __negdi2
600e53cc g     F .text  0000023c zlib_tr_flush_block
600e5142 g     F .text  0000028a zlib_tr_align
600e5d44 g     F .text  0000016a __Udiv

So it's not very constant.
And my printk debugging indicates that all this very likely happens
while in 
jffs2_scan_medium (fs/jffs2/scan.c).

Best regards, Pieter