Messages in this thread | | | Date | Thu, 14 May 1998 23:09:57 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.1.102 and APM -- is the patch correct? |
| |
On Thu, 14 May 1998, C. Scott Ananian wrote: > > patch-2.1.102 has this little gem embedded in it: > > --- v2.1.101/linux/arch/i386/kernel/time.c Fri Jan 30 11:28:06 1998 > +++ linux/arch/i386/kernel/time.c Wed May 13 13:23:13 1998 > @@ -525,10 +525,6 @@ > xtime.tv_usec = 0; > > /* If we have the CPU hardware time counters, use them */ > -#ifndef CONFIG_APM > - /* Don't use them if a suspend/resume could > - corrupt the timer value. This problem > - needs more debugging. */ > if (boot_cpu_data.x86_capability & 16) { > do_gettimeoffset = do_fast_gettimeoffset; > do_get_fast_time = do_x86_get_fast_time; > @@ -551,6 +547,5 @@ > "=d" (init_timer_cc.high)); > irq0.handler = pentium_timer_interrupt; > } > -#endif > setup_x86_irq(0, &irq0); > } > > > Is this correct? As far as I know, APM can slow or stop the processor > clock with impunity; thus those #ifdefs *really do* belong there, unless > some other means to conditionally disable do_fast_gettimeoffset is > available. I think that this portion of the patch should be reversed for > 2.1.103. Comments?
Well, the other gem embedded in time.c is something like
if (cyrix) x86_capability &= ~16;
which should take care of the problem wrt cyrix CPU's. I wanted to remove the APM workaround to see whether people will complain.
I can certainly put the APM workaround back, but I'd like to hear if somebody actually has problems with this change before I do so.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |