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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Jan 17, 2013 at 08:37:40AM -0500, Ben Guthro wrote:
> On Thu, Jan 17, 2013 at 7:04 AM, Ben Guthro <ben.guthro@gmail.com> wrote:
> > 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.
> 
> 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.

I just tried Xen 4.3 without trying to use any serial console, and found out that
it succesfully came back from resume. But only with one CPU active.

Doing 'xl debug-keys r' before shows:

(XEN) sched_smt_power_savings: disabled
(XEN) NOW=0x000000099F1C9611
(XEN) Idle cpupool:
(XEN) Scheduler: SMP Credit Scheduler (credit)
(XEN) info:
(XEN)   ncpus              = 2
(XEN)   master             = 0
(XEN)   credit             = 600
(XEN)   credit balance     = 0
(XEN)   weight             = 0
(XEN)   runq_sort          = 380
(XEN)   default-weight     = 256
(XEN)   tslice             = 30ms
(XEN)   ratelimit          = 1000us
(XEN)   credits per msec   = 10
(XEN)   ticks per tslice   = 3
(XEN)   migration delay    = 0us
(XEN) idlers: 02
(XEN) active vcpus:
(XEN) Cpupool 0:
(XEN) Scheduler: SMP Credit Scheduler (credit)
(XEN) info:
(XEN)   ncpus              = 2
(XEN)   master             = 0
(XEN)   credit             = 600
(XEN)   credit balance     = 0
(XEN)   weight             = 0
(XEN)   runq_sort          = 380
(XEN)   default-weight     = 256
(XEN)   tslice             = 30ms
(XEN)   ratelimit          = 1000us
(XEN)   credits per msec   = 10
(XEN)   ticks per tslice   = 3
(XEN)   migration delay    = 0us
(XEN) idlers: 02
(XEN) active vcpus:
(XEN) CPU[00]  sort=380, sibling=01, core=03
(XEN)   run: [0.0] pri=0 flags=0 cpu=0 credit=172 [w=256]
(XEN)     1: [32767.0] pri=-64 flags=0 cpu=0
(XEN) CPU[01]  sort=380, sibling=02, core=03
(XEN)   run: [32767.1] pri=-64 flags=0 cpu=1


after ACPI S3 resume:
(XEN) Idle cpupool:
(XEN) Scheduler: SMP Credit Scheduler (credit)
(XEN) info:
(XEN)   ncpus              = 2
(XEN)   master             = 0
(XEN)   credit             = 600
(XEN)   credit balance     = 0
(XEN)   weight             = 0
(XEN)   runq_sort          = 471
(XEN)   default-weight     = 256
(XEN)   tslice             = 30ms
(XEN)   ratelimit          = 1000us
(XEN)   credits per msec   = 10
(XEN)   ticks per tslice   = 3
(XEN)   migration delay    = 0us
(XEN) idlers: 02
(XEN) active vcpus:
(XEN) Cpupool 0:
(XEN) Scheduler: SMP Credit Scheduler (credit)
(XEN) info:
(XEN)   ncpus              = 2
(XEN)   master             = 0
(XEN)   credit             = 600
(XEN)   credit balance     = 0
(XEN)   weight             = 0
(XEN)   runq_sort          = 471
(XEN)   default-weight     = 256
(XEN)   tslice             = 30ms
(XEN)   ratelimit          = 1000us
(XEN)   credits per msec   = 10
(XEN)   ticks per tslice   = 3
(XEN)   migration delay    = 0us
(XEN) idlers: 02
(XEN) active vcpus:
(XEN) CPU[00]  sort=471, sibling=01, core=03
(XEN)   run: [0.1] pri=0 flags=0 cpu=0 credit=0 [w=256]
(XEN)     1: [0.0] pri=0 flags=0 cpu=0 credit=-120 [w=256]
(XEN)     2: [32767.0] pri=-64 flags=0 cpu=0

Where did the other CPU go!?