Hello All,
I am running the 2.4 kernel (latest from Fedora) on a Thinkpad 600E
laptop. If I start the laptop with the AC adapter turned on, the CPU
frequency in /proc/cpuinfo is approximatly 400 MHz. However, if I start
the laptop on battery power, /proc/cpuinfo indicates a processor frequency
of approximatly 100 MHz.
The frequency displayed in /proc/cpuinfo does not change if the AC
adapter is toggled on or off after the machine has booted. It stays
in the same mode as it was booted into. I am curious if this is because
the CPU frequency really is not changing, or if it is because the
number in /proc/cpuinfo is only calculated at boot.
Thanks,
Jim
On Sat, 2004-01-10 at 21:56, [email protected] wrote:
> The frequency displayed in /proc/cpuinfo does not change if the AC
> adapter is toggled on or off after the machine has booted. It stays
> in the same mode as it was booted into. I am curious if this is because
> the CPU frequency really is not changing, or if it is because the
> number in /proc/cpuinfo is only calculated at boot.
The MHz value in /proc/cpuinfo should be updated as the CPU speed
changes - that is, it is not calculated just at boot, but it is updated
as the speed actually changes.
You probably have some issue in your power management scripts - Fedora
should scale the CPU speed back as soon as you remove AC power, not just
at boot if not on AC.
Robert Love
On Sat, 10 Jan 2004 22:17:41 EST, Robert Love said:
> The MHz value in /proc/cpuinfo should be updated as the CPU speed
> changes - that is, it is not calculated just at boot, but it is updated
> as the speed actually changes.
Yes, it should. However, I remember chasing down a similar bug in the
SpeedStep code back around 2.5.73-75 timeframe (which managed to manifest as
the audio chipset latching onto the wrong clocking, no less - it wasn't till
later that I noticed that the frequency and bogomips numbers in /proc/cpuinfo
were bogus too). I admit never checking if either the original code or the
patch were backported to 2.4.
http://marc.theaimsgroup.com/?l=linux-kernel&m=105859009128595&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=105691055706753&w=2
(the final actual fix ended up being slightly different, but that was the bug).
Feel free to hit "delete" if this is irrelevant...
On Sat, Jan 10, 2004 at 10:17:41PM -0500, Robert Love wrote:
> You probably have some issue in your power management scripts - Fedora
> should scale the CPU speed back as soon as you remove AC power, not just
> at boot if not on AC.
I never understood why the speed depends on AC power (except to fake a long
autonomy). It would be smarter if it scaled the speed based on CPU usage.
It's what I did on my notebook (athlon 1.3G), and I'm happy to run it all
the day at 500 MHz and not to hear its stupid CPU fan dancing every minute,
and I too am happy to be able to compile a kernel in 3 minutes even on
battery, when it would take 10 min at 500 MHz and eat the battery much more,
since LCD and disk eat power during 7 more minutes.
Just my thought...
Cheers,
Willy
Le dim 11/01/2004 ? 11:27, Xavier Bestel a ?crit :
> > The MHz value in /proc/cpuinfo should be updated as the CPU speed
> > changes - that is, it is not calculated just at boot, but it is updated
> > as the speed actually changes.
>
> 2.6.0 doesn't do that on my laptop. Moreover, if I ever boot on battery,
> when switching to AC power, lots of things fail (mouse is jerky, pcmcia
> doesn't work ...)
I forgot one particularly annoying too: time is going twice too fast.
Xav
Le dim 11/01/2004 ? 04:17, Robert Love a ?crit :
> On Sat, 2004-01-10 at 21:56, [email protected] wrote:
>
> > The frequency displayed in /proc/cpuinfo does not change if the AC
> > adapter is toggled on or off after the machine has booted. It stays
> > in the same mode as it was booted into. I am curious if this is because
> > the CPU frequency really is not changing, or if it is because the
> > number in /proc/cpuinfo is only calculated at boot.
>
> The MHz value in /proc/cpuinfo should be updated as the CPU speed
> changes - that is, it is not calculated just at boot, but it is updated
> as the speed actually changes.
2.6.0 doesn't do that on my laptop. Moreover, if I ever boot on battery,
when switching to AC power, lots of things fail (mouse is jerky, pcmcia
doesn't work ...)
Xav
Robert Love wrote:
>The MHz value in /proc/cpuinfo should be updated as the CPU speed
>changes - that is, it is not calculated just at boot, but it is updated
>as the speed actually changes.
Is this true even when the speed changes aren't done through Speedstep?
Some older (PII/non-Speedstep PIIIs) Thinkpads automatically change
speed based on presence of AC power, but do it in a way that's exposed
as an ACPI throttling state rather than a performance state. My
experience is that this doesn't result in cpuinfo getting updated, and
various kernel things seem to become unhappy. On the other hand, I
haven't tried this since 2.5.5something - I just told the BIOS not to
touch stuff instead.
--
Matthew Garrett | [email protected]
On Sun, 2004-01-11 at 12:06, Matthew Garrett wrote:
> Is this true even when the speed changes aren't done through Speedstep?
> Some older (PII/non-Speedstep PIIIs) Thinkpads automatically change
> speed based on presence of AC power, but do it in a way that's exposed
> as an ACPI throttling state rather than a performance state. My
> experience is that this doesn't result in cpuinfo getting updated, and
> various kernel things seem to become unhappy. On the other hand, I
> haven't tried this since 2.5.5something - I just told the BIOS not to
> touch stuff instead.
No - if the laptop changes speed on its own, using a system that Linux
does not understand, then Linux won't know about the change,
/proc/cpuinfo will not be updated, and stuff won't go too good.
Robert Love
Robert Love wrote:
>No - if the laptop changes speed on its own, using a system that Linux
>does not understand, then Linux won't know about the change,
>/proc/cpuinfo will not be updated, and stuff won't go too good.
Is there any realistic way of noticing this sort of change?
--
Matthew Garrett | [email protected]
On Sun, 2004-01-11 at 12:44, Matthew Garrett wrote:
> Is there any realistic way of noticing this sort of change?
Sure. That is how Speedstep works, right? We have an interface for
Speedstep, so the kernel knows about it. We do not have an interface
for the proprietary BIOS stuff, I assume, so the kernel is oblivious.
But if you had the docs, I suppose you could code a solution and tie it
into the cpufreq code, just as we have proper support for Speedstep,
Longrun, etc.
Robert Love
There were some patches to solve this back in the 2.5 series.
Try booting with the kernel command line option
clock=pit
[email protected]
On Sun, 2004-01-11 at 04:33, Xavier Bestel wrote:
> Le dim 11/01/2004 ? 11:27, Xavier Bestel a ?crit :
>
> > > The MHz value in /proc/cpuinfo should be updated as the CPU speed
> > > changes - that is, it is not calculated just at boot, but it is updated
> > > as the speed actually changes.
> >
> > 2.6.0 doesn't do that on my laptop. Moreover, if I ever boot on battery,
> > when switching to AC power, lots of things fail (mouse is jerky, pcmcia
> > doesn't work ...)
>
> I forgot one particularly annoying too: time is going twice too fast.
>
> Xav
======================================================================
Jerry Cooperstein, <[email protected]>
Axian, Inc., Software Consulting and Training
4800 SW Griffith Dr., Ste. 202, Beaverton, OR 97005 USA
http://www.axian.com/
======================================================================
On Sun, 2004-01-11 at 02:33, Xavier Bestel wrote:
> Le dim 11/01/2004 ? 11:27, Xavier Bestel a ?crit :
>
> > > The MHz value in /proc/cpuinfo should be updated as the CPU speed
> > > changes - that is, it is not calculated just at boot, but it is updated
> > > as the speed actually changes.
> >
> > 2.6.0 doesn't do that on my laptop. Moreover, if I ever boot on battery,
> > when switching to AC power, lots of things fail (mouse is jerky, pcmcia
> > doesn't work ...)
>
> I forgot one particularly annoying too: time is going twice too fast.
More info please. What type of hardware is this? Could you send me your
dmesg for booting both with and without AC power?
thanks
-john
On Mon, 2004-01-12 at 14:52, john stultz wrote:
> More info please. What type of hardware is this? Could you send me your
> dmesg for booting both with and without AC power?
I had a similar problem with 2.4 (with and without acpi, speedstep, etc)
on an Inspiron 8500. Unfortunately, Dell only gives "use speedstep"
(boot in powersave on battery, performance on ac) and "always in lowest
performance mode" options in the bios. (Dell, you listening? How about
"don't use speedstep, only use [powersave/performance] mode"? Or "Boot
in last-used mode"..)
When the machine is suspended (swsusp) while on AC, it must be resumed
on AC (and same if suspended on battery) or the kernel gets very
confused. Time doubles (or halves), etc. No amount of arguing with
speedstep (or acpi in general, if speedstep wasn't applied/used) will
get it sane. (FWIW XP gets this right - hibernate XP on battery, resume
on ac, hibernate, resume on battery, etc and it does fine.)
Perhaps linux would benefit from some form of "make sure the cpu is
doing what we think it is" knob? Something that could be triggered by
scripts (or even swsusp/apm directly) as early in a resume as possible,
before the miscalculation cascades into crashes. (This would be
completely independent from speedstep or acpi, since I suspect that the
same problems may occur independently of acpi on other machines with
similar braindamaged bios.)
Thoughts? I can do more rigorous testing and report back if needed. (I
spent 2 days playing with it a few months ago, then gave it up as
hopeless.)
--
Disconnect <[email protected]>
Le lun 12/01/2004 ? 20:52, john stultz a ?crit :
> More info please. What type of hardware is this? Could you send me your
> dmesg for booting both with and without AC power?
It's an Armada 1700, with a pII 300MHz (150MHz on battery). It doesn't
support cpufreq (I tried modprobing all drivers, none work), I must boot
with acpi=off if I want suspend-to-ram and suspend-to-disk to work (apm
works great on this machine). As said elsewhere in this thread, booting
with clock=pit solves my problem.
Yet I can investigate for you (send dmesg, test things) if you're still
interested.
Thanks,
Xav
Le lun 12/01/2004 ? 17:58, Jerry Cooperstein a ?crit :
> There were some patches to solve this back in the 2.5 series.
>
> Try booting with the kernel command line option
> clock=pit
Great ! That works well now. Thansk !
Xav
On Mon, 2004-01-12 at 13:28, Xavier Bestel wrote:
> Le lun 12/01/2004 ? 20:52, john stultz a ?crit :
>
> > More info please. What type of hardware is this? Could you send me your
> > dmesg for booting both with and without AC power?
>
> It's an Armada 1700, with a pII 300MHz (150MHz on battery). It doesn't
> support cpufreq (I tried modprobing all drivers, none work), I must boot
> with acpi=off if I want suspend-to-ram and suspend-to-disk to work (apm
> works great on this machine). As said elsewhere in this thread, booting
> with clock=pit solves my problem.
> Yet I can investigate for you (send dmesg, test things) if you're still
> interested.
Please do. I have code in the kernel that tries to detect when the
problem you see occurs, so we will drop back to the PIT automatically.
Somehow it seems we're not triggering that code in your case.
thanks
-john
On Mon, 2004-01-12 at 12:11, Disconnect wrote:
> On Mon, 2004-01-12 at 14:52, john stultz wrote:
> > More info please. What type of hardware is this? Could you send me your
> > dmesg for booting both with and without AC power?
>
> I had a similar problem with 2.4 (with and without acpi, speedstep, etc)
> on an Inspiron 8500. Unfortunately, Dell only gives "use speedstep"
> (boot in powersave on battery, performance on ac) and "always in lowest
> performance mode" options in the bios. (Dell, you listening? How about
> "don't use speedstep, only use [powersave/performance] mode"? Or "Boot
> in last-used mode"..)
>
> When the machine is suspended (swsusp) while on AC, it must be resumed
> on AC (and same if suspended on battery) or the kernel gets very
> confused. Time doubles (or halves), etc. No amount of arguing with
> speedstep (or acpi in general, if speedstep wasn't applied/used) will
> get it sane. (FWIW XP gets this right - hibernate XP on battery, resume
> on ac, hibernate, resume on battery, etc and it does fine.)
>
> Perhaps linux would benefit from some form of "make sure the cpu is
> doing what we think it is" knob? Something that could be triggered by
> scripts (or even swsusp/apm directly) as early in a resume as possible,
> before the miscalculation cascades into crashes. (This would be
> completely independent from speedstep or acpi, since I suspect that the
> same problems may occur independently of acpi on other machines with
> similar braindamaged bios.)
>
> Thoughts? I can do more rigorous testing and report back if needed. (I
> spent 2 days playing with it a few months ago, then gave it up as
> hopeless.)
I'm surprised that you've seen this on 2.4, as the TSC time code does
not try to compensate for lost ticks. Instead we only use the TSC value
to offset from xtime, reseting our offset each tick. So changes in cpu
frequency should only cause time inconsistencies, not time doubling.
Might something be going oddly in setting up the timer interrupt on
restore? I'd be interested in more details.
In 2.6 we do try to detect when cpufreq changes without notifying us.
However its a balancing act as the symptoms are the same as when you
have a broken PIT or lose too many interrupt. Hopefully HPET and the
ACPI PM timesource will provide more reliable time sources.
thanks
-john
Linux version 2.6.0-1-686 (herbert@gondolin) (gcc version 3.3.2 (Debian)) #2 Sun Jan 11 16:59:17 EST 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000009ff8000 (usable)
BIOS-e820: 0000000009ff8000 - 000000000a000000 (ACPI NVS)
0MB HIGHMEM available.
159MB LOWMEM available.
On node 0 totalpages: 40952
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 36856 pages, LIFO batch:8
HighMem zone: 0 pages, LIFO batch:1
DMI not present.
Building zonelist for node : 0
Kernel command line: root=/dev/hda5 acpi=off single
Local APIC disabled by BIOS -- reenabling.
Could not enable APIC!
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 153.050 MHz processor.
Console: colour VGA+ 80x25
Memory: 154816k/163808k available (1494k kernel code, 8416k reserved, 603k data, 224k init, 0k highmem)
Calibrating delay loop... 294.91 BogoMIPS
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (ungzip failed); looks like an initrd
Freeing initrd memory: 4224k freed
CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xf0484, last bus=0
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031002
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fe2d0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x4a42, dseg 0xf0000
PnPBIOS: 18 nodes reported by PnP BIOS; 18 recorded by driver
ACPI: ACPI tables contain no PCI IRQ routing entries
PCI: Invalid ACPI-PCI IRQ routing table
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0
Machine check exception polling timer started.
VFS: Disk quotas dquot_6.5.1
devfs: v1.22 (20021013) Richard Gooch ([email protected])
devfs: boot_options: 0x0
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
pty: 256 Unix98 ptys configured
Serial: 8250/16550 driver $Revision: 1.90 $ 54 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 8
NET: Registered protocol family 20
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 4224 blocks [1 disk] into ram disk... |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\done.
VFS: Mounted root (cramfs filesystem).
Freeing unused kernel memory: 224k freed
NET: Registered protocol family 1
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Module ide_probe_mod cannot be unloaded due to unsafe usage in include/linux/module.h:483
hda: IBM-DADA-25400, ATA DISK drive
hdb: UJDA150, ATAPI CD/DVD-ROM drive
ide2: I/O resource 0x3EE-0x3EE not free.
ide2: ports already in use, skipping probe
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:DMA, hdb:DMA
Module piix cannot be unloaded due to unsafe usage in include/linux/module.h:483
hda: max request size: 128KiB
hda: 10553760 sectors (5403 MB) w/460KiB Cache, CHS=11168/15/63
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 > p4
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 264560k swap on /dev/hda6. Priority:-1 extents:1
EXT3 FS on hda5, internal journal
Real Time Clock Driver v1.12
NET: Registered protocol family 17
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
synaptics reset failed
synaptics reset failed
synaptics reset failed
Unable to query/initialize Synaptics hardware.
input: PS/2 Synaptics TouchPad on isa0060/serio1
mice: PS/2 mouse device common for all mice
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
evbug.c: Connected device: "AT Translated Set 2 keyboard", isa0060/serio0/input0
evbug.c: Connected device: "PS/2 Synaptics TouchPad", isa0060/serio1/input0
tsdev: module license 'unspecified' taints kernel.
ts: Compaq touchscreen protocol output
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ohci_hcd: 2003 Oct 13 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
PCI: Found IRQ 11 for device 0000:00:07.2
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: irq 11, io base 00001000
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
On Sun, Jan 11, 2004 at 12:54:51PM -0500, Robert Love wrote:
> On Sun, 2004-01-11 at 12:44, Matthew Garrett wrote:
>
> > Is there any realistic way of noticing this sort of change?
>
> Sure. That is how Speedstep works, right? We have an interface for
> Speedstep, so the kernel knows about it. We do not have an interface
> for the proprietary BIOS stuff, I assume, so the kernel is oblivious.
Speedstep support is one way right now. We tell the CPU "switch to this mode"
and it does. What we don't know how to do in cpufreq is detect when someone pulls
the power out, or plugs back in. BIOS SMM magick happens, and it all
gets taken care of transparently without us having a clue that anything
happened.
We *could* hook into the APM 'power source changed' notifiers, (and I
guess ACPI has something similar somewhere). That should take care of things.
> But if you had the docs, I suppose you could code a solution and tie it
> into the cpufreq code, just as we have proper support for Speedstep,
> Longrun, etc.
Of all the implementations I've played with (longhaul/powernow/speedstep-smi)
speedstep is the only one that does funky shit with SMM. The others are quite
dumb (and friendly) in comparison. (Ie, nothing happens on power source change)
Dave
On Tue, 2004-01-13 at 23:59, Dave Jones wrote:
> Of all the implementations I've played with (longhaul/powernow/speedstep-smi)
> speedstep is the only one that does funky shit with SMM. The others are quite
> dumb (and friendly) in comparison. (Ie, nothing happens on power source change)
I have an athlon-xp laptop (HP pavilion ze4500) with powernow that
definitely goes into low power mode when the plug is pulled. The screen
goes dark, and everything slows down. And, it appears to be some kind
of percentage of current speed, because if I'm in powersave mode (532000
Hz rather than 1795500), then it gets unbearably slow. However,
bogomips is not updated when I pull the plug. I've never run for any
length of time with boot-on-power-then-pull-the-plug, because I only do
that to go from one plug to another. If I'm running without the plug, I
generally booted that way. I use the k7-powernow module for my
powersaving.
[14:07:15 athena] dang> cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : mobile AMD Athlon(tm) XP2200+
stepping : 1
cpu MHz : 1788.828
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 1777.66
--
Daniel Gryniewicz <[email protected]>
On Wed, 2004-01-14 at 14:11, Daniel Gryniewicz wrote:
> I have an athlon-xp laptop (HP pavilion ze4500) with powernow that
> definitely goes into low power mode when the plug is pulled. The screen
> goes dark, and everything slows down.
Dave did not mean that the other power management schemes cannot do the
automatic reduction on loss of AC, just that there is no SMM/BIOS hacks
to do it automatically.
Your APM scripts are probably adjusting your CPU speed when you go on
AC. Fedora does this, for example.
That is cool - the OS (user-space, even) controls the policy.
What we don't like is how SpeedStep can be controlled from SMM.
Robert Love
On Wed, 2004-01-14 at 14:17, Robert Love wrote:
> Dave did not mean that the other power management schemes cannot do the
> automatic reduction on loss of AC, just that there is no SMM/BIOS hacks
> to do it automatically.
>
> Your APM scripts are probably adjusting your CPU speed when you go on
> AC. Fedora does this, for example.
No APM scripts, no APM even. I have ACPI, but no acpid, and I don't
currently do anything with ACPI other than get battery status and
temperature. It also happened before I built in any cpufreq support.
> That is cool - the OS (user-space, even) controls the policy.
>
> What we don't like is how SpeedStep can be controlled from SMM.
This happens even booted into DOS, so it's definitely a BIOS thing. I
haven't looked into turning it off, I can check next time I reboot.
--
Daniel Gryniewicz <[email protected]>
Hi!
> > I have an athlon-xp laptop (HP pavilion ze4500) with powernow that
> > definitely goes into low power mode when the plug is pulled. The screen
> > goes dark, and everything slows down.
>
> Dave did not mean that the other power management schemes cannot do the
> automatic reduction on loss of AC, just that there is no SMM/BIOS hacks
> to do it automatically.
People are designing machines where battery can't provide
enough ampers for cpu in high-power mode. If speedstep machines
have same problem, SMM is actually right thing to do.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Thu, 2004-01-15 at 15:42, Pavel Machek wrote:
> People are designing machines where battery can't provide
> enough ampers for cpu in high-power mode. If speedstep machines
> have same problem, SMM is actually right thing to do.
Okay, makes sense. I did wonder how they could run an Athlon XP off of
battery... Next time, maybe a Pentium-M. :)
--
Daniel Gryniewicz <[email protected]>
> > > I have an athlon-xp laptop (HP pavilion ze4500) with powernow that
> > > definitely goes into low power mode when the plug is pulled. The screen
> > > goes dark, and everything slows down.
> >
> > Dave did not mean that the other power management schemes cannot do the
> > automatic reduction on loss of AC, just that there is no SMM/BIOS hacks
> > to do it automatically.
>
> People are designing machines where battery can't provide
> enough ampers for cpu in high-power mode. If speedstep machines
> have same problem, SMM is actually right thing to do.
This reminds me of an idea I had years ago, but never really looked in
to very much, (it may well have been implemented somewhere
independently of my idea anyway). Basically, it was for a multi-cpu
machine which, instead of running cpus in parallel, with all the
common scaling problems, ran each CPU in series for a very short
timeslice, effectively being a uni-processor machine, but moving the
state of the processor's registers between physical CPUs. The theory
was that it would be possible to clock each CPU much higher for a
short period of time than it could be successfully clocked
continuously. Physical CPUs with poor cooling could even be given a
shorter timeslice.
John.
Hi!
> > > > I have an athlon-xp laptop (HP pavilion ze4500) with powernow that
> > > > definitely goes into low power mode when the plug is pulled. The screen
> > > > goes dark, and everything slows down.
> > >
> > > Dave did not mean that the other power management schemes cannot do the
> > > automatic reduction on loss of AC, just that there is no SMM/BIOS hacks
> > > to do it automatically.
> >
> > People are designing machines where battery can't provide
> > enough ampers for cpu in high-power mode. If speedstep machines
> > have same problem, SMM is actually right thing to do.
>
> This reminds me of an idea I had years ago, but never really looked in
> to very much, (it may well have been implemented somewhere
> independently of my idea anyway). Basically, it was for a multi-cpu
> machine which, instead of running cpus in parallel, with all the
> common scaling problems, ran each CPU in series for a very short
> timeslice, effectively being a uni-processor machine, but moving the
> state of the processor's registers between physical CPUs. The theory
> was that it would be possible to clock each CPU much higher for a
> short period of time than it could be successfully clocked
> continuously. Physical CPUs with poor cooling could even be given a
> shorter timeslice.
s390's actually do something like that. They have 16 (or so) physical
processors, but if you only have licence for running 1 cpu, you use
only one. OTOH if that cpu fails, it transfers state to next one and
continues.
Well, what you described could gain you some extra speed (relative to
uniprocessor), but it would be prohibitely expensive.
Wait.
We have it today.
Remember P4's? Those beasts have 90W but cooling designed only for 75W
or so, and thermal diode that slows when they get too hot.
If someone has SMP-P4 with such broken cooling solution (not sure how
common they are), ping-ponging task might actually get you extra
speed.
Same goes for any SMP machine whose CPU fans failed and is therefore
thermal-throttled. (But I'm not sure if thermal-throttling works at
all at SMPs.)
[I have one notebook here that has failed cpu fan... Thermal
throttling works more or less okay, but if you want your computation
to go fast, you need to place it next to fan...]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi!
> >No - if the laptop changes speed on its own, using a system that Linux
> >does not understand, then Linux won't know about the change,
> >/proc/cpuinfo will not be updated, and stuff won't go too good.
>
> Is there any realistic way of noticing this sort of change?
You can detect that tsc runs at wrong speed from timer interrupt.
pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Wed, Jan 14, 2004 at 04:59:45AM +0000, Dave Jones wrote:
> On Sun, Jan 11, 2004 at 12:54:51PM -0500, Robert Love wrote:
> > On Sun, 2004-01-11 at 12:44, Matthew Garrett wrote:
> >
> > > Is there any realistic way of noticing this sort of change?
> >
> > Sure. That is how Speedstep works, right? We have an interface for
> > Speedstep, so the kernel knows about it. We do not have an interface
> > for the proprietary BIOS stuff, I assume, so the kernel is oblivious.
>
> Speedstep support is one way right now. We tell the CPU "switch to this mode"
> and it does. What we don't know how to do in cpufreq is detect when someone pulls
> the power out, or plugs back in. BIOS SMM magick happens, and it all
> gets taken care of transparently without us having a clue that anything
> happened.
>
> We *could* hook into the APM 'power source changed' notifiers, (and I
> guess ACPI has something similar somewhere). That should take care of things.
>
> > But if you had the docs, I suppose you could code a solution and tie it
> > into the cpufreq code, just as we have proper support for Speedstep,
> > Longrun, etc.
>
> Of all the implementations I've played with (longhaul/powernow/speedstep-smi)
> speedstep is the only one that does funky shit with SMM. The others are quite
> dumb (and friendly) in comparison. (Ie, nothing happens on power source change)
I'm wondering if there is a need to get bios ownership like in
the speedstep-smi if not in acpi mode, in speedstep-ich?
Anyway speedstep-ich should be fine if you explicitely configure BIOS
in order to boot always in high performance mode.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.