Slab errors on 4xx (STB04)

Hi,

I am trying to use the "ppc-soc-ohci" driver on a redwood5 based board w/ kernel 2.6.17-rc1. It's not really inspiring confidence, because I get tons of messages similar to these

[  595.693614] slab error in cache_free_debugcheck(): cache `size-32':
double free, or memory outside object was overwritten
[  595.704278] Call Trace:
[  595.706683] [C056BE10] [C0009DD8] show_stack+0x58/0x194 (unreliable)
[  595.712967] [C056BE40] [C0009F2C] dump_stack+0x18/0x28
[  595.718028] [C056BE50] [C006103C] __slab_error+0x2c/0x3c
[  595.723265] [C056BE60] [C0062FF8] cache_free_debugcheck+0x23c/0x2e0
[  595.729427] [C056BE90] [C0063F64] kfree+0x8c/0x118
[  595.734152] [C056BEC0] [C68F46D0] usb_get_status+0x94/0xac [usbcore]
[  595.740718] [C056BEF0] [C68EEA44] choose_configuration+0x2c/0x1b8
[usbcore]
[  595.747758] [C056BF10] [C68EECCC] usb_new_device+0xfc/0x1bc [usbcore]
[  595.754286] [C056BF30] [C68F0034] hub_port_connect_change+0x24c/0x3dc
[usbcore]
[  595.761669] [C056BF60] [C68F0530] hub_events+0x36c/0x498 [usbcore]
[  595.767955] [C056BF90] [C68F066C] hub_thread+0x10/0xf0 [usbcore]
[  595.774073] [C056BFC0] [C0037CA0] kthread+0xbc/0xc4
[  595.778889] [C056BFF0] [C000525C] kernel_thread+0x44/0x60
[  595.784228] c0dec610: redzone 1:0x5a2cf071, redzone 2:0x170fc2a5.

when accessing devices.

Since it _seems_ to work nevertheless - is CONFIG_DEBUG_SLAB known to be broken on this platform? (Although such stack traces are only printed when doing sth with the USB). Or is this caused by some other (memory initialization?) error?

Greetings,
Andre'

Andre> Since it _seems_ to work nevertheless - is Andre> CONFIG_DEBUG_SLAB known to be broken on this platform? Andre> (Although such stack traces are only printed when doing sth Andre> with the USB). Or is this caused by some other (memory Andre> initialization?) error?

Last time I looked, I think CONFIG_DEBUG_SLAB was broken on non-cache-coherent architectures (such as PPC 4xx). The reason is that the slab poisoning breaks the cacheline alignment of slabs, and then invalidating the cache can trash stuff that slab debugging ends up thinking is overwritten.

- R.

Yes, it's very likely that CONFIG_DEBUG_SLAB is the culprit here. This config option changes allocation alignment (it becomes not L1 cache line aligned). For 4xx which has non-coherent L1 cache this with almost 100% probability will break DMA, resulting in memory corruption.

You can try changing __dma_sync() to do flush_dcache_range() even for DMA_FROM_DEVICE case. However, do this only to check this theory, not as a permanent solution :).

Eugene

Thanks Roland and Eugene for the advice.

OK, I will play with the cache later today... I wanted DEBUG_SLAB turned on for some other unrelated problem, so just for debugging, this hack would be fine if it worked :)

Greetings,
Andre'

Hi,

Eugene, your workaround works, thx!

Andre'