Hi Stefan, I address this question to you because one of your commits is connected to this problem, but other hints from other readers are also welcome ;-) .
We have a kirkwood based board with a micron NAND flash. We have one ubi device created on the NAND flash and inside the device we have one ubi volume were we store our linux kernel. At startup we attach to the ubi device, to be able to readout the kernel image. On our old u-boot branch which based on v2009.08 we hadn't any problems. Now after upgrading to the newest u-boot version we saw in some rarely cases our u-boot get stuck when we try to attach:
=> ubi part ubi0 Creating 1 MTD partitions on "nand0": 0x000000000000-0x000008000000 : "mtd=0" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: fixable bit-flip detected at PEB 71
And after this u-boot gets stuck until the end of days and we have to force a reboot, but the u-boot gets stuck again.
If I revert your commit: commit 1b1f9a9d00447d9eab32ae5633f60a106196b75f Author: Stefan Roese sr@denx.de Date: Mon May 17 10:00:51 2010 +0200
UBI: Ensure that "background thread" operations are really executed
the u-boot don't get stuck:
=> ubi part ubi0 Creating 1 MTD partitions on "nand0": 0x000000000000-0x000008000000 : "mtd=0" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: fixable bit-flip detected at PEB 71 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=0" UBI: MTD device size: 128 MiB UBI: number of good PEBs: 1024 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 9 UBI: available PEBs: 623 UBI: total number of reserved PEBs: 401 UBI: number of PEBs reserved for bad PEB handling: 10 UBI: max/mean erase counter: 8193/3082 =>
This is the reason why our old u-boot works, because the background thread seems to be not or not completely executed...
If I boot a recent linux kernel the kernel also reports an "fixable bit-flip detected at PEB 71" but linux is able to really fix this bit flip and is able to work as expceted, even u-boot is afterwards bootable because the bitflip is corrected and gone.
Now I could revert your commit in my local branch and then it seems to work, but I think this is not a good solution because I expect that the real error is somewhere in the UBI layer in u-boot and already fixed in current linux. AFAIK the ubi layer was initially copied from linux, but it seems that the bugfixes are not backported in the last years. Any thoughts or ideas?
Best regards Holger