cfi_cmdset_0002: do_write_buffer timeouts

Submitted by Huang Shijie on April 15, 2013, 7:55 a.m.

Details

Message ID 516BB279.9000000@freescale.com
State New, archived
Headers show

Commit Message

Huang Shijie April 15, 2013, 7:55 a.m.
于 2013年04月13日 10:59, Brian Norris 写道:
> Disabling CONFIG_NO_HZ doesn't fix my problem.
I also disable the CONFIG_NO_HZ, and it does not fix my problem too.

But after i remove the mutex_unlock/mutex_lock in 
UDELAY/INVALIDATE_CACHE_UDELAY,
my problem disappears. I run for three days, no timeout occurs. (I do 
not enable the CONFIG_MTD_XIP).


#endif

Comments

Brian Norris April 17, 2013, 9:45 p.m.
On Mon, Apr 15, 2013 at 12:55 AM, Huang Shijie <b32955@freescale.com> wrote:
> 于 2013年04月13日 10:59, Brian Norris 写道:
>
>> Disabling CONFIG_NO_HZ doesn't fix my problem.
>
> I also disable the CONFIG_NO_HZ, and it does not fix my problem too.
>
> But after i remove the mutex_unlock/mutex_lock in
> UDELAY/INVALIDATE_CACHE_UDELAY,
> my problem disappears. I run for three days, no timeout occurs. (I do not
> enable the CONFIG_MTD_XIP).
>
>
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -1043,17 +1043,13 @@ static void __xipram xip_udelay(struct map_info
> *map, struct flchip *chip,
>
> #define UDELAY(map, chip, adr, usec) \
> do { \
> - mutex_unlock(&chip->mutex); \
> cfi_udelay(usec); \
> - mutex_lock(&chip->mutex); \
> } while (0)
>
> #define INVALIDATE_CACHE_UDELAY(map, chip, adr, len, usec) \
> do { \
> - mutex_unlock(&chip->mutex); \
> INVALIDATE_CACHED_RANGE(map, adr, len); \
> cfi_udelay(usec); \
> - mutex_lock(&chip->mutex); \
> } while (0)
>
> #endif

This patch doesn't solve my problem, so it seems that Huang and I
probably are seeing different root causes for these timeouts.

I tried applying this patch and then timing the exact delay seen by
the time we "time out" (by directly accessing the CPU count register),
and the delay is always very close to 4ms (with my kernel, HZ=250, so
4ms is expected). So it seems like my system is waiting plenty long
(according to the flash part specification) but if I wait even longer,
the operation does complete successfully.

I'll continue to look at this issue, but I thought I'd post my results so far.

Brian
Huang Shijie April 18, 2013, 2:09 a.m.
于 2013年04月18日 05:45, Brian Norris 写道:
> This patch doesn't solve my problem, so it seems that Huang and I
> probably are seeing different root causes for these timeouts.
>
yes. My timeout maybe caused by the error in the erase-suspend/erase-resume.

thanks
Huang Shijie

Patch hide | download patch | download mbox

--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -1043,17 +1043,13 @@  static void __xipram xip_udelay(struct map_info 
*map, struct flchip *chip,

#define UDELAY(map, chip, adr, usec) \
do { \
- mutex_unlock(&chip->mutex); \
cfi_udelay(usec); \
- mutex_lock(&chip->mutex); \
} while (0)

#define INVALIDATE_CACHE_UDELAY(map, chip, adr, len, usec) \
do { \
- mutex_unlock(&chip->mutex); \
INVALIDATE_CACHED_RANGE(map, adr, len); \
cfi_udelay(usec); \
- mutex_lock(&chip->mutex); \
} while (0)