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


> But maybe we should enable the 1:1 workaround for Midway for now anyway?

We definitely need one or the other.


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

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