2.5.73 -- Uninitialised timer! (i386)

2.5.73 -- Uninitialised timer! (i386)

[Pete Clements]

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 
clem@clem.clem-digital.net

Re: 2.5.73 -- Uninitialised timer! (i386)

[Jeff]

-----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-----

Re: 2.5.73 -- Uninitialised timer! (i386)

[Mikael Pettersson]

Andrew Morton writes:
 > Mikael Pettersson <mikpe@csd.uu.se> 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

Re: 2.5.73 -- Uninitialised timer! (i386)

[Pete Clements]

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 
clem@clem.clem-digital.net

Re: 2.5.73 -- Uninitialised timer! (i386)

[Andrew Morton]

Mikael Pettersson <mikpe@csd.uu.se> 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?

Re: 2.5.73 -- Uninitialised timer! (i386)

[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

--- 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

Re: 2.5.73 -- Uninitialised timer! (i386)

[Pete Clements]

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 <clem@clem.clem-digital.net> 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 
clem@clem.clem-digital.net