From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 22 14:17:16 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4152A86D; Sun, 22 Sep 2013 14:17:16 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 367C82362; Sun, 22 Sep 2013 14:17:15 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id f12so2211425wgh.14 for ; Sun, 22 Sep 2013 07:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NGudCPtC72g5VN0o2QMPQMzN962VhiL9PksFHIUgWF8=; b=o81pGTEfJSuMDvNxxbUwneOWvthZWnZu3crIARbgszOWIWdD6Hw8XbdH2Cy6DSm5hn +d8fptw5DuUCbflEyKOUR2cYYRxelbpsnUX4eb0p5+HOxiSGt74D+HEkVAHdSOyGZza5 x4teoTQTld9s74rba7Mt9IVNaqFqABvaKU7Yb4rlIh0oaMRrGq4Ay6x3zkyeEA4AAfd4 1nkKFHN7j2FNR8xP6Zut33hn59p0Ea5nzlSacLVlfeBD2ybL/Fk4G+JmCgC5Fson7Vpg 3/cYwH7WbvKs15T1xow1q8kbHA8dkNL4o+cyDZM+uezpoE5T74GX+x708BqUNiiFJlV/ hJVg== MIME-Version: 1.0 X-Received: by 10.180.83.228 with SMTP id t4mr9859611wiy.12.1379859433395; Sun, 22 Sep 2013 07:17:13 -0700 (PDT) Received: by 10.217.67.65 with HTTP; Sun, 22 Sep 2013 07:17:13 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Sun, 22 Sep 2013 07:17:13 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 14:17:16 -0000 Just a note for anybody who might have this problem with 9.2 that I am still having this issue with 9.2-releng (unless I patch the kernel) and Andriy hasn't accessed my system yet, to have a look so 9.2 release is likely to have this same issue for some subset of users (maybe only 1, me!). We were able to figure out that my symptoms have nothing to do with the user of powerd (still happens if powerd is not enabled, and the CPU still scales after suspend/resume). As this only appears to affect the disk access, here's the dmesg output related to the SATA hardware and affected disk: ... ahci0: port 0xb880-0xb887,0xb\ 800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb09f mem 0xf7cf7000-0xf7cf77ff \ irq 21 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier supported ... ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 On Fri, Sep 6, 2013 at 3:01 PM, Adrian Chadd wrote: > .. anything happening? > > > -adrian > > > On 2 September 2013 07:29, Adrian Chadd wrote: > >> >> On 2 September 2013 07:25, Mike Harding wrote: >> >>> It's detailed in the ticket, see >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for >>> 'reverted'. >>> >>> >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for >> now. I'll retest this on my test laptops when I'm back home. >> >> >> >> -adrian >> >> > From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 23 11:06:41 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2163CBC3 for ; Mon, 23 Sep 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9FFF2125 for ; Mon, 23 Sep 2013 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8NB6er4069370 for ; Mon, 23 Sep 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8NB6euA069368 for freebsd-acpi@FreeBSD.org; Mon, 23 Sep 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Sep 2013 11:06:40 GMT Message-Id: <201309231106.r8NB6euA069368@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:06:41 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/73823 acpi [request] acpi / power-on by timer support 28 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 25 15:09:31 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CC584B0C; Wed, 25 Sep 2013 15:09:31 +0000 (UTC) (envelope-from bengta@P142s.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4273E2C67; Wed, 25 Sep 2013 15:09:30 +0000 (UTC) Received: from P142s.sics.se (n176-p236.kthopen.kth.se [130.229.176.236]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r8PF1bZk058755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 17:01:38 +0200 (CEST) (envelope-from bengta@P142s.sics.se) Received: from P142s.sics.se (localhost [127.0.0.1]) by P142s.sics.se (8.14.7/8.14.7) with ESMTP id r8PF1Nau003202; Wed, 25 Sep 2013 17:01:23 +0200 (CEST) (envelope-from bengta@P142s.sics.se) Received: (from bengta@localhost) by P142s.sics.se (8.14.7/8.14.7/Submit) id r8PF1NWK003201; Wed, 25 Sep 2013 17:01:23 +0200 (CEST) (envelope-from bengta@P142s.sics.se) From: Bengt Ahlgren To: Adrian Chadd Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance In-Reply-To: (Adrian Chadd's message of "Fri, 6 Sep 2013 15:01:26 -0700") References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Wed, 25 Sep 2013 17:01:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon , Mike Harding X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:09:31 -0000 Now having some experience with my "new" TP X201 and Intel/KMS graphics, I also ran into severe Xorg perfomance issues, but it was _not_ connected to suspend/resume, because it persisted after a clean reboot. I plugged in a projector to the VGA port, and used xrandr. The Xorg server seemed to come to a halt, in practice unusable. After the fact I saw in the log file that there were tons of these messages: [ 136.238] (II) intel(0): EDID vendor "IFS", prod id 4354 [ 136.238] (II) intel(0): Using hsync ranges from config file [ 136.238] (II) intel(0): Using vrefresh ranges from config file [ 136.238] (II) intel(0): Printing DDC gathered Modelines: [ 136.238] (II) intel(0): Modeline "1280x800"x0.0 83.40 1280 1344 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 136.238] (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 136.238] (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 136.238] (II) intel(0): Modeline "1280x720"x60.0 74.48 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) [ 136.238] (II) intel(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 136.238] (II) intel(0): Modeline "1366x768"x59.8 84.75 1366 1431 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) [ 136.238] (II) intel(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) [ 136.238] (II) intel(0): Modeline "1400x1050"x0.0 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) [ 136.238] (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 136.238] (II) intel(0): Modeline "1680x1050"x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) That is, the Xorg server constantly queried the display device for its capabilities (perhaps on behalf of some client - I run KDE, so you never know what it tries to do...). This seems to be a somewhat known issue: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857 Is this something different, or is this a variant of the slowdown others are seeing? Bengt Adrian Chadd writes: > .. anything happening? > > > -adrian > > > On 2 September 2013 07:29, Adrian Chadd wrote: > >> >> On 2 September 2013 07:25, Mike Harding wrote: >> >>> It's detailed in the ticket, see >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for >>> 'reverted'. >>> >>> >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. >> I'll retest this on my test laptops when I'm back home. >> >> >> >> -adrian From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 25 15:44:54 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F9B01A9; Wed, 25 Sep 2013 15:44:54 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A07922E7D; Wed, 25 Sep 2013 15:44:53 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hj3so5418252wib.0 for ; Wed, 25 Sep 2013 08:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mStZWZReWnzDWce3TJZPHGJ9KqC77CFPhn/GMNZaELc=; b=khaxSDl/g3DtTlkhcxpGPKtY5jscGDekYOjd+nFwL/dXtT+QQUdmU8M0fJ4AuaZuYm Puw8N4nFjNTU3mBRCDFugAzM0xHGJlUebiRuO1qDuyR+cWGMtMSnGWTG6zE7lLaR2ao/ IpBpd71rAS4uCSah2F9AIJvDbNpIGtZTfVYtR5ELhiX3YRmkx1GqiJ5qqt9K0CD5xSrR 0p0xz2yfeEXCD9Y/zBtndz8soPBW4vr16tCHhlyhEXGYgGzMiMOZw92rWqLSQ2phITvb QuIKX+iNURyxNh/Vk6T1cPy2pZgKCGof4uIYNLNk4v+silkYL7BM3UCW7EM9rTWjPFTm e/Gw== MIME-Version: 1.0 X-Received: by 10.180.94.233 with SMTP id df9mr18119659wib.63.1380123891452; Wed, 25 Sep 2013 08:44:51 -0700 (PDT) Received: by 10.217.67.65 with HTTP; Wed, 25 Sep 2013 08:44:51 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Wed, 25 Sep 2013 08:44:51 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Bengt Ahlgren Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List , "freebsd-acpi@freebsd.org" , Andriy Gapon X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:44:54 -0000 My slowdown manifests as extremely slow disk access, even with low CPU. This happens even if CPU scaling is disabled, or if I am remotely accessing the system, with no X. On Wed, Sep 25, 2013 at 8:01 AM, Bengt Ahlgren wrote: > Now having some experience with my "new" TP X201 and Intel/KMS graphics, > I also ran into severe Xorg perfomance issues, but it was _not_ > connected to suspend/resume, because it persisted after a clean reboot. > > I plugged in a projector to the VGA port, and used xrandr. The Xorg > server seemed to come to a halt, in practice unusable. After the fact I > saw in the log file that there were tons of these messages: > > [ 136.238] (II) intel(0): EDID vendor "IFS", prod id 4354 > [ 136.238] (II) intel(0): Using hsync ranges from config file > [ 136.238] (II) intel(0): Using vrefresh ranges from config file > [ 136.238] (II) intel(0): Printing DDC gathered Modelines: > [ 136.238] (II) intel(0): Modeline "1280x800"x0.0 83.40 1280 1344 > 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 > 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 36.00 800 824 896 > 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 > 840 480 481 484 500 -hsync -vsync (37.5 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 664 704 > 832 480 489 492 520 -hsync -vsync (37.9 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 30.24 640 704 768 > 864 480 483 486 525 -hsync -vsync (35.0 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 > 800 480 490 492 525 -hsync -vsync (31.5 kHz e) > [ 136.238] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 > 900 400 412 414 449 -hsync +vsync (31.5 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 > 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 > 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 75.00 1024 1048 > 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) > [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 > 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) > [ 136.238] (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 > 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 > 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 50.00 800 856 976 > 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) > [ 136.238] (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 > 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x720"x60.0 74.48 1280 1336 > 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x960"x0.0 108.00 1280 1376 > 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 > 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1366x768"x59.8 84.75 1366 1431 > 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) > [ 136.238] (II) intel(0): Modeline "1440x900"x0.0 106.50 1440 1520 > 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) > [ 136.238] (II) intel(0): Modeline "1400x1050"x0.0 121.75 1400 1488 > 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) > [ 136.238] (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 > 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1680x1050"x0.0 146.25 1680 1784 > 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) > > That is, the Xorg server constantly queried the display device for its > capabilities (perhaps on behalf of some client - I run KDE, so you never > know what it tries to do...). > > This seems to be a somewhat known issue: > > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857 > > Is this something different, or is this a variant of the slowdown others > are seeing? > > Bengt > > Adrian Chadd writes: > > > .. anything happening? > > > > > > -adrian > > > > > > On 2 September 2013 07:29, Adrian Chadd wrote: > > > >> > >> On 2 September 2013 07:25, Mike Harding wrote: > >> > >>> It's detailed in the ticket, see > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for > >>> 'reverted'. > >>> > >>> > >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for > now. > >> I'll retest this on my test laptops when I'm back home. > >> > >> > >> > >> -adrian >