Skip to contentSkip to conversation

Laptops & CPU frequency

DISCUSSION [email protected] 15 participants 28 messages Jan 11, 2004 – Jan 19, 2004

lore
Share & tools
lore

[email protected]

author
#0 lore raw

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

#1 lore raw
Quoted 5 lines · 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

#2 lore raw
Quoted 3 lines · Robert Love

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...

#3 lore raw
In reply to Robert Love
Quoted 3 lines · Robert Love

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

#4 lore raw
In reply to Robert Love
Quoted 11 lines · Robert Love
Quoted 5 lines · 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

#5 lore raw
Quoted 7 lines · Xavier Bestel
Quoted 3 lines

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

#6 lore raw

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]

Quoted 6 lines · Xavier Bestel
Quoted 4 lines · Xavier Bestel
Quoted 3 lines

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.

Quoted 7 lines
Quoted 3 lines

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/
======================================================================

#7 lore raw
Quoted 4 lines · Jerry Cooperstein

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

#8 lore raw
In reply to Xavier Bestel
Quoted 11 lines · Xavier Bestel
Quoted 7 lines · Xavier Bestel
Quoted 3 lines

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

#9 lore raw
Quoted 2 lines · john stultz

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.)

Signature · 1 line
Disconnect <[email protected]>
#10 lore raw
Quoted 26 lines · Disconnect
Quoted 2 lines · john stultz

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.)

Quoted 3 lines

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

#11 lore raw
In reply to john stultz
Quoted 2 lines · john stultz

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

#12 lore raw
Quoted 5 lines · Xavier Bestel
Quoted 2 lines · john stultz

More info please. What type of hardware is this? Could you send me your dmesg for booting both with and without AC power?

Quoted 7 lines

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

#13 lore raw
Quoted 3 lines · john stultz

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.

Here are the dmesgs. I did the diff to simplify your life. Tell me if you need more.

Xav

dmesg_battery 2004-01-13 10:09:20.000000000 +0100 renamed from dmesg_acpower 2004-01-13 10:09:10.000000000 +0100 +2 -2
@@ -18,10 +18,10 @@
 Could not enable APIC!
 Initializing CPU#0
 PID hash table entries: 1024 (order 10: 8192 bytes)
-Detected 300.092 MHz processor.
+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... 589.82 BogoMIPS
+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)

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 300.092 MHz processor.
Console: colour VGA+ 80x25
Memory: 154816k/163808k available (1494k kernel code, 8416k reserved, 603k data, 224k init, 0k highmem) Calibrating delay loop... 589.82 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

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

#14 lore raw
In reply to Robert Love
Quoted 3 lines · Robert Love

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.

Signature · 1 line
Matthew Garrett | [email protected]
#15 lore raw
Quoted 8 lines · Matthew Garrett

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

#16 lore raw
Quoted 3 lines · Robert Love

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?

Signature · 1 line
Matthew Garrett | [email protected]
#17 lore raw
Quoted 1 line · Matthew Garrett

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

#18 lore raw
Quoted 7 lines · Robert Love
Quoted 1 line · Matthew Garrett

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.

Quoted 3 lines

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

#19 lore raw
Quoted 3 lines · Dave Jones

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

Signature · 1 line
Daniel Gryniewicz <[email protected]>
#20 lore raw
Quoted 3 lines · Daniel Gryniewicz

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

#21 lore raw
Quoted 6 lines · Robert Love

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.

Quoted 3 lines

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.

Signature · 1 line
Daniel Gryniewicz <[email protected]>
#22 lore raw
In reply to Robert Love

Hi!

Quoted 7 lines
Quoted 3 lines

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

Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
#23 lore raw
Quoted 3 lines · Pavel Machek

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. :)

Signature · 1 line
Daniel Gryniewicz <[email protected]>
#24 lore raw
In reply to Pavel Machek
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines

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.

#25 lore raw

Hi!

Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines

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.

Quoted 11 lines

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

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#26 lore raw
In reply to Dave Jones
Quoted 18 lines · Dave Jones
Quoted 7 lines · Robert Love
Quoted 1 line · Matthew Garrett

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.

Quoted 7 lines
Quoted 3 lines

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.

Signature · 4 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
#27 lore raw
In reply to Matthew Garrett

Hi!

Quoted 5 lines
Quoted 3 lines

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

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]