Date: Fri, 5 Jun 2020 14:01:44 +0200 From: Marcin Wojtas <mw@semihalf.com> To: Dan Kotowski <dan.kotowski@a9development.com> Cc: "greg@unrelenting.technology" <greg@unrelenting.technology>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <CAPv3WKcQFeMDs%2B7Pji5=8D_avua8TK_vHxGLofhoKZArXLyUpQ@mail.gmail.com> In-Reply-To: <KwrTwABcfEzegUc4D8ZsCgFSxouYQIMOa9JoIbpe6d1HInlAX4G0OzdL_d_uug3gifKwFoh1C_EUd5MucQUgtvFy4T0qraW6riyZbje4Mw8=@a9development.com> References: <X6Vv06P26Vw5_LcsszpoJBBekBEtVOPLYn9JD5u7GmGzmpL19PqD21yZAb4Nm5-HpelPppbh8LAV7Cs5Amefzsx_kjJsy8LrmHH9mSRxuCY=@a9development.com> <8951311F-77F7-40B8-AEA0-F8CBCB1A05DE@yahoo.com> <4ad62e6669044f82e71a9d86fd493356@unrelenting.technology> <ShdSNL8XDgj0KtPR4v8nn1ohjVssrnoUQGwNL-gHOpylio7Eo5J_WjA2Ko9YjV5md64MeFz017Ts01KUnpJa3Xpw4y_PncL4e5cfUcotRWM=@a9development.com> <31D3FA64-8296-4CA5-92A2-F7FE7C4AE981@unrelenting.technology> <ZdPk7zJSE8UvoonkTixa2gV04ujgKfY93A71fz8cTB6ZPjt2uSCD5TdvFzDAEIR9Tu5LoGrcZLmXqgyrCmzh8OIB2JLc4gNKr6xF0pe931M=@a9development.com> <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <a727f3c05b234218e053c53100b539f0@unrelenting.technology> <KwrTwABcfEzegUc4D8ZsCgFSxouYQIMOa9JoIbpe6d1HInlAX4G0OzdL_d_uug3gifKwFoh1C_EUd5MucQUgtvFy4T0qraW6riyZbje4Mw8=@a9development.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Dan, pt., 5 cze 2020 o 13:46 Dan Kotowski <dan.kotowski@a9development.com> napisa=C5=82(a): > > > > > Oops, I've been adding some debug prints to gicv2 not gicv3. > > > > One thing I noticed is the interesting irq number the nvme admin qu= eue gets.. > > > > it's the same as gic_nirqs. > > > > gic0: SPIs: 288, IDs: 65535 > > > > nvme0: attempting to allocate 17 MSI-X vectors (33 supported) > > > > nvme0: using IRQs 21-37 for MSI-X > > > > acpi0: allocating via sysres: res 0xfffffd0000726280, start 21 + co= unt 1 - 1 =3D? end 21 > > > > intr_setup_irq(): irq 288 add handler error 0 on nvme0 > > > > maybe that's just like.. the first ITS handled interrupt? > > > > (funnily enough, NetBSD lists MSIs as IRQs starting from 8192) > > > > More SATA debugging: https://send.firefox.com/download/9de5357a2e58= edd9/#s9ZaU_k2NHlO-tLdyGk5iA > > > > > > https://gist.github.com/agrajag9/1aaf18f48ee883b917907dd417803711 > > > We have SATA! > > > > Wow that was silly. > > > > FreeBSD did not support multiple interrupts in an ACPI device, at all. > > Since forever, nobody else has needed this, apparently. > > It's really stupid that the error was returned this quietly >_< > > > > In the build below, it would try to attach all interrupts, not just the= first one. > > If that succeeds, I'll post that as a patch. > > > > > NVMe and mps still cause hangs, but progress is progress! > > > > Well I didn't say I've tried to actually fix PCIe interrupts yet, > > but I did add some debug logging that seems to be useful. > > Namely, IORT stuff. IORT is the ACPI table describing how interrupts fl= ow. > > > > Aaaand this is concerning: > > > > iort: Found PCI RC node with segment and device ID. its? 1 smmu3? 0 smm= u? 1 | nxtid 6400 rid 256 > > iort: entry lookup fail > > > > Wait a second, SMMU, that's not what IORT says the PCI nodes output to! > > > > https://github.com/SolidRun/edk2-platforms/blob/eec706c2d693be0b3793d91= 80e7d1a4813a526cf/Silicon/NXP > > LX2160A/AcpiTables/Iort.aslc > > > > .PciRcNode[0] =3D { .PciRcIdMapping =3D { ... > > .OutputReference =3D OFFSET_OF (NXP_EFI_ACPI_6_0_IO_REMAPPING_TABLE, It= sNode), }, > > > > Looks like our IORT parsing might be busted! > > > > The new build should output more info and force usage of the ITS node. > > So if that was the issue, and I did the forcing correctly, you should h= ave PCIe interrupts working now :) > > > > (btw: NetBSD for now doesn't care about OutputReference at all, lol) > > > > https://send.firefox.com/download/d655b27c2bd73021/#O9tR6di9HbS8FHp0isg= FkA > > https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea03ae9ac > > From jnettlet: > > BEGIN QUOTE > the V1 silicon has a SATA errata. I have partially worked around the err= ata moving some configuration into the firmware, but I still need to sort o= ut the remaining bits. Sometimes just unplugging and replugging your SATA = cable will help to reseat the connector and help. Also it is very sensiti= ve to marginal SATA cables. > END QUOTE > > I played around a bit and could create and destroy GPTs, make filesystems= , read and write to said filesystems, and hot-plug even seems to work. But = I'm not sure if jon's comment really explains the AHCI error we're still se= eing: > > ``` > (aprobe3:ahcich3:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00 00 00= 00 00 00 > (aprobe3:ahcich3:0:15:0): CAM status: Command timeout > (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted > ``` I experienced this issue on a cuple of targets (e.g. Zynq-MP or LS1046A). The port-multiplier quirk flag helped - please try adding: ahci->quirks |=3D AHCI_Q_NOPMP; Best regards, Marcin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPv3WKcQFeMDs%2B7Pji5=8D_avua8TK_vHxGLofhoKZArXLyUpQ>