imx27: No space left to write bad block table

[Miquel Raynal]

Hi Fabio,

Fabio Estevam <festevam at gmail.com> wrote on Sat, 17 Apr 2021 12:59:22
-0300:

> Hi,
> 
> I noticed this error recently on a imx27-phytec-phycard-s-rdk reported
> on kernelci:
> 
> nand: device found, Manufacturer ID: 0x20, Chip ID: 0xa1
> nand: ST Micro NAND01GR3B2CZA6
> nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> Bad block table not found for chip 0
> Bad block table not found for chip 0
> Scanning device for bad blocks
> random: fast init done
> Bad eraseblock 329 at 0x000002920000
> Bad eraseblock 330 at 0x000002940000
> Bad eraseblock 331 at 0x000002960000
> Bad eraseblock 332 at 0x000002980000
> Bad eraseblock 333 at 0x0000029a0000
> Bad eraseblock 334 at 0x0000029c0000
> Bad eraseblock 335 at 0x0000029e0000
> Bad eraseblock 336 at 0x000002a00000
> Bad eraseblock 337 at 0x000002a20000
> Bad eraseblock 338 at 0x000002a40000
> Bad eraseblock 339 at 0x000002a60000
> Bad eraseblock 340 at 0x000002a80000
> Bad eraseblock 341 at 0x000002aa0000
> Bad eraseblock 342 at 0x000002ac0000
> Bad eraseblock 343 at 0x000002ae0000
> Bad eraseblock 344 at 0x000002b00000
> Bad eraseblock 345 at 0x000002b20000
> Bad eraseblock 1020 at 0x000007f80000
> Bad eraseblock 1021 at 0x000007fa0000
> Bad eraseblock 1022 at 0x000007fc0000
> Bad eraseblock 1023 at 0x000007fe0000
> No space left to write bad block table
> nand_bbt: error while writing bad block table -28
> mxc_nand: probe of d8000000.nand-controller failed with error -28
> 
> Full log:
> https://storage.kernelci.org/next/master/next-20210416/arm/imx_v4_v5_defconfig/gcc-8/lab-pengutronix/baseline-imx27-phytec-phycard-s-rdk.html
> 
> I don't have access to this board but just wanted to report it.

Thanks for the report!

Indeed that's a misbehavior, this happens when *something* is not
happening correctly and the board boots over and over, each time
decrementing the block supposed to contain the BBT until there are none
available anymore. However I'm not sure this has been caused by a
recent issue as there have not been major changes in the core nor in
this driver since your last fix. Maybe this is a leftover of the
previous situation. Would this be possible? Do you have a mean to find
out the day/kernel version which started failing?

Thanks,
Miquèl