[parisc-linux] compiling kernels with gcc-3.1

[parisc-linux] compiling kernels with gcc-3.1

[Randolph Chung]

I seem to recall some reports that you cannot build a working kernel
with gcc-3.1....

Well, maybe they've changed things upstream, but I just tried with
gcc-3.1.1 (3.1.1 20020708 snapshot) and it seems to work well, at least
with my limited testing... this is with the debian default 64-bit smp
.config.

I did have to hack up a bunch of code... it seems like gcc-3.1.1 doesn't
like this construct:

typedef struct {
        volatile unsigned int __attribute__((aligned(16))) lock;
} spinlock_t;

typedef struct {
        spinlock_t lock;
        volatile unsigned int count;
} rwlock_t;

rwlock_t foo = (rwlock_t) { (spinlock_t) { 1 }, 0 };

it complains that the initializer is not constant in this case. 
removing the (rwlock_t) cast fixed that....

also it doesn't like it when you have a variable and you initialize it
after declaration with the { (spinlock_t) { 1 }, 0 } stuff...

(e.g. 
rwlock_t foo;

foo = { (spinlock_t) { 1 }, 0 };

gives a "parse error at {" message)

after working through these problems i got a working kernel...

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Hi Randolph,

I am on going to build mirroring on my test server.
But I will test it asap (as I already cvs update gcc-3.1.. ) and let you inform.

Thanks a lot for info,
Joel 

PS: Can you do a telnet or an ssh connection when this kernel is running? IIRC
as well as gcc-3.1 as gcc-3.2, I always reach well to build and boot kernels
(without kdb) but the system crashes as soon as you try to connect it via the
network.

Quoting Randolph Chung <randolph@tausq.org>:

> I seem to recall some reports that you cannot build a working kernel
> with gcc-3.1....
> 
> Well, maybe they've changed things upstream, but I just tried with
> gcc-3.1.1 (3.1.1 20020708 snapshot) and it seems to work well, at least
> with my limited testing... this is with the debian default 64-bit smp
> .config.
> 
> I did have to hack up a bunch of code... it seems like gcc-3.1.1
> doesn't
> like this construct:
> 
> typedef struct {
>         volatile unsigned int __attribute__((aligned(16))) lock;
> } spinlock_t;
> 
> typedef struct {
>         spinlock_t lock;
>         volatile unsigned int count;
> } rwlock_t;
> 
> rwlock_t foo = (rwlock_t) { (spinlock_t) { 1 }, 0 };
> 
> it complains that the initializer is not constant in this case. 
> removing the (rwlock_t) cast fixed that....
> 
> also it doesn't like it when you have a variable and you initialize it
> after declaration with the { (spinlock_t) { 1 }, 0 } stuff...
> 
> (e.g. 
> rwlock_t foo;
> 
> foo = { (spinlock_t) { 1 }, 0 };
> 
> gives a "parse error at {" message)
> 
> after working through these problems i got a working kernel...
> 
> randolph
> --  
> Randolph Chung
> Debian GNU/Linux Developer, hppa/ia64 ports
> http://www.tausq.org/
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.1

[Randolph Chung]

> PS: Can you do a telnet or an ssh connection when this kernel is running? IIRC
> as well as gcc-3.1 as gcc-3.2, I always reach well to build and boot kernels
> (without kdb) but the system crashes as soon as you try to connect it via the
> network.

yes, i can ssh into the box.

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting Randolph Chung <randolph@tausq.org>:

> > PS: Can you do a telnet or an ssh connection when this kernel is
> running? IIRC
> > as well as gcc-3.1 as gcc-3.2, I always reach well to build and boot
> kernels
> > (without kdb) but the system crashes as soon as you try to connect it
> via the
> > network.
> 
> yes, i can ssh into the box.
> 
Great news, I am impatient to also test it :)

Thanks a lot,
    Joel



-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Hi Randolph,

I am not so luky as you are:
The kernel compiles well and also boot well but always the same problem (in
addition to modules problems) as soon as I do an network connection with ssh the
system crash:
(I just note on the sti console)
sshd (pid 322): illegal instruction (code 8)
...
kernel panic...

Humm I try to boot from serial consol but there the behaviour is not quiet the same:
the system always panic but this time only a long list of:
Warning! stack pointer and cr30 do not correspond!
Dumping virtual address stack instead
Dumping satck from ... to ...:
....
(no stop or very very long?)

Well a last test (after I have to unplug replug power cable) at the serial
console : 
jso@palinux:~$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is ..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:...
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
jso@localhost's password: 

and the system also crashes (whithout any messages?).

So may I believe that the problems come first from ip stack itself and not from
ethernet driver?

Hmm I am also curious to test your .config file?

Joel

Quoting joel.soete@freebel.net:

> Quoting Randolph Chung <randolph@tausq.org>:
> 
> > > PS: Can you do a telnet or an ssh connection when this kernel is
> > running? IIRC
> > > as well as gcc-3.1 as gcc-3.2, I always reach well to build and
> boot
> > kernels
> > > (without kdb) but the system crashes as soon as you try to connect
> it
> > via the
> > > network.
> > 
> > yes, i can ssh into the box.
> > 
> Great news, I am impatient to also test it :)
> 
> Thanks a lot,
>     Joel
> 
> 
> 
> -------------------------------------------------
> This mail sent through Tiscali Webmail (http://webmail.tiscali.be)
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting joel.soete@freebel.net:

> Hi Randolph,
> 
> I am not so luky as you are:
> The kernel compiles well and also boot well but always the same problem
> (in
> addition to modules problems) as soon as I do an network connection with
> ssh the
> system crash:
> (I just note on the sti console)
> sshd (pid 322): illegal instruction (code 8)
> ...
> kernel panic...
> 
> Humm I try to boot from serial consol but there the behaviour is not
> quiet the same:
> the system always panic but this time only a long list of:
> Warning! stack pointer and cr30 do not correspond!
> Dumping virtual address stack instead
> Dumping satck from ... to ...:
> ....
> (no stop or very very long?)
> 
> Well a last test (after I have to unplug replug power cable) at the
> serial
> console : 
> jso@palinux:~$ ssh localhost
> The authenticity of host 'localhost (127.0.0.1)' can't be established.
> RSA key fingerprint is ..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:...
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'localhost' (RSA) to the list of known
> hosts.
> jso@localhost's password: 
> 
> and the system also crashes (whithout any messages?).
> 
> So may I believe that the problems come first from ip stack itself and
> not from
> ethernet driver?
> 
> Hmm I am also curious to test your .config file?
> 

How do you build gcc (3.1.1) natively or as crosscompiler (I do the last may be
it is the problem?)?

Joel


> 
> Quoting joel.soete@freebel.net:
> 
> > Quoting Randolph Chung <randolph@tausq.org>:
> > 
> > > > PS: Can you do a telnet or an ssh connection when this kernel is
> > > running? IIRC
> > > > as well as gcc-3.1 as gcc-3.2, I always reach well to build and
> > boot
> > > kernels
> > > > (without kdb) but the system crashes as soon as you try to
> connect
> > it
> > > via the
> > > > network.
> > > 
> > > yes, i can ssh into the box.
> > > 
> > Great news, I am impatient to also test it :)
> > 
> > Thanks a lot,
> >     Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.1

[Randolph Chung]

> > Hmm I am also curious to test your .config file?

i'm using the default config...

arch/parisc/debian-config/64-smp

> How do you build gcc (3.1.1) natively or as crosscompiler (I do the last may be
> it is the problem?)?

cross-compiler, hppa-linux->hppa64-linux

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting Randolph Chung <randolph@tausq.org>:

> > > Hmm I am also curious to test your .config file?
> 
> i'm using the default config...
> 
> arch/parisc/debian-config/64-smp

I will try (but I need to add md support now)

> 
> > How do you build gcc (3.1.1) natively or as crosscompiler (I do the
> last may be
> > it is the problem?)?
> 
> cross-compiler, hppa-linux->hppa64-linux
I just do hppa-linux->hppa-linux?

So I will first change my config file and let you inform.

Thanks for info,
    Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.1

[John David Anglin]

> (I just note on the sti console)
> sshd (pid 322): illegal instruction (code 8)
> ...
> kernel panic...

This is just a guess but I will wager that this problem is related
to the problems with expect, the cc1plus crash and the mmap issues noted
elsewhere with SMP kernels.  There seem to be circumstances where the
kernel crashes when a user application traps unexpectedly.

Joel, you should be able to run sshd under gdb and find what the
cause of the illegal instruction is.  It should not be a problem
to download and build 3.4p1 with gcc 3.2 from <http://www.openssh.org>.
Build at -O1 with debugging enabled.  There are examples on their
mail list on how to run sshd in debug mode.  If the situation is
similar to the cc1plus crash, gdb will prevent the system from
crashing when the fault occurs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > (I just note on the sti console)
> > sshd (pid 322): illegal instruction (code 8)
> > ...
> > kernel panic...
> 
> This is just a guess but I will wager that this problem is related
> to the problems with expect, the cc1plus crash and the mmap issues
> noted
> elsewhere with SMP kernels.  There seem to be circumstances where the
> kernel crashes when a user application traps unexpectedly.
> 
> Joel, you should be able to run sshd under gdb and find what the
> cause of the illegal instruction is.  It should not be a problem
> to download and build 3.4p1 with gcc 3.2 from <http://www.openssh.org>.
> Build at -O1 with debugging enabled.  There are examples on their
> mail list on how to run sshd in debug mode.  If the situation is
> similar to the cc1plus crash, gdb will prevent the system from
> crashing when the fault occurs.
> 
Ok Dave,

I will have a look.

Thanks a lot,
    Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.1

[Randolph Chung]

> This is just a guess but I will wager that this problem is related
> to the problems with expect, the cc1plus crash and the mmap issues noted
> elsewhere with SMP kernels.  There seem to be circumstances where the
> kernel crashes when a user application traps unexpectedly.

in at least some of the cases, i've seen one CPU is processing an
unaligned trap for a kernel space insn. i don't see how the particular
pieces of code that's causing the trap are unaligned tho (eg.
search_exception_table).

One thing about the unaligned handler is that it wlil fail silently
while handling "non-trivial" load/store insns. For example, it doesn't
handle the ma/mb or m/sm completors for displacement/indexed
load/stores.

It is possible that we haven't needed these in the past for kernel-space
with gcc-3.0, but gcc-3.[12] have different optimizations that
generate these instructions which we do not handle properly in unaligned
cases. Although I think this may just be masking an underlying problem.

I'm working on a more complete unaligned handler to see if that makes a
difference. Unfortunately I've found that sometimes when the kernel code
is modified in trivial ways (adding printk's, etc) the behaviors become
quite different. This definitely suggests some kind of cache flushing
problem as Grant described elsewhere.

randolph

Re: [parisc-linux] compiling kernels with gcc-3.1

[John David Anglin]

> in at least some of the cases, i've seen one CPU is processing an
> unaligned trap for a kernel space insn. i don't see how the particular
> pieces of code that's causing the trap are unaligned tho (eg.
> search_exception_table).
> 
> One thing about the unaligned handler is that it wlil fail silently
> while handling "non-trivial" load/store insns. For example, it doesn't
> handle the ma/mb or m/sm completors for displacement/indexed
> load/stores.

Is --disable-indexing used in kernel builds?  This should stop gcc
from generating the above.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> Is --disable-indexing used in kernel builds?  This should stop gcc
> from generating the above.
> 
AFAIK no (I will try tomorrow, I had to leave now :( )

Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] compiling kernels with gcc-3.2

[Randolph Chung]

well, after some advice from Dave about how to build gcc-3.2... i now
have a gcc-3.2 compiled kernel working as well:

tausq@a500:~$ uname -a
Linux version 2.4.18-pa54 (tausq@a500) (gcc version 3.2 20020711 (experimental)) #2 SMP Fri Jul 12 22:04:23 PDT 2002
tausq@a500:~$

I'm quite perplexed about why it doesn't seem to always work for
others... i didn't really have to do anything special with either gcc or
the kernel to get it to boot.

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] compiling kernels with gcc-3.2

[Joel Soete]

Hi Randolph,

Randolph Chung wrote:
> well, after some advice from Dave about how to build gcc-3.2... i now
> have a gcc-3.2 compiled kernel working as well:
> 

Great ;) I will try also

> tausq@a500:~$ uname -a
> Linux version 2.4.18-pa54 (tausq@a500) (gcc version 3.2 20020711 (experimental)) #2 SMP Fri Jul 12 22:04:23 PDT 2002
> tausq@a500:~$
> 
> I'm quite perplexed about why it doesn't seem to always work for
> others... i didn't really have to do anything special with either gcc or
> the kernel to get it to boot.

Well regarding release 3.2, I frequently encounter problems to compile 
gcc itself because of some broken part (it seems to me normal because it 
is the present development branch) for which I open PR which was solved 
in the mean time.
And when I reach to compile gcc and the kernel, this was a problem with 
network connection which make crash the system.
So now if I can obtain an working kernel (as you) I would be able to 
continu to test other interesting thing.

Thanks a lot for info,
     Joel

Re: [parisc-linux] compiling kernels with gcc-3.2

[Carlos O'Donell]

> 
> tausq@a500:~$ uname -a
> Linux version 2.4.18-pa54 (tausq@a500) (gcc version 3.2 20020711 (experimental)) #2 SMP Fri Jul 12 22:04:23 PDT 2002
> tausq@a500:~$
> 
> I'm quite perplexed about why it doesn't seem to always work for
> others... i didn't really have to do anything special with either gcc or
> the kernel to get it to boot.
> 
> randolph

I think the issue is one of quality assurance. We don't have a strict
set of criteria for testing/validating/certifying that a given snapshot
of a given toolchain, in a given configuration, will work.

I'm trying to address some of these things by building a cross-check
test-suite to test the toolchain weekly or nightly. This all came out
of a talk I had with Matt Taggart :) who is another toolchain-junkie.

When I get more work done I'll post.

c.

Re: [parisc-linux] compiling kernels with gcc-3.1

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

Hi Randolph,

Well I reach to compile gcc-3.1.1 without error (xc toolchain hppa -> 
hppa as gcc bootstrap).

Now I compile kernel 2.4.18-pa54 (last cvs I got Friday morning) for 
32-bits config first (not 64-bits yet) and may be that is why I do not 
met the problem mentioned below

> Well, maybe they've changed things upstream, but I just tried with
> gcc-3.1.1 (3.1.1 20020708 snapshot) and it seems to work well, at least
> with my limited testing... this is with the debian default 64-bit smp
> .config.
> 
> I did have to hack up a bunch of code... it seems like gcc-3.1.1 doesn't
> like this construct:
> 
> typedef struct {
>         volatile unsigned int __attribute__((aligned(16))) lock;
> } spinlock_t;
> 
> typedef struct {
>         spinlock_t lock;
>         volatile unsigned int count;
> } rwlock_t;
> 
> rwlock_t foo = (rwlock_t) { (spinlock_t) { 1 }, 0 };
> 
> it complains that the initializer is not constant in this case. 
> removing the (rwlock_t) cast fixed that....
> 
> also it doesn't like it when you have a variable and you initialize it
> after declaration with the { (spinlock_t) { 1 }, 0 } stuff...
> 
> (e.g. 
> rwlock_t foo;
> 
> foo = { (spinlock_t) { 1 }, 0 };
> 
> gives a "parse error at {" message)
> 
> after working through these problems i got a working kernel...
> 

OTC I met a strange problem with modules:

find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.18-pa54; fi
depmod: *** Unresolved symbols in 
/lib/modules/2.4.18-pa54/kernel/drivers/input/input.o
depmod:         mod_timer_R1f13d309
depmod:         unregister_chrdev_Rc192d491
depmod:         printk_Rdd132261
depmod:         jiffies_R0da02d67
depmod:         del_timer_Rfc62f16d
depmod:         register_chrdev_Rddc3984b
depmod:         sprintf_R1d26aa98
depmod:         try_inc_mod_count_R133c9d8f
depmod: *** Unresolved symbols in 
/lib/modules/2.4.18-pa54/kernel/drivers/input/keybdev.o
depmod:         kmalloc_R93d4cfe6
...

Any idea?

Thanks again for help and advises,
	Joel

PS: I join my compile log just in case you notice other details

[-- Attachment #2: k-2.4.18-pa54-gcc311.gz --]
[-- Type: application/gzip, Size: 55379 bytes --]

Re: [parisc-linux] compiling kernels with gcc-3.1

[John David Anglin]

> Is --disable-indexing used in kernel builds?  This should stop gcc
> from generating the above.

Oops, that should be "-mdisable-indexing".

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] compiling kernels with gcc-3.1

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 15:
> > Is --disable-indexing used in kernel builds?  This should stop gcc
> > from generating the above.
> 
> Oops, that should be "-mdisable-indexing".

right now we use:
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce
-mno-space-regs -mfast-indirect-calls -mdisable-fpregs
-ffunction-sections -march=2.0 -mschedule=8000

(the last two are only for pa8x00 builds...)

i'll try the disable-indexing stuff...

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] compiling kernels with gcc-3.1

[Matthew Wilcox]

On Mon, Jul 15, 2002 at 10:32:33AM -0700, Randolph Chung wrote:
> In reference to a message from John David Anglin, dated Jul 15:
> > > Is --disable-indexing used in kernel builds?  This should stop gcc
> > > from generating the above.
> > 
> > Oops, that should be "-mdisable-indexing".
> 
> right now we use:
> -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce
> -mno-space-regs -mfast-indirect-calls -mdisable-fpregs
> -ffunction-sections -march=2.0 -mschedule=8000
> 
> (the last two are only for pa8x00 builds...)
> 
> i'll try the disable-indexing stuff...

while we're on the subject of gcc flags ...

right now, we have an interesting patch in the kernel to get around a
fun feature of the PA ABI that no other ABI seems to have:

-asmlinkage ssize_t sys_pread(unsigned int fd, char * buf,
-                            size_t count, loff_t pos)
+static inline
+ssize_t do_pread(unsigned int fd, char * buf, size_t count, loff_t pos)
[...]
+#if BITS_PER_LONG == 32
+#ifdef __BIG_ENDIAN
+#define LOFF_T(high, low) unsigned int high, unsigned int low
+#else
+#define LOFF_T(high, low) unsigned int low, unsigned int high
+#endif
+
+asmlinkage
+ssize_t sys_pread(unsigned int fd, char *buf, size_t count, LOFF_T(high, low))
+{
+       return do_pread(fd, buf, count, (loff_t)high << 32 | low);
+}
+
+ssize_t sys_pwrite(unsigned int fd, char *buf, size_t count, LOFF_T(high, low))
+{
+       return do_pwrite(fd, buf, count, (loff_t)high << 32 | low);
+}

the problem is that the PA ABI specifies that quantities shall be
`naturally' aligned, even 64-bit quantities on 32-bit machines.  so the
kernel is expecting to see:

	fd (32 bits)
	buf (32 bits)
	count (32 bits)
	(empty)
	pos (64 bits)

what it _actually_ gets (because glibc is hideously broken, IMO):

	fd
	buf
	count
	(pos >> 32)
	pos & 0xffffffff

is there any chance of having a flag (or maybe an __attribute__ that
we could #define asmlinkage to?) which would change the ABI to be more
compressed like all the other architectures?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] compiling kernels with gcc-3.1

[John David Anglin]

> the problem is that the PA ABI specifies that quantities shall be
> `naturally' aligned, even 64-bit quantities on 32-bit machines.  so the
> kernel is expecting to see:
> 
> 	fd (32 bits)
> 	buf (32 bits)
> 	count (32 bits)
> 	(empty)
> 	pos (64 bits)
> 
> what it _actually_ gets (because glibc is hideously broken, IMO):
> 
> 	fd
> 	buf
> 	count
> 	(pos >> 32)
> 	pos & 0xffffffff

It's probably a whole lot easier to fix glibc than change gcc.

> is there any chance of having a flag (or maybe an __attribute__ that
> we could #define asmlinkage to?) which would change the ABI to be more
> compressed like all the other architectures?

I think this is basically a bad idea as it will have a whole lot
of nasty side effects.  How will gdb know which ABI, varargs, etc?

You would need to use a compiler switch and modify
FUNCTION_ARG_PARTIAL_NREGS and FUNCTION_ARG appropriately.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > Is --disable-indexing used in kernel builds?  This should stop gcc
> > from generating the above.
> 
> Oops, that should be "-mdisable-indexing".

Sorry Dave,

it do not help (system still crashing)

Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)