Re: System extremely slow under light load
As the processor gets hotter, internal clocks and so on are throttled within the hardware to try and stabilise the temperature (to keep the thermal trip point being reached, re: emergency shutdown), which greatly decreases performance. I'm not sure if there's a way to detect this, but I would hope (?) that it would be visible via the CPU clock frequency (on FreeBSD this would be sysctl dev.cpu.X.freq). sysctl dev.cpu.X.freq is used to set the frequency. I have not found any way to read back its internal state so far. If you boot into another operating system such as Linux or Windows, do you see the same overall behaviour? Linux might be easier and might have some built-in way to get at CPU temperatures (via /proc?). I will download a Linux ISO and give it a try. The machine currently has FreeBSD and nothing else installed on it. Trying to figure out if this is a FreeBSD issue or not is difficult. Can you please provide: - Contents of rc.conf # Console keymap=german.iso # Set German keyboard map # Network hostname=taiko.lan# Set hostname to taiko.lan ifconfig_re0=DHCP # Configure wired Ethernet via DHCP # Daemons powerd_enable=YES # Run powerd to lower our power usage sshd_enable=YES # Run the SSH daemon moused_enable=YES # Run the mouse daemon dbus_enable=YES # Run the D-Bus daemon hald_enable=YES # Run the HAL daemon webcamd_enable=YES# Run the webcam daemon cupsd_enable=YES # Run the CUPS printer daemon # Miscellaneous clear_tmp_enable=YES # Clear /tmp at startup devfs_system_ruleset=local# Apply the local ruleset to /dev # PostgreSQL postgres_enable=YES # Run the PostgreSQL server - sysctl -a 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: NONE 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.acline: 1 hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 26.8C 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: 100.0C hw.acpi.thermal.tz0._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 0.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 95.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 100.0C hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 0 hw.acpi.thermal.tz1._TC2: 2 hw.acpi.thermal.tz1._TSP: 10 - sysctl -a dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 82.0C dev.cpu.0.freq: 1333 dev.cpu.0.freq_levels: 1734/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 816/23233 699/19914 583/16595 466/13276 349/9957 233/6638 116/3319 dev.cpu.0.cx_supported: C1/3 C2/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 285us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 82.0C dev.cpu.1.cx_supported: C1/3 C2/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 383us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 82.0C dev.cpu.2.cx_supported: C1/3 C2/245 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% last 238us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 82.0C dev.cpu.3.cx_supported: C1/3 C2/245 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% last 187us dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=\_PR_.CPU4 dev.cpu.4.%pnpinfo: _HID=none _UID=0 dev.cpu.4.%parent: acpi0 dev.cpu.4.temperature: 82.0C dev.cpu.4.cx_supported: C1/3 C2/245 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% 0.00% last 426us dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=\_PR_.CPU5 dev.cpu.5.%pnpinfo: _HID=none _UID=0 dev.cpu.5.%parent: acpi0 dev.cpu.5.temperature: 82.0C
Re: System extremely slow under light load
On Mon, 25 Apr 2011, Bartosz Fabianowski wrote: [Jeremy wrote:] As the processor gets hotter, internal clocks and so on are throttled within the hardware to try and stabilise the temperature (to keep the thermal trip point being reached, re: emergency shutdown), which greatly decreases performance. I'm not sure if there's a way to detect this, but I would hope (?) that it would be visible via the CPU clock frequency (on FreeBSD this would be sysctl dev.cpu.X.freq). sysctl dev.cpu.X.freq is used to set the frequency. I have not found any way to read back its internal state so far. dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed. Jeremy's right, it's running very hot, probably 20C too hot. I was just going to mention a couple of things you could try when it began to seem all too familiar .. a bit of hunting found your previous overheating problems on a Dell Studio 1557 from April last year: http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006415.html and your eventual apparent solution which included some fiddling with thermal parameters but primarily by disabling p4tcc and acpi_throttle hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 in loader.conf; I'm surprised you haven't tried that again on this one? hw.acpi.cpu.cx_lowest: C1 See below. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 26.8C 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: 100.0C hw.acpi.thermal.tz0._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a machine with CPU temp. at 82C could possibly be as low as 26.8C, so this value is likely as bogus as the 0.0C CPU reported by tz1. This fan should come on at 55C and run fastest above 71C. If your CPU is at 82C and the fan isn't running flat out, it'd overheat for sure. tz0.active is -1, not running - but maybe the BIOS is controlling it? hw.acpi.thermal.tz1.temperature: 0.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 95.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 100.0C hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 0 hw.acpi.thermal.tz1._TC2: 2 hw.acpi.thermal.tz1._TSP: 10 _ACx is N/A here, unless there's a separate CPU fan? Anyway at bogus 0.0C it's never going to trigger passive or active cooling. You said before that with the fixed DSDT to get proper temperature reading here, it shut down due to over temperature, which of course it should .. does that fixed DSDT include fixing detected tz0 temperature .. if so the fan might behave itself without having to use .thermal.user_override=1 dev.cpu.0.temperature: 82.0C dev.cpu.0.freq: 1333 Are you limiting it to 1333 manually, or with powerd's -M switch? dev.cpu.0.freq_levels: 1734/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 816/23233 699/19914 583/16595 466/13276 349/9957 233/6638 116/3319 Clearly including p4tcc and/or acpi_throttle N*12.5% rates; compare to dev.est.0.freq_settings below to figure the freqs added by throttling. Hopefully this machine will respond as well to disabling both methods as your earlier one, as you reported here (same subject, later thread): http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006443.html The more I review those threads, the more it seems likely that this is your main problem on this one too. dev.cpu.0.cx_supported: C1/3 C2/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 285us Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 Latency 245us isn't long compared to the delays you're experiencing :) dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed. From what I have seen, dev.cpu.X.freq always retains the value I set it to. Internal CPU throttling does not seem to be reported this way. a bit of hunting found your previous overheating problems on a Dell Studio 1557 from April last year: and your eventual apparent solution which included some fiddling with thermal parameters but primarily by disabling p4tcc and acpi_throttle Yes, that thread described the issues I had with my previous laptop before Dell exchanged it. I never posted an actual solution as I never found one. The problem only went away because the laptop went away. Disabling p4tcc and acpi_throttle may have seemed to address the problems at first - but longer-term evaluation showed that the issues persisted unchanged. hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 I just tried this on my current Dell Studio 1558, with devastating results. The first boot attempt ended with the machine shutting down due to overheating while loading the kernel. I let it cool down a bit and then booted again. This time, I got to my desktop - with a CPU temperature of 95°C. If the DSDT was fixed, the machine would have shut down at this point. I only got down the temperature by reducing the maximal temperature to 1.2GHz again. With the above settings, the machine is idling at 80°C now and very sluggish - some internal throttling appears to be active again. tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a machine with CPU temp. at 82C could possibly be as low as 26.8C, so this value is likely as bogus as the 0.0C CPU reported by tz1. Yes, the 26.8°C is bogus. It never changes. Unfortunately, I have not found a way to fix this reading. The two thermal zones are implemented very differently in the DSDT and I have only managed to fix tz1. However, there is no second fan inside the laptop. I have taken it apart down to the last screw. There is one fan only and that corresponds to tz0. This fan should come on at 55C and run fastest above 71C. If your CPU is at 82C and the fan isn't running flat out, it'd overheat for sure. tz0.active is -1, not running - but maybe the BIOS is controlling it? Yes, the BIOS appears to control the fan. The thresholds exposed via ACPI seem to be purely informative. Whether I fix the DSDT so that temperature readings work or not, the fan turns on at 55°C and speeds up at 71°C. It never spins down again after that as the CPU keeps running very hot. _ACx is N/A here, unless there's a separate CPU fan? Anyway at bogus 0.0C it's never going to trigger passive or active cooling. You said before that with the fixed DSDT to get proper temperature reading here, it shut down due to over temperature, which of course it should .. does that fixed DSDT include fixing detected tz0 temperature .. if so the fan might behave itself without having to use .thermal.user_override=1 See above: Fixing the DSDT makes tz1 work. tz0 remains broken. Are you limiting it to 1333 manually, or with powerd's -M switch? I have tried both. It appears to make no difference whether I use powerd -M or just set dev.cpu.0.freq directly. Clearly including p4tcc and/or acpi_throttle N*12.5% rates; compare to dev.est.0.freq_settings below to figure the freqs added by throttling. Hopefully this machine will respond as well to disabling both methods as your earlier one, as you reported here (same subject, later thread): See above: Unfortunately, the machine did nor respond well at all. Instead, it is overheating even worse. Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 I have set dev.cpu.X.cx_lowest=C2 at run-time. If I understand correctly, this should achieve the same effect. The CPU does not seem to ever make it to C2 though, even after I enable it: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 270us dev.cpu.1.cx_usage: 100.00% 0.00% last 399us dev.cpu.2.cx_usage: 100.00% 0.00% last 403us dev.cpu.3.cx_usage: 100.00% 0.00% last 404us dev.cpu.4.cx_usage: 100.00% 0.00% last 323us dev.cpu.5.cx_usage: 100.00% 0.00% last 313us dev.cpu.6.cx_usage: 100.00% 0.00% last 174us dev.cpu.7.cx_usage: 100.00% 0.00% last 137us dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels. Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85°C, 1999 leads to 78-80°C. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
Re: System extremely slow under light load
On Apr 25, 2011 6:28 AM, Ian Smith smi...@nimnet.asn.au wrote: On Mon, 25 Apr 2011, Bartosz Fabianowski wrote: [Jeremy wrote:] As the processor gets hotter, internal clocks and so on are throttled within the hardware to try and stabilise the temperature (to keep the thermal trip point being reached, re: emergency shutdown), which greatly decreases performance. I'm not sure if there's a way to detect this, but I would hope (?) that it would be visible via the CPU clock frequency (on FreeBSD this would be sysctl dev.cpu.X.freq). sysctl dev.cpu.X.freq is used to set the frequency. I have not found any way to read back its internal state so far. dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed. Jeremy's right, it's running very hot, probably 20C too hot. I was just going to mention a couple of things you could try when it began to seem all too familiar .. a bit of hunting found your previous overheating problems on a Dell Studio 1557 from April last year: http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006415.html and your eventual apparent solution which included some fiddling with thermal parameters but primarily by disabling p4tcc and acpi_throttle hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 in loader.conf; I'm surprised you haven't tried that again on this one? hw.acpi.cpu.cx_lowest: C1 See below. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 26.8C 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: 100.0C hw.acpi.thermal.tz0._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a machine with CPU temp. at 82C could possibly be as low as 26.8C, so this value is likely as bogus as the 0.0C CPU reported by tz1. I am not sure tz0 is the real thermal zone, especially given values of _tc1, _tc2 and _tsp. Temperature value (3001) looks suspicious as well. Can you, by any chance, put your ASL someplace accessible and provide a description of what you have done to fix the temperature reporting. As the side note: I have seen and do own pieces of equipment that use thermal zones to initiate critical shutdown for various and unrelated reasons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
I am not sure tz0 is the real thermal zone, especially given values of _tc1, _tc2 and _tsp. Temperature value (3001) looks suspicious as well. I agree. tz0 looks entirely bogus. There is no second fan to control for it and I have no idea what it is supposed to be monitoring. Can you, by any chance, put your ASL someplace accessible and provide a description of what you have done to fix the temperature reporting. Certainly. I have uploaded the files at [1] through [5]. The DSDT source returned by acpidump -d is at [1]. I modified this so that it can be compiled back into AML without errors or warnings. This modified source is at [2]. It contains no functional changes. The thermal zones are still broken. A variant with fixed tz1 is at [3]. For convenience, I have also uploaded diffs between these source files. [4] is the diff required to make the source compile (difference between [1] and [2]). [5] is the actual change I made to fix tz1 (difference between [2] and [3]). As you can see, all I did was to remove a bogus function that ends up always returning 0°C. As the side note: I have seen and do own pieces of equipment that use thermal zones to initiate critical shutdown for various and unrelated reasons. In my case, the thermal zone and its various tripping points do correspond to the actual system fan. It is just that the BIOS enforces power management itself, ignoring ACPI - except for critical shutdown which appears to be triggered by ACPI only. - Bartosz [1] http://www.fabianowski.de/dsdt/decompiled.asl [2] http://www.fabianowski.de/dsdt/compilable.asl [3] http://www.fabianowski.de/dsdt/fixed.asl [4] http://www.fabianowski.de/dsdt/decompile_compilable.diff [5] http://www.fabianowski.de/dsdt/compilable_fixed.diff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, 25 Apr 2011, Bartosz Fabianowski wrote: [..] See above: Unfortunately, the machine did nor respond well at all. Instead, it is overheating even worse. Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 I have set dev.cpu.X.cx_lowest=C2 at run-time. If I understand correctly, this should achieve the same effect. The CPU does not seem to ever make it to C2 though, even after I enable it: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 270us dev.cpu.1.cx_usage: 100.00% 0.00% last 399us dev.cpu.2.cx_usage: 100.00% 0.00% last 403us dev.cpu.3.cx_usage: 100.00% 0.00% last 404us dev.cpu.4.cx_usage: 100.00% 0.00% last 323us dev.cpu.5.cx_usage: 100.00% 0.00% last 313us dev.cpu.6.cx_usage: 100.00% 0.00% last 174us dev.cpu.7.cx_usage: 100.00% 0.00% last 137us You need sysctl hw.acpi.cpu.cx_lowest=C2 instead .. that's what /etc/rc.d/power_profile adjusts when you apply or remove power. I doubt it's likely to help much given the scale of overheating. dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels. Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85°C, 1999 leads to 78-80°C. That's pretty sad. Not sure what the first two differing by only 1MHz means .. but I'm out of ideas, and my depth. cheers, Ian___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. I am still on the hunt for a bootable Linux distribution. I am in the unfortunate situation of having no CD-Rs at hand. And because it is Easter, shops are closed. Most Linux distributions require you to run a proprietary tool from inside Windows or another Linux installation to create a bootable USB medium. I found a USB image for OpenSUSE but that failed to boot. I am continuing to hunt... You need sysctl hw.acpi.cpu.cx_lowest=C2 instead .. that's what /etc/rc.d/power_profile adjusts when you apply or remove power. I doubt it's likely to help much given the scale of overheating. I use the correct sysctl now, the cx_lowest value changed from C1 to C2 for all CPUs but nothing seems to have changed otherwise: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 230us dev.cpu.1.cx_usage: 100.00% 0.00% last 216us dev.cpu.2.cx_usage: 100.00% 0.00% last 159us dev.cpu.3.cx_usage: 100.00% 0.00% last 323us dev.cpu.4.cx_usage: 100.00% 0.00% last 320us dev.cpu.5.cx_usage: 100.00% 0.00% last 357us dev.cpu.6.cx_usage: 100.00% 0.00% last 378us dev.cpu.7.cx_usage: 100.00% 0.00% last 374us That's pretty sad. Not sure what the first two differing by only 1MHz means .. but I'm out of ideas, and my depth. Thanks for all the tips. I will report back once I have had a chance to compare with Linux. If nothing else helps, I will call Dell again in the futile attempt to have them magically fix the issue somehow. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 04:03:49PM +0200, Bartosz Fabianowski wrote: Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. I am still on the hunt for a bootable Linux distribution. I am in the unfortunate situation of having no CD-Rs at hand. And because it is Easter, shops are closed. Most Linux distributions require you to run a proprietary tool from inside Windows or another Linux installation to create a bootable USB medium. I found a USB image for OpenSUSE but that failed to boot. I am continuing to hunt... Try Knoppix, or Ubuntu LiveCD. I tend to use the former for rescue situations: http://www.knopper.net/knoppix/index-en.html https://help.ubuntu.com/community/LiveCD Saves you from having to install anything as well. Don't expect good X performance, but even if it's software-driven that's still a good stress test for the CPU. Thanks for all the tips. I will report back once I have had a chance to compare with Linux. If nothing else helps, I will call Dell again in the futile attempt to have them magically fix the issue somehow. I'll be very surprised if Dell is of any assistance, as the last I checked they did not officially support FreeBSD (that's usually their statement). I think testing Linux and/or Windows will overall act as a better confirmation. I wish I knew what else to recommend too, or what else to check. :-( Folks familiar with ACPI tables might be able to shed some light on the situation, if it is indeed a problem there. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Try Knoppix, or Ubuntu LiveCD. I tend to use the former for rescue situations: Thanks. I am aware of both - but neither boots from USB (and I have no CD-Rs at hand). I am running UNetbootin under Windows XP in VirtualBox right now to try and get Xubuntu 10.04 onto a USB key. It is really sad that almost all Linux distributions require this detour via a proprietary operating system. I'll be very surprised if Dell is of any assistance, as the last I checked they did not officially support FreeBSD (that's usually their statement). I think testing Linux and/or Windows will overall act as a better confirmation. Absolutely, they do not support FreeBSD. But if the laptop overheats during normal usage, to me, the hardware is broken and needs to be fixed. So far, Dell have been very cooperative, sent out technicians several times and in the end provided me with a completely new laptop. Going by this previous experience, I expect them to send out a technician again and attempt a repair. I am doubtful it will actually fix anything though. I wish I knew what else to recommend too, or what else to check. :-( Folks familiar with ACPI tables might be able to shed some light on the situation, if it is indeed a problem there. I will be able to provide a comparison with Linux soon. This may be helpful. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 10:03 AM, Bartosz Fabianowski free...@chillt.dewrote: Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. I am still on the hunt for a bootable Linux distribution. I am in the unfortunate situation of having no CD-Rs at hand. And because it is Easter, shops are closed. Most Linux distributions require you to run a proprietary tool from inside Windows or another Linux installation to create a bootable USB medium. I found a USB image for OpenSUSE but that failed to boot. I am continuing to hunt... You need sysctl hw.acpi.cpu.cx_lowest=C2 instead .. that's what /etc/rc.d/power_profile adjusts when you apply or remove power. I doubt it's likely to help much given the scale of overheating. I use the correct sysctl now, the cx_lowest value changed from C1 to C2 for all CPUs but nothing seems to have changed otherwise: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 230us dev.cpu.1.cx_usage: 100.00% 0.00% last 216us dev.cpu.2.cx_usage: 100.00% 0.00% last 159us dev.cpu.3.cx_usage: 100.00% 0.00% last 323us dev.cpu.4.cx_usage: 100.00% 0.00% last 320us dev.cpu.5.cx_usage: 100.00% 0.00% last 357us dev.cpu.6.cx_usage: 100.00% 0.00% last 378us dev.cpu.7.cx_usage: 100.00% 0.00% last 374us That's pretty sad. Not sure what the first two differing by only 1MHz means .. but I'm out of ideas, and my depth. Thanks for all the tips. I will report back once I have had a chance to compare with Linux. If nothing else helps, I will call Dell again in the futile attempt to have them magically fix the issue somehow. - Bartosz ___ Please , see the site http://www.mandriva.com/en/linux/ My opinion is that Mandriva is a very good Linux distribution . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Please , see the site http://www.mandriva.com/en/linux/ Thanks for the link. It looks like this a USB with a preinstalled Mandriva Linux on it that you have to buy for €50 though. I am looking for an image that I can just download. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. I am still on the hunt for a bootable Linux distribution. I am in the unfortunate situation of having no CD-Rs at hand. And because it is Easter, shops are closed. Most Linux distributions require you to run a proprietary tool from inside Windows or another Linux installation to create a bootable USB medium. I found a USB image for OpenSUSE but that failed to boot. I am continuing to hunt... GRML ISOs (from grml.org) can be dd-ed directly to a USB stick and should then boot with any reasonable current BIOS. Regards Florian signature.asc Description: PGP signature
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 10:58 AM, Bartosz Fabianowski free...@chillt.dewrote: Please , see the site http://www.mandriva.com/en/linux/ Thanks for the link. It looks like this a USB with a preinstalled Mandriva Linux on it that you have to buy for €50 though. I am looking for an image that I can just download. - Bartosz There are downloadable free USB files , also . At the right of the page , http://www.mandriva.com/en/flash/ click the link 2009 Rescue iso , which will lead to http://dl1.mandriva.com/flash/rescue/2009.0/ Perhaps they may be useful . Also you may see : http://www.archlinux.org/download/ All available images can be burned to a CD, mounted as an ISO file, or be directly written to a USB stick using a utility like `dd`. http://mir.archlinux.fr/iso/latest/ Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
click the link 2009 Rescue iso , which will lead to http://dl1.mandriva.com/flash/rescue/2009.0/ Thanks. There is no mention anywhere on the page that the ISO files can be treated as USB boot images as well. Hence, I did not realize they would suit my needs. Also you may see : http://www.archlinux.org/download/ I know ArchLinux ISO files are also bootable from USB. However, Arch provides no LiveCD, just a simple installer. That said, I find Arch to be an excellent distribution. It just does not fit my particular needs at the moment. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
GRML ISOs (from grml.org) can be dd-ed directly to a USB stick and should then boot with any reasonable current BIOS. Thanks. It is great to see that so many ISOs can be dd-ed to USB keys. I wish the distributions would make it clearer which ISOs work as USB images and which do not. I am reluctant to download gigabytes of ISOs just to find that most do not work. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 11:18 AM, Bartosz Fabianowski free...@chillt.dewrote: click the link 2009 Rescue iso , which will lead to http://dl1.mandriva.com/flash/rescue/2009.0/ Thanks. There is no mention anywhere on the page that the ISO files can be treated as USB boot images as well. Hence, I did not realize they would suit my needs. Also you may see : http://www.archlinux.org/download/ I know ArchLinux ISO files are also bootable from USB. However, Arch provides no LiveCD, just a simple installer. That said, I find Arch to be an excellent distribution. It just does not fit my particular needs at the moment. - Bartosz Please , see : http://cdimage.debian.org/debian-cd/6.0.1-live/amd64/ http://cdimage.debian.org/debian-cd/6.0.1-live/i386/ By using dd , you may copy a hybrid .iso to USB stick . If you have USB HDD , also there are HDD .iso images in there . Previously , I copied an arbitrary .iso ( I do not remember which OS ) to a USB stick with dd , and it booted , and installed very well . My idea was to make an experiment about whether an .iso can be booted if it is recorded by dd into a USB stick . It was successful . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Date: Mon, 25 Apr 2011 23:58:39 +1000 (EST) From: Ian Smith smi...@nimnet.asn.au Sender: owner-freebsd-sta...@freebsd.org On Mon, 25 Apr 2011, Bartosz Fabianowski wrote: [..] See above: Unfortunately, the machine did nor respond well at all. Instead, it is overheating even worse. Sorry to hear none of that helped. It seems a very serious problem, and it would be useful to know if it behaves any better under linux or not. Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest=C2 economy_cx_lowest=C2 I have set dev.cpu.X.cx_lowest=C2 at run-time. If I understand correctly, this should achieve the same effect. The CPU does not seem to ever make it to C2 though, even after I enable it: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 270us dev.cpu.1.cx_usage: 100.00% 0.00% last 399us dev.cpu.2.cx_usage: 100.00% 0.00% last 403us dev.cpu.3.cx_usage: 100.00% 0.00% last 404us dev.cpu.4.cx_usage: 100.00% 0.00% last 323us dev.cpu.5.cx_usage: 100.00% 0.00% last 313us dev.cpu.6.cx_usage: 100.00% 0.00% last 174us dev.cpu.7.cx_usage: 100.00% 0.00% last 137us You need sysctl hw.acpi.cpu.cx_lowest=C2 instead .. that's what /etc/rc.d/power_profile adjusts when you apply or remove power. I doubt it's likely to help much given the scale of overheating. dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels. Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85°C, 1999 leads to 78-80°C. That's pretty sad. Not sure what the first two differing by only 1MHz means .. but I'm out of ideas, and my depth. As several have either discovered or pointed out, the dev.cpu.X.freq is telling you what FreeBSD is requesting, not what the CPU is actually doing. Particularly, if high temperatures cause TCC to kick in, this will not show up. IF you really want to monitor CPU temperature on an Intel CPU, use the coretemp kernel module. I use it on Intel systems that lack ACPI support for temperature monitoring. It uses a junction on the die, so it will be somewhat higher than the package temperature. TCC works by simply skipping 'n' out of 8 clock cycles. It really does not change the clock speed at all. Typically, only EST or the AMD equivalent actually does this. FreeBSD attempts to use TCC for power management, for which it was not intended. As has been repeatedly reported, it is of no use for this. I always recommend that it be turned off. But this has NO effect on its use for temperature management. So turning off TCC (or p4tcc, as it is called on FreeBSD) does nothing. TCC will automatically skip cycles when the _PSV temperature is exceeded. On some CPUs, this can be VERY high. My old Pentium-M ThinkPad starts throttling at 95C and will shut down at 99C. Compared to desktop systems, this is REALLY high, but the output you posted shows yours at 100C! I would assume that means that TCC should kick in at about 95 or 96C which does not entirely explain what you are seeing. Unfortunately, your system does not provide a value for _PSV, so I have no idea when it will actually kick in, but it should be in the data sheet for the CPU. If ACPI does not hange it, it runs in a purely automated fashion with no human intervention available. I wish I could provide some easy way to detect when it kicks in, but I don't think there is one. You can force it while monitoring performance. Try running md5 or sha256 on a bunch of random (/dev/random) data. Collect the time it takes to do a bunch of these and you will see it increase by .125 every time throttling adds another step to the pause time. It will be fairly dramatic and very close to steps of exactly .125 of the original time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
I have read all of the messages in succession . No one of the messages are mentioning which software is running . Please see my message as http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061672.html Please read that message and compare with your case . The above message is went as unnoticed , although the same problem is still valid in FreeBSD 9.0 Current amd64 snapshots by Nathan Whitehorn and PC-BSD 8.2 and 9.0 Current amd64 snapshots . The reason of slowness is as follows : I have started x by startx , then started KDE by startkde in xterm . The reason of slowness is the generated endless amount of error messages . The GNOME is also generating endless amount of error messages displayed on the xterm terminal when it is started from xterm after starting X . When KDE or GNOME is started by the .xinitrc or rc.conf , those messages are NOT seen , but it is exposing itself as a very slow execution steps . During generation of those messages , CPU and other fans fan are becoming crazy . I did not test i386 snapshots . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 02:45:14PM +0200, Bartosz Fabianowski wrote: dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed. From what I have seen, dev.cpu.X.freq always retains the value I set it to. Internal CPU throttling does not seem to be reported this way. ... I just tried this on my current Dell Studio 1558, with devastating results. The first boot attempt ended with the machine shutting down due to overheating while loading the kernel. I let it cool down a bit and then booted again. This time, I got to my desktop - with a CPU temperature of 95??C. If the DSDT was fixed, the machine would have shut down at this point. I could be wrong, but in my experience this really sounds like it is a hardware problem with the cooling system, and a very serious one at that. I would encourage you to take this up with Dell at once. While it's certainly possible that newer FreeBSD releases are failing to control the temperature as well as older ones due to some change, that does not mean that this is a FreeBSD problem - these temperatures are so far out of line that anything FreeBSD managed to do before should be viewed as an unexpectedly successful workaround. The only way I can see the core problem as OS-related is if the hardware design is relying on Windows-specific drivers to control the cooling system, which would be crazy though not impossible. ... Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85??C, 1999 leads to 78-80??C. Apart from your immediate problems, in my past experience this range of CPU temperatures is likely to lead to early failure of the CPU, very likely within a year or less. -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@volcano.org President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, 25 Apr 2011 16:23:37 +0200 Bartosz Fabianowski free...@chillt.de wrote: Try Knoppix, or Ubuntu LiveCD. I tend to use the former for rescue situations: Thanks. I am aware of both - but neither boots from USB (and I have no CD-Rs at hand). I am running UNetbootin under Windows XP in VirtualBox right now to try and get Xubuntu 10.04 onto a USB key. It is really sad that almost all Linux distributions require this detour via a proprietary operating system. Have you tried just using dd to copy the iso image of a Ubuntu / Linux LiveCD to a suitably sized USB memory stick? It has worked for me in the past. YMMV. -- Torfinn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 9:20 AM, Bartosz Fabianowski free...@chillt.de wrote:
I am not sure tz0 is the real thermal zone, especially given values
of _tc1, _tc2 and _tsp. Temperature value (3001) looks suspicious as
well.
I agree. tz0 looks entirely bogus. There is no second fan to control for it
and I have no idea what it is supposed to be monitoring.
Can you, by any chance, put your ASL someplace accessible and provide
a description of what you have done to fix the temperature
reporting.
Certainly. I have uploaded the files at [1] through [5].
The DSDT source returned by acpidump -d is at [1]. I modified this so that it
can be compiled back into AML without errors or warnings. This modified
source is at [2]. It contains no functional changes. The thermal zones are
still broken. A variant with fixed tz1 is at [3].
For convenience, I have also uploaded diffs between these source files. [4]
is the diff required to make the source compile (difference between [1] and
[2]). [5] is the actual change I made to fix tz1 (difference between [2] and
[3]). As you can see, all I did was to remove a bogus function that ends up
always returning 0°C.
As the side note: I have seen and do own pieces of equipment that
use thermal zones to initiate critical shutdown for various and
unrelated reasons.
In my case, the thermal zone and its various tripping points do correspond to
the actual system fan. It is just that the BIOS enforces power management
itself, ignoring ACPI - except for critical shutdown which appears to be
triggered by ACPI only.
Did you try to set OS override to any of the values, recognized by
your BIOS, with most interesting being Windows 2001 SP2, Windows
2006 and Windows 2009. There is no obvious impact on the thermal
part per se, but at least some of values seem to change the timer
configuration. You can change your OS name by setting
hw.acpi.osname=one of those strings in /boot/loader.conf
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html).
Additionally, could you, by any chance, replace _TMP method in TZ01
with the snippet below and let me know what the result is:
Method (_TMP, 0, Serialized)
{
If (LEqual (\_SB.PCI0.LPCB.EC0.EIDL, 0xDD))
{
Return (0x0BB8)
}
If (LAnd (DTSE, ETMD))
{
If (LGreater (\_SB.PCI0.LPCB.EC0.DTS2,
\_SB.PCI0.LPCB.EC0.DTS1))
{
Store (\_SB.PCI0.LPCB.EC0.DTS2, Local0)
}
Else
{
Store (\_SB.PCI0.LPCB.EC0.DTS1, Local0)
}
Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
}
If (LAnd (ECON, ETMD))
{
Acquire (\_SB.PCI0.LPCB.EC0.MUT0, 0x)
Store (\_SB.PCI0.LPCB.EC0.DTS1, Local0)
Release (\_SB.PCI0.LPCB.EC0.MUT0)
If (And (Local0, 0x80))
{
Subtract (Local0, 0x0100, Local0)
}
Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
}
Return (0x0BB8)
}
I assume, since you have already modified your ASL, you do realize all
of the pitfalls of this activity, including but not limited to turning
your laptop into molten blob of plastic ;)
- Bartosz
[1] http://www.fabianowski.de/dsdt/decompiled.asl
[2] http://www.fabianowski.de/dsdt/compilable.asl
[3] http://www.fabianowski.de/dsdt/fixed.asl
[4] http://www.fabianowski.de/dsdt/decompile_compilable.diff
[5] http://www.fabianowski.de/dsdt/compilable_fixed.diff
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Alexandre Sunny Kovalenko.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
If you boot into another operating system such as Linux or Windows, do you see the same overall behaviour? Linux might be easier and might have some built-in way to get at CPU temperatures (via /proc?). I finally found a working USB Linux image and have run some tests: Linux power management is quite different from FreeBSD. It clocks all cores at 933 MHz by default. When I start exercising the CPU, only the cores actually working hard get clocked up all the way to 1.7 GHz. This seems like a good idea but is not possible on FreeBSD right now as the only frequency sysctl is dev.cpu.0.freq. With the CPU idling at 933 MHz, the temperature is about 68°C. I am running FreeBSD with powerd -M 933 right now and the CPU is idling at 76°C while being clocked down to about 200 MHz most of the time. So Linux does something better here and manages to shave off about 10°C. As recommended by Kevin, I tried running md5 on a large chunk of data. I chose a Linux ISO file instead of /dev/random output to have reproducible input. Under FreeBSD, the machine currently is not sluggish and an md5 run completes in 5.7 seconds. I will retry the md5 experiment when the box becomes sluggish and will see whether I can detect TCC kicking in. Under Linux, the same md5 run took 12.6 seconds. This is surprising on the one hand as Linux clocked up all the way to 1.7 GHz while under FreeBSD, I was limiting the CPU to 1.199 GHz. On the other hand, Linux was running from a USB key while FreeBSD is properly installed. I tried running multiple copies of md5 in parallel to exercise multiple cores to the maximum under Linux. This actually made the temperature climb very quickly up to 95°-98°C. At 95°C, the fan audibly switched into a higher gear. I now remember that I have heard this under FreeBSD before as well. The fan seems to be controlled by the BIOS after all so when the CPU reaches 95°C, the BIOS turns up the fan, irrespective of the OS I am running. The great difference between FreeBSD and Linux was that I did not get any of the sluggishness and non-interactive response. Even under high load with a CPU temperature of 95°C and the fan in high gear, KDE was responsive and usable. I did have a few system stalls but according to the console, those were due to problems with reading from the USB key. There seemed to be no sudden breakdown of interactive performance even under load and thermal stress. So something is off under FreeBSD... - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Please , see : http://cdimage.debian.org/debian-cd/6.0.1-live/amd64/ http://cdimage.debian.org/debian-cd/6.0.1-live/i386/ By using dd , you may copy a hybrid .iso to USB stick . Thanks. I downloaded the amd64 image. It booted perfectly after copying to a USB key via dd. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
As several have either discovered or pointed out, the dev.cpu.X.freq is telling you what FreeBSD is requesting, not what the CPU is actually doing. Particularly, if high temperatures cause TCC to kick in, this will not show up. Yes, this is what I thought as well. IF you really want to monitor CPU temperature on an Intel CPU, use the coretemp kernel module. I use it on Intel systems that lack ACPI support for temperature monitoring. It uses a junction on the die, so it will be somewhat higher than the package temperature. Yes, I am using that module and monitoring the dev.cpu.X.temperature output. Technically, my system has support for ACPI monitoring but as I mentioned in earlier messages, the DSDT provided by Dell is broken. I would assume that means that TCC should kick in at about 95 or 96C which does not entirely explain what you are seeing. Unfortunately, your system does not provide a value for _PSV, so I have no idea when it will actually kick in, but it should be in the data sheet for the CPU. If ACPI does not hange it, it runs in a purely automated fashion with no human intervention available. I downloaded and read the specs. If I understand them correctly, the maximal junction temperature for this CPU is 100°C. TCC should kick in when any of the cores exceeds this value. It is unclear to me when exactly TCC deactivates again but if the diagrams in the documentation are drawn to scale, a pretty wide hysteresis is involved. So one explanation for what I am seeing may be this: One of the cores, for a split second, jumps over 100°C. TCC kicks in and does not turn off for a long while. During that time, the system feels sluggish and slow. Try running md5 or sha256 on a bunch of random (/dev/random) data. Collect the time it takes to do a bunch of these and you will see it increase by .125 every time throttling adds another step to the pause time. It will be fairly dramatic and very close to steps of exactly .125 of the original time. Thanks, I will be using that to try and determine whether it really is TCC that makes my machine sluggish under load. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
I could be wrong, but in my experience this really sounds like it is a hardware problem with the cooling system, and a very serious one at that. I would encourage you to take this up with Dell at once. Yes, I will. They have exchanged a lot of components already though (including the whole laptop) and so far, nothing has helped. While it's certainly possible that newer FreeBSD releases are failing to control the temperature as well as older ones due to some change, that does not mean that this is a FreeBSD problem - these temperatures are so far out of line that anything FreeBSD managed to do before should be viewed as an unexpectedly successful workaround. This box has been running FreeBSD 8 since day one. It always had trouble with high temperatures. But now that summer is coming and ambient temperatures are rising, the issue keeps getting worse. Apart from your immediate problems, in my past experience this range of CPU temperatures is likely to lead to early failure of the CPU, very likely within a year or less. Yes, I am afraid that may happen. Then again, Intel's data sheet clearly states that this CPU is designed to operate at up to 100°C. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Have you tried just using dd to copy the iso image of a Ubuntu / Linux LiveCD to a suitably sized USB memory stick? It has worked for me in the past. As per Mehmet's tip, I did just that with a Debian image. If it works for Ubuntu images as well then I really wonder why the only documented way is via Unetbootin. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Date: Tue, 26 Apr 2011 01:19:03 +0200 From: Bartosz Fabianowski free...@chillt.de As several have either discovered or pointed out, the dev.cpu.X.freq is telling you what FreeBSD is requesting, not what the CPU is actually doing. Particularly, if high temperatures cause TCC to kick in, this will not show up. Yes, this is what I thought as well. IF you really want to monitor CPU temperature on an Intel CPU, use the coretemp kernel module. I use it on Intel systems that lack ACPI support for temperature monitoring. It uses a junction on the die, so it will be somewhat higher than the package temperature. Yes, I am using that module and monitoring the dev.cpu.X.temperature output. Technically, my system has support for ACPI monitoring but as I mentioned in earlier messages, the DSDT provided by Dell is broken. I would assume that means that TCC should kick in at about 95 or 96C which does not entirely explain what you are seeing. Unfortunately, your system does not provide a value for _PSV, so I have no idea when it will actually kick in, but it should be in the data sheet for the CPU. If ACPI does not hange it, it runs in a purely automated fashion with no human intervention available. I downloaded and read the specs. If I understand them correctly, the maximal junction temperature for this CPU is 100°C. TCC should kick in when any of the cores exceeds this value. It is unclear to me when exactly TCC deactivates again but if the diagrams in the documentation are drawn to scale, a pretty wide hysteresis is involved. So one explanation for what I am seeing may be this: One of the cores, for a split second, jumps over 100°C. TCC kicks in and does not turn off for a long while. During that time, the system feels sluggish and slow. The specified maximum CPU temperature is usually the same at the ACPI _CRT, not _PSV. That is the temperature when an ACPI shutdown should be triggered, but TCC should kick in at some point below this. It does have significant hysteresis, but I'd need to look up the Intel documentation of TCC (which I have read in the past but can't seem to find now) to see just how it is governed. Try running md5 or sha256 on a bunch of random (/dev/random) data. Collect the time it takes to do a bunch of these and you will see it increase by .125 every time throttling adds another step to the pause time. It will be fairly dramatic and very close to steps of exactly .125 of the original time. Thanks, I will be using that to try and determine whether it really is TCC that makes my machine sluggish under load. It works to tell you that TCC is doing the job, but does not explain in any way why your CPU is so hot. I'll be very curious as to what you find when running another OS. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
The specified maximum CPU temperature is usually the same at the ACPI _CRT, not _PSV. That is the temperature when an ACPI shutdown should be triggered, but TCC should kick in at some point below this. This laptop is a replacement for an earlier one that had similar overheating issues. On that earlier laptop, Dell had managed to set _CRT=85°C with _PSV=95°C. This meant that the laptop did an emergency shutdown at 85°C *before* TCC got a chance to kick in at 95°C. At least on this one, _CRT=100°C and _PSV=95°C represent a more reasonable combination. It works to tell you that TCC is doing the job, but does not explain in any way why your CPU is so hot. I'll be very curious as to what you find when running another OS. I experimented with a Debian Live CD. The results are here: http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/062407.html - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Did you try to set OS override to any of the values, recognized by your BIOS, with most interesting being Windows 2001 SP2, Windows 2006 and Windows 2009. Yes, I tried this a while ago, before messing with the DSDT. I figured it was unlikely that Dell shipped a DSDT which leads to 0°C readings under Windows. Alas, no OS override seemed to change anything. The CPU was running just as hot and the temperature reported by ACPI remained 0°C. Now that I have tried Linux, I can confirm that there, too, the temperature is 0°C. The DSDT is completely broken. Additionally, could you, by any chance, replace _TMP method in TZ01 with the snippet below and let me know what the result is: I am running with that change right now. It seems to have the same effect as my own fixes: hw.acpi.thermal.tz1.temperature works and returns a temperature that agrees with dev.cpu.X.temperature. No other obvious changes. All temperatures are still in the same ranges. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
This appears to be a different issue from the one I am seeing. The system is very responsive at first and only under load (and with rising temperatures) becomes extremely sluggish. As load (and temperatures) drop, the system becomes usable again. Also, there is no difference between Qt and Gtk apps. All of them are equally fast or slow. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Tue, 2011-04-26 at 01:44 +0200, Bartosz Fabianowski wrote: Did you try to set OS override to any of the values, recognized by your BIOS, with most interesting being Windows 2001 SP2, Windows 2006 and Windows 2009. Yes, I tried this a while ago, before messing with the DSDT. I figured it was unlikely that Dell shipped a DSDT which leads to 0°C readings under Windows. Alas, no OS override seemed to change anything. The CPU was running just as hot and the temperature reported by ACPI remained 0°C. Now that I have tried Linux, I can confirm that there, too, the temperature is 0°C. The DSDT is completely broken. Additionally, could you, by any chance, replace _TMP method in TZ01 with the snippet below and let me know what the result is: I am running with that change right now. It seems to have the same effect as my own fixes: hw.acpi.thermal.tz1.temperature works and returns a temperature that agrees with dev.cpu.X.temperature. No other obvious changes. All temperatures are still in the same ranges. There are two things of interest here: * Obviously Dell BIOS writer expected different scoping rules than FreeBSD is applying (DS1 and DS2 are defined in the two different scopes). As you have already pointed out it is unlikely that Dell has produced laptop which will not work correctly in Windows, so, likely Windows scoping rules are also different from FreeBSD ones. You might want to start thread on acpi@ and might get some suggestions from Intel folks who tend to hang out there and/or from people who, unlike me, know something about ACPI in general and FreeBSD ACPI implementation in particular. It is quite possible that scoping is causing some other problems as well, some of which, actually might be applicable to the problem in hand. Alternative approach would be to explicitly name all of the methods/fields in all _ACx, _ALx and fan objects and see whether fans will kick in in time and with the desired intensity and keep temperature at bay. * The main difference between your change and mine is that mine (or, rather, the intent of the original writer) uses two sources and the higher value of the two. I am curious whether the behavior WRT critical shutdown will be the same in both cases. - Bartosz -- Alexandre Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Mon, Apr 25, 2011 at 7:23 PM, Bartosz Fabianowski free...@chillt.dewrote: Have you tried just using dd to copy the iso image of a Ubuntu / Linux LiveCD to a suitably sized USB memory stick? It has worked for me in the past. As per Mehmet's tip, I did just that with a Debian image. If it works for Ubuntu images as well then I really wonder why the only documented way is via Unetbootin. - Bartosz ___ To reduce the number of files to maintain , some Linux distributions started to generate .iso files both for CD/DVD burning and USB stick dd copying . Such distributions are mostly called dual or hybrid in their names with .iso extension to distinguish them from only CD/DVD burning .iso files . If an .iso is named for USB without dual or hybrid names , it is very likely that it is prepared in such a way for USB dd copying . With respect to my opinion , most .iso files which they are prepared for CD/DVD burning will be able to boot and install from dd copied USB sticks because .iso is a FILE format , NOT a DEVICE format . The problem is not the file format but the ability of the operating system to use devices . For example , I am seeing operating systems in CD , they are booting from DVD drive ( because BIOS is loading their kernel , etc. ) but failing to install because their kernels , etc. are NOT able to use the DVD drive when they are taking the control of the PC . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Just for an experiment, try to disable powerd and look if things improve. Or just bump it to maximum, temporarily. I have tried both now. The results are as follows: * With powerd disabled and the CPU clocked down, the computer is responsive when almost nothing is going on but becomes very slow as soon as there is a light load. This is identical to the behavior I am seeing with powerd enabled and a reduced maximum frequency. * With powerd disabled and the CPU clocked to its full speed, the computer is running much hotter but responsiveness is not improved. It appears that powerd is not at fault. Something else is making this computer run unbelievably slow. My Atom netbook regularly outperforms this Core i7 when building ports. This just cannot be right :(. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
Bartosz Fabianowski wrote: Just for an experiment, try to disable powerd and look if things improve. Or just bump it to maximum, temporarily. I have tried both now. The results are as follows: * With powerd disabled and the CPU clocked down, the computer is responsive when almost nothing is going on but becomes very slow as soon as there is a light load. This is identical to the behavior I am seeing with powerd enabled and a reduced maximum frequency. * With powerd disabled and the CPU clocked to its full speed, the computer is running much hotter but responsiveness is not improved. It appears that powerd is not at fault. Something else is making this computer run unbelievably slow. My Atom netbook regularly outperforms this Core i7 when building ports. This just cannot be right :(. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org did you test the caches? I've seen such a behavior when cpu cache was disabled. and it can be thermal throttle in case of bad contact between cpu and heatsink. try to reapply thermal compound -- SY, Marat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
did you test the caches? I've seen such a behavior when cpu cache was disabled. The Dell BIOS setup is very minimalistic and would not even allow me to turn off caches. So unless the FreeBSD boot loader somehow turned them off, the caches should be active. Is there some tool I can use to verify my caches are active? and it can be thermal throttle in case of bad contact between cpu and heatsink. try to reapply thermal compound The CPU temperature is about 60°C-70°C when idle, 80°-90°C under light load and exceeds 90°C under heavy load. All of these readings are obtained from sysctl dev.cpu as ACPI always reports a temperature of 0°C. If I fix the DSDT to correctly report temperatures, a medium to heavy load forces an emergency shutdown. To prevent this, I am running with the original broken DSDT and the CPU throttled from 1.8GHz to 1.3GHz where it never exceeds 90°C. Yes, the CPU is very warm. But it does not appear to be critically hot. The ACPI critical threshold is 95°C. It seems that this model (Dell Studio 15) always runs that hot. I have had several visits from a Dell technician who changed everything from heat pipe to complete motherboard. The temperatures never changed. Dell finally exchanged the entire laptop for a slightly newer model but the temperatures remained as they were. So reapplying thermal grease or even swapping components does not seem to change anything. Again, a tool would be useful that can tell me whether the CPU is throttling itself. Does such a thing exist? - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
I don't know which i7 you have, but the intel datasheet for the i7-870 states that the maximum case temperature is 72.7C. I have a Core i7 Q740 with a native speed of 1.73GHz. My previous Dell had a Q730. Both were exhibiting the same problems. Since this is a laptop, I would expect temperatures to be higher than in a desktop box. So up to 50-60°C CPU temperature while idling and 90°C under load may be acceptable. But the behavior the computer is exhibiting definitely is not acceptable. - Bartosz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
The CPU temperature is about 60°C-70°C when idle, 80°-90°C under light load and exceeds 90°C under heavy load. All of these readings are obtained from sysctl dev.cpu Yes, the CPU is very warm. But it does not appear to be critically hot. The ACPI critical threshold is 95°C. It seems that this model (Dell Studio 15) always runs that hot. I don't know which i7 you have, but the intel datasheet for the i7-870 states that the maximum case temperature is 72.7C. The reported cpu temperatures will be a little higher at this case temperature, maybe a few degrees. How much higher I can't say without knowing the thermal resistance. The i7-870 motherboard I have with a large cooler idles at about 40C. Under heavy load it runs at about 65C. John Theus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Sun, Apr 24, 2011 at 08:41:24PM +0200, Bartosz Fabianowski wrote: I don't know which i7 you have, but the intel datasheet for the i7-870 states that the maximum case temperature is 72.7C. I have a Core i7 Q740 with a native speed of 1.73GHz. My previous Dell had a Q730. Both were exhibiting the same problems. Since this is a laptop, I would expect temperatures to be higher than in a desktop box. So up to 50-60??C CPU temperature while idling and 90??C under load may be acceptable. But the behavior the computer is exhibiting definitely is not acceptable. The temperatures you reported in your earlier post: http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/062377.html Are not normal, nor are they acceptable, even for a laptop. Desktop i7 boxes tend to run around 45C idle, 60-65C load with stock cooling. Laptops should be higher, but not 60-65C idle with 90C under load. Others have already stated what the thermal cut-off point is. As the processor gets hotter, internal clocks and so on are throttled within the hardware to try and stabilise the temperature (to keep the thermal trip point being reached, re: emergency shutdown), which greatly decreases performance. I'm not sure if there's a way to detect this, but I would hope (?) that it would be visible via the CPU clock frequency (on FreeBSD this would be sysctl dev.cpu.X.freq). If you were running Windows there would be a multitude of tools you could check to confirm this behaviour (Core Temp, CPU-Z, RMClock, etc.). If you boot into another operating system such as Linux or Windows, do you see the same overall behaviour? Linux might be easier and might have some built-in way to get at CPU temperatures (via /proc?). Trying to figure out if this is a FreeBSD issue or not is difficult. Can you please provide: - Contents of rc.conf - sysctl -a hw.acpi - sysctl -a dev.cpu - sysctl -a dev.est - sysctl -a dev.cpufreq - sysctl -a kern.timecounter Finally, just as a data point -- and this should be honoured no matter what -- there have been cases where manufacturers have incorrectly been applying thermal grease (if used rather than a TIM pad): http://gizmodo.com/#!171394/thermal-greasy-apple-sics-lawyers-on-something-awful So don't think necessarily that just because Dell replaced the entire laptop that the next one wouldn't behave the same way. This is why I recommend trying out another OS to see if it exhibits the problem. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On 16 April 2011 11:24, Ronald Klop ronald-freeb...@klop.yi.org wrote: On Wed, 13 Apr 2011 14:28:03 +0200, Bartosz Fabianowski free...@chillt.de wrote: Hi list I am having problems with my 8.2-STABLE laptop. At times, even a very light load makes the system grind to a halt. Once an application is in the foreground, I can interact with it just fine. But when I click on a long-unused menu item or try to switch applications, I have to wait dozens of seconds or even minutes. It feels as if things were being swapped in very slowly. However, top says otherwise: The box has 4 GB of RAM with only 680 MB used. On top of that, 69 MB of swap are in used. That last number does not seem to be changing, so nothing is being swapped in or out. The load that seems to cause the worst problems is an import of OpenStreetMap data into a PostgreSQL 9 database. This does not exercise the CPU (a Core i7 Quad) much as CPU load hovers around the 20% mark most of the time and powerd is happy to reduce the operating frequency down to a few hundred MHz. There also does not seem to be much disk activity. So, memory, CPU and disk all seem fine. And still, whenever I try to switch applications, I have to wait minutes for them to appear. I am having a hard time figuring out what is going on. Any tips would be greatly appreciated. Just for an experiment, try to disable powerd and look if things improve. Or just bump it to maximum, temporarily. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: System extremely slow under light load
On Wed, 13 Apr 2011 14:28:03 +0200, Bartosz Fabianowski free...@chillt.de wrote: Hi list I am having problems with my 8.2-STABLE laptop. At times, even a very light load makes the system grind to a halt. Once an application is in the foreground, I can interact with it just fine. But when I click on a long-unused menu item or try to switch applications, I have to wait dozens of seconds or even minutes. It feels as if things were being swapped in very slowly. However, top says otherwise: The box has 4 GB of RAM with only 680 MB used. On top of that, 69 MB of swap are in used. That last number does not seem to be changing, so nothing is being swapped in or out. The load that seems to cause the worst problems is an import of OpenStreetMap data into a PostgreSQL 9 database. This does not exercise the CPU (a Core i7 Quad) much as CPU load hovers around the 20% mark most of the time and powerd is happy to reduce the operating frequency down to a few hundred MHz. There also does not seem to be much disk activity. So, memory, CPU and disk all seem fine. And still, whenever I try to switch applications, I have to wait minutes for them to appear. I am having a hard time figuring out what is going on. Any tips would be greatly appreciated. I am including the outputs of vmstat -c 2 and iostat -c 2 in the hope that these may shed some light on this. Thanks, - Bartosz Fabianowski vmstat -c 2 procs memory pagedisks faultscpu r b w avmfre flt re pi pofr sr ad0 cd0 in sy cs us sy id 0 1 20 21376M 203M 1652 2 1 1 2993 289 0 0 90 949 2764 5 2 93 0 0 20 21378M 197M 1332 0 5 1 2165 0 58 0 208 7875 3614 2 2 96 iostat -c 2 ttyada0 cd0pass0cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 188 2367 51.73 22 1.12 0.00 0 0.00 0.00 0 0.00 3 1 2 0 93 1 991 18.06 49 0.86 0.00 0 0.00 0.00 0 0.00 3 0 2 0 94 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Just for an experiment, try to disable powerd and look if things improve. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
System extremely slow under light load
Hi list I am having problems with my 8.2-STABLE laptop. At times, even a very light load makes the system grind to a halt. Once an application is in the foreground, I can interact with it just fine. But when I click on a long-unused menu item or try to switch applications, I have to wait dozens of seconds or even minutes. It feels as if things were being swapped in very slowly. However, top says otherwise: The box has 4 GB of RAM with only 680 MB used. On top of that, 69 MB of swap are in used. That last number does not seem to be changing, so nothing is being swapped in or out. The load that seems to cause the worst problems is an import of OpenStreetMap data into a PostgreSQL 9 database. This does not exercise the CPU (a Core i7 Quad) much as CPU load hovers around the 20% mark most of the time and powerd is happy to reduce the operating frequency down to a few hundred MHz. There also does not seem to be much disk activity. So, memory, CPU and disk all seem fine. And still, whenever I try to switch applications, I have to wait minutes for them to appear. I am having a hard time figuring out what is going on. Any tips would be greatly appreciated. I am including the outputs of vmstat -c 2 and iostat -c 2 in the hope that these may shed some light on this. Thanks, - Bartosz Fabianowski vmstat -c 2 procs memory pagedisks faults cpu r b w avmfre flt re pi pofr sr ad0 cd0 in sy cs us sy id 0 1 20 21376M 203M 1652 2 1 1 2993 289 0 0 90 949 2764 5 2 93 0 0 20 21378M 197M 1332 0 5 1 2165 0 58 0 208 7875 3614 2 2 96 iostat -c 2 ttyada0 cd0pass0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 188 2367 51.73 22 1.12 0.00 0 0.00 0.00 0 0.00 3 1 2 0 93 1 991 18.06 49 0.86 0.00 0 0.00 0.00 0 0.00 3 0 2 0 94 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
