Re: [Xen-devel] S3 resume issues

[Ben Guthro <ben@xxxxxxxxxx>]

On Tue, Jan 15, 2013 at 1:39 PM, Malcolm Crossley
<malcolm.crossley@xxxxxxxxxx> wrote:
> On 15/01/13 18:38, Ben Guthro wrote:
>>
>> On Tue, Jan 15, 2013 at 1:32 PM, Malcolm Crossley
>> <malcolm.crossley@xxxxxxxxxx> wrote:
>>>
>>> On 15/01/13 18:22, Ben Guthro wrote:
>>>>
>>>> On Tue, Jan 15, 2013 at 1:17 PM, Malcolm Crossley
>>>> <malcolm.crossley@xxxxxxxxxx> wrote:
>>>>>
>>>>> You get 0xFF when there is nothing responding to the ioport. If the
>>>>> 16550
>>>>> is
>>>>> on a PCI card then it could be the PCI connection has not been setup
>>>>> again
>>>>> after the resume and you can't get to that ioport range.
>>>>
>>>> This is not a PCI card, it is on onboard card (io base 0x3f8)
>>>>
>>>> Ben
>>>
>>> Interesting, it may be the serial device requires some ACPI method to be
>>> called to initialise/enable it correctly.
>>>
>>> A serial port on a HP Elitebook 8570p we have seems to not initialise the
>>> serial port after the BIOS has started. The serial only starts working
>>> when
>>> the Linux kernel runs the ACPI enable method (halfway through the kernel
>>> boot) . I've tried to decompile the ACPI AML and it looks like it's
>>> enabling
>>> the serial via a microcontroller.
>>>
>>> It could be you have a similar microcontroller based serial port on your
>>> system which can only be initialised via ACPI.
>>>
>>> It might be worth checking that the io decode windows are enabled on the
>>> panther point chipset for the 0x3f8 port ranges. Check that bits 0-2 are
>>> 0
>>> at address 0x80 and that bit 0 is 0 at address 0x82 in PCI device 0:1f
>>> config space.
>>
>> It looks like bit 0 is 1 at 0x82 (if I'm reading this correctly):
>>
>> 00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev
>> 04)
>>         Subsystem: Intel Corporation Device 7270
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 0
>>         Capabilities: [e0] Vendor Specific Information: Len=0c <?>
>> 00: 86 80 55 1e 07 00 10 02 04 00 01 06 00 00 80 00
>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72
>> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
>> 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00
>> 50: f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 60: 8b 80 8a 8a 90 00 00 00 85 80 8b 85 f8 f0 00 00
>> 70: 78 f0 78 f0 78 f0 78 f0 78 f0 78 f0 78 f0 78 f0
>> 80: 70 00 0f 3c 81 06 7c 00 41 16 0c 00 c1 07 3c 00
>> 90: e1 02 1c 00 00 0f 00 00 00 00 00 00 00 00 00 00
>> a0: 14 0e a0 00 48 39 06 00 00 47 00 00 00 00 00 02
>> b0: 00 00 00 00 00 00 00 00 04 80 00 20 00 00 00 00
>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> d0: 33 22 11 00 67 45 00 00 c0 fc 00 00 08 00 00 00
>> e0: 09 00 0c 10 00 00 00 00 a3 02 e4 02 00 00 00 00
>> f0: 01 c0 d1 fe 81 30 1a 00 87 0f 04 08 00 00 00 00
>>
>>
>> Is that something that needs to be re-enabled at resume time?
>
> Sorry I made a mistake, bit 0 should 1 at address 0x82.
>
>

It appears that Malcolm is correct, in this regard.

On the mobile SDP (and other newer laptops) - it looks like the serial
device is not part of the PCH, but a SuperIO card hanging off of the
LPC bus.
Disassembling the DSDT, and looking at the output of "lspnp -b -vv"
shows this device providing the legacy port io base addresses.

Presumably, the BIOS executes the AML at boot time to set this device
up, but we don't seem to do anything of the sort in Xen, which gives
F's when accessing the ioport.

I'm still investigating how this device might properly be re-enabled in Xen.

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