FYI:
With 2.5.73 (i386) have picked up an 'Uninitialised timer!'
message with associated 'Call Trace:'. Only see this on
systems complied as UP.
--
Pete Clements
[email protected]
Quoting Andrew Morton
>
> Well it beats me. That timer is clearly initialised OK.
>
> What compiler version are you using? Can you try
> a different one>?
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
Only compiler currently installed. Have four systems (3 single
processor, 1 dual) all running Debian--woody with same versions.
On the UP systems, will see several of these traces during boot.
After that, it is very seldom (0 to 3 in 12 hours). Have seen none
on the SMP system. Recompiled one of the UP systems with SMP
enabled and no longer saw the trace during boot and post. Have
not seen this prior to 2.5.73.
>
>
> Pete Clements <[email protected]> wrote:
> >
> > Quoting Andrew Morton
> > > >
> > > > FYI:
> > > >
> > > > With 2.5.73 (i386) have picked up an 'Uninitialised timer!'
> > > > message with associated 'Call Trace:'. Only see this on
> > > > systems complied as UP.
> > >
> > > So what is the call trace?
> > >
> > > make sure you have CONFIG_KALLSYMS=y
> > >
> >
> > They all start off with check_timer_failed, then various
> > subsystems. Here is one example:
> >
> >
> > Uninitialised timer!
> > This is just a warning. Your computer is OK
> > function=0xc8866e0c, data=0x0
> > Call Trace:
> > [check_timer_failed+64/76] check_timer_failed+0x40/0x4c
> > [_end+139703180/1070409088] fib6_run_gc+0x0/0xb4 [ipv6]
> > [_end+139846020/1070409088] ip6_fib_timer+0x0/0x1c [ipv6]
> > [mod_timer+39/144] mod_timer+0x27/0x90
> > [_end+139846020/1070409088] ip6_fib_timer+0x0/0x1c [ipv6]
> > [_end+139700888/1070409088] fib6_add+0x74/0xbc [ipv6]
> > [_end+139846020/1070409088] ip6_fib_timer+0x0/0x1c [ipv6]
> > [_end+139690360/1070409088] rt6_ins+0x28/0x38 [ipv6]
> > [_end+139845460/1070409088] ip6_routing_table+0x0/0x1c [ipv6]
> > [_end+139690546/1070409088] rt6_cow+0xaa/0xd0 [ipv6]
> > [_end+139690981/1070409088] ip6_route_input+0x18d/0x1cc [ipv6]
> > [_end+139671818/1070409088] gcc2_compiled.+0x15a/0x1cc [ipv6]
> > [netif_receive_skb+351/400] netif_receive_skb+0x15f/0x190
> > [_end+139846080/1070409088] fib6_gc_lock+0x0/0x18 [ipv6]
> > [process_backlog+106/256] process_backlog+0x6a/0x100
> > [net_rx_action+109/260] net_rx_action+0x6d/0x104
> > [do_softirq+90/172] do_softirq+0x5a/0xac
> > [do_IRQ+224/240] do_IRQ+0xe0/0xf0
> > [default_idle+0/44] default_idle+0x0/0x2c
> > [rest_init+0/28] _stext+0x0/0x1c
> > [common_interrupt+24/32] common_interrupt+0x18/0x20
> > [default_idle+0/44] default_idle+0x0/0x2c
> > [rest_init+0/28] _stext+0x0/0x1c
> > [default_idle+38/44] default_idle+0x26/0x2c
> > [cpu_idle+38/56] cpu_idle+0x26/0x38
> > [rest_init+25/28] _stext+0x19/0x1c
> > [start_kernel+298/304] start_kernel+0x12a/0x130
> >
--
Pete Clements
[email protected]
Pete Clements writes:
> Quoting Andrew Morton
> >
> > Well it beats me. That timer is clearly initialised OK.
> >
> > What compiler version are you using? Can you try
> > a different one>?
>
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> gcc version 2.95.4 20011002 (Debian prerelease)
>
> Only compiler currently installed. Have four systems (3 single
> processor, 1 dual) all running Debian--woody with same versions.
> On the UP systems, will see several of these traces during boot.
> After that, it is very seldom (0 to 3 in 12 hours). Have seen none
> on the SMP system. Recompiled one of the UP systems with SMP
> enabled and no longer saw the trace during boot and post. Have
> not seen this prior to 2.5.73.
Apply the patch below (which I posted to LKML yesterday btw).
2.5.73 incorrectly removed the workaround needed to prevent
gcc-2.95.x from miscompiling spinlocks on UP (they become
empty structs, and gcc-2.95.x has problems with those).
/Mikael
--- linux-2.5.73/include/linux/spinlock.h.~1~ 2003-06-23 13:07:39.000000000 +0200
+++ linux-2.5.73/include/linux/spinlock.h 2003-06-23 22:58:29.000000000 +0200
@@ -146,8 +146,13 @@
/*
* gcc versions before ~2.95 have a nasty bug with empty initializers.
*/
-typedef struct { } spinlock_t;
-#define SPIN_LOCK_UNLOCKED (spinlock_t) { }
+#if (__GNUC__ > 2)
+ typedef struct { } spinlock_t;
+ #define SPIN_LOCK_UNLOCKED (spinlock_t) { }
+#else
+ typedef struct { int gcc_is_buggy; } spinlock_t;
+ #define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
+#endif
/*
* If CONFIG_SMP is unset, declare the _raw_* definitions as nops
Mikael Pettersson <[email protected]> wrote:
>
> Apply the patch below (which I posted to LKML yesterday btw).
> 2.5.73 incorrectly removed the workaround needed to prevent
> gcc-2.95.x from miscompiling spinlocks on UP (they become
> empty structs, and gcc-2.95.x has problems with those).
Are you sure? I saw no problems with 2.95.3. Maybe it's
a 2.95.4 problem?
Quoting Mikael Pettersson
> Pete Clements writes:
> > Quoting Andrew Morton
> > >
> > > Well it beats me. That timer is clearly initialised OK.
> > >
> > > What compiler version are you using? Can you try
> > > a different one>?
> >
> > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> > gcc version 2.95.4 20011002 (Debian prerelease)
> >
> > Only compiler currently installed. Have four systems (3 single
> > processor, 1 dual) all running Debian--woody with same versions.
> > On the UP systems, will see several of these traces during boot.
> > After that, it is very seldom (0 to 3 in 12 hours). Have seen none
> > on the SMP system. Recompiled one of the UP systems with SMP
> > enabled and no longer saw the trace during boot and post. Have
> > not seen this prior to 2.5.73.
>
> Apply the patch below (which I posted to LKML yesterday btw).
> 2.5.73 incorrectly removed the workaround needed to prevent
> gcc-2.95.x from miscompiling spinlocks on UP (they become
> empty structs, and gcc-2.95.x has problems with those).
>
> /Mikael
>
Patch applied, cleared up the traces.
--
Pete Clements
[email protected]
Andrew Morton writes:
> Mikael Pettersson <[email protected]> wrote:
> >
> > Apply the patch below (which I posted to LKML yesterday btw).
> > 2.5.73 incorrectly removed the workaround needed to prevent
> > gcc-2.95.x from miscompiling spinlocks on UP (they become
> > empty structs, and gcc-2.95.x has problems with those).
>
> Are you sure? I saw no problems with 2.95.3. Maybe it's
> a 2.95.4 problem?
I know the problem exists in 2.95.3 since that's the one I
used for my initial 2.5.73 testing. Having seen the spinlock.h
patch, I strongly suspected things would break.
If I remember correctly, the empty struct miscompilation exists
in all old egcs and gcc-2.95 versions, but was fixed during 3.0
development, so 2.96 is apparently also Ok.
/Mikael
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hmmm, it appears that the patch didn't make it into -bk2. (or did I mix up the
times?) I also get the spinlock warning...
gcc version 2.95.4
Jeff.
- --
Keyboard not found!
Press F1 to enter Setup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE++ck2wFP0+seVj/4RAudmAKDez0rPcXSTIj2YIP77mjEP4wgrgACgtqTv
0IqyMwdcMVBY/HkoPS29vbk=
=Syb0
-----END PGP SIGNATURE-----