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

[Ben Guthro <ben@xxxxxxxxxx>]

On Thu, Jan 17, 2013 at 7:04 AM, Ben Guthro <ben.guthro@xxxxxxxxx> wrote:
> On Jan 17, 2013, at 6: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).
>>
>> Jan
>>
>
> Admittedly, I have been doing my testing on 4.2.y
>
> I can try unstable today to see if it makes a difference in this path.

Further testing on the Lenovo T430 shows that this fix is insufficient
to fully resolve the S3 failures, (even on 4.2.y)
The first one seems to work, but the second fails - which is a
different behavior than I am seeing on the Intel Mobile SDP.

So while I think this is a valuable patch to have for debugging S3, it
is not the root cause of the failures as I had previously believed.

...back to the drawing board, I guess.

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