Re: gcc in testing (2.95.4) can't a build working kernel
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 to: