Bug: Flash writing & suspending

Bug: Flash writing & suspending

[Holger Schurig]

Hi !  I get the above error message sometimes when I write to the flash.

I use Kernel 2.6.13-rc2, but with the MTD (drivers/mtd/, include/mtd, 
include/linux/mtd) from today's CVS. JFFS2 is still the old one.

 partitions are

I wrote a little tests script which can trigger the error:

----------------------------------------------
#!/bin/sh
cd /tmp
for i in 0 1 2 3 4 5 6 7 8 9; do
        logread >log$i.txt
done

for i in 0 1 2 3 4 5 6 7 8 9; do
        rm -f /opt/mn/log*.txt
        cp log*.txt /opt/mn
done

ls /opt/mn/

echo mem >/sys/power/state

ls /opt/mn/
----------------------------------------------

Now I run this script, resume by pressing a key, run it, resume, run it etc. 
Sometimes at the first run, sometimes at the second or third I get this 
error:

Flash: Waiting for chip to be ready timed out. Status 913ad69c
Write of 48 bytes at 0x01db67b4 failed. returned -5, retlen 0
Not marking the space at 0x01db67b4 as dirty because the flash driver returned 
retlen zero
Flash: Waiting for chip to be ready timed out. Status e0011985
error -5 reading node at 0x00890c44 in get_inode_nodes()
jffs2_get_inode_nodes() for ino 1086 returned -5
...



So, where is the culprit?






Additional infos


My partitions are:

/dev/root on / type jffs2 (rw,noatime)
proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
none on /sys type sysfs (rw)
tmpfs on /var type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw)


Flash related kernel messages are:

...
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
...
Flash: Found 2 x16 devices at 0x0 in 32-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Creating 3 MTD partitions on "Flash":
0x00000000-0x00040000 : "Boot"
0x00040000-0x00140000 : "Linux"
0x00140000-0x02000000 : "Files"
...
VFS: Mounted root (jffs2 filesystem).
...


The flash chips are Intel Strataflash 28F128J3A-150 on an Intel PXA255 device.


Flash related kernel .config is like this (all non-mention 
CONFIG_MTD-variables are in the 'is not set'-state):

CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y

CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y

CONFIG_MTD_CFI=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_UTIL=y  
CONFIG_MTD_MAP_MN=y

CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y

Re: Bug: Flash writing & suspending

[Holger Schurig]

> I use Kernel 2.6.13-rc2, but with the MTD (drivers/mtd/, include/mtd,
> include/linux/mtd) from today's CVS. JFFS2 is still the old one.

Oh, BTW, the same error happens also on:

a) plain 2.6.13-rc2
b) 2.6.13-rc2 with both MTD and JFFS2 from CVS (using the ./patchkernel.sh)

The reason I just installed (manually) the MTD stuff only has to do with a 
suspicion about the problem source.

I suspect that maybe MTD is writing data into the StrataFlash. While this 
erasing & writings happens, it probably polls the built-in state-machine 
status of the chips. Probably during such an operation the suspend-to-memory 
takes place. The hardware switches off the power to the StrataFlash, but MTD 
doesn't know about this.

At resume time, the StataFlash get's power and resets to some initial state. 
Linux thaws the processes, among them the JFFS2/MTD thread. Which continues 
to poll the StrataFlash, but because it has been resetted in the meantime ...

Re: Bug: Flash writing & suspending

[Todd Poynor]

Holger Schurig wrote:

> I suspect that maybe MTD is writing data into the StrataFlash. While this 
> erasing & writings happens, it probably polls the built-in state-machine 
> status of the chips. Probably during such an operation the suspend-to-memory 
> takes place. The hardware switches off the power to the StrataFlash, but MTD 
> doesn't know about this.
> 
> At resume time, the StataFlash get's power and resets to some initial state. 
> Linux thaws the processes, among them the JFFS2/MTD thread. Which continues 
> to poll the StrataFlash, but because it has been resetted in the meantime ...

Right, the mtd state machine goes out of sync with the actual chip state 
when the system sleep mode power cycles the chips.

I submitted a patch to rmk's ARM patch system that adds flash chips as 
platform devices to the Lubbock (PXA25x eval board) and Mainstone 
(PXA27x eval board) files.  If that's accepted, I'll send a common 
PXA2xx platform driver for mtd that adds the PM suspend/resume callbacks 
as discussed here recently.

In the meantime, get the struct mtd_info's ->resume routine called 
somehow at resume time.

-- 
Todd

Re: Bug: Flash writing & suspending

[Holger Schurig]

> In the meantime, get the struct mtd_info's ->resume routine called
> somehow at resume time.

Thanks, that solved my problem.


> If that's accepted, I'll send a common PXA2xx platform driver for mtd that
> adds the PM suspend/resume callbacks as discussed here recently.

Do you mean something like the sa1100-flash.c file?  Can't you re-use this 
file?

Re: Bug: Flash writing & suspending

[Todd Poynor]

Holger Schurig wrote:
>>If that's accepted, I'll send a common PXA2xx platform driver for mtd that
>>adds the PM suspend/resume callbacks as discussed here recently.
> 
> Do you mean something like the sa1100-flash.c file?  Can't you re-use this 
> file?

Although we would need to do something about the sa1100-specific 
physical addresses and register access for bankwidth (this could 
probably go into the info passed from board files, there's a width field 
of the flash_info struct), and perhaps the pxa2xx cache invalidate code, 
but: yes, we're pretty close to a generic mapping driver for arches that 
declare a include/asm/mach/flash.h compatible with ARM's.  And there's 
probably a need for an alternative to the current definition of struct 
device's platform_data for these sorts of things, since many uses of 
platform_data really hold info represented in generic data structures, 
without a need for platform-specific definition or interpretation, so it 
could be on all platforms.  I might try to run that by folks sometime soon.


-- 
Todd