Re: [Xen-devel] [PATCH] PCI uart: fix boot hang, and second S3 resume inactive timer list corruption

[Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx>]

On 08/27/2013 08:55 AM, Jan Beulich wrote:
> > > > On 26.08.13 at 18:12, Tomasz Wroblewski<tomasz.wroblewski@xxxxxxxxxx>  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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel