Numonyx NOR flash mutex problem when creating UBI volumes

Numonyx NOR flash mutex problem when creating UBI volumes

[Stefan Bigler]

Hi all,
we have on a powerpc based board with a new Numonyx P30 65nm 1GBit flash and
we see have problems with write errors when we create an ubi volume.

To find the problem I added few printk in the cfi_cmdset_0001.c
Adding a printk for erase suspend make the problem show always.
I expect a problem with the protection as discussed already in the thread
Numonyx NOR and chip->mutex bug?

I printed the time (using jiffies), the tid, the operation and address 
of the operation.


-bash-3.2# ubimkvol /dev/ubi0 -s 6MiB -N test_volume

  time   tid  operation               address of operation       my comments
--------------------------------------------------------------------------------- 

[0179][0209] do_erase_oneblock start adr=0x00000000             start 
erase block
[0187][0465] erase suspend           adr=0x01125000             erase 
suspend (strange adr)
[0191][0209] erase resumed           adr=0x00000000             erase 
resume  (correct adr)
[0199][0209] do_erase_oneblock end   adr=0x00000000             erase end
[1175][0465] 50000000.flash: buffer write error status 0xb0 
adr=0x01125400 len=0x400

program failed status (0xb0) ready & cmd sequence error

In addition I added all cmd sent to the flash in a buffer and print it 
in case of error.
Here is the log:

  time   tid  operation                                  my comments
--------------------------------------------------------------------------------- 

[0187][0209] do_erase_oneblock start adr=0x00000000     first thread  
Start with erasing adr=0
[0187][0209] map_write 0x50 to 0x00000000                             
Clr Status Reg
[0187][0209] map_write 0x20 to 0x00000000                      Block 
Erase adr=0
[0187][0209] map_write 0xd0 to 0x00000000                      Block 
Erase Confirm adr=0
[0187][0465] map_write 0xb0 to 0x01125000               second thread 
Erase suspend
[0191][0465] map_write 0x70 to 0x01125000                      Read 
Status Reg
[0191][0465] map_write 0xe8 to 0x01125000                             
Buffered Prog  adr=0x01125000
[0191][0209] map_write 0x70 to 0x00000000               first thread  
Read Status Reg
[0191][0209] map_write 0xd0 to 0x00000000                             
Resume (what!?!)
[0191][0209] map_write 0x70 to 0x00000000                             
Read Status Reg
[0199][0209] erase resumed 2b        adr=0x00000000                   
(Erase) Resumed Finsh
[0207][0209] do_erase_oneblock end   adr=0x00000000                   
Erase finished
[0207][0465] map_write 0x1ff to 0x01125000              second thread 
!!! contiune with Buffer Prog, write size
[0207][0465] map_write 0xc03c0000 to 0x01125000                       
write 512 word data to buf
[0207][0465] map_write 0xc03c0000 to 0x01125002
..
[0211][0465] map_write 0xc03c0000 to 0x011253fc
[0211][0465] map_write 0xc03c0000 to 0x011253fe
[0211][0465] map_write 0xd0 to 0x01125000                             
Buffered Prog Confirm
[1175][0465] map_write 0x50 to 0x01125000                  Clr Status Reg
[1175][0465] map_write 0x70 to 0x01125000                             
Read Status Reg
[1183][0465] 50000000.flash: buffer write error status 0xb0 
adr=0x01125400 len=0x0 (0x400)  Buffered Prog failed status (0xb0) ready 
& cmd sequence error

Conclusion:
I expect is a protection problem. A running erase is suspended due to 
write. But the write is not finished.
The erase is resumed in the middle of the buffered Prog preparation.

Do you have any ideas why this can happen?

Best Regards
Stefan Bigler

Re: Numonyx NOR flash mutex problem when creating UBI volumes

[Michael Cashwell]

On Feb 2, 2011, at 6:18 AM, Stefan Bigler wrote:

> To find the problem I added few printk in the cfi_cmdset_0001.c
> Adding a printk for erase suspend make the problem show always.

Interestingly, I've tended to see the problem also when doing UBI, but during writes, not formatting. And in my case adding printks to any relevant hot path tended to make the problem vanish.

> I expect a problem with the protection as discussed already in the thread Numonyx NOR and chip->mutex bug?

I believe I've found the issue. It was not a mutex bug as I originally thought though it was true that not dropping the chip mutex while waiting for lengthy commands to complete did mask the problem.

I was going to post my results later today anyway but as you are also struggling I'll endeavor to do this soon. I will also make the post as a follow-on to the message thread I originally started.

Just a few minutes, please.

-Mike Cashwell