Date: Thu, 3 May 2018 14:57:59 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org> Subject: Re: hpet vs suspend to ram Message-ID: <39dad33d-3983-c85f-5049-e3b934800829@FreeBSD.org> In-Reply-To: <18935a5e-cd60-a434-f226-1c4ab258c044@FreeBSD.org> References: <8d3f5a6f-f2be-f2e1-18d5-f774f4909694@icyb.net.ua> <20180503095558.GJ6887@kib.kiev.ua> <18935a5e-cd60-a434-f226-1c4ab258c044@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/05/2018 14:50, Andriy Gapon wrote:
> Thank you very much for the suggestion!
> It seems that doing that (and a little bit more[*]) helps indeed.
>
> However there seems to be another issue.
> hpet_suspend() is called too early. [Some] Other drivers require a working
> event timer for their suspend routines. So after HPET is stopped the suspend
> process gets stuck. Repeatedly pressing keyboard keys helps the process to
> finally reach the firmware suspend. Everything is okay after resume.
Got a patch for this issue as well.
The idea is to suspend children in the reverse order (comparing to their attach
order).
--- a/sys/kern/subr_bus.c
+++ b/sys/kern/subr_bus.c
@@ -3772,15 +3772,16 @@ int
bus_generic_suspend(device_t dev)
{
int error;
- device_t child, child2;
+ device_t child;
- TAILQ_FOREACH(child, &dev->children, link) {
+ TAILQ_FOREACH_REVERSE(child, &dev->children, device_list, link) {
error = BUS_SUSPEND_CHILD(dev, child);
- if (error) {
- for (child2 = TAILQ_FIRST(&dev->children);
- child2 && child2 != child;
- child2 = TAILQ_NEXT(child2, link))
- BUS_RESUME_CHILD(dev, child2);
+ if (error != 0) {
+ child = TAILQ_NEXT(child, link);
+ if (child != NULL) {
+ TAILQ_FOREACH_FROM(child, &dev->children, link)
+ BUS_RESUME_CHILD(dev, child);
+ }
return (error);
}
}
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39dad33d-3983-c85f-5049-e3b934800829>