RE: Debugng the flash watchdog problem

["Mikael Starvik" <starvik@xxxxxxxx>]

Great, thanks!

>Could it be that simply the n-th printk fails to re-enable the
interrupts?
>(strange though, that the interrupts are somehow enabled again at a
later 
>stage. If the watchdog is disabled, the system boots normally)

Could be when the printk log buffer wraps or if another process is
already
printing etc. I'll try to find int. There are some situations when
interrupts
are enabled unconditionally e.g. when the system call returns the CPU
flags
(including the interrut enable flag) is restored to the state they were
before the interrupt.

-----Original Message-----
From: Pieter Grimmerink [mailto:mailinglists@xxxxxxx.nl] 
Sent: Tuesday, April 04, 2006 3:13 PM
To: Mikael Starvik
Cc: dev-etrax
Subject: Re: Debugng the flash watchdog problem


On Tuesday 04 April 2006 11:05, Mikael Starvik wrote:
> I'll continue to investigate that and try to find the location.
> Meanwhile it would be great if you could add the following
> in the start of cfi_amdstd_read.
>
> I know, I ask a lot. I would be happy if I could repeat it here...

No problem, I'm glad we're finally getting somewhere with this strange 
situation ;-)

This is the result:

JFFS2: Erase block at 0x001a0000 is not formatted. It will be erased
Interrupts disabled in jffs2_scan_medium (after printk)
Interrupts disabled in jffs2_scan_medium (before list_add 7)
Interrupts disabled in jffs2_scan_medium (after list_add 7)
Interrupts disabled in jffs2_scan_medium (before jffs2_scan_eraseblock)
Interrupts disabled in jffs2_scan_eraseblock (start)
Interrupts disabled in jffs2_scan_empty
Interrupts disabled in part_read
Interrupts disabled in cfi_amdstd_read
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0fa4: 
0xfeff instead
ERP 60093804
20ED10 80 61F10000 6013DFF7 1A 204131 203133 34300020 A 371E 371E
6011A020 
60006BDE 60113798 60113798 3745
3745 61F20240 C 20 61954500 27 80 60006D3A 6013A4CF E9848 60006ED4 0 
61F42000 61F42000 6005F728 0
0 0 0 6013DFF7 0 1 E9848 61F20240 C 20 20ED10 80 61F10000 6013DFF7 1A 0
400 6009450A 60093804 61F10000 6013DFF7 1A 6009450A 21 6013DFF0 6011A020

60110080 600616CE 3769 3748 3748 6011A020
60006BDE 60113798 60113798 3769 3769 60006D12 21 6013E8AC FFFFDBC1
60130080 
60006F78 61F40080 60006D3A 6013A4C9 60006ED4 C
61F403A0 0 20ED10 A0BABDFD 1B9 35F 81A4 600800A6 600F85C8 20ED10 0 C
C6000 
2000 6195450C 61F7ECE8
61954500 61F403A0 6005B2BA 61995E3C 61995E48 61F7ECE8 0 61F7ECE8 0
61954500 
60006DA0 C A 20ED10 C0021985 2044
A0BABDFD 6005ADEE 61961F02 61968000 61F7ED3C 61F7ECE8 61F7EC00 61F7ED1C 
61F7ECF0 6005D2F4 61F7ECE8 61F7EC00 61F7ED1C 1 61F7ED4C 6005A4A6
61F7EC00 60119084 0 60115868 61F7EC28 1 0 61F7ED1C 61F7ED1C 6002509E 0 
6196C000 61968000 0 FFFFFFF4 6196A000
60119084 603F24C0 61B0BEE0 603F23C0 603F24C0 FFFFFFF4 6196A000 9 1
6002525A 
61968000 61995F50 0 0 61995F50 6196C000
60033BC2 61995F50 0 6196A000 61F39000 0 60033E0A 6196A000 61968000 84710
0 
C0ED0000 E9858 60033C72 61F39000 0
61966120 603F23C0 2000 E9858 60033C72 9 1 6003412C 61968000 4FFFFF81
EB878 
E9858 C0ED0000 0 61968000 6196A000
6196C000 6005F5C6 E9848 B73E2 61995FA4 0 E9858 C0ED0000 4FFFFF81 EB878 
FFFFFFDA 15 E9848 0 84710 0
4FFFFF81 EB878 E9858 C0ED0000 C0ED0000 E9848 5A0 B73E2 1AC26168 F0000180

1AC26160 1AAB44AE 4F08200A 61504074 6E6F4379 73752F20
6F6C2F72 5D6C6163 23313731 20 0 0 0 0 0 0 0 0 0 0 0 0

Very strange, it seems to be printk(KERN_NOTICE...) which leaves the 
interrupts disabled.

Attached is fs/jffs2/scan.c, with my debug messages.
The printk is on line 250.
I tried to remove the format field, but that didn't change it.
Removed KERN_NOTICE as well, still the same.
Shortened the debug message, and no change.
Replaced it by some other message, and the problem remains.

Could it be that simply the n-th printk fails to re-enable the
interrupts?
(strange though, that the interrupts are somehow enabled again at a
later 
stage. If the watchdog is disabled, the system boots normally)

Best regards, Pieter