RE: Incorrect mdelay() results on Power Managed Machines x86

Woller, Thomas (twoller@crystal.cirrus.com)
Thu, 22 Mar 2001 17:26:05 -0600


> > I wonder if there is a way to modify mdelay to use a kernel timer if
> > interval > 10msec? I am not familiar with this section of the kernel,
> but I
> > do know that Microsoft's similar function KeStallExecutionProcessor is
> not
> > recommended for more than 50 *micro*seconds.
>
>>Basically the same kind of recommendation applies. But as with all
rules its
>>sometimes appropriate to break it

thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC
enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time
I booted and kept the machine on battery power the ENTIRE time, i had not
tried this before. the MHZ value Detected in time.c is 132Mhz (down from
500Mhz if not on battery power). but the interesting thing that i just
noticed is that the mdelay() wait time, is STILL about 25% of what it should
delay. i use 10000 (for a 10 second delay) and get only about 2-3 seconds
out of it. this smaller delay occurs with or without "notsc" on the boot
line. now, i did not expect this behaviour if i did not plug in to get more
CPU speed, with the calculated cpu rate when on battery power. i expected
that mdelay() would function properly with the appropriate wait time if i
booted and stayed on battery power, at the same reduced CPU frequency.
Alan, you might have answered this in your first post but i don't under the
INTEL speedstep logic to understand if this is expected behaviour. but the
bottom line is that my delay of 700 milleseconds in the driver fails if i
boot and stay on battery power exclusively. did anyone else expect this
behaviour?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/