Date: Sun, 24 May 2020 16:15:42 -0600 From: Warner Losh <imp@bsdimp.com> To: myfreeweb <greg@unrelenting.technology> Cc: Dan Kotowski <dan.kotowski@a9development.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <CANCZdfrt=ijzc5rLyzZkqRy8JTwEhWhwXawGGWT85xM1mUvWXg@mail.gmail.com> In-Reply-To: <6E6E4F0C-F85B-428B-B221-C5F704677076@unrelenting.technology> References: <SBSqkdZA-3beqJyVy2tMuk5GRmV22DVVnz_8sNDhYCNOjNPe1wgoiSCoOitGhtlBspk-Gk2MKFv4sUyJKy58mKOBpXrGtZoRQKqmDvB1xIg=@a9development.com> <LqTdXCGMiTFwSobCq9LtV5QVLOZ42AiBDUTC9UrdM67cUlD_I8Y7no-8F7d_vs3VDJwIFJLgHTSZVrbkIXXeZ_-hcU0FxfWj0dr-GvhKXHA=@a9development.com> <b04385d558850dc1dfa60fc398c9ac6c@unrelenting.technology> <CAPv3WKdyOzegfK4NJjKzXQTp9jGV9VkDRWxY%2BhDudzWQKkRfEQ@mail.gmail.com> <3e81db774e0fc1a3c2251c89b7629e1b@unrelenting.technology> <86119565e5927716a9feebabcb611871@unrelenting.technology> <f801aa134da12d1b4a34b87dbc180b4a@unrelenting.technology> <37858865a8ebddd3fe1e3a228a19ef62@unrelenting.technology> <7066da0bc417ed047dc27b4741c90e81@unrelenting.technology> <xoiJF1ZUP3-rgbxC8ZmJGQNpsJSyK4zsAXhbLl8Ml96Da1lBPGwPqn0ANf7q-GgthPAWePSR9QDCM5vKysd_3e2aGtp-0egUXu6AW3bhLDg=@a9development.com> <CANCZdfqbd_u35toFYKr4LKkCBwnRhutM5knjnVcGR018Jfo1Vw@mail.gmail.com> <6E6E4F0C-F85B-428B-B221-C5F704677076@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 22, 2020 at 7:46 PM myfreeweb <greg@unrelenting.technology> wrote: > > > On May 23, 2020 1:25:48 AM UTC, Warner Losh <imp@bsdimp.com> wrote: > >On Fri, May 22, 2020 at 7:07 PM Dan Kotowski < > dan.kotowski@a9development.com> > >wrote: > > > >> > > > > I spent some time looking at that NetBSD Layerscape code - I > >> couldn't figure out how to add it > >> > > > > trivially to the current HEAD on my own, so I'm looking forward > to > >> seeing how we're going to yeet > >> > > > > that in for testing... > >> > > > > Something like this: > >> > > > > > >> > https://github.com/myfreeweb/freebsd/commit/6cbdafbc310b9a0fa4d046f71979aa01302e8b0b > >> > > > > > >> > https://send.firefox.com/download/ec0419c6d3fa856e/#QOMHO8pBq1dP1K2_4P4CBw > >> > > > > >> > > > https://gist.github.com/agrajag9/b214aa837d0ed6bb14139770ff5835ff > >> > > > Line 404: panic: Misaligned access from kernel space! > >> > > > oops, I actually have to care about the`bytes` parameter.. > >> > > > at least I got the ACPI-walking on the first try :) > >> > > > > >> > https://send.firefox.com/download/6406af63fee41a8a/#FnEEayn7igQ_eTGs0Wq0uw > >> > > > >> > > https://gist.github.com/agrajag9/b47d63484fa51eed535d8a43625a5276 > >> > > >> > hmmm. there's now a pcib2: <PCI-PCI bridge> at device 0.0 on pci1 > >> > > >> > and it actually does allocate memory, after the root fails to: > >> > > >> > pcib1: rman_reserve_resource: start=0x670000000, end=0x67003ffff, > >> count=0x40000 > >> > pcib1: pci_host_generic_core_alloc_resource FAIL: type=3, rid=28, > >> start=0000000670000000, end=000000067003ffff, count=0000000000040000, > >> flags=4800 > >> > pcib2: allocated memory range (0x70040000-0x7007ffff) for rid 1c of > >> pci1:1:0:0 > >> > > >> > iiiinteresting. Try to kldload mpr/mps/whatever? Also insert the nvme > >> drive > >> > >> https://gist.github.com/agrajag9/226018f25c9c5dd9c5dec4d5ea1b767d > >> > >> It just kept looping like that for about 5min before I killed it. But it > >> definitely reads the firmware version correctly - it's been on a shelf > for > >> a while. But I'm thinking maybe the card isn't initializing right - > there's > >> none of the usual output during POST - so I'm going to dig up that PCI > >> power cable and the RX480 tomorrow and try those. > >> > >> As for NVMe, it panics before I get to a shell. > >> > > > >Where? > > You can see that in the gist: "NVME polled command failed to complete > within 1s" > > Same as before (with straight ECAM). > > Looks like straight ECAM *is* supposed to work, after all (with > limitations on bifurcation or something, I've heard). The code I'm porting > from NetBSD does use that same ECAM space when touching non-0 busses. > > Whoops, I might've been working on increasing features instead of fixing > bugs.. :D > > It's odd that what's failing is just polling I/O with the devices, and > after successful reads. Does that smell like cache issues or something? > It's not really polling the I/O. It's waiting for an interrupt to keep it going. No interrupt, no update in the status -> panic. So I'm guessing there's an interrupt issue at play here of some sort. The polling path, which needs to be redone, doesn't use the same timeout stuff, so it doesn't check to see if there's any complete requests before failing (which is why it needs to be redone). We could likely just throw it all away because it was there before we configured everything with a config interrupt hook. Not sure about the root cause of the interrupt issue is...a Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrt=ijzc5rLyzZkqRy8JTwEhWhwXawGGWT85xM1mUvWXg>