From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Wroblewski Subject: Re: [PATCH] PCI uart: fix boot hang, and second S3 resume inactive timer list corruption Date: Tue, 27 Aug 2013 10:52:02 +0200 Message-ID: <521C68B2.7070401@citrix.com> References: <521B1D24.1060903@citrix.com> <521B557002000078000EE575@nat28.tlf.novell.com> <521B3E58.5020206@citrix.com> <521B6C1E02000078000EE640@nat28.tlf.novell.com> <521B5744.1070608@citrix.com> <521B79AA02000078000EE6B4@nat28.tlf.novell.com> <521B6FAD.6060509@citrix.com> <521B8FC902000078000EE799@nat28.tlf.novell.com> <521B7E78.8030302@citrix.com> <521C698D02000078000EE9CC@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VEF1A-0004BK-OU for xen-devel@lists.xenproject.org; Tue, 27 Aug 2013 08:52:52 +0000 In-Reply-To: <521C698D02000078000EE9CC@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 08/27/2013 08:55 AM, Jan Beulich wrote: >>>> On 26.08.13 at 18:12, Tomasz Wroblewski wrote: >> On 08/26/2013 05:26 PM, Jan Beulich wrote: >>> My question was along the lines of "If I/O port access is disabled, >>> isn't the whole driver screwed (even if only temporarily)?" And if >>> the answer to this is "yes" (I can't see it to be "no"), dealing with >>> this likely requires more than the change you proposed. >> It could be, I only have empirical evidence of not noticing any serial >> out hiccups during dom0 kernel init. Since this is is small driver and >> it seems to primarily interact with the I/O only in ns16550_interrupt, >> ns16550_poll, ns16550_tx_ready, putc, getc (and in some init functions >> but these will only be called before dom0 boot), I thought that: >> >> * ns16550_interrupt will be fine with IO ports disabled, it'll just exit > Ah, right, the flag being tested is a "no-interrupt-pending" one. > Good. > >> * ns16550_poll will be fine with the posted patch, it'll exit >> * ns16550_getc looks like it has a potential of producing 0xFF >> characters incorrectly, so maybe would need a port test as well > Right. > >> * ns16550_putc should be fine since write to ioport will just be dropped > Ideally it would of course postpone the writes, see below. > >> * ns16550_tx_ready should be fine, it will return 1 if ioports are >> disabled which is what it needs to be returning to avoid spinning in >> serial.c > Actually, one could probably tweak this so that at least in the non- > sync, non-log-everything case it serial.c would prefer buffering > over calling ->putc() (and hence dropping), by allowing > ->tx_ready() to indicate this "disconnected" state via a special > return value. Aha okay. I'm trying to come up with something along the above lines then. I think I'll split this patch into two, one for the timer list fix (which I think is not controversial) and other for the hang/port unavailable case > Jan >