From owner-freebsd-current@freebsd.org Thu May 17 13:26:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11D1CEF118B for ; Thu, 17 May 2018 13:26:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93EAE7F566 for ; Thu, 17 May 2018 13:26:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: d247bfed-59d5-11e8-afd2-4ddcc8249dd4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id d247bfed-59d5-11e8-afd2-4ddcc8249dd4; Thu, 17 May 2018 13:25:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w4HDPq3M083860; Thu, 17 May 2018 07:25:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1526563552.32688.47.camel@freebsd.org> Subject: Re: serial console vs suspend From: Ian Lepore To: Andriy Gapon , freebsd-hackers , FreeBSD Current Date: Thu, 17 May 2018 07:25:52 -0600 In-Reply-To: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> References: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:26:05 -0000 On Thu, 2018-05-17 at 10:54 +0300, Andriy Gapon wrote: > > It seems that the serial console, or rather a UART used by it, may require > re-initialization after waking up (from suspend to RAM).  At least one of my > systems fails to wake up properly if I configure the serial console.  I've done > some experimenting with cu (and without the console) and the UART seems to be in > some weird state, it echoes back the input and does not send anything on the > wire.  I guess that trying to print to the serial console while the UART is in > that state results in a hang. > > To test the theory I made this hack and it does help: > Index: sys/dev/uart/uart_tty.c > =================================================================== > --- sys/dev/uart/uart_tty.c (revision 333667) > +++ sys/dev/uart/uart_tty.c (working copy) > @@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp) >   uart_init(di); >  } > > +void uart_resume(void); > +void > +uart_resume(void) > +{ > + uart_init(&uart_console); > +} > + >  static void >  uart_cnterm(struct consdev *cp) >  { > Index: sys/x86/acpica/acpi_wakeup.c > =================================================================== > --- sys/x86/acpica/acpi_wakeup.c (revision 333667) > +++ sys/x86/acpica/acpi_wakeup.c (working copy) > @@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc) >  } >  #endif > > +extern void uart_resume(void); > + >  int >  acpi_sleep_machdep(struct acpi_softc *sc, int state) >  { > @@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat >  #else >   npxresume(susppcbs[0]->sp_fpususpend); >  #endif > + uart_resume(); >   } > >   return (1); /* wakeup successfully */ > > > =================================================================== > > This is quick and dirty, of course. > I think that this should go through the console layer. > And, obviously, not all consoles actually need such a reinit. > > So, maybe: > cnresume() > { > for each console { > if cn->cn_ops->cn_resume != NULL > cn->cn_ops->cn_resume(cn) > } > } > > uart_resume(struct consdev *cp) > { > uart_init(cp->cn_arg); > } > > What do you think? > > Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method. > So, will I have to add a dummy resume to all console drivers? Why should it go through the console layer? If the uart hardware needs some re-init on resume, won't that be true whether the uart is serving as a console, a dial-in terminal, or the interface to wifi or bluetooth chip? -- Ian