I'm getting the
make: *** [.tmp_vmlinux1] Error 139
problem with kernel 2.6.6. It works fine on one of my computer, but not
the other.
The full line is
ld -m elf_i386 -T arch/i386/kernel/vmlinux.lds.s
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o
--start-group usr/built-in.o arch/i386/kernel/built-in.o
arch/i386/mm/built-in.o arch/i386/mach-default/built-in.o
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a
lib/built-in.o arch/i386/lib/built-in.o drivers/built-in.o
sound/built-in.o arch/i386/pci/built-in.o arch/i386/power/built-in.o
net/built-in.o --end-group -o .tmp_vmlinux1
make: *** [.tmp_vmlinux1] Error 139
Both are using gcc 2.95.3. Both are using binutils version
2.14.90.0.8. Both have the same module-init-tools version. Etc., etc.,
etc.
The only difference is on the nonworking one, the processor type is
Pentium M instead of Pentium 4, and I'm using different video and
ethernet drivers because the two machines have different video and
ethernet cards :P. The nonworking one is a laptop, if that makes a
difference. I've got the enhanced SpeedStep option enabled for it.
I found a lot of stuff on Google about this problem, but a lot of it is
old and/or just tells you to upgrade to a 2.14 of binutils, which I
have. I get this error if I use gcc3 as well.
--Geoff Mishkin <[email protected]>
Geoff Mishkin wrote:
> I'm getting the
>
> make: *** [.tmp_vmlinux1] Error 139
>
> problem with kernel 2.6.6. It works fine on one of my computer, but not
> the other.
>
> The full line is
>
> ld -m elf_i386 -T arch/i386/kernel/vmlinux.lds.s
> arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o
> --start-group usr/built-in.o arch/i386/kernel/built-in.o
> arch/i386/mm/built-in.o arch/i386/mach-default/built-in.o
> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a
> lib/built-in.o arch/i386/lib/built-in.o drivers/built-in.o
> sound/built-in.o arch/i386/pci/built-in.o arch/i386/power/built-in.o
> net/built-in.o --end-group -o .tmp_vmlinux1
> make: *** [.tmp_vmlinux1] Error 139
>
Error 139 is a SEGV somewhere in a subprocess. Linker errors
like this might be an indicator for problems with your physical
memory.
My suggestion would be to enter your PC's BIOS setup at boot
time and verify the RAM access timing. Maybe it was set too
optimistic.
Good luck
Harri
I couldn't find exactly what I was looking for in the BIOS utility (IBM
ThinkPad T42), but I turned on Diagnostics mode and the RAM check, so at
boot it checked the RAM, which all turned out okay.
Still having the problem, though.
--Geoff Mishkin <[email protected]>
On Wed, 2004-06-16 at 02:13, Harald Dunkel wrote:
> Geoff Mishkin wrote:
> > I'm getting the
> >
> > make: *** [.tmp_vmlinux1] Error 139
> >
> > problem with kernel 2.6.6. It works fine on one of my computer, but not
> > the other.
> >
> > The full line is
> >
> > ld -m elf_i386 -T arch/i386/kernel/vmlinux.lds.s
> > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o
> > --start-group usr/built-in.o arch/i386/kernel/built-in.o
> > arch/i386/mm/built-in.o arch/i386/mach-default/built-in.o
> > kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> > security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a
> > lib/built-in.o arch/i386/lib/built-in.o drivers/built-in.o
> > sound/built-in.o arch/i386/pci/built-in.o arch/i386/power/built-in.o
> > net/built-in.o --end-group -o .tmp_vmlinux1
> > make: *** [.tmp_vmlinux1] Error 139
> >
>
> Error 139 is a SEGV somewhere in a subprocess. Linker errors
> like this might be an indicator for problems with your physical
> memory.
>
> My suggestion would be to enter your PC's BIOS setup at boot
> time and verify the RAM access timing. Maybe it was set too
> optimistic.
>
>
> Good luck
>
> Harri
I tried it again with linux-2.6.7-rc3, but got the same error.
My glibc version is 2.3.3.20040420. The kernel still compiles fine on
my other machine. I also compiled on the nonworking machine with the
same .config as the working one, and still got the same problem.
--Geoff Mishkin <[email protected]>
Geoff Mishkin wrote:
> I tried it again with linux-2.6.7-rc3, but got the same error.
>
> My glibc version is 2.3.3.20040420. The kernel still compiles fine on
> my other machine. I also compiled on the nonworking machine with the
> same .config as the working one, and still got the same problem.
>
Maybe you are simply running out of memory at link time. You
could use 'top -d 1' on another terminal to watch memory
consumption while the linker is running.
Regards
Harri
On Wednesday 16 June 2004 05:41 am, Geoff Mishkin wrote:
> I couldn't find exactly what I was looking for in the BIOS utility (IBM
> ThinkPad T42), but I turned on Diagnostics mode and the RAM check, so at
> boot it checked the RAM, which all turned out okay.
The bios does very wimpy checking of ram. If it is indeed a RAM problem, you
should use a tool like memtest86 in linux (you boot to it, its not a linux
tool per se) or prime95(is that the name?) in windows.
> Still having the problem, though.
>
> --Geoff Mishkin <[email protected]>
>
> 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/
The system has a gig of RAM and a gig of swap, so I don't think it's
running out of space. Also, ld segfaults immediately after being
invoked, not midway through the link.
As for the memory check, it's a brand new system, but I'll run the check
anyway later today when I get a chance.
Thanks for the tips so far.
--Geoff Mishkin <[email protected]>
Yes, it always happens right away, even between reboots. And just for
technicality, its ld that segfaults, not gcc. If it makes a difference.
--Geoff Mishkin <[email protected]>
On Wed, 2004-06-16 at 12:35, Denis Vlasenko wrote:
> On Wednesday 16 June 2004 15:01, Eric wrote:
> > On Wednesday 16 June 2004 05:41 am, Geoff Mishkin wrote:
> > > I couldn't find exactly what I was looking for in the BIOS utility (IBM
> > > ThinkPad T42), but I turned on Diagnostics mode and the RAM check, so at
> > > boot it checked the RAM, which all turned out okay.
> >
> > The bios does very wimpy checking of ram. If it is indeed a RAM problem,
> > you should use a tool like memtest86 in linux (you boot to it, its not a
> > linux tool per se) or prime95(is that the name?) in windows.
>
> In my case, it wasn't enough. Neuther memtest86 nor cpuburn
> was able to trigger problem, only gcc. (I did not try prime95).
> I tweaked memory timings until gcc stopped segv'ing.
>
> BTW, "bad memory" theory does not hold if fails _every time in the
> same place_.
> --
> vda
>
I've got some new information, this is the output of the ld command with
the -v option. The original invocation is in my original post in this
topic.