CFI/MTD weird problem

CFI/MTD weird problem

[Nicola]

Booting a linux-2.4.19-rmk4-ds3 I get this weird problem: 

1.Without MTD support module I get a good output to console until the
kernel prints out that there is no filesystem support. So my system's
printk works fine.

2.With MTD support module 
The CFI probing is working correctly and detects QRY. 
When I start tracing the code execution putting some printk into the
MTD/CFI code, I get a weird behavior where the console output is
corrupted BEFORE the calling of the MTD/CFI code, (see minicom log
below).
And I get out some '%' chars instead of the regular numerical values. 

After some days debugging this problem I need a suggestion because I
have exhausted ideas about where to search. 
TIA 

CFI/MTD weird problem

[Graham Greene]

Is code executing out of the flash part being queried? Only thing I can
think of off hand.

gg

-----Original Message-----
From: linux-mtd-admin@lists.infradead.org
[mailto:linux-mtd-admin at lists.infradead.org]On Behalf Of Nicola
Sent: Friday, February 07, 2003 12:03 PM
To: linux-mtd at lists.infradead.org
Subject: CFI/MTD weird problem


Booting a linux-2.4.19-rmk4-ds3 I get this weird problem:

1.Without MTD support module I get a good output to console until the
kernel prints out that there is no filesystem support. So my system's
printk works fine.

2.With MTD support module
The CFI probing is working correctly and detects QRY.
When I start tracing the code execution putting some printk into the
MTD/CFI code, I get a weird behavior where the console output is
corrupted BEFORE the calling of the MTD/CFI code, (see minicom log
below).
And I get out some '%' chars instead of the regular numerical values.

After some days debugging this problem I need a suggestion because I
have exhausted ideas about where to search.
TIA




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

CFI/MTD weird problem

[Nicola]

I forgot to attach the console output that could be useful to understand
the problem:

Uncompressing Linux............................................ done,
booting the kernel.
Linux version 2.4.19-rmk4-ds2 (local at localhost.localdomain) (gcc version
2.95.3 20010315 (release)) #261 ven feb 7 14:32:33 CET 2003
CPU: %s revision -1073616200
Machine: %
Ignoring unrecognised tag 0x00000000
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: %
Calibrating delay loop... 398.%2lu BogoMIPS
Memory: 64MB = 64MB total
Memory: 63344KB available (1187K code, 205K data, 52K init)
XScale Cache/TLB Locking Copyright(c) 2001 MontaVista Software, Inc.
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
init!
Unable to handle kernel %at virtual address c0127b5c
pgd = c0004000
*pgd = 00000000, *pmd = 00000000
Internal error: %: c0127b6c

CFI/MTD weird problem

[Jörn Engel]

On Fri, 7 February 2003 18:03:24 +0100, Nicola wrote:
> When I start tracing the code execution putting some printk into the
> MTD/CFI code, I get a weird behavior where the console output is
> corrupted BEFORE the calling of the MTD/CFI code, (see minicom log
> below).
> And I get out some '%' chars instead of the regular numerical values. 

When adding/removing a printk changes the behaviour of the code, the
usual cause is memory and/or cache corruption. Among the stuff I have
seen:
- struct foo* cast to struct bar*, where sizeof(struct bar) >
  sizeof(struct foo). Writing to bar mangles someone elses memory, the
  concrete owner varies depending on the printks.
- dma buffer not alligned to cacheline size. part of dma buffer is in
  processor cache, dma transfers into buffer, variable on same
  cacheline is written and complete cacheline written back to memory.
  Part of the dma buffer now contains the old data again.
  Again, a printk might accidentally align the dma buffer, fixing the
  problem.

The problem with these bugs is that they take a long time to track
down. Weeks or month are not uncommon. Good luck!

J?rn

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth