[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 26.08.13 at 11:17, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:
>- fix occasional xen boot hang whilst using PCI uart. Dom0 kernel disables 
>ioport responses
>  during PCI system initialisation, causing xen hang if __ns16550_poll() 
> routine happens to
>  be scheduled during that time. Detect and exit. Amended 
> ns16550_ioport_invalid function
>  to only check IER register, which contains three reservered (always 0) bits, 
> therefore
>  it's sufficient for this test.

And this was observed with 4.4-unstable? I'm asking because I
would at a first glance have thought that taking care of this
ought to be a desirable side effect of calling pci_hide_device().

>+static int ns16550_ioport_invalid(struct ns16550 *uart)
>+    return (((unsigned char)ns_read_reg(uart, UART_IER)) == 0xff);

Why checking just one register is sufficient when originally

>-static int ns16550_ioport_invalid(struct ns16550 *uart)
>-    return ((((unsigned char)ns_read_reg(uart, UART_LSR)) == 0xff) &&
>-            (((unsigned char)ns_read_reg(uart, UART_MCR)) == 0xff) &&
>-            (((unsigned char)ns_read_reg(uart, UART_IER)) == 0xff) &&
>-            (((unsigned char)ns_read_reg(uart, UART_IIR)) == 0xff) &&
>-            (((unsigned char)ns_read_reg(uart, UART_LCR)) == 0xff));

we checked five also needs some better explanation.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.