Re: 9.2-RC3 - suspend/resume causes slow system performance
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 1280x800x0.0 83.40 1280 1344 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) [ 136.238] (II) intel(0): Modeline 800x600x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline 720x400x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline 1280x1024x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 136.238] (II) intel(0): Modeline 832x624x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 136.238] (II) intel(0): Modeline 1152x864x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 136.238] (II) intel(0): Modeline 1280x720x60.0 74.48 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) [ 136.238] (II) intel(0): Modeline 1280x960x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 136.238] (II) intel(0): Modeline 1366x768x59.8 84.75 1366 1431 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) [ 136.238] (II) intel(0): Modeline 1440x900x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) [ 136.238] (II) intel(0): Modeline 1400x1050x0.0 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) [ 136.238] (II) intel(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 136.238] (II) intel(0): Modeline 1680x1050x0.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 adr...@freebsd.org writes: .. anything happening? -adrian On 2 September 2013 07:29, Adrian Chadd adr...@freebsd.org wrote: On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
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 ben...@sics.se 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 1280x800x0.0 83.40 1280 1344 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) [ 136.238] (II) intel(0): Modeline 800x600x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 136.238] (II) intel(0): Modeline 640x480x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline 720x400x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline 1280x1024x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 136.238] (II) intel(0): Modeline 1024x768x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 136.238] (II) intel(0): Modeline 832x624x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 136.238] (II) intel(0): Modeline 800x600x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 136.238] (II) intel(0): Modeline 1152x864x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 136.238] (II) intel(0): Modeline 1280x720x60.0 74.48 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) [ 136.238] (II) intel(0): Modeline 1280x960x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 136.238] (II) intel(0): Modeline 1366x768x59.8 84.75 1366 1431 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) [ 136.238] (II) intel(0): Modeline 1440x900x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) [ 136.238] (II) intel(0): Modeline 1400x1050x0.0 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) [ 136.238] (II) intel(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 136.238] (II) intel(0): Modeline 1680x1050x0.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 adr...@freebsd.org writes: .. anything happening? -adrian On 2 September 2013 07:29, Adrian Chadd adr...@freebsd.org wrote: On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to
Re: 9.2-RC3 - suspend/resume causes slow system performance
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: Intel 5 Series/3400 Series AHCI SATA controller 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: ST1000DM003-9YN162 CC4D 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=0x14K ada0: Previously was known as ad4 On Fri, Sep 6, 2013 at 3:01 PM, Adrian Chadd adr...@freebsd.org wrote: .. anything happening? -adrian On 2 September 2013 07:29, Adrian Chadd adr...@freebsd.org wrote: On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
So you tinkered with this - which particular line(s) did you revert back to get the old behaviour? -adrian On 1 September 2013 22:46, Mike Harding mvhard...@gmail.com wrote: Why not put this out to stable and take a survey with more than 2 members? I am sure that there are those who will be delighted, as I was with 9.1, to discover that suspend/resume worked without rebooting the machine. I can make the system available to you, contact me at this email. I am in the PDT time zone. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. On Mon, Sep 2, 2013 at 6:35 AM, Adrian Chadd adr...@freebsd.org wrote: So you tinkered with this - which particular line(s) did you revert back to get the old behaviour? -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
on 01/09/2013 02:40 Adrian Chadd said the following: On 31 August 2013 10:35, Mike Harding mvhard...@gmail.com mailto:mvhard...@gmail.com wrote: I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. Wow, nice! Avg - can we get this fixed? Or just revert this! Thank you for trying to be helpful. But let's not jump to conclusions. BTW, I am following up on the problem in the PR. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
On 31 August 2013 23:41, Andriy Gapon a...@freebsd.org wrote: I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. Wow, nice! Avg - can we get this fixed? Or just revert this! Thank you for trying to be helpful. But let's not jump to conclusions. BTW, I am following up on the problem in the PR. Sure, I'd like to know why it's behaving badly. But since we're so close to 9.2-REL, do you think you can get it sorted out and bug-free on all the existing platforms that people are using 9.2 on (including server, desktop and laptop) without reverting it? Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? Thanks, -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
On 1 September 2013 14:35, Andriy Gapon a...@freebsd.org wrote: Do you have any evidence that there is anybody else besides Mike who has this problem? Nope! but we can't assume that users are reporting all the system slowdowns. And honestly, I've heard enough strange stories on mailing lists and IRC of things like during disk IO, blah would be really slow, when I change timekeeping or halt from ACPI to something else, things get better. So I can't discount that this is affecting people and they either don't know, or just chalk it up as shitty hardware. Also, I usually try to sort out things after there is a clear understanding of what the problem is and how it should be fixed. Well, the big change is that it's now going into a sleep state on a HT core, right? Are you able to go into an ACPI sleep state on a HT logical CPU, rather than the physical core? Or am I mis-understanding what's going on? Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? I do not see any problem with the code*.* I do not see any explanation of the root cause of the problem that Mike has. I do not see why anything has to be reverted. Especially because since we're so close to 9.2-REL. Just in case, I'll remind that the commit in question is in stable/9 since Dec 23 2012. Right, but I also know a lot of people who just have stayed with 8.x or 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that everyone has been keeping up to date with stable/9 and providing feedback. Thanks, -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
on 02/09/2013 00:58 Adrian Chadd said the following: On 1 September 2013 14:35, Andriy Gapon a...@freebsd.org mailto:a...@freebsd.org wrote: Do you have any evidence that there is anybody else besides Mike who has this problem? Nope! but we can't assume that users are reporting all the system slowdowns. Why? And honestly, I've heard enough strange stories on mailing lists and IRC of things like during disk IO, blah would be really slow, when I change timekeeping or halt from ACPI to something else, things get better. So I can't discount that this is affecting people and they either don't know, or just chalk it up as shitty hardware. Strange stories are just that. Also, I usually try to sort out things after there is a clear understanding of what the problem is and how it should be fixed. Well, the big change is that it's now going into a sleep state on a HT core, right? Are you able to go into an ACPI sleep state on a HT logical CPU, rather than the physical core? Or am I mis-understanding what's going on? Most likely. I do not see how the change is HT-specific or HT-related at all. Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? I do not see any problem with the code*.* I do not see any explanation of the root cause of the problem that Mike has. I do not see why anything has to be reverted. Especially because since we're so close to 9.2-REL. Just in case, I'll remind that the commit in question is in stable/9 since Dec 23 2012. Right, but I also know a lot of people who just have stayed with 8.x or 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that everyone has been keeping up to date with stable/9 and providing feedback. I am positive that it's not everyone who uses (up-to-date) stable/9. Still, I believe that a user-base of stable/9 is 1. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
.. well, when is that pointer NULL? It looks like it's supposed to be NULL for one pair of the two HT CPUs? Are you taking the whole core into an ACPI idle state if one of two logical CPUs representing a core is going idle? -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
This would be a 'strange story' if I had not tracked this down. The disk works, only much slower than normal. I only noticed it because I was doing a buildworld. There is no crash, no dmesg, no console logs. I'll ask again, why change that line? Did you feel that the original author of the code had made a mistake? The code in question is from Oct. 2005. Also why move the check for the HT in front of the check for the disabled idle? The only change that affects my system is that idle is enabled in a code path that should only be run when idle is disabled. I don't know the larger context but I also don't know why the code was changed. It looks like the intent of the code has been changed (don't suspend if this flag is set) and I don't know what benefit this provides. The code path seems to only be run during startup, shutdown and wake from sleep. Contact me via email and I'll set up remote access. This is a personal machine so this is a bit awkward. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
on 02/09/2013 01:21 Adrian Chadd said the following:
.. well, when is that pointer NULL?
It's never NULL. But that is besides the point as we are talking about a
different check.
* if (is_idle_disabled(sc)) {*
- ACPI_ENABLE_IRQS();
+ acpi_cpu_c1();
It looks like it's supposed to be NULL for
one pair of the two HT CPUs?
Are you taking the whole core into an ACPI idle state if one of two logical
CPUs
representing a core is going idle?
--
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
on 02/09/2013 02:13 Mike Harding said the following: I'll ask again, why change that line? I got your question the first few times you asked it. I do not see why you keep asking it when nobody has a clear explanation of what exactly is going on on your system and I've already told that I want to investigate / analyze that first. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. On Thu, Aug 29, 2013 at 11:50 PM, Adrian Chadd adr...@freebsd.org wrote: On 29 August 2013 23:46, Mike Harding mvhard...@gmail.com wrote: I was able to track this down by building kernels against /base/stable/9 (it took -hours!-). Wow, thanks! The issue does occur with commit 244616, but does not occur with 244614. The only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - this code appears to do with c-state processing. I'll note it in the ticket, but somebody might want to look at this ASAP That's awesome. It's a very small ACPI patch. Let's see if the others who are having this issue can test this out and report back! Thanks! -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
On 31 August 2013 10:35, Mike Harding mvhard...@gmail.com wrote: I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. Wow, nice! Avg - can we get this fixed? Or just revert this! -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
