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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


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

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