From owner-freebsd-arm@freebsd.org Sun May 24 19:43:46 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E43B22CF7AA for ; Sun, 24 May 2020 19:43:46 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49VVyn4WzPz4XmS for ; Sun, 24 May 2020 19:43:44 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1590349423; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KbP6GG+fjv67KcFRx3/sO3c5FuBc5ZTzzEEgIaOMnmo=; b=QnZYeNf8I2j0mS8yvyooIItJVBm5EBoVeKl0jPFVmM5WR5jCdl7ZX0R61JtMquiqudEObw Tu/X+GuvxGH80He5HuaMvrnEciQY17Infeyqj7iVdW2/Ibhd9/mFKVQP2Olr0Sfz3J1hM6 jqtJJa0K/2LY/1sa8xaNmLuvXSUFUfw= Date: Sun, 24 May 2020 19:43:41 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: <4ad62e6669044f82e71a9d86fd493356@unrelenting.technology> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "freebsd-arm" In-Reply-To: References: <37858865a8ebddd3fe1e3a228a19ef62@unrelenting.technology> <7066da0bc417ed047dc27b4741c90e81@unrelenting.technology> <664db38a87ea8803be72af9738534994@unrelenting.technology> <8951311F-77F7-40B8-AEA0-F8CBCB1A05DE@yahoo.com> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49VVyn4WzPz4XmS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=QnZYeNf8; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; NEURAL_HAM_LONG(-0.97)[-0.974]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.84)[-0.844]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 19:43:46 -0000 May 24, 2020 10:08 PM, "Dan Kotowski" 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?