Re: saving power in a Dell Poweredge 750.
On Thu, Jan 11, 2007 at 09:21:50AM -0800, George Hartzell wrote: Bruno Ducrot writes: [...] What specific driver(s) were loaded actually? A devinfo might help. It looks like: p4tcc0 cpufreq0 Here's a devinfo and a dmesg: http://shrimp.alerce.com/merlin/merlin.devinfo http://shrimp.alerce.com/merlin/merlin.dmesg I'm starting to understand that the box is probably running along as quietly as it knows how, unless there's some magic about fans and disks that I've missed. p4tcc0 reduce only frequency (actually it wont reduce the core frequency), but not core voltage. You actually wont save a lot of power with it. It's main usage is to reduce processor temperature if need be. The cpufreq0 actually is not a real driver. It's used to merge different drivers (for example p4tcc0 and est0 if your processor support SpeedStep) in order to provide an unified interface available via dev.cpu.0. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: saving power in a Dell Poweredge 750.
On Wed, Jan 10, 2007 at 10:49:40AM -0800, George Hartzell wrote: Peter Jeremy writes: On Wed, 2007-Jan-10 09:34:21 -0800, George Hartzell wrote: I hooked my kill-a-watt meter up and ran the machine for a couple of days and it uses 88 watts (3.90KWH/44.01H). What was it doing for those couple of days? [...] It's a small time mail server and web host. It was running under its real world load. I presume you confirmed that cpufreq/powerd was actually functioning (ie the CPU frequency was being changed). Yep, or at least I confirmed that powerd -v from a shell cycled up and down w/ demand, then I configured it to run as a daemon and confirmed that was cpufreq was loaded and that powerd was running in the background. That surprised me a bit, and seems to suggest that it's spending most of its energy spinning fans or something. PSU overheads, fans, northbridge, video, RAM, disk, ... it all adds up. That's sort of what I was figuring, it is/was just that my laptop experience with powerd and battery life suggested that there would be more of a difference. I can't specifically help with the Dell. What specific driver(s) were loaded actually? A devinfo might help. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temperature/fan monitoring on a Supermicro P8SCT
On Wed, Jan 10, 2007 at 06:46:10PM +1030, Daniel O'Connor wrote: On Wednesday 10 January 2007 14:08, Bruno Ducrot wrote: From the OP, I think the processor is an AMD 64 bits of some sort. From BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors, available at The P8SCT is an Intel S775 board so AMD specific things are unlikely to work :) Ermm, yes. Indeed this wont work. Sorry for the noise. I was basically wondering if anyone had patches or similar to mbmon/healthd I could use. Failing that I will try and generate some myself (when I get some time, ho ho ho). Well, from http://www.supermicro.com/support/faqs/faq.cfm?faq=3099 you pointed out, I think the sensor where fan, temp and so on is the W83792D and not the W83627HF. That's one is probably not yet supported by healthd nor mbmon, and a quick and the spec show that you can access it only via SMBus. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temperature/fan monitoring on a Supermicro P8SCT
Hi,
On Tue, Jan 09, 2007 at 12:39:45PM +1030, Daniel O'Connor wrote:
Has anyone had any success?
I've tried healthd (0.7.9) but it can't show temps, eg..
julx2:/usr/src/sys/amd64/confsudo healthd -1 -D
It seems we can get directly different temperatures from the CPU. At
least this works for some opteron CG core, and believe it should work
with other processors as well.
In the meantime, could you please try this:
# setpci -d1022:1103 e6.b | sed s,^,0x,g | \
awk 'BEGIN {i = 0} {print processor i++: $1 - 49 C}'
(you must have the sysutils/pciutils port, though, but I need a similar
command under Linux, that's why I'm doing something like that).
Cheers,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temperature/fan monitoring on a Supermicro P8SCT
On Tue, Jan 09, 2007 at 08:50:28AM -0800, Jeremy Chadwick wrote:
On Tue, Jan 09, 2007 at 02:50:47PM +0100, Bruno Ducrot wrote:
On Tue, Jan 09, 2007 at 12:39:45PM +1030, Daniel O'Connor wrote:
Has anyone had any success?
I've tried healthd (0.7.9) but it can't show temps, eg..
julx2:/usr/src/sys/amd64/confsudo healthd -1 -D
It seems we can get directly different temperatures from the CPU. At
least this works for some opteron CG core, and believe it should work
with other processors as well.
In the meantime, could you please try this:
# setpci -d1022:1103 e6.b | sed s,^,0x,g | \
awk 'BEGIN {i = 0} {print processor i++: $1 - 49 C}'
(you must have the sysutils/pciutils port, though, but I need a similar
command under Linux, that's why I'm doing something like that).
I don't understand how this interfaces with the Winbond 83627HF H/W
monitoring IC of the P8SCT. As far as I know, the 83627HF does not
sit on the PCI bus; you can only talk to it via SMBus (and that's
*only* if Supermicro added the SMBus tie-ins in their BIOS properly;
Supermicro has a history of being hit-or-miss when it comes to this,
most of the time being a miss), or via ancient x86 memory-mapped I/O
ports (which each motherboard vendor can set/implement at various
memory locations as they see fit; there is no standard).
Full engineering details of the 83627HF are here:
http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/627hf.pdf
Regarding your setpci request:
0x1022 is the vendor ID (AMD), 0x1103 is the device ID (what AMD
labels as Miscellaneous Control). How did you determine that
you should use configuration register E6? I can't find any
documentation about this PCI device.
Regardless, chances are what you're looking up on the PCI bus
is the on-die thermistor for CPU temperature. This doesn't
help when it comes to monitoring system (case/enclosure)
temperature.
From the OP, I think the processor is an AMD 64 bits of some sort. From
BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors,
available at
http://www.amd.com/fr-fr/Processors/TechnicalResources/0,,30_182_739_7203,00.html
you will find the corresponding documentation for this pci config
register. It happens that even though the bits used for thermal reading
is marked as reserved for older processors, this work for at least
an old opteron processor onto a HP DL385, where the situation is even worst
when one can't use the binary stuff that don't exist under FreeBSD, just
Linux or Windows. Of course, since we'll get the reading directly from
the processor, there is absolutely no need to get it from an external
chip like the winbond you mention. The drawback though is that we can't
get indeed the other sensors like fan, other thermal sensors and so on,
but it's the only solution I can give by now.
Cheers,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with the installer sysinstall.
On Tue, Nov 07, 2006 at 01:48:36PM -0500, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Ducrot wrote: cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Anyway the OP should enable eist and p4tcc (by loading cpufreq on boot) and both acpi_perf and acpi_throttle will be gone. Adding 'device cpufreq' results in dmesg looking like .. acpi0: TOSINV Capell00 on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST Strange. Does this happens only when you add cpufreq? Also, could you please add a link (www or ftp) to a file generated by acpidump -d -t the_model_of_this_computer.asl? acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_ec0: Embedded Controller: GPE 0x16 port 0x62,0x66 on acpi0 cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 Seems to be ok. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with the installer sysinstall.
On Fri, Nov 03, 2006 at 01:31:28AM +1100, Ian Smith wrote: On Thu, 2 Nov 2006, Michel Talon wrote: [..] I am joining the dmesg for reference. Just skimming through, tongue hanging out .. cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 .. just checking - is that a harmless or expected warning? Anyway the OP should enable eist and p4tcc (by loading cpufreq on boot) and both acpi_perf and acpi_throttle will be gone. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Tue, Oct 10, 2006 at 02:53:15PM -0400, Bill Moran wrote:
In response to Doug Ambrisko [EMAIL PROTECTED]:
John Baldwin writes:
| On Tuesday 10 October 2006 08:54, Bill Moran wrote:
| In response to Doug Ambrisko [EMAIL PROTECTED]:
| Bruno Ducrot writes:
| | On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote:
| | In response to Bruno Ducrot [EMAIL PROTECTED]:
| | Hi,
| |
| | On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote:
| |
| |A reboot causes the OS to halt, but the hardware just sits
there on the
| |shutdown screen.
| |
| |A shutdown -p does the same.
| |
| | What exactly are the last few lines?
| |
| | (manually copied)
| |
| | ...
| | All buffers synced.
| | Uptime: 1m16s
| |
| |
| | Thanks. Then this happen after print_uptime().
| |
| | I believe one of the drivers register a shutdown_final (or
| | shutdown_post_sync) event that hang your system. I think (though I
| | may be wrong) mfi may be that one.
| |
| | It would help if you can add some printf in dev/mfi/mfi.c into the
| | mfi_shutdown() function in order to check if that assumption
| | is correct.
|
| Some what related to this we have a local hack:
|
| --- sys/kern/subr_bus.c.orig Tue Jun 27 15:49:39 2006
| +++ sys/kern/subr_bus.c Tue Jun 27 15:49:51 2006
| @@ -2906,6 +2906,7 @@ bus_generic_shutdown(device_t dev)
| device_t child;
|
| TAILQ_FOREACH(child, dev-children, link) {
| + DELAY(1000);
| device_shutdown(child);
| }
|
| This patch seems to fix the problem. I'm going to replace it with
| some printfs and see if I can determine which driver is actually
| causing the problem (hopefully it's only one).
|
| Am I wrong in saying that the correct solution would be to identify the
| driver that needs more time and implementing some sort of polling
| mechanism to ensure the hardware is ready when the driver wants to
| shut down?
|
| Well, first let's see which driver it is. :) You might be able to just
| remove the DELAY and add a printf and see which device is printed last.
I think it was in a different ones. One of our configs has the base
HW + bge NIC the other has base HW + 2 x 2 port em NICs. The more
NIC's the better chance for a problem.
I've removed the hack from our kernel and I'm going to run the reboot
cycle. I don't think a printf will work since I recall trying that
it fixed the problem so I put the DELAY in :-( It could be generic
problem to the system with a sufficiently fast CPU to beat the
HW at shutting down. I'm not sure if his system is Dempsey or Woodcrest.
We use Woodcrest and they are really faster. Other machines might be
slow enough that it's not a a problem! We haven't seen it on our older
platforms with the same kernel and similar HW configs.
Well, I already did this. The only printf is the
device_printf(child, shutdown\n) that Bruno suggested. With this
single change, I'm unable to reproduce the problem.
Have any commits been made to 6-STABLE that might have inadvertently
fixed this in the last week or so?
The device_printf() function take too much time I think, so you get the same
behaviour as the DELAY().
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
Hi, On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. What exactly are the last few lines? Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Wed, Oct 04, 2006 at 02:07:12PM -0400, Bill Moran wrote: In response to Bruno Ducrot [EMAIL PROTECTED]: Hi, On Wed, Oct 04, 2006 at 12:28:35PM -0400, Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. What exactly are the last few lines? (manually copied) ... All buffers synced. Uptime: 1m16s Thanks. Then this happen after print_uptime(). I believe one of the drivers register a shutdown_final (or shutdown_post_sync) event that hang your system. I think (though I may be wrong) mfi may be that one. It would help if you can add some printf in dev/mfi/mfi.c into the mfi_shutdown() function in order to check if that assumption is correct. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi: bad write to port
On Mon, Aug 07, 2006 at 03:35:41PM +0200, Dimitry Andric wrote: Oliver Fromme wrote: acpi: bad write to port 0x080 (32), val ... ... Do I have to worry? So far it doesn't seem to cause any harm. It's probably just a buggy BIOS, see: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-June/002890.html IMO this io (0x80) should not be blacklisted. It's used as a debug port in that context. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi: bad write to port
On Mon, Aug 07, 2006 at 03:19:03PM +0100, Gavin Atkinson wrote: However the 0x80 port is a single byte wide - and his AML is trying to write 32 bits to it, so it's falling foul of the (correct) blocking of writes to port in the range 0x81 - 0x83. Oops, yes. You are indeed right. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd PCI and ACPI messages on 'INSYDE RSDT_000' laptop
On Mon, Jul 31, 2006 at 12:33:58AM +0200, Ed Schouten wrote: Hello, Last week I got a laptop from a few friends of mine with a broken screen. I removed the screen from the device and connected a regular CRT to it to install FreeBSD 6.1 on it for serving as a jukebox (silent, doesn't consume too much power). I first tried FreeSBIE 1.1, which just deadlocked during the bootsplash. After that I downloaded a FreeBSD 6.1 CD. When I boot FreeBSD 6.1 without the ACPI kernel module, it panics (fatal trap 12) right after probing uhci0. When I boot with ACPI, it boots like it should. Because the laptop doesn't have a serial connector, I didn't copy the kernel backtrace. If it is really needed, I'll boot the CD once again and type over the screen contents. Anyway, I installed FreeBSD 6.1 on it, with the ACPI module loaded, but I still get some really strange messages in my dmesg I thought would be useful to mention: | ... | cpu0: ACPI CPU on acpi0 | acpi_perf0: ACPI CPU Frequency Control on cpu0 | acpi_perf0: failed in PERF_STATUS attach | device_attach: acpi_perf0 attach returned 6 | ... | acpi_perf0: ACPI CPU Frequency Control on cpu0 | acpi_perf0: failed in PERF_STATUS attach | device_attach: acpi_perf0 attach returned 6 | ... This means you can't get configuration for speedstep on this processor via ACPI because something is broken into the bios. But since we have that: CPU: Intel(R) Pentium(R) M processor 1500MHz (1498.73-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 ^^^ speedstep should work if you put: cpufreq_load=YES into /boot/loader.conf and you don't need acpi_perf anyway. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Thu, Jul 27, 2006 at 02:25:19AM -0400, Mike Jakubik wrote: Jiawei Ye wrote: On 7/27/06, Mike Jakubik [EMAIL PROTECTED] wrote: I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. What about using SMBus? Is it available on your system? xmbmon reads temperatures off the SMBus IIRC. I tried that, unfortunately it does not work. All i want to know is if this a shortcoming of freebsd or the motherboard, if its the later, i will contact the manufacturer. Could you please try (if you have a working smb device) # smbmsg -p -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Thu, Jul 27, 2006 at 11:09:51AM -0400, Mike Jakubik wrote: Bruno Ducrot wrote: Could you please try (if you have a working smb device) # smbmsg -p Well, i don't think its being detected/supported. I tried loading all the smbus related kernel modules, but no device. Id Refs AddressSize Name 19 0xc040 2d1624 kernel 21 0xc06d2000 606acacpi.ko 33 0xc4dca000 2000 smbus.ko 41 0xc4dcc000 3000 iicsmb.ko 53 0xc4dcf000 3000 iicbus.ko 61 0xc4de4000 3000 smb.ko 71 0xc4df3000 3000 iic.ko 81 0xc4df6000 3000 if_ic.ko However, dmesg seems to show that there is a SMBus device on the MB. pci0: serial bus, SMBus at device 31.3 (no driver attached) It should be ichsmb with a ich7 southbridge IIRC, but there is a missing pci id onto sys/ichsmb/ichsmb_pci.c, (it should be 0x27da8086). Maybe the ich7 isn't supported yet. I don't have time to check more ATM. I'll look intel specs tomorrow. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Tue, Jul 25, 2006 at 11:51:25AM -0400, Mike Jakubik wrote: I need to be able to get the cpu and fan information from my motherboard, however none of the monitoring utilities in the ports seems to support my motherboard (Supermicro PDSMi, Intel E7230 (Mukilteo) Chipset). On my older VIA based motherboards and some Nvidia, i can get this information using ACPI and the hw.acpi.thermal sysctl. This however is not available on this motherboard. Would this be a shortcoming of the motherboards ACPI implementation, or a lack of support by freebsd? Does this one support IPMI? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq not working on AMD
Hi, On Wed, Jul 12, 2006 at 08:45:02PM +0200, Ivan Voras wrote: Loading cpufreq.ko results in these messages: powernow0: Cool`n'Quiet K8 on cpu0 device_attach: powernow0 attach returned 6 powernow0: Cool`n'Quiet K8 on cpu0 device_attach: powernow0 attach returned 6 I've googled for it - there are many similar problems but no solution. This is: CPU: AMD Athlon(tm) 64 Processor 3000+ (1795.32-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff0 Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF in i386 mode, and setting cpu frequency works in Windows. Is acpi loaded on that system? Could you please provide a dmesg after a boot -v? Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powernow0: no match for extended cpuid 780
On Thu, Apr 27, 2006 at 08:40:57PM +0200, Stefan 'Steve' Tell wrote: Hi, first of all a big thanks for your reply. * Bruno Ducrot [EMAIL PROTECTED] wrote: On Fri, Apr 21, 2006 at 04:11:00PM +, Stefan 'Steve' Tell wrote: powernow0: PowerNow! K7 on cpu0 powernow0: ACPI MAX frequency not found powernow0: no match for extended cpuid 780 Maybe by chance a BIOS upgrade will be ok. Sorry, no chance here. This is always the newest bios version available. :( If that's not the case, or BIOS is alredy the newest, we could resolve that issue by hardcoding sane values under the powernow driver, or by rewritting the DSDT of this laptop. The second solution will give you the oportunity to not have to patch powernow for each upgrades. This would be great. Do you need more information? What can I do? I think I will take the DSDT override approach. This is explained in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html So all you have to do is to dump the ACPI tables via: acpidump -t -d Acer_Aspire_1304LC.asl Give an URL where we can get this file, or if you can't, send it to me privately. I will correct that asl so that after an override of the DSDT (see 11.16.5 Fixing Your ASL into the handbook), then powernow driver will work. I have already found what are those values from there: http://lug-owl.de/pipermail/linux/2003-July/019183.html especially those lines: + *pst++ = 4; /* 666 MHz */ + *pst++ = 19; /* 1.20 V */ + *pst++ = 6; /* 800 Mhz */ + *pst++ = 19; /* 1.20 V */ + *pst++ = 10; /* 1066 Mhz */ + *pst++ = 19; /* 1.20 V */ + *pst++ = 14; /* 1333 Mhz */ + *pst++ = 11; /* 1.45 V */ + *pst++ = 1; /* 1533 Mhz */ + *pst = 9;/* 1.55 V */ Correcting the DSDT is therefore easy to me. Just in case you wonder, I can't provide a generic workaround under the powernow driver, and if I write a specific workaround for your model into the powernow driver (and I think his maintainer have to change it in order to support more processors soon) you may have trouble and I would have to redo the work. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powernow0: no match for extended cpuid 780
On Fri, Apr 21, 2006 at 04:11:00PM +, Stefan 'Steve' Tell wrote: Hi, I tried to install FreeBSD 6.1-RC1 on my Acer Aspire 1304LC Notebook. That notebook has a AMD Athlon XP 1800+ CPU. The installation process succeeded but I can't get any power management to work. If I load cpufreq.ko I get: powernow0: PowerNow! K7 on cpu0 powernow0: ACPI MAX frequency not found That means ACPI table are likely broken with regard to frequencies tables. powernow0: no match for extended cpuid 780 And that means the legacy bios tables are broken as well. Maybe by chance a BIOS upgrade will be ok. If that's not the case, or BIOS is alredy the newest, we could resolve that issue by hardcoding sane values under the powernow driver, or by rewritting the DSDT of this laptop. The second solution will give you the oportunity to not have to patch powernow for each upgrades. device_attach: powernow0 attach returned 6 /etc/rc.d/powerd start brings powerd: lookup freq: No such file or directory Are there any chances to get a working cpufreq-mechanism on that machine? Here you can find the dmesg output: * http://daemon.crashmail.de/~stell/paradise_dmesg.txt And a complete lists of all sysctls: * http://daemon.crashmail.de/~stell/paradise_sysctl.txt very litte hw.acpi.*, hum? Well, that seems normal to my eyes. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Fri, Jan 20, 2006 at 01:21:28PM -0800, Nate Lawson wrote: JoaoBR wrote: I have some Epox socket 939 motherboards, nvidia3 with AMD Athlon 64 and some X2 They give me a very good performance but sporadic reboots without core dumps or any other advices so I guess there is some sudden irq conflict or so I get nothing usefull by vmstat. I mount the same Nics, adaptec, mem and processor on an Asus A8V and it runs wothout any problem stable. btw I am running releng_6 If disabling acpi doesn't solve the problem, then it's probably not acpi. I downloaded the acpi table and iasl shows me this epox.asl 2575: Name (_HID, _NVRAIDBUS) Error1068 - String must be entirely alphanumeric ^ (_NVRAIDBUS) Is here somebody how like to try to help me out here? You can get the files here: http://suporte.matik.com.br/epox.dsl http://suporte.matik.com.br/epox.dmesg You could get rid of the _ anywhere NVRAIDBUS occurs. But this should have nothing to do with causing resets. IIRC it is an error to put non-alphanumeric onto an _HID node, but ACPI-CA interpreter is able to handle this situation. IOW iasl will give up if such error is done and is to compiling such ASL, but the in-kernel AML interpreter should interprete such things correctly. If the ASL contains only this error, it won't help the OP to override the DSDT. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Mon, Jan 23, 2006 at 10:49:02AM -0200, JoaoBR wrote: On Monday 23 January 2006 08:59, Bruno Ducrot wrote: epox.asl 2575: Name (_HID, _NVRAIDBUS) Error1068 - String must be entirely alphanumeric ^ (_NVRAIDBUS) Is here somebody how like to try to help me out here? You can get the files here: http://suporte.matik.com.br/epox.dsl http://suporte.matik.com.br/epox.dmesg You could get rid of the _ anywhere NVRAIDBUS occurs. But this should have nothing to do with causing resets. good to know, after it iasl compiles fine with only an WAK warning as Reserved method must return a value (_WAK) IIRC it is an error to put non-alphanumeric onto an _HID node, but ACPI-CA interpreter is able to handle this situation. IOW iasl will give up if such error is done and is to compiling such ASL, but the in-kernel AML interpreter should interprete such things correctly. If the ASL contains only this error, it won't help the OP to override the DSDT. good to know as well, what means supposed my cards are ok the motherboard has issues right Can't tell for sure if you don't test without ACPI loaded. It may be possible after all the apci_thermal subsystem trigger a (false) overheat situation which may explain a sudden shutdown. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: need help for DSDT for an Epox Amd64 MB
On Mon, Jan 23, 2006 at 01:52:11PM -0200, JoaoBR wrote: On Monday 23 January 2006 11:49, Bruno Ducrot wrote: good to know as well, what means supposed my cards are ok the motherboard has issues right Can't tell for sure if you don't test without ACPI loaded. It may be possible after all the apci_thermal subsystem trigger a (false) overheat situation which may explain a sudden shutdown. very nice because exactly this is what I thought, still more likely since the sudden off happens after a certain time when compiling world or other processor expensive tasks any hint how I can get closer to know this? Am I right that the shutdown comes from the motherboard in this case so there is not so very much to do for the OS? normally I find 20 up to 23 hw.acpi.thermal.tz0.temperature: 21.8C but unfortunatly I never could get it in time when it shut off there is an option in the BIOS as ACPI Shutdown Temp but it is disabled I just compiled cpufrequency into the kernel and enabled BIOS Smartfan CPU Temp to see what I get hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% machdep.cpu_idle_hlt: 1 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2000 dev.cpu.0.freq_levels: 2000/67000 1800/64700 1000/28600 dev.acpi_perf.0.%parent: cpu0 dev.powernow.0.%parent: cpu0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 The temperature is read from some isa io port at 0x295... I'm wondering if you should use mbmon instead of ACPI (the _TMP method in that DSDT look a little ugly to my eyes, though I am not sure if it will give some buggy informations). Maybe you should try to disable acpi thermal stuff via hint.acpi_tz.0.disabled=1 and use the mbmon port for monitoring those temperatures. Don't use ACPI and mbmon at the same time: there will be some conflicts accessing the sensor chip internal registers. As an added 'bonus', you should have access to motherboard temperature, not only CPU, and you should be able to monitor voltages, fan, etc. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powerd effectiveness
On Thu, Jan 12, 2006 at 03:17:19PM -0500, Mike Jakubik wrote: Victor Balada Diaz wrote: I know that this is not what you're asking for, but anyway: You should try sysutils/fvcool, it will reduce de heat a lot and the performance will not suffer. --- === WARNING This software can have a negative impact on system stability. In particular while doing heavy duty work such as encoding music, under certain conditions the system can freeze. Don't use this software in production or mission-critical environments! Also note that this software is supposed to be used with AMD Athlon (XP) an AMD Duron processors only. I don't think the latest statement is true. The Athlon 4 family use the same kind of power saving technology than the other version of the Athlon XP. Problem is that the Athlon 4 do have some annoying erratum that prevent it to use them for this purpose if a specific MSR is not set correctly by the BIOS, and when there is a half-frequency multiplier used. If an half-frequency multiplier is in use, it's possible the BIOS configured the northbridge such that the disconnect bit is not set, and then asserting the STPCLK# to the processor prevent it to go into a lower power state. see http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23614.pdf errata #11 PLL Overshoot on Wake-Up from disconnect causes Auto-Compensation Circuit to Fail errata #14 Processors with Half-Frequency Multipliers May Hang Upon Wake-up from disconnect If the latter, it may be possible to put another multiplier by a bios option. For the former, well it may be possible the BIOS do not set correctly the CLK_CTL MSR. In order to check the value put to this MSR, I just written a dummy module here: http://people.freebsd.org/~bruno/read_clk_ctl.tar.bz2 If a value like that one: ctl_ctl = 60031223 (or something like such) then it's likely the bios is not upgraded or do not include some workaround. If something like that 20031223 then it's likely your BIOS do have this kind of workaround enabled already. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powerd effectiveness
Hi Make, On Thu, Jan 12, 2006 at 01:11:52AM -0500, Mike Jakubik wrote: Daniel O'Connor wrote: Wow, that's weird, wish my AMD would do speeds like that :) As for your temperature observation - I have no idea sorry. It would appear that powerd is doing the right thing but for some reason your CPU is not benefiting. That said checking by measuring temperature is fraught with complexity because there is probably a significant delay between a change in power consumption and a corresponding chaange in heatsink temperature. Actually, i took readings from the wrong box :P CPU: AMD Athlon(tm) Processor (1210.79-MHz 686-class CPU) acpi0: ASUS A7V on motherboard [EMAIL PROTECTED]:~# sysctl dev.cpu. dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 75 dev.cpu.0.freq_levels: 1215/-1 1139/-1 1063/-1 987/-1 911/-1 835/-1 759/-1 683/-1 607/-1 531/-1 455/-1 379/-1 303/-1 227/-1 151/-1 75/-1 Thats the correct one, it is 75mhz. I was suspecting hardwares limitations in terms of modulating the frequency quickly enough. Just wanted to make sure. What you have noticed is acpi_throttle(4). The combinaison of some VIA chipset and AMD processors give 16 frequencies. powerd(8) is not designed for thermal stuff, and will never be. It's up to acpi_thermal(4) to cool the processor if needed. Note that I think acpi_throttle(4) can only be used for cooling a processor. I don't think it is usefull for power comsuption at all for which powerd(4) is designed. Some other people may have different opinion of course. BTW you may want to try to check if setting hw.acpi.cpu.cx_lowest to C2 permit to cool the processor. There are a lot of old systems based upon AMD processors that require this for resolving overheating issues. You may also want to check if sysutlis/fvcool can help you if setting the above sysctl is not possible (but don't mix the two). Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powerd effectiveness
On Fri, Jan 13, 2006 at 10:10:51AM +1030, Daniel O'Connor wrote: On Fri, 13 Jan 2006 00:10, Bruno Ducrot wrote: Thats the correct one, it is 75mhz. I was suspecting hardwares limitations in terms of modulating the frequency quickly enough. Just wanted to make sure. What you have noticed is acpi_throttle(4). The combinaison of some VIA chipset and AMD processors give 16 frequencies. powerd(8) is not designed for thermal stuff, and will never be. It's up to acpi_thermal(4) to cool the processor if needed. Note that I think acpi_throttle(4) can only be used for cooling a processor. I don't think it is usefull for power comsuption at all for which powerd(4) is designed. Some other people may have different opinion of course. I don't see how reducing power consumption could NOT affect the temperature. Nearly all of the energy going into the CPU is disipated as heat. Of course. But the goal of powerd is to reduce power comsuption with nearly no visible impact on performance. This imply that if the runpercent is nearly 100%, then the processor will be put to full frequency even though this can imply an overheat situation. The role of acpi_thermal is to reduce frequency if the processor is too hot, and this imply performance loss if runpercent is high. You may also want to check if sysutlis/fvcool can help you if setting the above sysctl is not possible (but don't mix the two). How come? (I am just curious :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: powerd effectiveness
On Fri, Jan 13, 2006 at 10:27:37AM +1030, Daniel O'Connor wrote: On Fri, 13 Jan 2006 10:24, Bruno Ducrot wrote: Nearly all of the energy going into the CPU is disipated as heat. Of course. But the goal of powerd is to reduce power comsuption with nearly no visible impact on performance. This imply that if the runpercent is nearly 100%, then the processor will be put to full frequency even though this can imply an overheat situation. The role of acpi_thermal is to reduce frequency if the processor is too hot, and this imply performance loss if runpercent is high. Yes, but the original poster was wondering why their CPU temperature didn't go down when the clock was (allegedly) very slow. Maybe because the bus disconnect feature on the northbridge is not enabled, and then the processor does not enter a low-power state upon assertion of STPCLK# I think. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Fri, Dec 02, 2005 at 08:35:54PM +1030, Daniel O'Connor wrote: On Fri, 2 Dec 2005 19:35, Marco Calviani wrote: It's not present under powerd for the simple fact that to be efficient in term of not being too intrusive (kernel to user data transfers, etc), powerd can only provide a limited number of check per second (at this time, 2 per second). But the current algorithm present in powerd is not well suited in that case. You have to wait one demi-second for the processor being put to full speed if the system was idle before. Are there on the horizon any sort of plans to implement a newer and more efficient algorithm to increase the number of transition per second? Sorry but i've not understood why linux-cpufreqd is able to cope with those without being so intrusive. I don't see why you can't run powerd more frequently, I do.. Unless your ACPI has a problem that means the transition is slow. I'm sure this could not be done under Linux without a lot of problems (it is required to use the /proc things and it's too slow in that case). I can't imagine that doing 5 (or even 50) syscalls a second is a big CPU load unless there is a specific problem with sysctls or the cpufreq infrastructure. If that's possible being not so intrusive with, say 50 syscalls under FreeBSD, then all I said above is indeed stupid crap. I run powerd like this - /usr/sbin/powerd -i 90 -r 30 -a adaptive -b adaptive -n adaptive -p 200 -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lockup with powerd on amd64/tyan k8sd pro
On Thu, Dec 01, 2005 at 07:07:35PM +1100, Joe Shevland wrote: I've installed 6-stable as of about two weeks ago. I tried out using powerd in 'debug' mode (adaptive by default I guess), more for my own interest's sake, and it locked up the machine solid. Prior to the lock-up the messages reported is was dropping through the various MHz steps, and then the lock-up when it reached what I'm guessing was the lowest level. Could you post a full sysctl dev.cpu and the same with sysctl dev.powernow? Is the lowest frequency the only one which cause that look-up? If you change manually the frequency via a sysctl dev.cpu.0.freq=something other than the lowest one will tell us if that's the case. I think anyway that I found what is wrong. I think the 2 processors are doing a transition at the very same time, and it's possible that will confuse the northbridge. I don't have time to write a fix right now. I will post a patch to be tested latter. Thanks, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 12:37:43PM +0100, Marco Calviani wrote: Hi, having seen on the cpufreq(4) man page that there is more than one driver that is currently supported. In particular having a centrino processor, i would like to use the est driver. Currently, by default, the running driver is the one that comes with acpi (AFAIU), and i'm using powerd to control the cpu frequency in adaptive mode. You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = YES to /boot/loader.conf should be OK. In particular doing comparison with the linux case in which i have cpufreq with speedstep-centrino driver and the ondemand governor, in this case the system is much more responsive and also the fans runs much more quieter (although i cannot rely on proven data since i don't know any benchmark program). In particular i understood that the ondemand governor responds to the system much faster that powerd is able to do. Is there someone who can share some impression or thoughts? powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot [EMAIL PROTECTED]:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = YES
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of sysctl dev.cpu. There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to emulate
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by on-demand governor. The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 12:23:52PM -0800, Nate Lawson wrote:
Bruno Ducrot wrote:
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot [EMAIL PROTECTED]:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = YES
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of sysctl dev.cpu. There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to emulate
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by on-demand governor. The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
Send me a URL to the datasheet that says Intel implemented this.
http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y
That algorithm is basically what powerd does. So just run powerd.
Indeed.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 08:05:59PM +, Marco Calviani wrote: Hi Nate, 2005/11/30, Nate Lawson [EMAIL PROTECTED]: You should send the full output of sysctl dev.cpu. There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 1800/24000 1600/2 1400/18000 1225/15750 1050/13500 1000/16000 875/14000 750/12000 625/1 600/12000 525/10500 450/9000 375/7500 300/6000 225/4500 150/3000 75/1500 If you are using acpi and load cpufreq.ko, you've got all the cpufreq drivers in one package. The right one for your platform will automatically probe/attach. It seems that my system has recognized acpi_perf as the appropriate driver. But since my CPU is a dothan type centrino i would like to understand why is not possible to use the est driver. Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 01:57:42PM -0800, Nate Lawson wrote: Marco Calviani wrote: Hi Bruno, Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. est is preferred if supported. But probably est doesn't have a table for his processor so acpi_perf is used. That's the case for any Dothan IIRC. There's nothing wrong with using acpi_perf -- it just gives a BIOS interface to est anyway. indeed. You can test this with: hint.acpi_perf.0.disabled=1 This will cause acpi_perf to let est attach. But I suspect est won't. est need acpi_perf if a dothan or above is in use... On the other hand, the linux driver work for the OP, and that's not acceptable we can't do the same :) Maybe a link to a 'acpidmp -d -t' may help to see a little deeper? Marco, could you send to me privately or better provide a link to this output? Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop choices
On Tue, Nov 22, 2005 at 05:12:46PM -0800, Graham North wrote: Am currently trying to choose between a couple of laptops, the luck winner of which will have Freebsd loaded alongside WinXP. Dell Latitude d600 with Radeon 9000? video, intel pro wireless or IBM R51 - Intel Extreme2, intel pro wireless. The main differences will likely be the video and maybe bios, acpi...? Can someone suggest to me whether these are both safe choices? Am I better off installing 5.4 or 6.0? AFAIK there are still some issues with suspend-to-ram with the Dell (and I never liked the way they wrote their ASL, but it's more a style issue ;) On the other hand, I don't remember if the IBM R51 do have the same kind of issue with suspend-to-ram, though I'm pretty sure suspending to ram work for almost IBM thinkpads under FreeBSD. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu frequency on 6.0
On Sun, Oct 16, 2005 at 06:54:12AM +0200, Zoran Kolic wrote: Dear all! I'd like to know, prior to install upcoming 6.0, about putting cpu into cooler mo- de. On 5.4 and amd64 2800+ cpu (754, 0.13) with acpi_ppc, it works fine and temperature is just over 30. Could I do the same with device cpufreq and powerd_enable? Yes. Also, is it possible to tune celeron M processor (1400, says it has stepping=5) the same way? It's possible to use p4tcc (integrated onto cpufreq.ko) I believe, but that will cool less the processor than other techniques (as for example est for the pentium-M). -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu frequency on 6.0
Answering to myself, somehow On Mon, Oct 17, 2005 at 04:01:01PM +0200, Bruno Ducrot wrote: On Sun, Oct 16, 2005 at 06:54:12AM +0200, Zoran Kolic wrote: Dear all! I'd like to know, prior to install upcoming 6.0, about putting cpu into cooler mo- de. On 5.4 and amd64 2800+ cpu (754, 0.13) with acpi_ppc, it works fine and temperature is just over 30. Could I do the same with device cpufreq and powerd_enable? Yes. Also, is it possible to tune celeron M processor (1400, says it has stepping=5) the same way? It's possible to use p4tcc (integrated onto cpufreq.ko) I believe, but that will cool less the processor than other techniques (as for example est for the pentium-M). In fact the two answers I gave you are wrong. powerd is used to give more power on demand, based upon cpu utilization. More performance is required, more the frequency will be high. As such, if there is a need to put the processor to full speed, powerd by itself won't down the frequency in order to cool the processor. By now, Umemoto-san have done some work, and I believe this has been commited to 6.0. Please search for passive cooling at current@ for more informations. This require though that the ACPI onto your system support thermal zones. There is no generic way to do it for now unfortunately. Of course, when the system is mostly idle, using powerd will cool the processor, but this is only a side effect. The same statement apply also for acpi_ppc. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE cpufreq hotter than est from ports
On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote: A couple days ago I updated my system and was excited to see cpufreq and powerd in 5-stable. Since then however I noticed that my laptop temperature is about 5°C higher than with est and estctrl. I found that cpufreq when setting 200MHz for example set the absolute frequency to 1600MHz (max for this laptop) and the relative frequency (p4tcc) to 12.5% instead of using a more power conserving setting like 800MHz/25%. The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) traverses freq levels from high to low when adding relative levels and skips duplicates. When it wants to add 800MHz/25% it sees this setting as a duplicate of 1600MHz/12.5% it has found before. This can be fixed by letting cpufreq_expand_set() traverse freq levels in reverse order (and still skipping duplicates). Then each frequency level has the lowest possible absolute setting. This is a one line change in sys/kern/kern_cpu.c (line 653). It's a well known bug. Someday I think I will have enough time to fix that one if Nate don't bite me. With this patch temperature is almost as low as with est again (only 1°C hotter). However, there are still such levels like 1400/12.5 (175MHz) which are lower than let's say 600/37.5 (225MHz), but consume a lot more power. On my laptop this problem doesn't really occur because of the way powerd works, only the absolute levels 1600, 800 and 600 are ever used. I can imagine somebody with a 1700MHz cpu not being so lucky though. So, I've worked out a patch (attached) that makes sure that a lower frequency level has at most the same absolute setting (preferably less of course). This eliminates quite a few levels so somebody with a better knowledge of cpufreq should check if this patch really does something good. This is the first time I've taken a look at FreeBSD source code by the way. It's in my todo list in a so long time that I must admit I must be blamed to have not fixed that already. Also, somewhat related, the p4tcc driver doesn't recognise acpi_throttle, which means that when you load the cpufreq module after booting, the freq levels are messed up. I'm not sure what the best solution for this is. Let p4tcc detect acpi_throttle and don't attach if it's present (like acpi_throttle does now if it finds p4tcc) or detach it before attaching? Or maybe p4tcc and acpi_throttle should be merged into one driver? Finally, is the kernel config option CPU_ENABLE_TCC still relevant? Because it's still listed in NOTES. Right. I forgot to kill that option. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: loss of keyboard in single-user mode in RELENG_5
On Fri, May 06, 2005 at 05:50:10PM +0200, Thierry Herbelot wrote: - ident strings of the modified sources between the two kernels : http://herbelot.tfh.free.fr/Diversion/div.kern.ident.diff² I can't get that one. Could you please rename it? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
