* Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> Well, just to let others who have this problem know, it's clear that
> Ingo's rt-preempt patches increase stack pressure on systems (like
> mine) where stack is borderline under 4K by default.
>
> If you disable CONFIG_4KSTACKS the stack overflows seem to disappear.
> As a result, until we isolate the problem, it'd probably be better if
> Ingo maintained an 8K stacks option in the rt-preempt patches assuming
> Adrian Bunk's "kill !4KSTACKS" patch gets into mainline..
Ok. Could you try to debug this some more? In the -51-17 patch i've
implemented a new stack-overflow debugging feature: 'stack footprint
maximum searching'. It is automatically active if you have
CONFIG_LATENCY_TRACE and CONFIG_DEBUG_STACKOVERFLOW enabled. It will
track and (if it can be done safely) print out maximum stack usage sites
immediately. Hopefully this results in better stackdumps. It should
print similar traces:
----------------------------->
| new stack-footprint maximum: smartd/1747, 1768 bytes.
------------|
[<c013c1b6>] check_raw_flags+0xb/0x55 (8)
[<c013ebeb>] sub_preempt_count+0x1a/0x1c (8)
[<c013cb28>] __mcount+0x6a/0x91 (28)
[<c013c3ff>] irqs_disabled+0x8/0x19 (16)
[<c013c7b5>] ____trace+0x9e/0x208 (4)
[<c01142d8>] mcount+0x14/0x18 (24)
[<c013c3ff>] irqs_disabled+0x8/0x19 (20)
[<c013c7b5>] ____trace+0x9e/0x208 (8)
[<c013f145>] trace_stop_sched_switched+0x40/0x17d (8)
[...]
i've written a separate, hopefully more robust stack-dumper which is
used for the above traces. Perhaps in your overflow case it results in
something usable.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
