Messages in this thread Patch in this message | | | Subject | Re: 2.6.18-rt1 | From | john stultz <> | Date | Thu, 28 Sep 2006 15:48:51 -0700 |
| |
On Wed, 2006-09-27 at 17:42 -0700, john stultz wrote: > On Fri, 2006-09-22 at 13:58 +0200, Ingo Molnar wrote: > > * john stultz <johnstul@us.ibm.com> wrote: > > > > > I'm seeing a similar issue. Although the log is a bit futzed. Maybe > > > its the sd_mod? > > > > > > at virtual address 75010000le kernel paging requestproc filesystem > > > > would be nice to figure out why it crashes - unfortunately i cannot > > trigger it. Could it be some build tool incompatibility perhaps? Some > > sizing issue (some module struct gets too large)? > > Been looking a bit deeper into this again: [snip] > c03879e8 r __ksymtab_find_next_bit > c03879f0 r __ksymtab_find_next_zero_bit > c03879f8 R __write_lock_failed > c0387a18 R __read_lock_failed > c0387a2c r __ksymtab___delay > c0387a34 r __ksymtab___const_udelay > c0387a3c r __ksymtab___udelay > c0387a44 r __ksymtab___ndelay > > That __read/__write_lock_failed bit looks wrong.
So it seems gcc 3.4.4 misplaces the __write_lock_failed function into the ksymtab. It doesn't happen w/ 4.0.3.
Anyway, this patch explicitly defines the section and fixes the issue for me. Would the other reporters of this issue give it a whirl as well?
thanks -john
Index: linux-rtj14/arch/i386/lib/bitops.c =================================================================== --- linux-rtj14.orig/arch/i386/lib/bitops.c 2006-09-28 15:24:08.000000000 -0700 +++ linux-rtj14/arch/i386/lib/bitops.c 2006-09-28 15:35:29.000000000 -0700 @@ -75,6 +75,7 @@ */ #ifdef CONFIG_SMP asm( +".section .sched.text\n" ".align 4\n" ".globl __write_lock_failed\n" "__write_lock_failed:\n\t" @@ -88,6 +89,7 @@ ); asm( +".section .sched.text\n" ".align 4\n" ".globl __read_lock_failed\n" "__read_lock_failed:\n\t"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |