From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Jiri Slaby <jslaby@suse.cz>
Cc: gregkh@linuxfoundation.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] serial: 8250, disable "too much work" messages
Date: Tue, 1 Apr 2014 14:40:57 +0100 [thread overview]
Message-ID: <20140401144057.63b3ceb5@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <1396352220-5031-1-git-send-email-jslaby@suse.cz>
On Tue, 1 Apr 2014 13:37:00 +0200
Jiri Slaby <jslaby@suse.cz> wrote:
> The 8250 driver now reports many of these:
> serial8250: too much work for irq4
> These messages turned out to be common these days with a use of
> virtualization. I tried to increase the limit of processed characters
> in commit e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 (serial: 8250,
> increase PASS_LIMIT) in 2011. It was raised from 256 to 512, but it is
> still not enough, apparently.
A lot of emulations model the queue completely incorrectly. However
simply hiding it with a pr_debug is the wrong answer - it wants fixing.
If we set a large PASS_LIMIT then it's not going to be a big loss on real
hardware - we'll burp for a second or two and continue, but it ought to
cure the virtualisation case.
If it doesn't we've got a bigger problem because it means we are jammed
in the kernel spinning in an IRQ handler feeding data to a fake serial
port that never stops being an IRQ and we end up hanging the virtualised
OS for a long period
If that is happening then we need to actually workaround whatever
crapware emulator is triggering it so we don't hang the guest for long
periods if there is a big I/O.
If its a real port that is jammed our normal time around the loop on the
LPC bus is going to be a shade over 24uS (32uS if TX is jammed on)
So we certainly ought to be able to go a bit higher without major
crisis. Beyond that if it is still tripping then instead of whining we
need to set IIR_NO_INT and set a polling timer to turn the IRQ back on
next timer tick. That way a crappy emulated port can't hang the guest
with a continual stream of data and a busted real one might actually sort
out.
Alan
next prev parent reply other threads:[~2014-04-01 13:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 11:37 [PATCH 1/1] serial: 8250, disable "too much work" messages Jiri Slaby
2014-04-01 12:43 ` Takashi Iwai
2014-04-01 13:40 ` One Thousand Gnomes [this message]
2014-04-02 9:45 ` Jiri Slaby
2014-04-02 16:43 ` One Thousand Gnomes
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=20140401144057.63b3ceb5@alan.etchedpixels.co.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).