[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A few patches for 2.4.x for Alpha...

On Wed, Aug 01, 2001 at 05:59:05PM -0400, Christopher C. Chimelis wrote:
> I seem to be VERY unsuccessful in getting patches into the kernel anymore,
> so I figured I'd try sending them to you first due to your high success
> rate :-)
> Attached is a patch that does three things:
> * drivers/char/rtc.c:
>   Removes MIPS DECstation epoch support for non-MIPS machines and adds
>   standard PC (1900) epoch support in its place (which will act
>   as a pre-2000 VMS epoch support patch as well).  It also adds post-2000
>   VMS epoch support.
>   My testing so far has shown that, with this patch, I can NEVER seem to
>   guess the year incorrectly, regardless of where it was set.

I usually don't enjoy changes in the RTC since it's not easy to audit
them (I've no idea where are the specs for such rtc settings and it
is more a guess for a few different protocols rather than a well
designed algorithm sigh). However I checked they won't break my alpha
box and I don't have any mips so I've no problem with them personally (I
fit in the digital unix epoch).

> * arch/alpha/kernel/smp.c:
>   Removed smp_tune_scheduling() function and the cacheflush_time var
>   since they weren't being used.  I also ran into a few machine types 

The space they waste is irrelevant, so I'd prefer not to drop it, we may
use it in the future.

>   where this function being executed on an SMP machine during boot caused
>   an oops.  I didn't bother looking into it too much (since the entire

I guess the reason it broke is because maybe there wasn't any cpu with
hardid 0 in the machine, so I will apply this patch to my tree instead
of dropping the code:

--- 2.4.8pre5aa1/arch/alpha/kernel/smp.c.~1~	Wed Jul  4 04:03:45 2001
+++ 2.4.8pre5aa1/arch/alpha/kernel/smp.c	Tue Aug  7 14:29:25 2001
@@ -211,13 +211,14 @@
  * We are not told how much cache there is, so we have to guess.
 static void __init
-smp_tune_scheduling (void)
+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);
+	cpu = (struct percpu_struct*)((char*)hwrpb + hwrpb->processor_offset
+				      + cpuid * hwrpb->processor_size);
 	switch (cpu->type)
 	case EV45_CPU:
@@ -599,7 +600,7 @@
 	current->processor = boot_cpuid;
-	smp_tune_scheduling();
+	smp_tune_scheduling(boot_cpuid);

Does it sound sane? Could you check if this cure the problem on your
problematic machines?

> * arch/alpha/kernel/entry.S:
>   arch/alpha/kernel/proto.h:
>   arch/alpha/kernel/traps.c:
>   This patch is from Daniel Potts (a coworker) who found out that, if the
>   user invokes the crlfen PALcode call, the kernel is unable to cope with
>   not having access to the FP registers.  He wrote two asm stubs to
>   basically skip FP register access in these cases.  The problem was found
>   to be extremely rare, but definite is a way for a user (non-root) to
>   crash a running Alpha.
>   There's also a small patch from Rick Gorton (also a coworker) that
>   allows an illop trap to be handled correctly by the kernel.


> If you have any questions about the patches, feel free to ask :-)  I'm
> extremely concerned about the problems that Daniel found (with the ability
> of a common user to crash a running machine by just disabling FP
> registers), so the sooner this goes in, the better off we all will be :-)

Indeed. Thanks!


Reply to: