Linux Kernel Seeing Workaround Revived For Buggy Micron NAND Block Erase Behavior
A new patch series has been revived from work originally published by Micron back in 2018 for dealing with the behavior on their planar 2D NAND devices where in rare cases when issuing block erase commands, the flash block might not actually be erased and this could lead to further problems down the road when touching said block.
Five patches sent out today revive Micron's work in dealing with some of their legacy 2D NAND devices where when a block erase command is issued, the block erase operation completes and a pass status returned, the flash block might have not been erased. But making matters worse is that operations on said blocks could in rare cases lead to subtle failures or corruption.
At least according to Micron's Bean Huo, these cases should be "extremely rare" but nevertheless is seeing Linux kernel patchwork in an attempt to ensure the problem doesn't come up. The workaround for affected Micron NAND is to ensure at least fifteen pages are programmed to a block before it is erased. If there haven't been 15 pages programmed, the MTD code will rewrite the first 15 pages of the block.
The revived Linux kernel work for this issue can be found on the LKML.
Five patches sent out today revive Micron's work in dealing with some of their legacy 2D NAND devices where when a block erase command is issued, the block erase operation completes and a pass status returned, the flash block might have not been erased. But making matters worse is that operations on said blocks could in rare cases lead to subtle failures or corruption.
At least according to Micron's Bean Huo, these cases should be "extremely rare" but nevertheless is seeing Linux kernel patchwork in an attempt to ensure the problem doesn't come up. The workaround for affected Micron NAND is to ensure at least fifteen pages are programmed to a block before it is erased. If there haven't been 15 pages programmed, the MTD code will rewrite the first 15 pages of the block.
The revived Linux kernel work for this issue can be found on the LKML.
2 Comments