Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote: On 4 May 2014 13:00, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. So, is the USB not working after $n resumes on T4xx and T2xx (at least) now fixed in HEAD? If so, it would be REALLY good to MFC whatever fixed it to 10 and hopefully to 9 before 9.3. I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 fails to even start to resume) though if that works on 10 I'd give it a go, despite Darren Pilgrim's dvd1_to_memstick script failing to have pkg use any of the local DVD packages, which is why I went back to 9.2 I know you only like working on HEAD, but unless there's API/ABI reasons preventing MFC, it would be great to have 9.3 work in this respect .. my X200 is not useful for purpose if it won't suspend/resume 100% reliably, with USB, and I don't want to run 11 on it, it's needed for developing non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and for that it needs to be rock solid while travelling from place to place. I'd like to see it working on more laptops and I've worked with various people in the past to try and fix whichever resume issues I find. Indeed; last I heard was last July with unsolved USB issues on your T400, and the mysterious but related 'CPU0: local APIC error 0x40' I'm happy leaving this as-is but at some point something has to be bitten and the bugs in the drivers / ACPI stuff need to be fixed. :) It's a bit disconcerting if fixes only ever make it into HEAD, for me. cheers, Ian (someone please sing out if I shouldn't be crossposting to -arch) ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.html which refers to te tail of this thread in -usb (and -stable) http://lists.freebsd.org/pipermail/freebsd-usb/2013-July/thread.html#12242 which began with Adrian's post in http://lists.freebsd.org/pipermail/freebsd-usb/2013-June/thread.html Then there's the wiki page: https://wiki.freebsd.org/SuspendResume which leads to some more bits, lots more scattered through -acpi and -laptop over the time. There used to be lots of useful per-laptop snippets in the FLCL (freebsd laptop compatibility list) which sadly disappeared last year, but I just googled up an archive of it at http://archive.today/CVo46 latest from mid-2013. Ah sorry, spoke too soon, individual pages redirect to eg: http://laptop.bsdgroup.de/freebsd/index.html?action=list_laptop_mfmfid=1 which is still down :( Ian ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
Warren Block wbl...@wonkity.com wrote: On Sun, 4 May 2014, Adrian Chadd wrote: The easy-to-run test is sysctl dev.cpu.0.cx_lowest=Cmax and then use stuff. It's that use stuff step that would preferably be automated. Is the failure mode a lockup, or could a program detect problems? The idea is to get lots of feedback, fast. One possible failure mode is that timers tick unreliably which can be detected automatically (in some cases), for example by using the DTrace script timestamp-test.d: http://www.fabiankeil.de/gehacktes/dtrace-timestamp-tests/ It should also be possible to let the kernel do this itself and log an error message and maybe optionally disable Cx states that cause problems: sysctl dev.cpu.0.cx_lowest=Cmax-as-long-as-it-appears-to-be-working Fabian signature.asc Description: PGP signature
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Mon, May 05, 2014 at 04:17:08PM +1000, Ian Smith wrote: On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote: On 4 May 2014 13:00, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. I can also confirm that suspend/resume works out of the box on my X200 and on several T61 I used with 10.0-RELEASE, even without newcons the T61 woke up. I know you only like working on HEAD, but unless there's API/ABI reasons preventing MFC, it would be great to have 9.3 work in this respect .. my X200 is not useful for purpose if it won't suspend/resume 100% reliably, with USB, and I don't want to run 11 on it, it's needed for developing non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and for that it needs to be rock solid while travelling from place to place. Tyler Croy got it working on his X200 which did not work for me: http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.html I worked around around this with an el cheapo USB 3.0 PCI-Express card which fits nicely into the card slot and works after every resume. ___ 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
Current problem reports assigned to freebsd-acpi@FreeBSD.org
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/187152 acpi [i386] [acpi] [suspend/resume] resume from ACPI suspen 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] Suspend/resume broken on Lenov o kern/173414 acpi [acpi] ACPI battery time incorrect 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] [suspend/resume] Dell E6520 doesn't resume afte o kern/161713 acpi [acpi] [suspend/resume] Suspend on Dell E6520 doesn't 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] [suspend/resume] Lenovo T61p does not resume o i386/146715 acpi [acpi] [suspend/resume] Suspend works, resume not on a 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 30 problems total. ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 2014-05-04 at 13:51 -0700, Adrian Chadd wrote: I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. T520, just works. Has for a while. I suspect disabling firewire and the eSATA port helps quite a bit. sean -arch for this. signature.asc Description: This is a digitally signed message part
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. -- John Baldwin ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On 5 May 2014 08:09, John Baldwin j...@freebsd.org wrote: On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) -a ___ 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
suspend issues with latest -HEAD, ahci failing to complete something?
Hiya, (I know, I just emailed out asking about setting S3 for the default lid suspend state, however I just updated to the very latest head and things went a little backwards.) Suspend no longer works for me: May 5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10 May 5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0 May 5 10:33:47 lucy-11i386 kernel: ahcich0: is cs fff80fff ss fff80fff rs fff80fff tfd d0 serr cmd d317 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13 May 5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59 May 5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0 May 5 10:34:37 lucy-11i386 kernel: ahcich0: is cs ff83 ss ff83 rs ff83 tfd d0 serr cmd c717 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03 What has recently changed that'd possibly break ahci's ability to correctly suspend? 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: suspend issues with latest -HEAD, ahci failing to complete something?
On 05.05.2014 20:37, Adrian Chadd wrote: (I know, I just emailed out asking about setting S3 for the default lid suspend state, however I just updated to the very latest head and things went a little backwards.) Suspend no longer works for me: May 5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10 May 5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0 May 5 10:33:47 lucy-11i386 kernel: ahcich0: is cs fff80fff ss fff80fff rs fff80fff tfd d0 serr cmd d317 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13 May 5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59 May 5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0 May 5 10:34:37 lucy-11i386 kernel: ahcich0: is cs ff83 ss ff83 rs ff83 tfd d0 serr cmd c717 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03 What has recently changed that'd possibly break ahci's ability to correctly suspend? When I tested it last time (awhile ago), it was working for me. ahci_ch_suspend() should block all I/O on the channel and wait until all active commands complete. On resume channel should be reinitialized, device reset and only then I/Os should be released. Do you see those timeouts on suspend or resume? Do you have kern.cam.ada.spindown_suspend enabled? Can you try to disable it? -- Alexander Motin ___ 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: suspend issues with latest -HEAD, ahci failing to complete something?
Hi, Would you mind testing the latest -HEAD out? It worked a couple weeks ago with my last rebuild on this particular laptop. -a On 5 May 2014 12:51, Alexander Motin m...@freebsd.org wrote: On 05.05.2014 20:37, Adrian Chadd wrote: (I know, I just emailed out asking about setting S3 for the default lid suspend state, however I just updated to the very latest head and things went a little backwards.) Suspend no longer works for me: May 5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10 May 5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0 May 5 10:33:47 lucy-11i386 kernel: ahcich0: is cs fff80fff ss fff80fff rs fff80fff tfd d0 serr cmd d317 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13 May 5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59 May 5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0 May 5 10:34:37 lucy-11i386 kernel: ahcich0: is cs ff83 ss ff83 rs ff83 tfd d0 serr cmd c717 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03 What has recently changed that'd possibly break ahci's ability to correctly suspend? When I tested it last time (awhile ago), it was working for me. ahci_ch_suspend() should block all I/O on the channel and wait until all active commands complete. On resume channel should be reinitialized, device reset and only then I/Os should be released. Do you see those timeouts on suspend or resume? Do you have kern.cam.ada.spindown_suspend enabled? Can you try to disable it? -- Alexander Motin ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Monday, May 05, 2014 12:55:29 pm Adrian Chadd wrote: On 5 May 2014 08:09, John Baldwin j...@freebsd.org wrote: On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) -- John Baldwin ___ 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
