Re: [Xen-devel] S3 resume issues

["Jan Beulich" <JBeulich@xxxxxxxx>]

(re-adding Cc list)

>>> On 16.01.13 at 11:43, Ben Guthro <ben@xxxxxxxxxx> wrote:
> On Wed, Jan 16, 2013 at 4:35 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 15.01.13 at 19:10, Ben Guthro <ben@xxxxxxxxxx> wrote:
>>> On Tue, Jan 15, 2013 at 7:55 AM, Ben Guthro <ben@xxxxxxxxxx> wrote:
>>>> I'll continue down the rcu_check_callbacks() path, I guess.
>>>
>>> I believe I've found the culprit of the issue, but am unsure of what
>>> the proper solution is.
>>>
>>> It looks like after resume, on these newer machines, the ns16550
>>> registers contain all FF's - and so, the timer code was getting stuck
>>> in __ns16550_poll in the following stack:
>>
>> Interesting. This isn't a plug in PCI device, is it? Which would
>> mean this is a BIOS bug (not bringing the device back online,
>> perhaps by keeping it disabled in some LPC register).
> 
> No, it appears to be the legacy COM1 0x3f8 device.
> 
>>
>>> A workaround seems to be to check some of the named registers at
>>> resume time, and bail out if they contain 0xFF's:
>>> ...
>>> This, of course means that you don't get any serial data after resume,
>>> which is not ideal.
>>
>> Yeah, but better than not resuming. I.e. if we can really nail this
>> down to a platform issue, applying a workaround like what you
>> suggested would seem worth considering.
>>
>> But I suppose this isn't helping on the laptop then?
> 
> It seemed to resolve the hang on both the Ivy Bridge Intel Mobile SDP
> (which is effectively laptop hardware in a desktop case) - as well as
> the Lenovo T430 machines.
> 
> Unfortunately, it did not resolve it for Tomasz's machine, or another
> Sandy Bridge laptop I tried (Lenovo X230T) - so there may be more than
> one issue here.
> 
>> And to me this
>> would also imply that if you run without serial console, there
>> wouldn't be an issue.
> 
> I thought this as well - but if I read the code correctly, it seems
> that the ns16550 is set up for the legacy devices in
> xen/arch/x86/setup.c _start_xen(), regardless of whether serial is
> configured on the command line (if the hardware exists):
> 
>     /* We initialise the serial devices very early so we can get debugging. 
> */
>     ns16550.io_base = 0x3f8;
>     ns16550.irq     = 4;
>     ns16550_init(0, &ns16550);
>     ns16550.io_base = 0x2f8;
>     ns16550.irq     = 3;
>     ns16550_init(1, &ns16550);

Yeah, but serial_resume() doesn't call their resume handlers
unless their state is serial_initialized, which it can get to only
through serial_parse_handle() seeing the right handle.

Jan


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