Numonyx NOR and chip->mutex bug?

[Joakim Tjernlund]

Michael Cashwell <mboards at prograde.net> wrote on 2011/02/05 22:47:33:
>
> Sorry, I misattributed these log entries. That's Stefan's info, not Joakim's.
>
> But still interesting...
>
> On Feb 2, 2011, at 12:37 PM, Stefan Bigler wrote:
>
> > [2307][465] erase suspend 1         adr=0x03fe5000
> > [2307][465] map_write 0x70 to 0x03fe5000
> > [2307][465] map_write 0xe8 to 0x03fe5000
> > [2307][209] map_write 0x70 to 0x00020000
> > [2307][209] map_write 0x50 to 0x00020000
> > [2307][209] map_write 0xd0 to 0x00020000
> > [2307][209] map_write 0x70 to 0x00020000
> > [2311][209] erase resumed 2b        adr=0x00020000
> > [2319][209] do_erase_oneblock end   adr=0x00020000 len=0x20000
> > [2319][465] map_write 0x1ff to 0x03fe5000
> > [2319][465] map_write 0xc03c0000 to 0x03fe5000
> > [2319][465] map_write 0xc03c0000 to 0x03fe5002
>
> Focusing even more on this... The last 3 lines are telling. That looks very much like a word count for the buffered write followed by data.
>
> So I think we're on the right track overall. Between the 0xe8 and the word count 0x1ff a suspended erase thread is jumping in and disturbing things.
>
> It's not that doing that causes incorrect bits in the SR but that it disrupts up the 0xe8/count/data... sequence that must happen atomically. That later causes a command sequence error, which is what the status 0xb0 means.
>
> So how is an erase thread waking up and not seeing the chip->state to be something other than the FL_ERASING and going back to sleep?

The only thing I can think of the the earlier discussion about dropping the lock.

Oh, one more thing, possibly one needs to add cpu_relax() or similar
to force gcc to reload chip->state in the while loop?

 Jocke