kernel build problem.

kernel build problem.

[Alex deVries]

So, I'm building 2.1.121 that's in cvs using egcs-2.90.27 980315 and
binutils  2.8.1.  Both are from Rough Cuts.

Here's the error:

make[2]: Entering directory `/usr/src/linux/arch/mips/mm'
egcs -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -pipe
-c -o r6000.o r6000.c
{standard input}: Assembler messages:
{standard input}:384: Warning: Unmatched %hi reloc
{standard input}:487: Internal error!
Assertion failure in tc_gen_reloc at ./config/tc-mips.c line 10203.
Please report this bug.
make[2]: *** [r6000.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/mips/mm'

Any ideas on what I should do here?  Also, Ralf, are you going to upload
2.1.131 soon?

- Alex

-- 
Alex deVries, puffin on LinuxNet.
I know exactly what I want in life.

Re: kernel build problem.

[ralf]

On Tue, Dec 22, 1998 at 06:26:08PM -0500, Alex deVries wrote:

> So, I'm building 2.1.121 that's in cvs using egcs-2.90.27 980315 and
> binutils  2.8.1.  Both are from Rough Cuts.
> 
> Here's the error:
> 
> make[2]: Entering directory `/usr/src/linux/arch/mips/mm'
> egcs -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -pipe
> -c -o r6000.o r6000.c
> {standard input}: Assembler messages:
> {standard input}:384: Warning: Unmatched %hi reloc
> {standard input}:487: Internal error!
> Assertion failure in tc_gen_reloc at ./config/tc-mips.c line 10203.
> Please report this bug.
> make[2]: *** [r6000.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/arch/mips/mm'

Add -mno-split-addresses to CFLAGS.  Your egcs still enables that optimization
by default.

> Any ideas on what I should do here?  Also, Ralf, are you going to upload
> 2.1.131 soon?

Somewhen, when it's working and when I'm done with more urgent non-software
things of live ...

  Ralf

Re: kernel build problem.

[Alex deVries]

On Wed, 23 Dec 1998 ralf@uni-koblenz.de wrote:
> Add -mno-split-addresses to CFLAGS.  Your egcs still enables that optimization
> by default.

Alright.  That made it build.

Now when I build it and boot that kernel I get in the Command Monitor:

Exception: <vector=UTLB Miss>
Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
Exception PC: 0x881385cc, Exception RA: 0x88002614
exception, bad address: 0x47c4
Local I/O interrupt register 1: 0x80 <VR/GIO2>
  Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
  arg: 7 8bfff938 8bfffc4d 880025dc
  tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
  sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
  t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
  gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614

PANIC: Unexpected exception

I can mail my .config if that helps.

- Alex

Re: kernel build problem.

[ralf]

On Thu, Dec 24, 1998 at 10:31:16AM -0500, Alex deVries wrote:

> On Wed, 23 Dec 1998 ralf@uni-koblenz.de wrote:
> > Add -mno-split-addresses to CFLAGS.  Your egcs still enables that optimization
> > by default.
> 
> Alright.  That made it build.
> 
> Now when I build it and boot that kernel I get in the Command Monitor:
> 
> Exception: <vector=UTLB Miss>
> Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
> Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
> Exception PC: 0x881385cc, Exception RA: 0x88002614
> exception, bad address: 0x47c4
> Local I/O interrupt register 1: 0x80 <VR/GIO2>
>   Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
>   arg: 7 8bfff938 8bfffc4d 880025dc
>   tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
>   sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
>   t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
>   gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614
> 
> PANIC: Unexpected exception

>clickety faq<

[...]
  5.2.  Self compiled kernels crash when booting.

  When I build my own kernel and it crashes.  On an Indy the crash
  message looks like the following but the same problem hits other
  machines as well and there what happens may look completly different.


     Exception: <vector=UTLB Miss>
     Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
     Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
     Exception PC: 0x881385cc, Exception RA: 0x88002614
     exception, bad address: 0x47c4
     Local I/O interrupt register 1: 0x80 <VR/GIO2>
     Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
       arg: 7 8bfff938 8bfffc4d 880025dc
       tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
       sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
       t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
       gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614

     PANIC: Unexpected exception




  This problem is caused by a still unfixed bug in Binutils newer than
  version 2.7.  As a workaround, remove the -N flags from LDFLAGS in
  arch/mips/Makefile and relink the kernel.
[...]

  Ralf

Re: kernel build problem.

[Alex deVries]

On Fri, 25 Dec 1998 ralf@uni-koblenz.de wrote:
>   This problem is caused by a still unfixed bug in Binutils newer than
>   version 2.7.  As a workaround, remove the -N flags from LDFLAGS in
>   arch/mips/Makefile and relink the kernel.
> [...]

I should know that, seeing as how I've complained about it about 10,000
times. Sorry.

However, that last sentence should read:

As a workaround, change the following line in arch/mips/Makefile from:

LINKFLAGS       = -static -N

to:

LINKFLAGS       = -static

- Alex

Kernel Build Problem

[Andrew Linfoot]

Hi,

I'm trying to build the 2.2.1 kernel with sound support enabled and i get
the following warnings:

sound_firmware.c: In function `do_mod_firmware_load':
sound_firmware.c:23: warning: implicit declaration of function `lseek'
sound_firmware.c:38: warning: implicit declaration of function `read'

and then during the final link:

drivers/sound/sound.a(sound_firmware.o): In function `do_mod_firmware_load':
sound_firmware.c(.text+0x84): undefined reference to `lseek'
sound_firmware.c(.text+0x84): relocation truncated to fit: R_MIPS_26 lseek
sound_firmware.c(.text+0xc4): undefined reference to `lseek'
sound_firmware.c(.text+0xc4): relocation truncated to fit: R_MIPS_26 lseek
sound_firmware.c(.text+0xfc): undefined reference to `read'
sound_firmware.c(.text+0xfc): relocation truncated to fit: R_MIPS_26 read
make: *** [vmlinux] Error 1

I can compile OK with/without modules and sound disabled.

Is this fixed in the 2.2.9 kernel and if so will an archive of 2.2.9 be made
available on linus? (I don't have CVS access from my development box at the
moment).

Any help would be appreciated.

Thanks
Andy

Andrew Linfoot
Tel: +44 (0)114 265 0251
Mobile: +44 (0)7974 299 545

Re: Kernel build problem

[Vladimir G. Ivanovic]

To be fair, it's not really a Red Hat issue, but rather Linus's belief
that debuggers lead to patching symptoms rather than fixing the
underlying problem.

--- Vladimir

-- 
Vladimir G. Ivanovic                        http://leonora.org/~vladimir
Palo Alto, CA 94306                                      +1 650 678 8014

>>>>> "cd" == Charles Dunn <Dunn> writes:

    >> It is a pity that
    >> RedHat do not want kdb, it means that RH users have a lot of trouble
    >> trying to debug their systems.  OTOH SuSE are happy to include kdb in
    >> their distributions.
    cd> 
    cd> I agree 1000%! I went around and around with RH sales about this. No
    cd> complaints about the sales person, she really tried to get to the bottom
    cd> of why this is the way it is, and she even found the answer.. In talking
    cd> with her it was clear that in 99% of her conversations with RH engineers
    cd> the attitude was one of: "Debuggers produce bad fixes. Always. Debuggers
    cd> are evil.".. 
    cd> 
    cd> This is like blaming forks for a person being overweight. Any tool can
    cd> be used badly. No debugger is a substitute for understanding the code
    cd> and producing a good solution. But a debugger can illuminate specific
    cd> problem causes and shorten the debug cycle like few other tools can...
    cd> This whole debugger thing with RH has been frustrating beyond words. We
    cd> may even switch from RH to SuSe because of this, but mostly because RH
    cd> seems to enjoy making life hard for embedded products makers who want to
    cd> use RH. We are building VoIP test equipment and want to use RH as the OS
    cd> inside.. They are making us jump through hoops that Microsoft hasn't
    cd> even thought of yet. It's getting close to the point where it would be
    cd> cheaper per  box sold to have Windows inside than Linux.. Am I crazy or
    cd> is that just a tad upside down from where Linux is supposed to be
    cd> going???
    cd> 
    cd> -Charlie Dunn
    cd>  Empirix Inc.
    cd> 
    cd> 
    cd> 
    cd> ---------------------------
    cd> Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.

Re: Kernel build problem

[Erik Mouw]

On Wed, Sep 01, 2004 at 09:23:55AM -0700, Vladimir G. Ivanovic wrote:
> To be fair, it's not really a Red Hat issue, but rather Linus's belief
> that debuggers lead to patching symptoms rather than fixing the
> underlying problem.

FYI, here is the complete quote:

"The debugger is akin to giving the _rabbits_ a bazooka. The poor wolf
 doesn't get any sharper teeth.  Yeah, it sure helps against wolves. 
 They explode in pretty patterns of red drops flying _everywhere_. Cool.
 But it doesn't help against a rabbit gene pool that is slowly
 deteriorating because there is nothing to keep them from breeding, and no
 darwin to make sure that it's the fastest and strongest that breeds.
 You mentioned how NT has the nicest debugger out there. 
 Contemplate it."

        - Linus Torvalds

Feel free to start a discussion about this on linux-kernel, but be
forewarned that it usually ends in a flamewar.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: Kernel build problem

[Bryan Henderson]

>>I went around and around with RH sales about this. No
>>complaints about the sales person, she really tried to get to the bottom
>>of why this is the way it is, and she even found the answer.. In talking
>>with her it was clear that in 99% of her conversations with RH engineers
>>the attitude was one of: "Debuggers produce bad fixes. Always. Debuggers
>>are evil.".. 

>To be fair, it's not really a Red Hat issue, but rather Linus's belief
>that debuggers lead to patching symptoms rather than fixing the
>underlying problem.

It's a Red Hat issue.  Linus doesn't ship Red Hat products.  The 
information in this email says that Red Hat engineers share Linus's 
belief, and suggests that their own position is what keeps debuggers out 
of Red Hat products.

It's clear that Red Hat is capable of shipping a version of Linux other 
than Linus', and that makes it equally clear that Red Hat itself doesn't 
want a debugger in its version of Linux.

It would be fair to say that if Linus believed differently, a debugger 
would probably be in Red Hat Linux products, but it wouldn't be fair to 
say this is not a Red Hat issue.  Red Hat has a decision to make just like 
SUSE has.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems