MTD suspend/resume bug
Russell King
rmk at arm.linux.org.uk
Wed Nov 10 15:43:31 EST 2004
People,
There appears to be a bug in the Intel CFI suspend/resume code in
2.6.10-rc1.
Looking at cfi_intelext_suspend() and cfi_intelext_resume(), consider
what happens if we suspend a MTD device, resume it, and then suspend
it again, with an intermediate switch to FL_STATUS mode.
Initial state:
cfi->oldstate = FL_READY;
cfi->state = FL_STATUS; (eg)
First suspend:
cfi->oldstate = FL_STATUS;
cfi->state = FL_PM_SUSPENDED;
Resume:
cfi->state = FL_READY;
Note: we do not touch cfi->oldstate here.
<something here sets cfi->state to FL_STATUS>
Second suspend:
At this point, cfi->state == FL_STATUS, cfi->oldstate == FL_STATUS.
Since cfi->oldstate != FL_READY, we do not set cfi->oldstate nor
cfi->state.
Resume occurs. Flash chip was powered off so is now in READY mode,
but MTD thinks its in FL_STATUS and complains about bad chip status:
Waiting for chip to be ready timed out. Status 41927a42
Write of 83 bytes at 0x00cf34e4 failed. returned -5, retlen 0
Not marking the space at 0x00cf34e4 as dirty because the flash driver returned retlen zero
Waiting for chip to be ready timed out. Status e0021985
Error reading node from 0x00917d88: -5
Shouldn't the resume function set both cfi->oldstate and cfi->state
to FL_READY ?
--
Russell King
More information about the linux-mtd
mailing list