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_store_cpu_info(boot_cpuid);
- smp_tune_scheduling();
+ smp_tune_scheduling(boot_cpuid);
smp_setup_percpu_timer(boot_cpuid);
init_idle();
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.
perfect.
> 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!
Andrea
Reply to: