On Wed, 13 Feb 2002, Scott Venier wrote:

> That's a bit of a broad statement in the subject line, so let me clairify
> a bit.  gcc 2.95.4 on alpha has some pretty nasty bugs.  Because of those
> bugs, it can't build many parts of the linux kernel.  Some of the problems
> are in device drivers (the adaptec 2940 driver is one, DAC960 another),
> other problems are in more basic parts of the kernel
> (arch/alpha/kernel/smp.c, for example).  I've got a Digital Ultimate
> Workstation (a dual 21164 533MHz - rawhide class machine).  When I try to
> build a kernel for it using 2.95.4 the kernel (2.4.17) panics early in the
> boot process.  I was able to use a kernel built with one of redhat's 2.96
> varients w/o any problems.

I'm attaching a patch for the SMP problem.  I think gcc is generating bad
code, but the function that it's generating bad code for is
unnecessary.  Unfortunately, upstream kernel people never saw fit to
accept this patch.

> I took a look at the bugs listed in bugs.debian.org/gcc but didn't see 
> anything that looked like this one.

File one :-)

C
Index: arch/alpha/kernel/smp.c
===================================================================
RCS file: /home/cvs/linux-24/arch/alpha/kernel/smp.c,v
retrieving revision 1.1.1.4
retrieving revision 1.4
diff -u -r1.1.1.4 -r1.4
--- arch/alpha/kernel/smp.c     11 Oct 2001 15:41:35 -0000      1.1.1.4
+++ arch/alpha/kernel/smp.c     11 Oct 2001 15:51:36 -0000      1.4
@@ -80,7 +80,6 @@
 int smp_num_probed;            /* Internal processor count */
 int smp_num_cpus = 1;          /* Number that came online.  */
 int smp_threads_ready;         /* True once the per process idle is forked. */
-cycles_t cacheflush_time;
 
 int __cpu_number_map[NR_CPUS];
 int __cpu_logical_map[NR_CPUS];
@@ -212,63 +211,6 @@
 
 
 /*
- * Rough estimation for SMP scheduling, this is the number of cycles it
- * takes for a fully memory-limited process to flush the SMP-local cache.
- *
- * We are not told how much cache there is, so we have to guess.
- */
-static void __init
-smp_tune_scheduling (int cpuid)
-{
-       struct percpu_struct *cpu;
-       unsigned long on_chip_cache;
-       unsigned long freq;
-
-       cpu = (struct percpu_struct*)((char*)hwrpb + hwrpb->processor_offset
-                                     + cpuid * hwrpb->processor_size);
-       switch (cpu->type)
-       {
-       case EV45_CPU:
-               on_chip_cache = 16 + 16;
-               break;
-
-       case EV5_CPU:
-       case EV56_CPU:
-               on_chip_cache = 8 + 8 + 96;
-               break;
-
-       case PCA56_CPU:
-               on_chip_cache = 16 + 8;
-               break;
-
-       case EV6_CPU:
-       case EV67_CPU:
-               on_chip_cache = 64 + 64;
-               break;
-
-       default:
-               on_chip_cache = 8 + 8;
-               break;
-       }
-
-       freq = hwrpb->cycle_freq ? : est_cycle_freq;
-
-#if 0
-       /* Magic estimation stolen from x86 port.  */
-       cacheflush_time = freq / 1024L * on_chip_cache / 5000L;
-
-        printk("Using heuristic of %d cycles.\n",
-               cacheflush_time);
-#else
-       /* Magic value to force potential preemption of other CPUs.  */
-       cacheflush_time = INT_MAX;
-
-        printk("Using heuristic of %d cycles.\n",
-               cacheflush_time);
-#endif
-}
-
-/*
  * Send a message to a secondary's console.  "START" is one such
  * interesting message.  ;-)
  */
@@ -607,7 +549,6 @@
        current->processor = boot_cpuid;
 
        smp_store_cpu_info(boot_cpuid);
-       smp_tune_scheduling(boot_cpuid);
        smp_setup_percpu_timer(boot_cpuid);
 
        init_idle();

Reply via email to