From owner-freebsd-mobile@FreeBSD.ORG Sun Aug 31 10:55:11 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D67106567C for ; Sun, 31 Aug 2008 10:55:11 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3CA88FC16 for ; Sun, 31 Aug 2008 10:55:10 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (unknown [74.193.170.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id CA3F48F02513; Sun, 31 Aug 2008 05:55:09 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.2/8.14.2) with ESMTP id m7VAt5QK048532; Sun, 31 Aug 2008 05:55:06 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Sun, 31 Aug 2008 05:55:05 -0500 (CDT) From: Wes Morgan To: freebsd_user@guice.ath.cx In-Reply-To: <20080830210736.GA4521@WORKSTATION.guice.ath.cx> Message-ID: References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Ian Smith , freebsd-mobile@freebsd.org Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 10:55:11 -0000 On Sat, 30 Aug 2008, freebsd_user@guice.ath.cx wrote: > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... >> > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C 61C? My laptop is routinely that temperature or higher, even in XP. A laptop is going to be much hotter than a desktop. From owner-freebsd-mobile@FreeBSD.ORG Sun Aug 31 16:45:58 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4642E106566B; Sun, 31 Aug 2008 16:45:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id A3EBD8FC2D; Sun, 31 Aug 2008 16:45:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id m7VGji9D005813; Mon, 1 Sep 2008 02:45:45 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Sep 2008 02:45:44 +1000 (EST) From: Ian Smith To: freebsd_user@guice.ath.cx Message-ID: <20080901020747.A1667@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support (fwd) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 16:45:58 -0000 Ok, I think we've finally obtained enough info to pin this issue down. I'm going to just forward your message to freebsd-acpi@ because your symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd therefore not shifting to a real lower frequency, so running flat out all the time) came up there several times this year on some machines. While I can't recall the details, nor have access to my own archives currently, I'm pretty sure there was a patch - not sure if it covers or can be applied to 6.3 though. You could browse the -acpi archives for this, but hopefully someone will show mercy and provide a pointer or two, if not directly help out? As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) but still it'd be better to get the mangled cpu freqs sorted out so that powerd can do its thing properly. [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry I didn't pay a bit more attention back when this was a 'hot issue' ..] cheers, Ian ---------- Forwarded message ---------- Date: Sat, 30 Aug 2008 17:07:36 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Cc: Ian Smith Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: FROM THE LAST MESSAGE ... > > > > > However we need some empirical data about what it's doing. Showing your > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > in fact what was needed or if the was some other incorrect setting. > > > > > > /var/run/dmesg.boot ... > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > ACPI APIC Table: > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > Features=0xbfebfbff > > > Features2=0xe3bd > > > AMD Features=0x20100000 > > > AMD Features2=0x1 > > > Cores per package: 2 > > > real memory = 2113142784 (2015 MB) > > > avail memory = 2058563584 (1963 MB) > > > ioapic0: Changing APIC ID to 1 > > > ioapic0 irqs 0-23 on motherboard > > [..] > > > acpi0: on motherboard > > > acpi0: Power Button (fixed) > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > cpu0: on acpi0 > > [..] > > > acpi_lid0: on acpi0 > > > battery0: on acpi0 > > > acpi_button0: on acpi0 > > > acpi_acad0: on acpi0 > > > acpi_tz0: on acpi0 > > [..] > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > CPU frequency control. So, powerd is rendered powerless .. > > > 'powerd' is now operational: idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500^M > > Try booting with the GENERIC kernel, you should see one or two of the > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > This has always been the /GENERIC kernel copied to a custome name. This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't considered as a default entry in the /GENERIC. > > > > > sysctl hw.acpi ... > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > hw.acpi.power_button_state: S5 > > > hw.acpi.sleep_button_state: S3 > > > hw.acpi.lid_switch_state: NONE > > > hw.acpi.standby_state: S1 > > > hw.acpi.suspend_state: S3 > > > hw.acpi.sleep_delay: 1 > > > hw.acpi.s4bios: 0 > > > hw.acpi.verbose: 0 > > > hw.acpi.disable_on_reboot: 0 > > > hw.acpi.handle_reboot: 0 > > > hw.acpi.reset_video: 0 > > > hw.acpi.cpu.cx_lowest: C1 > > > hw.acpi.battery.life: 100 > > > hw.acpi.battery.time: -1 > > > hw.acpi.battery.state: 0 > > > hw.acpi.battery.units: 1 > > > hw.acpi.battery.info_expire: 5 > > > hw.acpi.acline: 1 > > > hw.acpi.thermal.min_runtime: 0 > > > hw.acpi.thermal.polling_rate: 10 > > > hw.acpi.thermal.user_override: 0 > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > hw.acpi.thermal.tz0.active: -1 > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > hw.acpi.thermal.tz0._PSV: -1 > > > hw.acpi.thermal.tz0._HOT: -1 > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > overrides .. but it might all just work with the GENERIC kernel anyway. > Attempting to: --> sysctl hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 0 Attempting to: --> sysctl hw.acpi.thermal.user_override=1 hw.acpi.thermal.user_override: 0 -> 1 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling hw.acpi.thermal.tz0.passive_cooling: 0 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.tz0.passive_cooling: 0 sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported by device NOTE: While we are able to change the threshold for: hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because the above passive_cooling is not enabled. Well, so much for passive_cooling. :=\ > > Also, have you set anything in BIOS regarding power usage, speedstep or > > any other settings that might get reflected into your boot ACPI setup? Initially we left the BIOS power settings the way the OEM set them (Vista). We are able to choose from one of Dynamic, High or low not much else to play with in the way of power settings (ACPI) with the exception of LCD and/or letting the OS control devices. Unable to directly set CPU steppings/freq settings within this BIOS. > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > this, but may at least provide some useful info in its sysctls .. > > > This is an issue revisited; take a deep breath. Better yet, here's the short version, in the kernel 'device acpi_toshiba' does not work for us on this machine unless we neglected to make an accompanying needed acpi entry. Aa we understand it, we were to only add 'device acpi_toshiba' to load the neccessary acpi toshiba extras. Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using 'kldload acpi_toshiba' from the cli works like a charm but has no positive affect on the current discussion (heat). > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > exactly what it's doing re shifting CPU frequency under various loads. idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500 > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. The following data is the result of the concerns I have; running too hot. These figures are the lowest temperatures this machine idles while FreeBSD is installed and running. The temperatures shown herein only rise with use but never go lower than what we're showing here when the laptop returns to idle. Attempting to: --> sysctl hw.acpi.thermal.tz0. hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 102.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > (so far) when you apply or remove AC power, using the following values > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > economy_cpu_freq="HIGH" # Offline CPU frequency Our /etc/defaults/rc.conf performance_cx_lowest="HIGH" # Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency economy_cx_lowest="HIGH" # Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > variables to HIGH, LOW, a specific value, or NONE. Attempting to: --> sysctl hw.acpi.cpu.cx_supported sysctl: unknown oid 'hw.acpi.cpu.cx_supported' Attempting to: --> sysctl hw.acpi.cpu hw.acpi.cpu.cx_lowest: C1 Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' probe something? Attempting to: --> sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 Following is grepped from /var/run/dmesg.boot: CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz 686-class CPU) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > Our /etc/rc.conf performance_cx_lowest="C4" # Online CPU idle state #performance_cpu_freq="HIGH" # Online CPU frequency economy_cx_lowest="C5" # Offline CPU idle state #economy_cpu_freq="HIGH" # Offline CPU frequency This machine can afford to go to C4 and C5 unless needed otherwise. I'll try anything to lowwer this machines temp. > > > This is another issue in addition to the heat. As you say, this battery > > > should last any where from 2-3 hours, however as it is now; > > > out-of-the-box so to speak, this machine will only stay powered up > > > approximately 1-hour on using the oem battery. > > > > That's because it runs at (presumably) its maximum frequency all of the > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. These numbers have not changed (lowwer) prior to or during this thread. Attempting to: --> sysctl dev.cpu.0.freq dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature hw.acpi.thermal.tz0.temperature: 61.0C > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > and control this beast of a machine if possible. > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > now provided that information. > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > is not subject to any of the dual-core issues solved or being actively > > worked on in freebsd-acpi and being applied mostly or at least firstly > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > last few months, it's not that big .. that is, if using the GENERIC > > kernel and running powerd doesn't improve matters sufficiently. > > > > cheers, Ian From owner-freebsd-mobile@FreeBSD.ORG Sun Aug 31 18:26:14 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72E30106567E for ; Sun, 31 Aug 2008 18:26:14 +0000 (UTC) (envelope-from email@guice.ath.cx) Received: from guice.ath.cx (cpe-72-225-169-69.nyc.res.rr.com [72.225.169.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2A13F8FC1C for ; Sun, 31 Aug 2008 18:26:12 +0000 (UTC) (envelope-from email@guice.ath.cx) Received: from guice.ath.cx (localhost [127.0.0.1]) by guice.ath.cx (8.14.2/8.14.2) with ESMTP id m7VIPOBd004528; Sun, 31 Aug 2008 14:25:24 -0400 (EDT) (envelope-from email@guice.ath.cx) Received: (from email@localhost) by guice.ath.cx (8.14.2/8.14.2/Submit) id m7VIPNRQ004527; Sun, 31 Aug 2008 14:25:23 -0400 (EDT) (envelope-from email) Date: Sun, 31 Aug 2008 14:25:22 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Message-ID: <20080831182522.GA2191@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Ian Smith Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 18:26:14 -0000 On Sun, Aug 31, 2008 at 05:55:05AM -0500, Wes Morgan wrote: > On Sat, 30 Aug 2008, freebsd_user@guice.ath.cx wrote: > > >On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx > >wrote: > > FROM THE LAST MESSAGE ... > >> > >Attempting to: --> sysctl dev.cpu.0.freq > >dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > >Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > >hw.acpi.thermal.tz0.temperature: 61.0C > > 61C? My laptop is routinely that temperature or higher, even in XP. A > laptop is going to be much hotter than a desktop. While I am inclined to agree with you on that specific temperature issue, 61.0C not that hot, our concern is that the temp is 61.0C while doing absolutly nothing (idling), for hours on end. We have come upon some new data/findings which we're sorting out and will be responding to and/or addressing in the next msg to this thread. > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From owner-freebsd-mobile@FreeBSD.ORG Sun Aug 31 20:30:29 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB301065691 for ; Sun, 31 Aug 2008 20:30:29 +0000 (UTC) (envelope-from email@guice.ath.cx) Received: from guice.ath.cx (cpe-72-225-169-69.nyc.res.rr.com [72.225.169.69]) by mx1.freebsd.org (Postfix) with ESMTP id 02EC78FC12 for ; Sun, 31 Aug 2008 20:30:28 +0000 (UTC) (envelope-from email@guice.ath.cx) Received: from guice.ath.cx (localhost [127.0.0.1]) by guice.ath.cx (8.14.2/8.14.2) with ESMTP id m7VKTeMU004864; Sun, 31 Aug 2008 16:29:40 -0400 (EDT) (envelope-from email@guice.ath.cx) Received: (from email@localhost) by guice.ath.cx (8.14.2/8.14.2/Submit) id m7VKTdRI004863; Sun, 31 Aug 2008 16:29:39 -0400 (EDT) (envelope-from email) Date: Sun, 31 Aug 2008 16:29:39 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Message-ID: <20080831202938.GB2191@WORKSTATION.guice.ath.cx> References: <20080901020747.A1667@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080901020747.A1667@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: Ian Smith Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:30:29 -0000 On Mon, Sep 01, 2008 at 02:45:44AM +1000, Ian Smith wrote: > Ok, I think we've finally obtained enough info to pin this issue down. > > I'm going to just forward your message to freebsd-acpi@ because your > symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd > therefore not shifting to a real lower frequency, so running flat out > all the time) came up there several times this year on some machines. > > While I can't recall the details, nor have access to my own archives > currently, I'm pretty sure there was a patch - not sure if it covers or > can be applied to 6.3 though. I was recently introduced to this URL: http://lists.freebsd.org/pipermail/cvs-src/2007-August/081246.html. > > You could browse the -acpi archives for this, but hopefully someone will > show mercy and provide a pointer or two, if not directly help out? > > As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) > but still it'd be better to get the mangled cpu freqs sorted out so that > powerd can do its thing properly. In addition to the above URL, other findings: hw.acpi.toshiba.cpu_speed=7 hw.acpi.toshiba.force_fan=1 hw.acpi.thermal.min_runtime=30 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - # this value is bogus hw.acpi.thermal.tz0.active: -1 # Can not change hw.acpi.thermal.tz0.passive_cooling: 0 # Can not change hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV=10.0C # passive_cooling will- # activate @ this temp. # Above, passive_cooling # currently N/A. Since Sat Aug 30 06:20:00 EDT 2008, with the above sysctl variables set, we have logged the following results at 20-min intervals: Sat Aug 30 21:20:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 2201 hw.acpi.thermal.tz0.temperature: 61.0C The frquencies during the above time frame have not gone above 2201 and not fallen below 2200. During which time the hw.acpi.thermal.tz0.temperature: 61.0C has remained static. Moving forward ... It has been suggested that we try the following: Attempting to: --> sysctl dev.cpu.0.freq=900 dev.cpu.0.freq: 2201 -> 900 Here in lies 'a' rub, so to speak; after setting the above dev.cpu.0.freq: 2201 -> 900, the machine appeared to be running cooler --as in placing a finger near the output of the fan, the machine wasn't breathing fire. However, the reading of hw.acpi.thermal.tz0.temperature: 61.0C remained the same --how could this be? Sat Aug 30 21:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sat Aug 30 23:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C If you'll notice the time stamps, I've allowed time for the temperatures both actual and ambient to adjust, yet hw.acpi.thermal.tz0.temperature: 61.0C remains constant. Another suggestion/recommendation, 'kldload coretemp', no 'man page' within 6.3. After doing so, we began to log the following data: ... Notice and compare the time stamp(s)... Sun Aug 31 00:00:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sun Aug 31 00:40:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.temperature: 61.0C <--> remains unchanged. Here's the entry to drive my point home: Sun Aug 31 01:00:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C dev.cpu.0.temperature: 44 - Sun Aug 31 01:20:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 01:20:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.temperature: 45 - Sun Aug 31 15:40:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 15:40:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.temperature: 44 It is now thought, to say the least, that hw.acpi.thermal.tz0.temperature: 61.0C are not correct in comparison to the output of dev.cpu.0.temperature: 45. If I hadn't of experienced this back in 3.x to 4.x I may have dismissed it as a first time occurrance, but this heat issue has now haunted me using i386 AMD on a Tiger MPX as well as the TECRA_A9-S9017 laptops. Now we find out that there are numerous issues causing this, powerd, incorrect temp/sensor readings and perhaps an OEM ACPI implementation issue. With that being said, please allow me this one (1) rhetorical question; how is a common end-user supposed to keep his machine running and maintain her/his sanity chasing after issues such as we've discussed here? I'd like to extend my continued thanks to: FreeBSD-mobile FreeBSD-questions FreeBSDhelp @ EFnet > > [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry > I didn't pay a bit more attention back when this was a 'hot issue' ..] > > cheers, Ian > > ---------- Forwarded message ---------- > Date: Sat, 30 Aug 2008 17:07:36 -0400 > From: freebsd_user@guice.ath.cx > To: freebsd-mobile@freebsd.org > Cc: Ian Smith > Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support > > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... > > > > > > > However we need some empirical data about what it's doing. Showing your > > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > > in fact what was needed or if the was some other incorrect setting. > > > > > > > > /var/run/dmesg.boot ... > > > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > > ACPI APIC Table: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > [..] > > > > acpi0: on motherboard > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: on acpi0 > > > [..] > > > > acpi_lid0: on acpi0 > > > > battery0: on acpi0 > > > > acpi_button0: on acpi0 > > > > acpi_acad0: on acpi0 > > > > acpi_tz0: on acpi0 > > > [..] > > > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > > CPU frequency control. So, powerd is rendered powerless .. > > > > > > 'powerd' is now operational: > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500^M > > > > Try booting with the GENERIC kernel, you should see one or two of the > > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > > > > This has always been the /GENERIC kernel copied to a custome name. > This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't > considered as a default entry in the /GENERIC. > > > > > > > > sysctl hw.acpi ... > > > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S3 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > hw.acpi.verbose: 0 > > > > hw.acpi.disable_on_reboot: 0 > > > > hw.acpi.handle_reboot: 0 > > > > hw.acpi.reset_video: 0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > hw.acpi.battery.life: 100 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 1 > > > > hw.acpi.battery.info_expire: 5 > > > > hw.acpi.acline: 1 > > > > hw.acpi.thermal.min_runtime: 0 > > > > hw.acpi.thermal.polling_rate: 10 > > > > hw.acpi.thermal.user_override: 0 > > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > > hw.acpi.thermal.tz0.active: -1 > > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > > hw.acpi.thermal.tz0._PSV: -1 > > > > hw.acpi.thermal.tz0._HOT: -1 > > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > > overrides .. but it might all just work with the GENERIC kernel anyway. > > > Attempting to: --> sysctl hw.acpi.thermal.user_override > hw.acpi.thermal.user_override: 0 > Attempting to: --> sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling > hw.acpi.thermal.tz0.passive_cooling: 0 > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.tz0.passive_cooling: 0 > sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported > by device > > NOTE: While we are able to change the threshold for: > hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because > the above passive_cooling is not enabled. > > Well, so much for passive_cooling. :=\ > > > > Also, have you set anything in BIOS regarding power usage, speedstep or > > > any other settings that might get reflected into your boot ACPI setup? > > Initially we left the BIOS power settings the way the OEM set them > (Vista). We are able to choose from one of Dynamic, High or low > not much else to play with in the way of power settings (ACPI) > with the exception of LCD and/or letting the OS control devices. > Unable to directly set CPU steppings/freq settings within this BIOS. > > > > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > > this, but may at least provide some useful info in its sysctls .. > > > > > > This is an issue revisited; take a deep breath. Better yet, here's > the short version, in the kernel 'device acpi_toshiba' does not work > for us on this machine unless we neglected to make an accompanying > needed acpi entry. Aa we understand it, we were to only add 'device > acpi_toshiba' to load the neccessary acpi toshiba extras. > > Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using > 'kldload acpi_toshiba' from the cli works like a charm but has no > positive affect on the current discussion (heat). > > > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > > exactly what it's doing re shifting CPU frequency under various loads. > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500 > > > > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > The following data is the result of the concerns I have; running too > hot. These figures are the lowest temperatures this machine idles > while FreeBSD is installed and running. The temperatures shown > herein only rise with use but never go lower than what we're showing > here when the laptop returns to idle. > > Attempting to: --> sysctl hw.acpi.thermal.tz0. > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > > (so far) when you apply or remove AC power, using the following values > > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > > economy_cpu_freq="HIGH" # Offline CPU frequency > > Our /etc/defaults/rc.conf > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > > variables to HIGH, LOW, a specific value, or NONE. > > Attempting to: --> sysctl hw.acpi.cpu.cx_supported > sysctl: unknown oid 'hw.acpi.cpu.cx_supported' > Attempting to: --> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_lowest: C1 > > Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' > probe something? > > Attempting to: --> sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 > 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 > 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 > > Following is grepped from /var/run/dmesg.boot: > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz > 686-class CPU) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > > > Our /etc/rc.conf > > performance_cx_lowest="C4" # Online CPU idle state > #performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="C5" # Offline CPU idle state > #economy_cpu_freq="HIGH" # Offline CPU frequency > > This machine can afford to go to C4 and C5 unless needed otherwise. > I'll try anything to lowwer this machines temp. > > > > > This is another issue in addition to the heat. As you say, this battery > > > > should last any where from 2-3 hours, however as it is now; > > > > out-of-the-box so to speak, this machine will only stay powered up > > > > approximately 1-hour on using the oem battery. > > > > > > That's because it runs at (presumably) its maximum frequency all of the > > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > These numbers have not changed (lowwer) prior to or during this thread. > > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C > > > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > > and control this beast of a machine if possible. > > > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > > now provided that information. > > > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > > is not subject to any of the dual-core issues solved or being actively > > > worked on in freebsd-acpi and being applied mostly or at least firstly > > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > > last few months, it's not that big .. that is, if using the GENERIC > > > kernel and running powerd doesn't improve matters sufficiently. > > > > > > cheers, Ian > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From owner-freebsd-mobile@FreeBSD.ORG Sun Aug 31 20:55:58 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17EAF1065682 for ; Sun, 31 Aug 2008 20:55:58 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id BEDD68FC08 for ; Sun, 31 Aug 2008 20:55:57 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: by pinus.izb.knu.ac.kr (Postfix, from userid 59) id C9D843EA5; Mon, 1 Sep 2008 05:55:53 +0900 (KST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on pinus.izb.knu.ac.kr X-Spam-Level: X-Spam-Status: No, score=-48.6 required=15.1 tests=DKIM_SIGNED,DKIM_VERIFIED autolearn=disabled version=3.2.3 Received: from pinus.izb.knu.ac.kr (localhost.izb.knu.ac.kr [127.0.0.1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 724B43EA0 for ; Mon, 1 Sep 2008 05:55:50 +0900 (KST) Comment: DKIM? See http://www.google.com/search?btnI&q=RFC+4871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=izb.knu.ac.kr; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns/txt; s=s1024; bh=cc5SWF6sLkXBrz k1cMIlWymxgaupOsawoz+BMqPK18s=; b=gT44xl29cFAvp4y4IruaS7RwhfJG5h vndfoGlcIPmZ2JY0DElmP7WMDp6X1wxKlfB2dtGnCJGLdZuZieusuz8fumnbL9fo qkCnksuO0XYi4jApiuczBYznpTQtuz4IpDwr4iOOEhiCTVfPGs+S7x4RqEPppPic avSf9d5uDeA5M= Received: from [IPv6:2001:470:1f05:5f8:3::2] (phyll.izb.knu.ac.kr [IPv6:2001:470:1f05:5f8:3::2]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 1C6743E98 for ; Mon, 1 Sep 2008 05:55:48 +0900 (KST) From: Byung-Hee HWANG To: freebsd-mobile@freebsd.org Content-Type: text/plain Organization: InZealBomb Date: Mon, 01 Sep 2008 05:55:54 +0900 Message-Id: <1220216154.4029.2.camel@phyll.izb.knu.ac.kr> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Anycall SPH-B8250 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 20:55:58 -0000 Recently i'm interested in a mobile data synchronization with desktop (Windows XP). Especially, i'm using Anycall SPH-B8250 released in 2007-12-21 from SAMSUNG. Q: Is there anyone to use things like this on FreeBSD? Or can you please give me other related information? byunghee -- "Do what you want." -- Vito Corleone, "Chapter 1", page 37 From owner-freebsd-mobile@FreeBSD.ORG Sun Aug 31 22:38:11 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A94106569B for ; Sun, 31 Aug 2008 22:38:11 +0000 (UTC) (envelope-from email@guice.ath.cx) Received: from guice.ath.cx (cpe-72-225-169-69.nyc.res.rr.com [72.225.169.69]) by mx1.freebsd.org (Postfix) with ESMTP id F2C758FC20 for ; Sun, 31 Aug 2008 22:38:07 +0000 (UTC) (envelope-from email@guice.ath.cx) Received: from guice.ath.cx (localhost [127.0.0.1]) by guice.ath.cx (8.14.2/8.14.2) with ESMTP id m7VMbN4O005243 for ; Sun, 31 Aug 2008 18:37:23 -0400 (EDT) (envelope-from email@guice.ath.cx) Received: (from email@localhost) by guice.ath.cx (8.14.2/8.14.2/Submit) id m7VMbNPu005242 for freebsd-mobile@freebsd.org; Sun, 31 Aug 2008 18:37:23 -0400 (EDT) (envelope-from email) Date: Sun, 31 Aug 2008 18:37:22 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Message-ID: <20080831223722.GC2191@WORKSTATION.guice.ath.cx> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080830210736.GA4521@WORKSTATION.guice.ath.cx> User-Agent: Mutt/1.4.2.3i Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 22:38:11 -0000 In an effort to keep this thread *as a thread*, it appears to have branched off in to a totally different entity due to edits to the subject, I'm duplicating this message as part of this original thread to better help other with the same issue and/or machine keep up with what has taken place with this TECRA_A9-S9017. Errors-To: owner-freebsd-mobile@freebsd.org On Mon, Sep 01, 2008 at 02:45:44AM +1000, Ian Smith wrote: > Ok, I think we've finally obtained enough info to pin this issue down. > > I'm going to just forward your message to freebsd-acpi@ because your > symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd > therefore not shifting to a real lower frequency, so running flat out > all the time) came up there several times this year on some machines. > > While I can't recall the details, nor have access to my own archives > currently, I'm pretty sure there was a patch - not sure if it covers or > can be applied to 6.3 though. I was recently introduced to this URL: http://lists.freebsd.org/pipermail/cvs-src/2007-August/081246.html. > > You could browse the -acpi archives for this, but hopefully someone will > show mercy and provide a pointer or two, if not directly help out? > > As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) > but still it'd be better to get the mangled cpu freqs sorted out so that > powerd can do its thing properly. In addition to the above URL, other findings: hw.acpi.toshiba.cpu_speed=7 hw.acpi.toshiba.force_fan=1 hw.acpi.thermal.min_runtime=30 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - # this value is bogus hw.acpi.thermal.tz0.active: -1 # Can not change hw.acpi.thermal.tz0.passive_cooling: 0 # Can not change hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV=10.0C # passive_cooling will- # activate @ this temp. # Above, passive_cooling # currently N/A. Since Sat Aug 30 06:20:00 EDT 2008, with the above sysctl variables set, we have logged the following results at 20-min intervals: Sat Aug 30 21:20:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 2201 hw.acpi.thermal.tz0.temperature: 61.0C The frquencies during the above time frame have not gone above 2201 and not fallen below 2200. During which time the hw.acpi.thermal.tz0.temperature: 61.0C has remained static. Moving forward ... It has been suggested that we try the following: Attempting to: --> sysctl dev.cpu.0.freq=900 dev.cpu.0.freq: 2201 -> 900 Here in lies 'a' rub, so to speak; after setting the above dev.cpu.0.freq: 2201 -> 900, the machine appeared to be running cooler --as in placing a finger near the output of the fan, the machine wasn't breathing fire. However, the reading of hw.acpi.thermal.tz0.temperature: 61.0C remained the same --how could this be? Sat Aug 30 21:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sat Aug 30 23:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C If you'll notice the time stamps, I've allowed time for the temperatures both actual and ambient to adjust, yet hw.acpi.thermal.tz0.temperature: 61.0C remains constant. Another suggestion/recommendation, 'kldload coretemp', no 'man page' within 6.3. After doing so, we began to log the following data: ... Notice and compare the time stamp(s)... Sun Aug 31 00:00:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sun Aug 31 00:40:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.temperature: 61.0C <--> remains unchanged. Here's the entry to drive my point home: Sun Aug 31 01:00:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C dev.cpu.0.temperature: 44 - Sun Aug 31 01:20:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 01:20:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.temperature: 45 - Sun Aug 31 15:40:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 15:40:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.temperature: 44 It is now thought, to say the least, that hw.acpi.thermal.tz0.temperature: 61.0C are not correct in comparison to the output of dev.cpu.0.temperature: 45. If I hadn't of experienced this back in 3.x to 4.x I may have dismissed it as a first time occurrance, but this heat issue has now haunted me using i386 AMD on a Tiger MPX as well as the TECRA_A9-S9017 laptops. Now we find out that there are numerous issues causing this, powerd, incorrect temp/sensor readings and perhaps an OEM ACPI implementation issue. With that being said, please allow me this one (1) rhetorical question; how is a common end-user supposed to keep his machine running and maintain her/his sanity chasing after issues such as we've discussed here? I'd like to extend my continued thanks to: FreeBSD-mobile FreeBSD-questions FreeBSDhelp @ EFnet > > [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry > I didn't pay a bit more attention back when this was a 'hot issue' ..] > > cheers, Ian > > ---------- Forwarded message ---------- > Date: Sat, 30 Aug 2008 17:07:36 -0400 > From: freebsd_user@guice.ath.cx > To: freebsd-mobile@freebsd.org > Cc: Ian Smith > Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support > > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... > > > > > > > However we need some empirical data about what it's doing. Showing your > > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > > in fact what was needed or if the was some other incorrect setting. > > > > > > > > /var/run/dmesg.boot ... > > > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > > ACPI APIC Table: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > [..] > > > > acpi0: on motherboard > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: on acpi0 > > > [..] > > > > acpi_lid0: on acpi0 > > > > battery0: on acpi0 > > > > acpi_button0: on acpi0 > > > > acpi_acad0: on acpi0 > > > > acpi_tz0: on acpi0 > > > [..] > > > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > > CPU frequency control. So, powerd is rendered powerless .. > > > > > > 'powerd' is now operational: > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500^M > > > > Try booting with the GENERIC kernel, you should see one or two of the > > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > > > > This has always been the /GENERIC kernel copied to a custome name. > This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't > considered as a default entry in the /GENERIC. > > > > > > > > sysctl hw.acpi ... > > > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S3 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > hw.acpi.verbose: 0 > > > > hw.acpi.disable_on_reboot: 0 > > > > hw.acpi.handle_reboot: 0 > > > > hw.acpi.reset_video: 0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > hw.acpi.battery.life: 100 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 1 > > > > hw.acpi.battery.info_expire: 5 > > > > hw.acpi.acline: 1 > > > > hw.acpi.thermal.min_runtime: 0 > > > > hw.acpi.thermal.polling_rate: 10 > > > > hw.acpi.thermal.user_override: 0 > > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > > hw.acpi.thermal.tz0.active: -1 > > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > > hw.acpi.thermal.tz0._PSV: -1 > > > > hw.acpi.thermal.tz0._HOT: -1 > > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > > overrides .. but it might all just work with the GENERIC kernel anyway. > > > Attempting to: --> sysctl hw.acpi.thermal.user_override > hw.acpi.thermal.user_override: 0 > Attempting to: --> sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling > hw.acpi.thermal.tz0.passive_cooling: 0 > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.tz0.passive_cooling: 0 > sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported > by device > > NOTE: While we are able to change the threshold for: > hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because > the above passive_cooling is not enabled. > > Well, so much for passive_cooling. :=\ > > > > Also, have you set anything in BIOS regarding power usage, speedstep or > > > any other settings that might get reflected into your boot ACPI setup? > > Initially we left the BIOS power settings the way the OEM set them > (Vista). We are able to choose from one of Dynamic, High or low > not much else to play with in the way of power settings (ACPI) > with the exception of LCD and/or letting the OS control devices. > Unable to directly set CPU steppings/freq settings within this BIOS. > > > > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > > this, but may at least provide some useful info in its sysctls .. > > > > > > This is an issue revisited; take a deep breath. Better yet, here's > the short version, in the kernel 'device acpi_toshiba' does not work > for us on this machine unless we neglected to make an accompanying > needed acpi entry. Aa we understand it, we were to only add 'device > acpi_toshiba' to load the neccessary acpi toshiba extras. > > Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using > 'kldload acpi_toshiba' from the cli works like a charm but has no > positive affect on the current discussion (heat). > > > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > > exactly what it's doing re shifting CPU frequency under various loads. > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500 > > > > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > The following data is the result of the concerns I have; running too > hot. These figures are the lowest temperatures this machine idles > while FreeBSD is installed and running. The temperatures shown > herein only rise with use but never go lower than what we're showing > here when the laptop returns to idle. > > Attempting to: --> sysctl hw.acpi.thermal.tz0. > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > > (so far) when you apply or remove AC power, using the following values > > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > > economy_cpu_freq="HIGH" # Offline CPU frequency > > Our /etc/defaults/rc.conf > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > > variables to HIGH, LOW, a specific value, or NONE. > > Attempting to: --> sysctl hw.acpi.cpu.cx_supported > sysctl: unknown oid 'hw.acpi.cpu.cx_supported' > Attempting to: --> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_lowest: C1 > > Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' > probe something? > > Attempting to: --> sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 > 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 > 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 > > Following is grepped from /var/run/dmesg.boot: > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz > 686-class CPU) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > > > Our /etc/rc.conf > > performance_cx_lowest="C4" # Online CPU idle state > #performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="C5" # Offline CPU idle state > #economy_cpu_freq="HIGH" # Offline CPU frequency > > This machine can afford to go to C4 and C5 unless needed otherwise. > I'll try anything to lowwer this machines temp. > > > > > This is another issue in addition to the heat. As you say, this battery > > > > should last any where from 2-3 hours, however as it is now; > > > > out-of-the-box so to speak, this machine will only stay powered up > > > > approximately 1-hour on using the oem battery. > > > > > > That's because it runs at (presumably) its maximum frequency all of the > > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > These numbers have not changed (lowwer) prior to or during this thread. > > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C > > > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > > and control this beast of a machine if possible. > > > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > > now provided that information. > > > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > > is not subject to any of the dual-core issues solved or being actively > > > worked on in freebsd-acpi and being applied mostly or at least firstly > > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > > last few months, it's not that big .. that is, if using the GENERIC > > > kernel and running powerd doesn't improve matters sufficiently. > > > > > > cheers, Ian > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" On Sat, Aug 30, 2008 at 05:07:36PM -0400, freebsd_user@guice.ath.cx wrote: > On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: > FROM THE LAST MESSAGE ... > > > > > > > However we need some empirical data about what it's doing. Showing your > > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > > in fact what was needed or if the was some other incorrect setting. > > > > > > > > /var/run/dmesg.boot ... > > > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > > ACPI APIC Table: > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > [..] > > > > acpi0: on motherboard > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: on acpi0 > > > [..] > > > > acpi_lid0: on acpi0 > > > > battery0: on acpi0 > > > > acpi_button0: on acpi0 > > > > acpi_acad0: on acpi0 > > > > acpi_tz0: on acpi0 > > > [..] > > > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > > CPU frequency control. So, powerd is rendered powerless .. > > > > > > 'powerd' is now operational: > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500^M > > > > Try booting with the GENERIC kernel, you should see one or two of the > > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > > > > This has always been the /GENERIC kernel copied to a custome name. > This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't > considered as a default entry in the /GENERIC. > > > > > > > > sysctl hw.acpi ... > > > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S3 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > hw.acpi.verbose: 0 > > > > hw.acpi.disable_on_reboot: 0 > > > > hw.acpi.handle_reboot: 0 > > > > hw.acpi.reset_video: 0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > hw.acpi.battery.life: 100 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 1 > > > > hw.acpi.battery.info_expire: 5 > > > > hw.acpi.acline: 1 > > > > hw.acpi.thermal.min_runtime: 0 > > > > hw.acpi.thermal.polling_rate: 10 > > > > hw.acpi.thermal.user_override: 0 > > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > > hw.acpi.thermal.tz0.active: -1 > > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > > hw.acpi.thermal.tz0._PSV: -1 > > > > hw.acpi.thermal.tz0._HOT: -1 > > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > > overrides .. but it might all just work with the GENERIC kernel anyway. > > > Attempting to: --> sysctl hw.acpi.thermal.user_override > hw.acpi.thermal.user_override: 0 > Attempting to: --> sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling > hw.acpi.thermal.tz0.passive_cooling: 0 > Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.tz0.passive_cooling: 0 > sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported > by device > > NOTE: While we are able to change the threshold for: > hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because > the above passive_cooling is not enabled. > > Well, so much for passive_cooling. :=\ > > > > Also, have you set anything in BIOS regarding power usage, speedstep or > > > any other settings that might get reflected into your boot ACPI setup? > > Initially we left the BIOS power settings the way the OEM set them > (Vista). We are able to choose from one of Dynamic, High or low > not much else to play with in the way of power settings (ACPI) > with the exception of LCD and/or letting the OS control devices. > Unable to directly set CPU steppings/freq settings within this BIOS. > > > > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > > this, but may at least provide some useful info in its sysctls .. > > > > > > This is an issue revisited; take a deep breath. Better yet, here's > the short version, in the kernel 'device acpi_toshiba' does not work > for us on this machine unless we neglected to make an accompanying > needed acpi entry. Aa we understand it, we were to only add 'device > acpi_toshiba' to load the neccessary acpi toshiba extras. > > Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using > 'kldload acpi_toshiba' from the cli works like a charm but has no > positive affect on the current discussion (heat). > > > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > > exactly what it's doing re shifting CPU frequency under various loads. > > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M > ^Ctotal joules used: 41737.500 > > > > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. > > The following data is the result of the concerns I have; running too > hot. These figures are the lowest temperatures this machine idles > while FreeBSD is installed and running. The temperatures shown > herein only rise with use but never go lower than what we're showing > here when the laptop returns to idle. > > Attempting to: --> sysctl hw.acpi.thermal.tz0. > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 102.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > > (so far) when you apply or remove AC power, using the following values > > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > > economy_cpu_freq="HIGH" # Offline CPU frequency > > Our /etc/defaults/rc.conf > > performance_cx_lowest="HIGH" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > > > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > > variables to HIGH, LOW, a specific value, or NONE. > > Attempting to: --> sysctl hw.acpi.cpu.cx_supported > sysctl: unknown oid 'hw.acpi.cpu.cx_supported' > Attempting to: --> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_lowest: C1 > > Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' > probe something? > > Attempting to: --> sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 > 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 > 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 > > Following is grepped from /var/run/dmesg.boot: > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz > 686-class CPU) > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > > > Our /etc/rc.conf > > performance_cx_lowest="C4" # Online CPU idle state > #performance_cpu_freq="HIGH" # Online CPU frequency > economy_cx_lowest="C5" # Offline CPU idle state > #economy_cpu_freq="HIGH" # Offline CPU frequency > > This machine can afford to go to C4 and C5 unless needed otherwise. > I'll try anything to lowwer this machines temp. > > > > > This is another issue in addition to the heat. As you say, this battery > > > > should last any where from 2-3 hours, however as it is now; > > > > out-of-the-box so to speak, this machine will only stay powered up > > > > approximately 1-hour on using the oem battery. > > > > > > That's because it runs at (presumably) its maximum frequency all of the > > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. > > These numbers have not changed (lowwer) prior to or during this thread. > > Attempting to: --> sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. > Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 61.0C > > > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > > and control this beast of a machine if possible. > > > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > > now provided that information. > > > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > > is not subject to any of the dual-core issues solved or being actively > > > worked on in freebsd-acpi and being applied mostly or at least firstly > > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > > last few months, it's not that big .. that is, if using the GENERIC > > > kernel and running powerd doesn't improve matters sufficiently. > > > > > > cheers, Ian > > > > > > > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" From owner-freebsd-mobile@FreeBSD.ORG Mon Sep 1 00:13:16 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11D45106566B for ; Mon, 1 Sep 2008 00:13:16 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7FACF8FC21 for ; Mon, 1 Sep 2008 00:13:15 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (unknown [74.193.170.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id A33A38F0253B; Sun, 31 Aug 2008 19:13:12 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.2/8.14.2) with ESMTP id m810D9lD057060; Sun, 31 Aug 2008 19:13:10 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Sun, 31 Aug 2008 19:13:09 -0500 (CDT) From: Wes Morgan To: freebsd_user@guice.ath.cx In-Reply-To: <20080831223722.GC2191@WORKSTATION.guice.ath.cx> Message-ID: References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> <20080831223722.GC2191@WORKSTATION.guice.ath.cx> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-mobile@freebsd.org Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 00:13:16 -0000 On Sun, 31 Aug 2008, freebsd_user@guice.ath.cx wrote: > In addition to the above URL, other findings: > > hw.acpi.toshiba.cpu_speed=7 > hw.acpi.toshiba.force_fan=1 > hw.acpi.thermal.min_runtime=30 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - > # this value is bogus > > hw.acpi.thermal.tz0.active: -1 # Can not change > hw.acpi.thermal.tz0.passive_cooling: 0 # Can not change > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV=10.0C # passive_cooling will- > # activate @ this temp. > # Above, passive_cooling > # currently N/A. Have you tried 7.0 instead of 6.3? I can't think of any compelling reason to stick with 6.x on a laptop. > With that being said, please allow me this one (1) rhetorical > question; how is a common end-user supposed to keep his machine > running and maintain her/his sanity chasing after issues such as > we've discussed here? When dealing with a piece of hardware that was designed from the ground up with only Microsoft Windows XP or even Vista in mind, I would say that we're doing pretty well. That the two frequencies for each core disagree, could be simply rounding difference or the core may actually report differently, as you may notice that your true frequency is not 2200mhz. The ACPI temperature may be measured in a different location than the "coretemp". On my system there is not even a sysctl for the frequency of the second core. I imagine that setting each core to a different frequency could be advantageous if the scheduler was able to take advantage of this, but I wonder if some applications might be adversely effected. I would try installing 7-stable and rerunning the tests, perhaps posting the results with slightly less verbosity as each message is becoming inordinately long and cluttered with too much information. From owner-freebsd-mobile@FreeBSD.ORG Mon Sep 1 05:22:40 2008 Return-Path: Delivered-To: mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C0E106569B for ; Mon, 1 Sep 2008 05:22:40 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mh0.csub.edu (mh0.csub.edu [136.168.1.94]) by mx1.freebsd.org (Postfix) with ESMTP id DA40F8FC24 for ; Mon, 1 Sep 2008 05:22:40 +0000 (UTC) (envelope-from raj@csub.edu) Received: from [192.168.1.148] (adsl-75-15-224-71.dsl.bkfd14.sbcglobal.net [75.15.224.71]) (authenticated bits=0) by mh0.csub.edu (8.13.8/8.13.8) with ESMTP id m814pS7b075230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2008 21:51:29 -0700 (PDT) (envelope-from raj@csub.edu) Message-ID: <48BB74CB.4000401@csub.edu> Date: Sun, 31 Aug 2008 21:51:23 -0700 From: Russell Jackson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20071103 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Josh Paetzel References: <200808300950.51698.josh@tcbug.org> In-Reply-To: <200808300950.51698.josh@tcbug.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mobile@freebsd.org Subject: Re: Heat issues on the IBM/Lenovo T60 resolved X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 05:22:41 -0000 Josh Paetzel wrote: > I've been relatively happy with my T60, with the exception of the heat issues > it's had since day one. The fan would run full out pretty much all the time, > and it would frequently reach 99-100C when doing anything cpu intensive, > regardless of OS. If there was any obstruction to the air vents it would > shutdown due to overheating. > > It turns out this is not an uncommon problem with the T60/T61, people either > complain of them being loud, or too hot, or sometimes both. > > After going down the road of OS tweaks and BIOS flashes I started burning up > phone lines at Lenovo, and I was finally able to talk to someone who said > they had some assembly problems that resulted in far too much thermal paste > being applied to the cpu and heatsink. > > So, I disassembled my laptop, and sure enough, the thermal paste was applied > much like a 3 year old applies grape jelly to a sandwich. I cleaned the > heatsink, cpu, and gpu and applied some generic thermal paste I found at Best > Buy. (caveat: The GPU uses a thermal pad that accomodates cooling the > memory chips, which are at a different height. I cut out the area where the > GPU makes contact and used thermal paste there, leaving the rest of the > thermal pad in place to contact the ram) > > Upon reassembly I loaded up both cores with make buildworld and cpuburn, and > initially feared I had damaged the fan speed sensor, as FreeBSD reported 0 > rpm. The cpu temps very slowly climbed to 60C, where the fan spun up to a > nearly inaudible 2000 rpm > > If I leave it at full CPU utilization the fan will eventually spin up to > 3000rpm, and temps stabilize at 66-69C. Under normal use the fan rarely > runs, a welcome change from it running full out all the time, especially on > battery. > > I have a friend that was having similar problems with his T61, and has had > similar success after reapplying the thermal paste. > > Fow what it's worth, Lenovo said the issue was covered under warranty, I just > disn't feel like going through the hassle of shipping the laptop to them. > Apple had the exact same issue with the Mac Books when they first came out. I just ordered a t400 yesterday (very giddy about getting rid of my Dell Inspiron POS). I'm hoping it'll just work right out of the box without having to disassemble it first. Thanks for the data point. -- Russell A. Jackson Network Analyst California State University, Bakersfield Memory fault -- brain fried From owner-freebsd-mobile@FreeBSD.ORG Mon Sep 1 14:59:37 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A91E1065675 for ; Mon, 1 Sep 2008 14:59:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id E43608FC1F for ; Mon, 1 Sep 2008 14:59:36 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id m81ExPFJ018529; Tue, 2 Sep 2008 00:59:26 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 2 Sep 2008 00:59:25 +1000 (EST) From: Ian Smith To: Wes Morgan In-Reply-To: Message-ID: <20080902001541.G12899@sola.nimnet.asn.au> References: <489E9531.2090200@guice.ath.cx> <20080825025833.GB3301@WORKSTATION.guice.ath.cx> <20080826002657.B14827@sola.nimnet.asn.au> <20080825191804.GA6846@WORKSTATION.guice.ath.cx> <20080826182124.O14827@sola.nimnet.asn.au> <20080830210736.GA4521@WORKSTATION.guice.ath.cx> <20080831223722.GC2191@WORKSTATION.guice.ath.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd_user@guice.ath.cx, freebsd-mobile@freebsd.org Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 14:59:37 -0000 On Sun, 31 Aug 2008, Wes Morgan wrote: > On Sun, 31 Aug 2008, freebsd_user@guice.ath.cx wrote: [..] > > hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - > > # this value is bogus [..] > Have you tried 7.0 instead of 6.3? I can't think of any compelling reason to > stick with 6.x on a laptop. Indeed. Getting a bit bored with this, I hunted back through the -acpi archives tonight to find the exact issue .. a refresh cycle for failing memory :) http://lists.freebsd.org/pipermail/freebsd-acpi/2008-January/thread.html has several mentions of this: the PR+patch, tested, MFC'd to 7-STABLE: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-January/004380.html http://lists.freebsd.org/pipermail/freebsd-acpi/2008-January/004441.html among others, and especially: http://www.freebsd.org/cgi/query-pr.cgi?pr=114722 [..] > I would try installing 7-stable and rerunning the tests, perhaps posting the > results with slightly less verbosity as each message is becoming inordinately > long and cluttered with too much information. Too right. I expect that the chances of interesting anyone to work on merging much of the recent ACPI work back into the 6.X tree are fairly close to zero. That's all from me on this one .. cheers, Ian From owner-freebsd-mobile@FreeBSD.ORG Thu Sep 4 10:13:29 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBF82106564A for ; Thu, 4 Sep 2008 10:13:29 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 3A79D8FC21 for ; Thu, 4 Sep 2008 10:13:29 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from [91.76.105.49] (helo=kibab-nb) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1KbBbH-0006hu-Sk for freebsd-mobile@freebsd.org; Thu, 04 Sep 2008 13:58:04 +0400 Date: Thu, 4 Sep 2008 09:57:51 +0400 From: Ilya Bakulin To: freebsd-mobile@freebsd.org Message-Id: <20080904095751.bfd489b7.webmaster@kibab.com> In-Reply-To: <20080710171907.GG1106@snobol> References: <20080710171907.GG1106@snobol> Organization: HT-Systems X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__4_Sep_2008_09_57_51_+0400_qeBrJMSY1CVyOs+I" Subject: Re: [sarumont@sigil.org: Re: fprint (finger print sensor framework) port ready for testing] X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2008 10:13:29 -0000 --Signature=_Thu__4_Sep_2008_09_57_51_+0400_qeBrJMSY1CVyOs+I Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 10 Jul 2008 12:19:07 -0500 Richard Kolkovich wrote: > Forgot to reply to all... >=20 > ----- Forwarded message from Richard Kolkovich ----- >=20 > Date: Thu, 10 Jul 2008 10:19:09 -0500 > From: Richard Kolkovich > To: Simon Barner > Subject: Re: fprint (finger print sensor framework) port ready for testing > User-Agent: Mutt/1.5.17 (2007-11-01) >=20 > On Mon, Apr 14, 2008 at 08:07:40PM +0200, Simon Barner wrote: > > Hi, > >=20 > > I did a port [2] of the fprint finger print sensor framework [1] > > and would like to receive some feedback before I commit it. > >=20 > > It comes with a PAM module for finger print based authentication, a > > graphical (fprint_demo) and a console (pam_fprint_enroll) application > > for finger print enrollment. > >=20 > > I did my tests with the UPEK sensor found in Lenovo's T61. > >=20 > > Simon > >=20 > > (M'fup2 ports@) > >=20 > > [1] http://www.reactivated.net/fprint/wiki/Main_Page > > [2] http://home.leo.org/~barner/freebsd/fprint.tar.gz > >=20 > > --=20 > > Best regards / Viele Gr??e, barner@FreeBSD.= org > > Simon Barner barner@gmx= .de >=20 >=20 > Anyone had success with this on the T43p? fprint_demo doesn't detect any= devices. The kernel sees it as follows: >=20 > ugen0: on uhub2 >=20 > From the looks of it, the STM device is not supported by fprint, but I ca= n't find anything online that confirms or denies this. >=20 > Thanks, >=20 > --=20 >=20 > Richard Kolkovich > sarumont@sigil.org >=20 >=20 >=20 > ----- End forwarded message ----- >=20 > --=20 >=20 > Richard Kolkovich > sarumont@sigil.org >=20 Just want to confirm, fprint-* ports work OK on Dell Vostro 1310: ugen1: on uhub0 kibab@kibab-nb%usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 addr 2: full speed, power 100 mA, config 1, Biometric Coprocessor(0= x2016), STMicroelectronics(0x0483), rev 0.01 After adding devfs rules and enrolling fingerprints PAM module works like a= charm, thanks :-) --=20 Ilya Bakulin --Signature=_Thu__4_Sep_2008_09_57_51_+0400_qeBrJMSY1CVyOs+I Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAki/eOcACgkQo9vlj1oadwg0KQCfYPymGggdbx71Cw54AqmmtLvM L5IAnjpTlmwDL5WZ5axTLSEyngCTTSF4 =ot5c -----END PGP SIGNATURE----- --Signature=_Thu__4_Sep_2008_09_57_51_+0400_qeBrJMSY1CVyOs+I-- From owner-freebsd-mobile@FreeBSD.ORG Fri Sep 5 17:42:39 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F20F51065671 for ; Fri, 5 Sep 2008 17:42:39 +0000 (UTC) (envelope-from engywook@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 84E458FC12 for ; Fri, 5 Sep 2008 17:42:38 +0000 (UTC) (envelope-from engywook@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so773061fgb.35 for ; Fri, 05 Sep 2008 10:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=utrauF+qcw1A9625k/jzu1I6pNsacAPF4zflThVs6N0=; b=QdbwIncNdM6ztU+JQN0w7efuQkVzkqdD13fsiI6TzGDW7XqZmANvZKVQAqapVU9BYy D0zMvXe7D1Mha+DBWFsa7I3COE5Rk0d0886UAo6a6Lfwztne/78UQA0mq0eYoGZJA7sO hCQ0JZvPCSlj4Afc+P6Qy1bDpeWRWwESuXXxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=ZaTf5m6q4Y2MpUUmGRKbr/o9pnBp119OZ4pz+Jh/CyV5c0DhVwfOSLPhwMwsYsRnoW W/OmazFpfZqJd0FNi4oNVEk33lxT90QDNjCOQARt0X+/4lkBiTw6l2VtLcHmw2OwxMiv W6XMvSNy9vnBQa+myZQTM0XSAy+EQSZXTXsuw= Received: by 10.181.4.17 with SMTP id g17mr9393764bki.67.1220635031430; Fri, 05 Sep 2008 10:17:11 -0700 (PDT) Received: by 10.181.2.12 with HTTP; Fri, 5 Sep 2008 10:17:11 -0700 (PDT) Message-ID: <24adbbc00809051017s7817323dj8e2454a78228a578@mail.gmail.com> Date: Fri, 5 Sep 2008 19:17:11 +0200 From: "Daniel Andersson" To: freebsd-mobile@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ral0: device timeout X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 17:42:40 -0000 Hi! I tried to set up my ral nic as an AP. It doesn't work though, I get: "engy# dmesg | tail ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout ral0: device timeout" I read found some posts and a bug report (misc/117655) with the same problem I'm having but they didn't get any replies so I'm trying here. Here's a link to a bug report: http://freebsd.monkey.org/freebsd-bugs/200710/msg00374.html I'm running 7.0 Release. "engy# vmstat -i interrupt total rate irq16: em0 66100435 54 irq17: em1 938188957 780 irq18: ral0+ 32773446 27 irq20: ohci0+ 182929022 152 cpu0: timer 2404332470 1999 Total 3624324330 3014" Is there anything I can do? Upgrade to stable or current? Thanks! Daniel Andersson From owner-freebsd-mobile@FreeBSD.ORG Fri Sep 5 21:05:27 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503AF106564A for ; Fri, 5 Sep 2008 21:05:27 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7048FC1C for ; Fri, 5 Sep 2008 21:05:26 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K6Q00DTYNT02D70@osl1smout1.broadpark.no> for freebsd-mobile@freebsd.org; Fri, 05 Sep 2008 22:05:24 +0200 (CEST) Received: from kg-work.kg4.no ([80.202.72.251]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K6Q006MTNT02HA1@osl1sminn1.broadpark.no> for freebsd-mobile@freebsd.org; Fri, 05 Sep 2008 22:05:24 +0200 (CEST) Date: Fri, 05 Sep 2008 22:05:23 +0200 From: Torfinn Ingolfsen To: freebsd-mobile@freebsd.org Message-id: <20080905220523.3170d480.torfinn.ingolfsen@broadpark.no> In-reply-to: <24adbbc00809051017s7817323dj8e2454a78228a578@mail.gmail.com> References: <24adbbc00809051017s7817323dj8e2454a78228a578@mail.gmail.com> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ral0: device timeout X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 21:05:27 -0000 On Fri, 05 Sep 2008 19:17:11 +0200 Daniel Andersson wrote: > I tried to set up my ral nic as an AP. It doesn't work though, I get: Do you have any timeouts if you run the card as a normal interface? > Here's a link to a bug report: > http://freebsd.monkey.org/freebsd-bugs/200710/msg00374.html This link works better: http://www.freebsd.org/cgi/query-pr.cgi?pr=117655 -- Regards, Torfinn Ingolfsen From owner-freebsd-mobile@FreeBSD.ORG Sat Sep 6 11:32:00 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 091601065670 for ; Sat, 6 Sep 2008 11:32:00 +0000 (UTC) (envelope-from engywook@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 93FAE8FC25 for ; Sat, 6 Sep 2008 11:31:59 +0000 (UTC) (envelope-from engywook@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so566374fkk.11 for ; Sat, 06 Sep 2008 04:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=9rZ3NILlAnahDng2SJGJeRhwf+upxKf6GQvwU8bQ5Xk=; b=iJSf1S83A5sYZQpETP5xxDmrnLnveYsk8wXzomOt+MmuxKKwuE8RkAqbQfJuPjQJFt C2CZOvMVioWL89PUjWAMmf/fKBi4rbTOjRblzgsMBs9bZuTzLellLku/f6f1lYsNvkQs harNKI141F4EjTWcAJDIJ4qm4fPNJExWWh9L0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=pGlAyoPTLS90B2ncXRCSZ1mgTIZxyYDpipnnNxuOom8zdcUw7D4zLNBYh6d5HmceKT mZWfcreqpuDaDts0QoeQbXBek/OhVy29aseq6n0jmP6ARDwell56uhK9C6vzEu+wDRmF FgtEfo586cpXbyxks00pAguxG/tb0/BCCd6Yg= Received: by 10.181.13.19 with SMTP id q19mr9774974bki.102.1220700717970; Sat, 06 Sep 2008 04:31:57 -0700 (PDT) Received: by 10.181.2.12 with HTTP; Sat, 6 Sep 2008 04:31:57 -0700 (PDT) Message-ID: <24adbbc00809060431i7394f312md63b1d2f396fa27a@mail.gmail.com> Date: Sat, 6 Sep 2008 13:31:57 +0200 From: "Daniel Andersson" To: freebsd-mobile@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: ral0: device timeout X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 11:32:00 -0000 >Do you have any timeouts if you run the card as a normal interface? No. I don't have access to any other AP's though so I haven't really been able to test it. > This link works better: > http://www.freebsd.org/cgi/query-pr.cgi?pr=117655 Hmm. Might be power related. The current PSU is 300W iirc. The only things connected to the box are 3 hdds, 3 nics and a geforce 2 MX. It should be able to handle it? Thanks for the reply! Daniel