Re: Xen osstest on Calxeda midway progress (Was: Re: [xen-unstable test] 21486: tolerable FAIL - PUSHED)

[Andre Przywara <andre.przywara@calxeda.com>]

On 11/06/2013 08:40 PM, Stefano Stabellini wrote:
> On Wed, 6 Nov 2013, Ian Campbell wrote:
>> On Wed, 2013-11-06 at 11:14 +0000, Stefano Stabellini wrote:
>>> On Wed, 6 Nov 2013, Ian Campbell wrote:
>>>> On Wed, 2013-11-06 at 06:52 +0000, xen.org wrote:
>>>>
>>>>> flight 21486 xen-unstable real [real]
>>>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/21486/
>>>> [...]
>>>>>   test-armhf-armhf-xl           5 xen-boot                     fail   never pass
>>>>
>>>> Switching the ARM tests over to Linux 3.12 means we now get much further
>>>> and run into:
>>>>
>>>> (from http://www.chiark.greenend.org.uk/~xensrcts/logs/21486/test-armhf-armhf-xl/serial-marilith-n5.txt)
>>>>
>>>>> [Wed Nov  6 02:34:54 2013][    1.136164] sata_highbank gpio_request 0 failed: -517
>>>>> [Wed Nov  6 02:34:54 2013][    1.140696] highbank-ahci ffe08000.sata: AHCI 0001.0300 32 slots 5 ports 3 Gbps 0x1f impl platform mode
>>>>> [Wed Nov  6 02:34:54 2013][    1.149152] highbank-ahci ffe08000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst
>>>>> [Wed Nov  6 02:34:54 2013][    1.159435] scsi0 : sata_highbank
>>>>> [Wed Nov  6 02:34:54 2013][    1.162451] scsi1 : sata_highbank
>>>>> [Wed Nov  6 02:34:54 2013][    1.165490] scsi2 : sata_highbank
>>>>> [Wed Nov  6 02:34:54 2013][    1.168516] scsi3 : sata_highbank
>>>>> [Wed Nov  6 02:34:54 2013][    1.171566] scsi4 : sata_highbank
>>>>> [Wed Nov  6 02:34:54 2013][    1.174606] ata1: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x100 irq 115
>>>>> [Wed Nov  6 02:34:54 2013][    1.181779] ata2: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x180 irq 115
>>>>> [Wed Nov  6 02:34:54 2013][    1.189060] ata3: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x200 irq 115
>>>>> [Wed Nov  6 02:34:54 2013][    1.196323] ata4: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x280 irq 115
>>>> [...]
>>>>> [Wed Nov  6 02:34:54 2013][    1.203581] ata5: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x300 irq 115
>>>>> [Wed Nov  6 02:35:04 2013][   10.353721] ata1: softreset failed (1st FIS failed)
>>>>> [Wed Nov  6 02:35:14 2013][   19.362722] ata1: softreset failed (1st FIS failed)
>>>>> [Wed Nov  6 02:35:49 2013][   50.871721] ata1: softreset failed (1st FIS failed)
>>>>> [Wed Nov  6 02:35:49 2013][   50.876019] ata1: limiting SATA link speed to 1.5 Gbps
>>>>> [Wed Nov  6 02:35:54 2013][   55.389720] ata1: softreset failed (1st FIS failed)
>>>>> [Wed Nov  6 02:35:54 2013][   55.394018] ata1: reset failed, giving up
>>>>> [Wed Nov  6 02:35:55 2013][   55.704724] ata2: SATA link down (SStatus 0 SControl 300)
>>>>> [Wed Nov  6 02:35:55 2013][   56.019724] ata3: SATA link down (SStatus 0 SControl 300)
>>>>> [Wed Nov  6 02:35:55 2013][   56.334723] ata4: SATA link down (SStatus 0 SControl 300)
>>>>> [Wed Nov  6 02:35:56 2013][   56.649722] ata5: SATA link down (SStatus 0 SControl 300)
>>>> [...]
>>>>> [Wed Nov  6 02:35:56 2013]Begin: Mounting root file system ... Begin: Running /scripts/local-top ...   Volume group "marilith-n5" not found
>>>> ... fail to find root.
>>>>
>>>> Has anyone seen this before, is it a known 3.12 on Midway issue perhaps?
>>>>
>>>> I think the failure is too soon to be related a lack of swiotlb?
>>>
>>> No, I think it's probably it.
>>
>> OK.
>>
>>>> But maybe we should enable the 1:1 workaround for Midway for now anyway?
>>>
>>> We definitely need one or the other.
>>
>> Ack.
>>
>>>> Or perhaps we should make it the default in the absence of SMMU?
>>>> Stefano, how did you end up coordinating this stuff with the dom0 kernel
>>>> side of things?
>>>
>>> I am assuming the presence of the 1:1 mapping and then only dealing with
>>> foreign grants in Linux. So yes, I think that we should just make the
>>> 1:1 workaround the default until we get SMMU support.
>>
>> Do you have a patch to that affect?
>
> Just sent. I have more patches in my queue, most of them by Julien and
> Andre and might need to be reworked. In particular the patch to
> introduce SMP support.

Yes, Julien and I agreed last week that he will send the remaining fixes 
out ASAP.
So beside that one above (thanks for sending, Stefano!), we have the SMP 
patch, Julien's "Dom0 interrupt" series and some minor things. Should be 
all in Julien's tree on xenbits.

Regards,
Andre.

>> BTW, at one point we discussed relaxing the 1:1 mapping into just a
>> contiguous mapping and publishing the offset to the guest, whatever
>> became of that idea?
>>
>> Julien solved his issue on Arndale by allocating the 1:1 from as close
>> to the start of physical RAM as he could, but having an offset would be
>> more elegant and less prone to spurious breakage I think.
>
> I take that by "and publishing the offset to the guest" you mean
> adjusting the start of the memory region in the device tree?
>