Slab errors on 4xx (STB04)

Slab errors on 4xx (STB04)

[Andre Draszik]

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'

Re: Slab errors on 4xx (STB04)

[Roland Dreier]

    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.

Re: Slab errors on 4xx (STB04)

[Eugene Surovegin]

On Mon, Apr 10, 2006 at 12:33:56AM +0200, Andre Draszik wrote:
> 
> Since it _seems_ to work nevertheless - is CONFIG_DEBUG_SLAB known to be
> broken on this platform?

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

Re: Slab errors on 4xx (STB04)

[Andre Draszik]

Eugene Surovegin wrote:
> On Mon, Apr 10, 2006 at 12:33:56AM +0200, Andre Draszik wrote:
>> Since it _seems_ to work nevertheless - is CONFIG_DEBUG_SLAB known to be
>> broken on this platform?
> 
> Yes, it's very likely that CONFIG_DEBUG_SLAB is the culprit here. This 
> [...]

Thanks Roland and Eugene for the advice.

> 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 :).

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'

Re: Slab errors on 4xx (STB04)

[Andre Draszik]

Hi,

Andre Draszik wrote:
> Eugene Surovegin wrote:
>> 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 :).
> 
> 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 :)

Eugene, your workaround works, thx!

Andre'