LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: nigel@nigel.suspend2.net, nigel@suspend2.net,
	Pavel Machek <pavel@ucw.cz>,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH: 2/2] [SERIAL] avoid stalling suspend if serial port won't drain
Date: Mon, 14 Jan 2008 09:46:31 +0000	[thread overview]
Message-ID: <20080114094631.GB22818@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20080114004959.0f533fef@lxorguk.ukuu.org.uk>

On Mon, Jan 14, 2008 at 12:49:59AM +0000, Alan Cox wrote:
> > > Is printk() enough for 'we've just lost your data' condition? Maybe we
> > > should abort suspend if we can't drain fifo?
> > 
> > No way. Think about this from a users' perspective. No one wants suspend
> > to ram or hibernate functionality that works sometimes and not others.
> > They want it to work reliably so they don't have to worry about their
> > laptop overheating while they're getting on the bus or airplane.
> > Aborting isn't an option.
> 
> Dumb question on the printk however - what if the port that is sticking
> is the console - don't we recurse and die ?

How do we recurse?  printk never calls the suspend method.

What *might* happen is that printk might call the serial console write
function, which waits a maximum of 10ms per character to be sent without
hardware console flow control, or one second per character with hardware
console flow control.

This will only happen when there isn't something asserting CTS connected
to the console port and hardware console flow control has been configured
at boot time.

This will also happen in normal operation if you set the system up as
above and deassert CTS - there's nothing suspend specific about that.

Finally note that hardware console flow control is entirely separate from
the user-level flow control settings or the hardware's ability.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  parent reply	other threads:[~2008-01-14  9:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08 11:51 [PATCH: 1/2] [SERIAL] avoid waking up closed serial ports on resume Russell King
2008-01-08 11:57 ` [PATCH: 2/2] [SERIAL] avoid stalling suspend if serial port won't drain Russell King
2008-01-09  0:06   ` Andrew Morton
2008-01-09  1:29     ` Alan Cox
2008-01-09  8:34     ` Russell King
2008-01-11 10:17   ` Pavel Machek
2008-01-13 22:51     ` nigel
2008-01-14  0:49       ` Alan Cox
2008-01-14  2:40         ` nigel
2008-01-14 10:04           ` Russell King
2008-01-14  9:46         ` Russell King [this message]
2008-01-13 22:56     ` Benjamin Herrenschmidt
2008-01-14  0:29     ` Russell King
2008-01-14  9:04       ` Pavel Machek
2008-01-14  9:35         ` Russell King
2008-01-14 10:21           ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080114094631.GB22818@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigel@nigel.suspend2.net \
    --cc=nigel@suspend2.net \
    --cc=pavel@ucw.cz \
    --subject='Re: [PATCH: 2/2] [SERIAL] avoid stalling suspend if serial port won'\''t drain' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).