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 page disks faults
cpu
r b w avm fre flt re pi po fr 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
tty ada0 cd0 pass0
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
On Wed, 13 Apr 2011 14:28:03 +0200, Bartosz Fabianowski <freebsd@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 page disks faults cpu > r b w avm fre flt re pi po fr 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 > tty ada0 cd0 pass0 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-unsubscribe@freebsd.org"Just for an experiment, try to disable powerd and look if things improve. Ronald.
On 16 April 2011 11:24, Ronald Klop <ronald-freebsd8@klop.yi.org> wrote:> On Wed, 13 Apr 2011 14:28:03 +0200, Bartosz Fabianowski <freebsd@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. -- --
>> 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
On Apr 25, 2011 6:28 AM, "Ian Smith" <smithi@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 foundany> > 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.
> 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
On Mon, Apr 25, 2011 at 10:58 AM, Bartosz Fabianowski <freebsd@chillt.de>wrote:> 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
> 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
> 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
On Mon, Apr 25, 2011 at 11:18 AM, Bartosz Fabianowski <freebsd@chillt.de>wrote:> 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
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
On Mon, Apr 25, 2011 at 9:20 AM, Bartosz Fabianowski <freebsd@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, 0xFFFF) ??????????????????? 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-unsubscribe@freebsd.org"Alexandre "Sunny" Kovalenko.
> 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
> 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
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
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 (????????? ?????????)