Re: [Xen-devel] [PATCH] ns16550: delay resume until dom0 ACPI has a chance to run

[Ben Guthro <ben@xxxxxxxxxx>]

On Tue, Apr 23, 2013 at 7:40 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 22.04.13 at 15:51, Ben Guthro <ben@xxxxxxxxxx> wrote:
>> On Thu, Jan 17, 2013 at 11:09 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 16.01.13 at 22:48, Ben Guthro <ben@xxxxxxxxxx> wrote:
>>>> On Wed, Jan 16, 2013 at 4:40 PM, Malcolm Crossley
>>>> <malcolm.crossley@xxxxxxxxxx> wrote:
>>>>
>>>>> Do these laptops (T430/T530) have built in serial?
>>>>
>>>> They seem to have the hardware for it, but no actual serial connector
>>>> out of the machine.
>>>> This hardware provides the legacy port that Xen initializes in
>>>> xen/arch/x86/setup.c __start_xen()
>>>>
>>>> When the resume happened, it was getting stuck in __ns16550_poll()
>>>> because it thought that the
>>>> LSR register was 0xFF - and had lots of data to read. It got stuck in
>>>> that while loop, and never
>>>> exited.
>>>
>>> So before acking the patch I'd like to understand how we end up
>>> in that loop even when no serial console is in use. Assuming that's
>>> because the post-IRQ initialization (mostly) unconditionally inserts
>>> the timer, that shouldn't be an issue on -unstable (as post-IRQ
>>> init of the individual drivers doesn't get called anymore when no
>>> respective command line option was present, and likewise their
>>> suspend/resume handlers don't get called anymore in that case).
>>> In which case backporting from -unstable would be preferable
>>> over putting custom stuff on the 4.x branches (albeit we likely
>>> still want the change here to have a way to resume with serial
>>> console, but the impact would be quite different).
>>
>> I'm dragging this thread back up from the archives, because I think it is
>> still applicable, and now that some of the other S3 scheduling things are
>> explained, this is a good fix.
>>
>> My assertion in this thread about getting into this loop when no
>> serial is in use turned out to be false.
>
> Good.
>
>> However, if you are using serial with one of these SuperIO controllers on
>> the LPC bus, you will get into an infinite loop at resume time.
>
> Yes, I can see how that can happen.
>
> However, there's another loose end on that thread - see your
> response
> http://lists.xen.org/archives/html/xen-devel/2013-01/msg01223.html

This issue was resolved with the following changeset:

commit 1868a0c5c083a53f7473067ceb871bd096c72386
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Sep 11 12:33:31 2012 +0200

    x86/MSI: fix 2nd S3 resume with interrupt remapping enabled

    The first resume from S3 was corrupting internal data structures (in
    that pci_restore_msi_state() updated the globally stored MSI message
    from traditional to interrupt remapped format, which would then be
    translated a second time during the second resume, breaking interrupt
    delivery).

    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25834:0376c85caaf3
    xen-unstable date: Fri Sep  7 15:57:10 UTC 2012



>
> And I'd expect you to resubmit anyway, in order to
> - fix the description (as you had promised to Pasi)
> - fix various coding style issues
> - Cc Keir (who will have to ack the patch in order for it to go in)
> - make sure we're not applying something stale after this long a
>   time

OK, I'll take a look at doing this.

Thanks.

Ben

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