Previously today I wrote:
> 2.5.59 with CONFIG_PACKET=m oopes when af_packet.ko is insmodded:
>
> Unable to handle kernel paging request at virtual address 2220c021
> printing eip:
> c0124011
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0060:[<c0124011>] Not tainted
> EFLAGS: 00010097
> EIP is at __find_symbol+0x3d/0x7c
> eax: c020f70e ebx: 00000536 ecx: 00000000 edx: c028b600
> esi: 2220c021 edi: e8889558 ebp: e8889558 esp: e67c5ecc
> ds: 007b es: 007b ss: 0068
> Process insmod (pid: 482, threadinfo=e67c4000 task=e6c80ce0)
> Stack: e8888f34 e8889a40 00000038 e8883f50 c0124960 e8889558 e67c5ef4 00000001
> e8888f34 e8889374 e67c5f28 c0124b2a e8883f50 00000016 e8889374 e8889558
> e8889a40 e8883f50 0000000c 00000017 e8889a40 00000000 0000007c c01253a4
> Call Trace:
> [<c0124960>] resolve_symbol+0x20/0x4c
> [<c0124b2a>] simplify_symbols+0x82/0xe4
> [<c01253a4>] load_module+0x5c4/0x7ec
> [<c012562b>] sys_init_module+0x5f/0x194
> [<c0108887>] syscall_call+0x7/0xb
This oops occurs for every module, not just af_packet.ko, at
resolve_symbol()'s first call to __find_symbol().
What happens is that __find_symbol() oopses because the kernel's
symbol table is in la-la land. (Note the bogus kernel adress
2220c021 it tried to dereference above.)
Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
problem and modules now load correctly for me.
I don't know if this is a problem also for non-i386 archs.
/Mikael
I believe I'm experiencing the same problem that Mikael Pettersson
reported, although the symptom is normally a hang with SMP, because
the bad pointer dereference in __find_symbol results in the fault
hanndler calling search_exception_tables, which calls search_module_extable,
which tries to grab the modlist_lock spinlock, but that lock was
already taken by resolve_symbol (which called __find_symbol in the first
place).
Somone else on irc reported a similar problem when I asked.
Thanks Mikael, for posting the kernel oops listing. You
probably just saved me about 45 minutes of switching over to a
non-SMP kernel to check for that oops.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
Mikael Pettersson wrote:
> Previously today I wrote:
> > 2.5.59 with CONFIG_PACKET=m oopes when af_packet.ko is insmodded:
> >
> > Unable to handle kernel paging request at virtual address 2220c021
> > printing eip:
> > c0124011
> > *pde = 00000000
> > Oops: 0000
> > CPU: 0
> > EIP: 0060:[<c0124011>] Not tainted
> > EFLAGS: 00010097
> > EIP is at __find_symbol+0x3d/0x7c
> > eax: c020f70e ebx: 00000536 ecx: 00000000 edx: c028b600
> > esi: 2220c021 edi: e8889558 ebp: e8889558 esp: e67c5ecc
> > ds: 007b es: 007b ss: 0068
> > Process insmod (pid: 482, threadinfo=e67c4000 task=e6c80ce0)
> > Stack: e8888f34 e8889a40 00000038 e8883f50 c0124960 e8889558 e67c5ef4 00000001
> > e8888f34 e8889374 e67c5f28 c0124b2a e8883f50 00000016 e8889374 e8889558
> > e8889a40 e8883f50 0000000c 00000017 e8889a40 00000000 0000007c c01253a4
> > Call Trace:
> > [<c0124960>] resolve_symbol+0x20/0x4c
> > [<c0124b2a>] simplify_symbols+0x82/0xe4
> > [<c01253a4>] load_module+0x5c4/0x7ec
> > [<c012562b>] sys_init_module+0x5f/0x194
> > [<c0108887>] syscall_call+0x7/0xb
>
> This oops occurs for every module, not just af_packet.ko, at
> resolve_symbol()'s first call to __find_symbol().
>
> What happens is that __find_symbol() oopses because the kernel's
> symbol table is in la-la land. (Note the bogus kernel adress
> 2220c021 it tried to dereference above.)
>
> Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> problem and modules now load correctly for me.
>
> I don't know if this is a problem also for non-i386 archs.
>
> /Mikael
What version of ld are you using?
--
Brian Gerst
Brian Gerst writes:
> Mikael Pettersson wrote:
> > Previously today I wrote:
> > > 2.5.59 with CONFIG_PACKET=m oopes when af_packet.ko is insmodded:
> > >
> > > Unable to handle kernel paging request at virtual address 2220c021
> > > printing eip:
> > > c0124011
> > > *pde = 00000000
> > > Oops: 0000
> > > CPU: 0
> > > EIP: 0060:[<c0124011>] Not tainted
> > > EFLAGS: 00010097
> > > EIP is at __find_symbol+0x3d/0x7c
> > > eax: c020f70e ebx: 00000536 ecx: 00000000 edx: c028b600
> > > esi: 2220c021 edi: e8889558 ebp: e8889558 esp: e67c5ecc
> > > ds: 007b es: 007b ss: 0068
> > > Process insmod (pid: 482, threadinfo=e67c4000 task=e6c80ce0)
> > > Stack: e8888f34 e8889a40 00000038 e8883f50 c0124960 e8889558 e67c5ef4 00000001
> > > e8888f34 e8889374 e67c5f28 c0124b2a e8883f50 00000016 e8889374 e8889558
> > > e8889a40 e8883f50 0000000c 00000017 e8889a40 00000000 0000007c c01253a4
> > > Call Trace:
> > > [<c0124960>] resolve_symbol+0x20/0x4c
> > > [<c0124b2a>] simplify_symbols+0x82/0xe4
> > > [<c01253a4>] load_module+0x5c4/0x7ec
> > > [<c012562b>] sys_init_module+0x5f/0x194
> > > [<c0108887>] syscall_call+0x7/0xb
> >
> > This oops occurs for every module, not just af_packet.ko, at
> > resolve_symbol()'s first call to __find_symbol().
> >
> > What happens is that __find_symbol() oopses because the kernel's
> > symbol table is in la-la land. (Note the bogus kernel adress
> > 2220c021 it tried to dereference above.)
> >
> > Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> > problem and modules now load correctly for me.
> >
> > I don't know if this is a problem also for non-i386 archs.
> >
> > /Mikael
>
> What version of ld are you using?
2.13.90.0.2, as included in RH8.0.
/Mikael
On Fri, Jan 17, 2003 at 01:55:21PM +0100, Mikael Pettersson wrote:
> This oops occurs for every module, not just af_packet.ko, at
> resolve_symbol()'s first call to __find_symbol().
>
> What happens is that __find_symbol() oopses because the kernel's
> symbol table is in la-la land. (Note the bogus kernel adress
> 2220c021 it tried to dereference above.)
>
> Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> problem and modules now load correctly for me.
>
> I don't know if this is a problem also for non-i386 archs.
Well:
__start___ksymtab = .; \
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
*(__ksymtab) \
} \
__stop___ksymtab = .; \
breaks on some ARM binutils (from a couple of years ago.) The most
reliable way we've found in with ARM binutils is to place the symbols
inside the section - this appears to work 100% every single time and
I've never had any reports of failure (whereas I did with the symbols
outside as above.)
On the topic of these changes, I'd prefer it if people didn't silently
run around making random stuff generic when there are subtle differences
between each architecture version without:
1. querying why things are different.
2. waiting a reasonable time for replies to why things are different.
3. copying such changes to the architecture maintainers for review
in case steps 1 and 2 failed.
Unfortunately, it seems that the BK disease is growing and seems to
be killing the review process, as some people here predicted it
would. ;(
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
At 02:49 PM 1/17/2003 +0100, Mikael Pettersson wrote:
>Brian Gerst writes:
> > Mikael Pettersson wrote:
> > >
> > > This oops occurs for every module, not just af_packet.ko, at
> > > resolve_symbol()'s first call to __find_symbol().
> > >
> > > What happens is that __find_symbol() oopses because the kernel's
> > > symbol table is in la-la land. (Note the bogus kernel adress
> > > 2220c021 it tried to dereference above.)
> > >
> > > Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> > > problem and modules now load correctly for me.
> > >
> > > I don't know if this is a problem also for non-i386 archs.
> > >
> > > /Mikael
> >
> > What version of ld are you using?
>
>2.13.90.0.2, as included in RH8.0.
It oopses with latest binutils too.
(binutils-2.13.2... _upgraded_ from 2.13.90.0.10;)
On Fri, 17 Jan 2003, Mikael Pettersson wrote:
> What happens is that __find_symbol() oopses because the kernel's
> symbol table is in la-la land. (Note the bogus kernel adress
> 2220c021 it tried to dereference above.)
>
> Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> problem and modules now load correctly for me.
That's interesting. It doesn't happen for me, but I'm using older
binutils. The patch really only changes two things (except for ARM):
o whitespace
o It adds AT(ADDR(section) - 0)
Both of these should be NOPs, but apparently not. Could you try removing
the AT(...) from include/asm-generic/vmlinux.lds.h?
Also, what does
objdump -h vmlinux
and
grep __start_ System.map
say?
--Kai
Russell King <[email protected]> writes:
> On Fri, Jan 17, 2003 at 01:55:21PM +0100, Mikael Pettersson wrote:
> > This oops occurs for every module, not just af_packet.ko, at
> > resolve_symbol()'s first call to __find_symbol().
> >
> > What happens is that __find_symbol() oopses because the kernel's
> > symbol table is in la-la land. (Note the bogus kernel adress
> > 2220c021 it tried to dereference above.)
> >
> > Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> > problem and modules now load correctly for me.
> >
> > I don't know if this is a problem also for non-i386 archs.
>
> Well:
>
> __start___ksymtab = .; \
> __ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
> *(__ksymtab) \
> } \
> __stop___ksymtab = .; \
>
> breaks on some ARM binutils (from a couple of years ago.) The most
> reliable way we've found in with ARM binutils is to place the symbols
> inside the section - this appears to work 100% every single time and
> I've never had any reports of failure (whereas I did with the symbols
> outside as above.)
That has been roughly my experience on x86 as well with the exception
of bss sections. For bss sections placing the symbols inside the section
itself has been deadly.
Eric
On Fri, Jan 17, 2003 at 09:13:14AM -0700, Eric W. Biederman wrote:
> That has been roughly my experience on x86 as well with the exception
> of bss sections. For bss sections placing the symbols inside the section
> itself has been deadly.
Could you elaborate a bit more what you have seen?
TIA,
Sam
On 17 Jan 2003, Eric W. Biederman wrote:
> > Well:
> >
> > __start___ksymtab = .; \
> > __ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
> > *(__ksymtab) \
> > } \
> > __stop___ksymtab = .; \
> >
> > breaks on some ARM binutils (from a couple of years ago.) The most
> > reliable way we've found in with ARM binutils is to place the symbols
> > inside the section - this appears to work 100% every single time and
> > I've never had any reports of failure (whereas I did with the symbols
> > outside as above.)
>
> That has been roughly my experience on x86 as well with the exception
> of bss sections. For bss sections placing the symbols inside the section
> itself has been deadly.
Can both of you guys elaborate on what "break" means here, I'm trying to
better understand what's going on. One thing is rather obvious, and that's
what causing the current breakage with RH8 binutils:
If "." isn't properly aligned, __kstart___ksymtab will point to an address
which is before the actual start of the section, since that gets aligned
to its requirements. Was that the ARM problem?
Now, what's different for __bss, i.e. what goes wrong there?
Related issue: The linker will actually automatically emit
__{start,stop}_SECTION symbols when SECTION is a C symbol (i.e.
letters,numbers,_), so things should actually work without explicitly
defining those symbols. They do on i386 with my binutils, but I assume
there's some reason why we don't just rely on that?
--Kai
On Fri, Jan 17, 2003 at 01:56:38PM +0000, Russell King wrote:
> Well:
>
> __start___ksymtab = .; \
> __ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
> *(__ksymtab) \
> } \
> __stop___ksymtab = .; \
>
> breaks on some ARM binutils (from a couple of years ago.) The most
> reliable way we've found in with ARM binutils is to place the symbols
> inside the section - this appears to work 100% every single time and
> I've never had any reports of failure (whereas I did with the symbols
> outside as above.)
quote from 'info ld'
--------------
the address of the output section will be set to the current value of
the location counter aligned to the alignment requirements of the
output section. The alignment requirement of the output section is the
strictest alignment of any input section contained within the output
section.
--------------
In other words, the value of __start___ksymtab may differ placed inside
or outside {}, if . is not aligned according to the rules above.
Was it binutils that faulted, or may ARM has been hit by this?
Usually vmlinux.lds.S files has a lot of un-commented . = ALIGN(N);
spread all over, that may have saved us several times in the past.
Sam
On Fri, Jan 17, 2003 at 10:24:42AM -0600, Kai Germaschewski wrote:
> Can both of you guys elaborate on what "break" means here
You've already realised my problem I think - if you set the address
of a section explicitly, symbols around that section are set "not
as expected" unless they are inside the section itself.
> Related issue: The linker will actually automatically emit
> __{start,stop}_SECTION symbols when SECTION is a C symbol (i.e.
> letters,numbers,_), so things should actually work without explicitly
> defining those symbols. They do on i386 with my binutils, but I assume
> there's some reason why we don't just rely on that?
It doesn't seem to be guaranteed. For instance:
c03dddc8 ? __ksymtab_linkwatch_fire_event
c03dddd0 ? __ksymtab_profile_event_register
c03dddd0 A __start___gpl_ksymtab
c03dddd0 A __stop___ksymtab
c03dddd8 ? __ksymtab_profile_event_unregister
c03ddde0 ? __ksymtab_dequeue_signal
...
c03ddec8 ? __ksymtab_xfrm_ealg_get_byname
c03dded0 ? __kstrtab_sa1100fb_backlight_power
c03dded0 A __stop___gpl_ksymtab
c03ddeec ? __kstrtab_sa1100fb_lcd_power
c03ddf00 ? __kstrtab_sa1100_request_dma
...
c03e51e0 ? __kstrtab_register_gifconf
c03e51f4 ? __kstrtab_softnet_data
c03e5204 ? __kstrtab_linkwatch_fire_event
c03e6000 D init_thread_union
c03e8000 d runqueues
c03e8940 D tasklist_lock
Note that __start___ksymtab_strings and __stop___ksymtab_strings don't
exist, despite __ksymtab_strings being C symbol-like.
The only __start_ / __stop_ symbols which appear in System.map are those
which are explicitly defined:
rmk@raistlin:[linux-sa1100]:<1004> grep '__start_\|__stop_' System.map
c021d050 ? __start___param
c021d050 ? __stop___param
c03da0b0 ? __start___ex_table
c03daa48 ? __stop___ex_table
c03daa58 A __start___ksymtab
c03dddd0 A __start___gpl_ksymtab
c03dddd0 A __stop___ksymtab
c03dded0 A __stop___gpl_ksymtab
rmk@raistlin:[rmk]:<1005>
The only time that I've seen the linker automatically generate the __start_
and __stop_ symbols for a section is when the section isn't explicitly
placed by the linker file. When sections aren't explicitly placed, more
things go wrong (the linker places them at some random address way outside
the kernel image) so this isn't an unacceptable solution either.
(This is as seen with ARM ld versions 2.10.1, 2.11.2, 2.12.1)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 17 Jan 2003, Mikael Pettersson wrote:
> This oops occurs for every module, not just af_packet.ko, at
> resolve_symbol()'s first call to __find_symbol().
Okay, the details I received so far seem to indicate that the appended
patch will fix it, though I didn't get actual confirmation it does.
If you experience crashes when loading modules (and have RH 8 binutils),
please give it a shot.
--Kai
-----------------------------------------------------------------------------
[email protected], 2003-01-16 16:29:31-06:00, [email protected]
kbuild: Fix __start_SECTION, __stop_SECTION
In a discussion with Sam Ravnborg, the following problem became apparent:
Most vmlinux.lds.S (but the ARM ones) used the following construct:
__start___ksymtab = .;
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) {
*(__ksymtab)
}
__stop___ksymtab = .;
However, the link will align the beginning of the section __ksymtab
according to the requirements for the input sections. If '.' (current
location counter) wasn't sufficiently aligned before, it's possible
that __ksymtab actually starts at an address after the one
__start___ksymtab points to, which will confuse the users of
__start___ksymtab badly. The fix is to follow what the ARM Makefiles
did for this case, ie
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) {
__start___ksymtab = .;
*(__ksymtab)
__stop___ksymtab = .;
}
---------------------------------------------------------------------------
diff -Nru a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h Fri Jan 17 10:09:57 2003
+++ b/include/asm-generic/vmlinux.lds.h Fri Jan 17 10:09:57 2003
@@ -13,18 +13,18 @@
} \
\
/* Kernel symbol table: Normal symbols */ \
- __start___ksymtab = .; \
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
+ __start___ksymtab = .; \
*(__ksymtab) \
+ __stop___ksymtab = .; \
} \
- __stop___ksymtab = .; \
\
/* Kernel symbol table: GPL-only symbols */ \
- __start___gpl_ksymtab = .; \
__gpl_ksymtab : AT(ADDR(__gpl_ksymtab) - LOAD_OFFSET) { \
+ __start___gpl_ksymtab = .; \
*(__gpl_ksymtab) \
+ __stop___gpl_ksymtab = .; \
} \
- __stop___gpl_ksymtab = .; \
\
/* Kernel symbol table: strings */ \
__ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) { \
Sam Ravnborg <[email protected]> writes:
> On Fri, Jan 17, 2003 at 09:13:14AM -0700, Eric W. Biederman wrote:
> > That has been roughly my experience on x86 as well with the exception
> > of bss sections. For bss sections placing the symbols inside the section
> > itself has been deadly.
>
> Could you elaborate a bit more what you have seen?
Sorry. Placing symbols inside .bss sections (sections by any name
that are not allocated) has occasionally given them values not as
expected. While at the same time placing the symbols around the .bss
sections has worked reliably for me.
Eric
On Fri, Jan 17, 2003 at 06:11:01PM -0600, Kai Germaschewski wrote:
>On Fri, 17 Jan 2003, Mikael Pettersson wrote:
>
>> This oops occurs for every module, not just af_packet.ko, at
>> resolve_symbol()'s first call to __find_symbol().
>
>Okay, the details I received so far seem to indicate that the appended
>patch will fix it, though I didn't get actual confirmation it does.
>
>If you experience crashes when loading modules (and have RH 8 binutils),
>please give it a shot.
It isn't a scientific test since I also just added the 2.5.59-mm1
patches, but applying this patch seemed to fix my problems. I'm sending
this from a kernel running 2.5.59 + mm1 + your patch, built with RH 8.0
binutils.
cgf
A confirmation from the peanut gallery -
2.5.59 oopses during boot, 2.5.59 plus the
vmlinux.lds.S patch boots and runs fine -
Also Red Hat 8.0 -
Joe
Christopher Faylor wrote:
>On Fri, Jan 17, 2003 at 06:11:01PM -0600, Kai Germaschewski wrote:
>
>
>>On Fri, 17 Jan 2003, Mikael Pettersson wrote:
>>
>>
>>
>>>This oops occurs for every module, not just af_packet.ko, at
>>>resolve_symbol()'s first call to __find_symbol().
>>>
>>>
>>Okay, the details I received so far seem to indicate that the appended
>>patch will fix it, though I didn't get actual confirmation it does.
>>
>>If you experience crashes when loading modules (and have RH 8 binutils),
>>please give it a shot.
>>
>>
>
>It isn't a scientific test since I also just added the 2.5.59-mm1
>patches, but applying this patch seemed to fix my problems. I'm sending
>this from a kernel running 2.5.59 + mm1 + your patch, built with RH 8.0
>binutils.
>
>cgf
>-
>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/
>
>
>
At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:
>Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
>problem and modules now load correctly for me.
Hi,
Putting . = ALIGN(64) back in front of __start___ksymtab = .
(vmlinux.lds.h) fixed it here.
-Mike
At 06:11 PM 1/17/2003 -0600, Kai Germaschewski wrote:
>On Fri, 17 Jan 2003, Mikael Pettersson wrote:
>
> > This oops occurs for every module, not just af_packet.ko, at
> > resolve_symbol()'s first call to __find_symbol().
>
>Okay, the details I received so far seem to indicate that the appended
>patch will fix it, though I didn't get actual confirmation it does.
>
>If you experience crashes when loading modules (and have RH 8 binutils),
>please give it a shot.
Works fine with 2.13.90.0.10 (not RH) and 2.13.2, both of which failed
previously.
thanks,
-Mike
On Sat, Jan 18, 2003 at 09:00:51AM +0100, Mike Galbraith wrote:
> At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:
>
> >Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> >problem and modules now load correctly for me.
>
> Hi,
>
> Putting . = ALIGN(64) back in front of __start___ksymtab = .
> (vmlinux.lds.h) fixed it here.
But that is just a way to hide the real problem.
With . = ALIGN(64);
you make sure that the linker does not do any alignment of .
when entering the section.
It is much better to let the linker do proper alignment, and not
to rely on a magic number in the .lds file.
Now consider if we decide to put in a new symbol with alignment 128 for
some reason. A little gcc magic is used to sepecy the alignment of
the symbol, but the resulting kernel oopses. Why?
Because the ALIGN() preceeding the section was not adjusted properly.
Only sane way is to move the labels inside the block, or at least let
them depend on the address of the section. The lables should not
be assigned the value of ., when we know the linker may adjust it.
The solution that Russell used for ARM is IMO the best way to do it.
The only issue remaining here is what the linker will do for an empty
section, as Eric points out. I have not investigated that.
Sam
At 10:23 AM 1/18/2003 +0100, Sam Ravnborg wrote:
>On Sat, Jan 18, 2003 at 09:00:51AM +0100, Mike Galbraith wrote:
> > At 01:55 PM 1/17/2003 +0100, Mikael Pettersson wrote:
> >
> > >Reverting 2.5.59's patch to arch/i386/vmlinux.lds.S cured the
> > >problem and modules now load correctly for me.
> >
> > Hi,
> >
> > Putting . = ALIGN(64) back in front of __start___ksymtab = .
> > (vmlinux.lds.h) fixed it here.
>
>But that is just a way to hide the real problem.
Yup. I was only checking to see if that change was why it was
croaking. Kai's patch works a treat here.
-Mike
On Fri, 17 Jan 2003 18:11:01 -0600 (CST), Kai Germaschewski wrote:
>Okay, the details I received so far seem to indicate that the appended
>patch will fix it, though I didn't get actual confirmation it does.
>
>If you experience crashes when loading modules (and have RH 8 binutils),
>please give it a shot.
...
>diff -Nru a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>--- a/include/asm-generic/vmlinux.lds.h Fri Jan 17 10:09:57 2003
>+++ b/include/asm-generic/vmlinux.lds.h Fri Jan 17 10:09:57 2003
>@@ -13,18 +13,18 @@
> } \
> \
> /* Kernel symbol table: Normal symbols */ \
>- __start___ksymtab = .; \
> __ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
>+ __start___ksymtab = .; \
> *(__ksymtab) \
>+ __stop___ksymtab = .; \
> } \
>- __stop___ksymtab = .; \
> \
> /* Kernel symbol table: GPL-only symbols */ \
>- __start___gpl_ksymtab = .; \
> __gpl_ksymtab : AT(ADDR(__gpl_ksymtab) - LOAD_OFFSET) { \
>+ __start___gpl_ksymtab = .; \
> *(__gpl_ksymtab) \
>+ __stop___gpl_ksymtab = .; \
> } \
>- __stop___gpl_ksymtab = .; \
> \
> /* Kernel symbol table: strings */ \
> __ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) { \
>
This patch fixed the module-loading problem for me. Thanks.
Note that the problem wasn't specific to RH8.0 binutils:
I've also seen it with binutils-2.10.91 from RH7.1.
/Mikael