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

[Ben Guthro <ben.guthro@gmail.com>]

On Jan 17, 2013, at 6:09 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 16.01.13 at 22:48, Ben Guthro <ben@guthro.net> wrote:
>> On Wed, Jan 16, 2013 at 4:40 PM, Malcolm Crossley
>> <malcolm.crossley@citrix.com> 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.