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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

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.

Ian.


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