Re: [Xen-devel] S3 resume issues

[Ben Guthro <ben@xxxxxxxxxx>]

On Wed, Jan 16, 2013 at 5:57 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> (re-adding Cc list)
>

apologies.

>>>> 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.

hmm, OK, I guess I missed that part.

I'll look closer today, to see if there is something in the config
space of this device that isn't getting preserved.

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