Date: Sun, 24 May 2020 19:43:41 +0000 From: greg@unrelenting.technology To: "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <4ad62e6669044f82e71a9d86fd493356@unrelenting.technology> In-Reply-To: <fn58k-44ZAkuwnDdytVzV-cLaB9amYMgZWydbpR_muUcKNZwohKqn9zFxqqw_Vz8Ij8L8yOSv0XhefrcTSo_bSYSOe5_7wcjoBWl8Q2dDVM=@a9development.com> References: <fn58k-44ZAkuwnDdytVzV-cLaB9amYMgZWydbpR_muUcKNZwohKqn9zFxqqw_Vz8Ij8L8yOSv0XhefrcTSo_bSYSOe5_7wcjoBWl8Q2dDVM=@a9development.com> <YI70eszO0ei1z8fnsDWQ7Cwt9u63BkXvIDMcBQ0XYj6gwcloNfare1sgktdUeO9cgby8KQk8v7EVqIOVigIwlnrPlcFDYAxgEJKcbZUyi2w=@a9development.com> <f801aa134da12d1b4a34b87dbc180b4a@unrelenting.technology> <37858865a8ebddd3fe1e3a228a19ef62@unrelenting.technology> <7066da0bc417ed047dc27b4741c90e81@unrelenting.technology> <xoiJF1ZUP3-rgbxC8ZmJGQNpsJSyK4zsAXhbLl8Ml96Da1lBPGwPqn0ANf7q-GgthPAWePSR9QDCM5vKysd_3e2aGtp-0egUXu6AW3bhLDg=@a9development.com> <CANCZdfqbd_u35toFYKr4LKkCBwnRhutM5knjnVcGR018Jfo1Vw@mail.gmail.com> <664db38a87ea8803be72af9738534994@unrelenting.technology> <b5105ce888b7a91eff50ec9118a910a8@unrelenting.technology> <8951311F-77F7-40B8-AEA0-F8CBCB1A05DE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
May 24, 2020 10:08 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wr= ote:=0A=0A> Booted with NetBSD -current=0A> Generic 64-bit=0A> Build: 202= 005232000Z=0A> SHA256: c64278c292489674215f9ecd335f2cbf01b99c2886f03a76b2= 4415cd1c24d255=0A> =0A> https://gist.github.com/agrajag9/6f2c986c99fbca41= 3e60cf608a453a00=0A> =0A> Found the onboard eMMC (sdmmc1), so that's nice= . But it panicked with the SAS HBA attached. Removed=0A> it and wired a d= rive straight up to the SATA ports, but fdisk doesn't like it. Smelling m= ore like a=0A> firmware problem now...=0A=0AWhat was the panic? How about= with the NVMe drive?=0A=0AIt's quite possible that the SATA controller o= n this hardware is buggy and=0Anot fully standards compliant (there are f= sl_ahci drivers after all for NXP stuff),=0Abut what's weird is that we'r= e failing so early, with interrupt configuration.=0AIt's.. interesting th= at there are *three* interrupts for the controller.=0AI do have a suspici= on related to this now..=0A=0Ahttps://send.firefox.com/download/e2f1b3825= db111ff/#hOc-bD4J3Wj1yyJSb-3pSQ=0A=0AThis new build might do something ab= out AHCI.=0AAlso PMU should be fixed, I would appreciate it if you tested= it=0A(kldload hwpmc; pmcstat -S INST_RETIRED -T; wait a few seconds, it = should show samples)=0A=0ABack to your previous FreeBSD log:=0A=0A> https= ://gist.github.com/agrajag9/2e07426702d46aa086348b70be942397=0A=0AMPS INT= ERRUPT!=0Aintr_setup_irq(): irq 288 add handler error 0 on mps0=0A=0AI'm = not sure why the interrupt handler prints before intr_setup_irq o_0=0Abut= it was called, right after the IOCCapabilities line when we want it,=0As= o now I'm less inclined to think that the PCIe bug is interrupts not work= ing..=0A=0AMaybe some config writes aren't taking effect after all but in= that case I would expect=0Amore spectacular explosions earlier in the bo= ot process.=0A=0AI've sent a link to a known firmware build before:=0Ahtt= ps://drive.google.com/file/d/1yXSS1O1U8CmtwaIPfxNDkzhAClJGvErK/view=0AHav= e you tried it? Any difference in FreeBSD/NetBSD, with NVMe?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ad62e6669044f82e71a9d86fd493356>