Slub debugging NAND error in 2.6.25.10.atmel.2

[Eirik Aanonsen]

>"Eirik Aanonsen" <eaa at wprmedical.com> wrote:
>> > Using physmap partition information
>> > Creating 5 MTD partitions on "physmap-flash.0":
>> > 0x00000000-0x00020000 : "u-boot"
>> > 0x00020000-0x00640000 : "root"
>> > 0x00640000-0x00720000 : "kernel1"
>> > 0x00720000-0x007e0000 : "modules"
>> > 0x007e0000-0x00800000 : "env"
>> > NAND device: Manufacturer ID: 0xec, Chip ID: 0xd5 (Samsung NAND 2GiB
>3,3V 8-bit)
>> > Scanning device for bad blocks
>> > Bad eraseblock 31 at 0x00f80000
>> > Bad eraseblock 1579 at 0x31580000
>> > Bad eraseblock 2921 at 0x5b480000
>> > Bad eraseblock 2931 at 0x5b980000
>> > Bad eraseblock 3359 at 0x68f80000
>> > Creating 1 MTD partitions on "atmel_nand":
>> > 0x00000000-0x80000000 : "main"
>> >
>========================================================================
>=====
>> > BUG kmalloc-4096: Poison overwritten
>> > --------------------------------------------------------------------
>---------
>
>Hmm...I just saw this when booting 2.6.27-rc5 on the NGW100:
>
>physmap platform flash device: 00800000 at 00000000
>physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
> Amd/Fujitsu Extended Query Table at 0x0041
>number of CFI chips: 1
>cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
>RedBoot partition parsing not available
>Using physmap partition information
>Creating 3 MTD partitions on "physmap-flash.0":
>0x00000000-0x00020000 : "u-boot"
>0x00020000-0x007f0000 : "root"
>kobject (91ce8410): tried to init an initialized object, something is
>seriously wrong.
>Call trace:
> [<90017184>] dump_stack+0x18/0x20
> [<900c1894>] kobject_init+0x28/0x5c
> [<900c1bf6>] kobject_init_and_add+0xe/0x24
> [<900beff0>] blk_register_filter+0x28/0x40
> [<900be224>] add_disk+0x38/0x68
> [<900e70f0>] add_mtd_blktrans_dev+0x174/0x184
> [<900e748e>] mtdblock_add_mtd+0x36/0x3c
> [<900e6e38>] blktrans_notify_add+0x1a/0x3a
> [<900e533c>] add_mtd_device+0x60/0xa0
> [<900e5f7e>] add_mtd_partitions+0x37a/0x3a0
> [<900ec4d0>] physmap_flash_probe+0x1ec/0x21c
> [<900e0f24>] platform_drv_probe+0x10/0x12
> [<900e06d0>] driver_probe_device+0x84/0xf0
> [<900e076a>] __driver_attach+0x2e/0x44
> [<900e0096>] bus_for_each_dev+0x2e/0x4c
> [<900e05b6>] driver_attach+0x12/0x14
> [<900e036c>] bus_add_driver+0x6c/0x178
> [<900e08a4>] driver_register+0x58/0xb0
> [<900e1126>] platform_driver_register+0x56/0x5c
> [<9000aaf6>] physmap_init+0xa/0x10
> [<9001422a>] do_one_initcall+0x2a/0x10c
> [<900005b8>] kernel_init+0x48/0x90
> [<9001fcc0>] do_exit+0x0/0x4cc
>
>0x007f0000-0x00800000 : "env"
>kobject (91ce8410): tried to init an initialized object, something is
>seriously wrong.
>Call trace:
> [<90017184>] dump_stack+0x18/0x20
> [<900c1894>] kobject_init+0x28/0x5c
> [<900c1bf6>] kobject_init_and_add+0xe/0x24
> [<900beff0>] blk_register_filter+0x28/0x40
> [<900be224>] add_disk+0x38/0x68
> [<900e70f0>] add_mtd_blktrans_dev+0x174/0x184
> [<900e748e>] mtdblock_add_mtd+0x36/0x3c
> [<900e6e38>] blktrans_notify_add+0x1a/0x3a
> [<900e533c>] add_mtd_device+0x60/0xa0
> [<900e5f7e>] add_mtd_partitions+0x37a/0x3a0
> [<900ec4d0>] physmap_flash_probe+0x1ec/0x21c
> [<900e0f24>] platform_drv_probe+0x10/0x12
> [<900e06d0>] driver_probe_device+0x84/0xf0
> [<900e076a>] __driver_attach+0x2e/0x44
> [<900e0096>] bus_for_each_dev+0x2e/0x4c
> [<900e05b6>] driver_attach+0x12/0x14
> [<900e036c>] bus_add_driver+0x6c/0x178
> [<900e08a4>] driver_register+0x58/0xb0
> [<900e1126>] platform_driver_register+0x56/0x5c
> [<9000aaf6>] physmap_init+0xa/0x10
> [<9001422a>] do_one_initcall+0x2a/0x10c
> [<900005b8>] kernel_init+0x48/0x90
> [<9001fcc0>] do_exit+0x0/0x4cc
>
>I wonder if it's related?
>
>Haavard
>

The fault from my posts here seems to be related to a wrong definition related to my board. I had to change the include/linux/mtd/nand.h
Where I had to replace:
#define NAND_MAX_OOBSIZE	64
#define NAND_MAX_PAGESIZE	2048
With:
#define NAND_MAX_OOBSIZE	128
#define NAND_MAX_PAGESIZE	4096
Nice the nand driver did not allocate enogh memory to handle ny nand flash. This was what caused the overwriting of the memory in my case.

It could prove useifull to have these values in KConfig instead in an header, since the size of these values differ a lot from chip to chip?

Eirik Aanonsen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: neko_test.elf
Type: application/octet-stream
Size: 665804 bytes
Desc: neko_test.elf
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20080829/12590c1f/attachment-0001.obj