lkml.org 
[lkml]   [1998]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.052 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site