Date: Thu, 4 Jun 2020 18:26:53 +0530 From: Sanepara Hardik <hardik.sanepara@gmail.com> To: freebsd-arm@freebsd.org Subject: Re: freebsd-arm Digest, Vol 736, Issue 5 Message-ID: <CAD38EoYKNyP3yV-tvuwEW0Udw_jnXwg9MtiLN64PwL=E8AEBLA@mail.gmail.com> In-Reply-To: <mailman.80.1591272001.63907.freebsd-arm@freebsd.org> References: <mailman.80.1591272001.63907.freebsd-arm@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Team, I would like to unsubscribe mail. Please remove my mail id from your mail list. Thanks, Regards, Hardik On 6/4/20, freebsd-arm-request@freebsd.org <freebsd-arm-request@freebsd.org> wrote: > Send freebsd-arm mailing list submissions to > freebsd-arm@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > or, via email, send a message with subject or body 'help' to > freebsd-arm-request@freebsd.org > > You can reach the person managing the list at > freebsd-arm-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-arm digest..." > > > Today's Topics: > > 1. Re: FreeBSD on Layerscape/QorIQ LX2160X (Dan Kotowski) > 2. Re: FreeBSD on Layerscape/QorIQ LX2160X (myfreeweb) > 3. Problems with cdce/cdceem as a USB-device on R-Pi (Luke Ross) > 4. Re: Problems with cdce/cdceem as a USB-device on R-Pi > (Hans Petter Selasky) > 5. Re: FreeBSD on Layerscape/QorIQ LX2160X > (greg@unrelenting.technology) > 6. Ssh sessions running top keep disconnecting (bob prohaska) > 7. Re: Ssh sessions running top keep disconnecting (Mark Millard) > 8. Re: FreeBSD on Layerscape/QorIQ LX2160X (Dan Kotowski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 03 Jun 2020 13:37:34 +0000 > From: Dan Kotowski <dan.kotowski@a9development.com> > To: myfreeweb <greg@unrelenting.technology> > Cc: freebsd-arm <freebsd-arm@freebsd.org> > Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X > Message-ID: > <ZdPk7zJSE8UvoonkTixa2gV04ujgKfY93A71fz8cTB6ZPjt2uSCD5TdvFzDAEIR9Tu5LoGrcZLmXqgyrCmzh8OIB2JLc4gNKr6xF0pe931M=@a9development.com> > > Content-Type: text/plain; charset=UTF-8 > >> > > I've sent a link to a known firmware build before: >> > > https://drive.google.com/file/d/1yXSS1O1U8CmtwaIPfxNDkzhAClJGvErK/view >> > > Have you tried it? Any difference in FreeBSD/NetBSD, with NVMe? >> > >> > I decided to go back to the UEFI sources and have found some differences >> > that I think need to be reconciled before moving forward. That said, I'm >> > not an ACPI wizard by any means - for me it's low-level mage spells at >> > best... >> > In https://github.com/SolidRun/edk2-platforms we have 2 different >> > branches that SolidRun seems to use: >> > >> > 1. LSDK-19.09-sr >> > 2. master-lx2160a >> > >> > I've been building from the latter branch, but found some significant >> > differences in the former that I think may be important to merge in. >> >> To me it seems like 19.09 is just outdated and doesn't have any benefits. >> Ask the solidrun people to be sure. >> >> Either way, nothing here would fix the interrupt bug. It's our bug since >> NetBSD works fine :( > > Any chance I can get a new test kernel without PCIe quirks? I just got a > much more recent image from jnettlet with the following comments: > > BEGIN QUOTE > If you are using that recent uefi firmware I posted then you shouldn't be > using the quirks for pcie. That has an ecam shift setup where it should > behave....relatively to SBSA standards. > it definitely won't work with the quirk enabled though. I have to add an > interface to edk2 to turn the mode on or off depending if you want access to > the root bus and have a kernel with the quirk applied, or you want it to > work with just the devices exposed but in a more compliant manner without > quirks > END QUOTE > > > ------------------------------ > > Message: 2 > Date: Wed, 03 Jun 2020 16:09:17 +0000 > From: myfreeweb <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: > <49F29C72-F76C-46DA-920A-3148B4B0415A@unrelenting.technology> > Content-Type: text/plain; charset=utf-8 > > > > On June 3, 2020 1:37:34 PM UTC, Dan Kotowski > <dan.kotowski@a9development.com> wrote: >>> > > I've sent a link to a known firmware build before: >>> > > https://drive.google.com/file/d/1yXSS1O1U8CmtwaIPfxNDkzhAClJGvErK/view >>> > > Have you tried it? Any difference in FreeBSD/NetBSD, with NVMe? >>> > >>> > I decided to go back to the UEFI sources and have found some >>> > differences that I think need to be reconciled before moving forward. >>> > That said, I'm not an ACPI wizard by any means - for me it's low-level >>> > mage spells at best... >>> > In https://github.com/SolidRun/edk2-platforms we have 2 different >>> > branches that SolidRun seems to use: >>> > >>> > 1. LSDK-19.09-sr >>> > 2. master-lx2160a >>> > >>> > I've been building from the latter branch, but found some significant >>> > differences in the former that I think may be important to merge in. >>> >>> To me it seems like 19.09 is just outdated and doesn't have any benefits. >>> Ask the solidrun people to be sure. >>> >>> Either way, nothing here would fix the interrupt bug. It's our bug since >>> NetBSD works fine :( >> >>Any chance I can get a new test kernel without PCIe quirks? I just got a >> much more recent image from jnettlet with the following comments: >> >>BEGIN QUOTE >>If you are using that recent uefi firmware I posted then you shouldn't be >> using the quirks for pcie. That has an ecam shift setup where it should >> behave....relatively to SBSA standards. >>it definitely won't work with the quirk enabled though. I have to add an >> interface to edk2 to turn the mode on or off depending if you want access >> to the root bus and have a kernel with the quirk applied, or you want it >> to work with just the devices exposed but in a more compliant manner >> without quirks >>END QUOTE > > > In the last couple kernels I posted, you should be able to set > debug.acpi.disabled=pci_layerscape to skip the quirk. > > I'll build the next one soon though, I guess with more interrupt debug > prints lol > > > ------------------------------ > > Message: 3 > Date: Wed, 03 Jun 2020 18:51:49 +0100 > From: Luke Ross <luke@lukeross.name> > To: freebsd-arm@freebsd.org > Subject: Problems with cdce/cdceem as a USB-device on R-Pi > Message-ID: > <75a918d07625de979e9995b3f01662c9deb0a9c1.camel@lukeross.name> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I have a plan to run FreeBSD on a Raspberry Pi Zero configured as a USB > network device, attached to a USB host. > > I've booted the 12.1 image, and in theory it looks like it ought to be > as simple as: > > /boot/loader.conf: hw.usb.template=8 > > If I do this, the Pi does indeed have an interface ue0, and the host > recognises a new CDC-ether device. Configuring both ends with IPs is > successful, but no packets can be passed between the two ends. The USB > serial console works fine, so there is some USB connectivity, just not > the cdce network. The same applies with hw.usb.template=1 (cdce with no > serial). > > I then reconfigured with hw.usb.template=11 for cdceem connectivity. > This is more successful - using the same IP configuration, packets pass > between host and pi-device in the main without problem. Every 15 > seconds or so, the link freezes for a few seconds and the pi logs: > > cdceem0: WARNING: cdceem_bulk_read_callback: USB_ST_ERROR: > USB_ERR_STALLED > > Unfortunately this stall is frequent enough to make cdceem mode not > useful for my use-case. > > Has anyone else got cdce device-mode working on a Pi, or knows hows to > prevent the cdceem stall? I did experiment with using a 13-CURRENT > image (same behaviour) and with FreeBSD or Linux hosts (same > behaviour). I double-checked for any inadvertent firewalling on the > host. The same sort of set-up works fine under Raspbian, so I don't > believe it's a hardware fault. > > Any suggestions/pointers very much appreciated! > > Many thanks, > > Luke > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 3 Jun 2020 20:13:51 +0200 > From: Hans Petter Selasky <hps@selasky.org> > To: Luke Ross <luke@lukeross.name>, freebsd-arm@freebsd.org > Subject: Re: Problems with cdce/cdceem as a USB-device on R-Pi > Message-ID: <e88dbae2-0f00-1e10-576b-54e7f021f53e@selasky.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2020-06-03 19:51, Luke Ross wrote: >> cdceem0: WARNING: cdceem_bulk_read_callback: USB_ST_ERROR: >> USB_ERR_STALLED > > Try to have a look at the USB traffic using: > > usbdump -i usbusX -f Y -s 65536 > > At both client and server side. Might be a controller driver bug, or the > chip is out of available endpoints, I.E. that you can only have either > ethernet or serial, but not both. > > --HPS > > > ------------------------------ > > Message: 5 > Date: Wed, 03 Jun 2020 23:40:52 +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: <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> > Content-Type: text/plain; charset="utf-8" > > June 3, 2020 7:09 PM, "myfreeweb" <greg@unrelenting.technology> wrote: > >> On June 3, 2020 1:37:34 PM UTC, Dan Kotowski >> <dan.kotowski@a9development.com> wrote: >> >>>>>> I've sent a link to a known firmware build before: >>>>>> https://drive.google.com/file/d/1yXSS1O1U8CmtwaIPfxNDkzhAClJGvErK/view >>>>>> Have you tried it? Any difference in FreeBSD/NetBSD, with NVMe? >>>>> >>>>> I decided to go back to the UEFI sources and have found some >>>>> differences that I think need to be >>>> reconciled before moving forward. That said, I'm not an ACPI wizard by >>>> any means - for me it's >>>> low-level mage spells at best... >>>>> In https://github.com/SolidRun/edk2-platforms we have 2 different >>>>> branches that SolidRun seems to >>>> use: >>>>> >>>>> 1. LSDK-19.09-sr >>>>> 2. master-lx2160a >>>>> >>>>> I've been building from the latter branch, but found some significant >>>>> differences in the former >>>> that I think may be important to merge in. >>>> >>>> To me it seems like 19.09 is just outdated and doesn't have any >>>> benefits. Ask the solidrun people >>>> to be sure. >>>> >>>> Either way, nothing here would fix the interrupt bug. It's our bug since >>>> NetBSD works fine :( >>> >>> Any chance I can get a new test kernel without PCIe quirks? I just got a >>> much more recent image >>> from jnettlet with the following comments: >>> >>> BEGIN QUOTE >>> If you are using that recent uefi firmware I posted then you shouldn't be >>> using the quirks for >>> pcie. That has an ecam shift setup where it should behave....relatively >>> to SBSA standards. >>> it definitely won't work with the quirk enabled though. I have to add an >>> interface to edk2 to turn >>> the mode on or off depending if you want access to the root bus and have >>> a kernel with the quirk >>> applied, or you want it to work with just the devices exposed but in a >>> more compliant manner >>> without quirks >>> END QUOTE >> >> In the last couple kernels I posted, you should be able to set >> debug.acpi.disabled=pci_layerscape >> to skip the quirk. >> >> I'll build the next one soon though, I guess with more interrupt debug >> prints lol > > https://send.firefox.com/download/ae38fa35246497c1/#AVSGMsnrM0YB2MSL7rRJRQ > > - customized pcie driver > + https://reviews.freebsd.org/D25121 > + more interrupt debugging (stray interrupts, all GIC config writes) > > > ------------------------------ > > Message: 6 > Date: Wed, 3 Jun 2020 19:02:50 -0700 > From: bob prohaska <fbsd@www.zefox.net> > To: freebsd-arm@freebsd.org > Subject: Ssh sessions running top keep disconnecting > Message-ID: <20200604020250.GA26450@www.zefox.net> > Content-Type: text/plain; charset=us-ascii > > For some reason, ssh sessions running top seem to be quitting > with > packet_write_wait: Connection to 50.1.20.25 port 22: Broken pipe > > I'm in the habit of leaving an ssh session running top going on > machines running long jobs like world or port builds. On my Pi3 > running 12.1-stable those sessions keep disconnecting. No other > ssh sessions, among the four open, seem to be affected. > > The client is a Pi3b+ running raspberry pi os. It has a dozen > or so ssh sessions open, no others are affected. > > Any ideas what might be going on? > > Thanks for reading, > > bob prohaska > > > > > > ------------------------------ > > Message: 7 > Date: Wed, 3 Jun 2020 19:39:44 -0700 > From: Mark Millard <marklmi@yahoo.com> > To: bob prohaska <fbsd@www.zefox.net> > Cc: freebsd-arm@freebsd.org > Subject: Re: Ssh sessions running top keep disconnecting > Message-ID: <7A0C9F2C-734E-49F8-B533-B3B487588D71@yahoo.com> > Content-Type: text/plain; charset=us-ascii > > > > On 2020-Jun-3, at 19:02, bob prohaska <fbsd at www.zefox.net> wrote: > >> For some reason, ssh sessions running top seem to be quitting >> with >> packet_write_wait: Connection to 50.1.20.25 port 22: Broken pipe >> >> I'm in the habit of leaving an ssh session running top going on >> machines running long jobs like world or port builds. On my Pi3 >> running 12.1-stable those sessions keep disconnecting. No other >> ssh sessions, among the four open, seem to be affected. >> >> The client is a Pi3b+ running raspberry pi os. It has a dozen >> or so ssh sessions open, no others are affected. >> >> Any ideas what might be going on? >> > > No clue. But a possible kind of experiment . . . > > top keeps its ssh connection in use on a rather > frequent basis, even if the mount of traffic is > not large. > > Try having some other ssh session into the 12.1 > Stable FreeBSD system that also keeps its ssh > connection in use on a rather frequent basis. > Does it get the same issue as the top sessions > do? (Need not be at the same times but if the > times were near each other for failures that > might indicate something.) > > Of course, it may be that some of your other ssh > connections to the same system already do this > test --or it may be they all rarely put their > connection to use (compared to top). > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > > > ------------------------------ > > Message: 8 > Date: Thu, 04 Jun 2020 11:40:14 +0000 > From: Dan Kotowski <dan.kotowski@a9development.com> > To: "greg@unrelenting.technology" <greg@unrelenting.technology> > Cc: freebsd-arm <freebsd-arm@freebsd.org> > Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X > Message-ID: > <ePx99n--NpqSdQxbdbM3B2qgpSXi0Gjvhspj566br-72pDug8bfXbCXAjnd68jPO2h1bWxkyPDpq5y2BzStbS38-MKkhwMzJI3uHhWcmP_g=@a9development.com> > > Content-Type: text/plain; charset=UTF-8 > >> https://send.firefox.com/download/ae38fa35246497c1/#AVSGMsnrM0YB2MSL7rRJRQ >> >> - customized pcie driver >> >> - https://reviews.freebsd.org/D25121 >> - more interrupt debugging (stray interrupts, all GIC config writes) > > https://gist.github.com/agrajag9/484cdd9c340a15f88be0fabbe2cf9b09 > > With NVMe attached it no longer panics, now it just hangs > > Loading mps still just loops > > And anything attached via AHCI is still MIA > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > ------------------------------ > > End of freebsd-arm Digest, Vol 736, Issue 5 > ******************************************* >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD38EoYKNyP3yV-tvuwEW0Udw_jnXwg9MtiLN64PwL=E8AEBLA>