From owner-freebsd-arm@freebsd.org Thu Jun 4 12:56:56 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 3295B2F225C for ; Thu, 4 Jun 2020 12:56:56 +0000 (UTC) (envelope-from hardik.sanepara@gmail.com) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49d5QH3mPdz3T0X for ; Thu, 4 Jun 2020 12:56:55 +0000 (UTC) (envelope-from hardik.sanepara@gmail.com) Received: by mail-qt1-x842.google.com with SMTP id z1so5089925qtn.2 for ; Thu, 04 Jun 2020 05:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=utBzZ262iyudqf6n8VjWQNtiFOEjU9SXtwjEPRUVUCc=; b=qpcadISbuPMHdqLHwylSx56Dq04q6pTf7VLGFVexht/M7taHyljWdsaUV7Kg0VsAC6 XOHzOXWXzuVkgiYNOrERukNQPW2Fm63LHyIwkD3ijq6xBUvbnq7vhHYIlINGQdXW5eCM UvZdkEnVUHcnIeZKHYpB51SmKO5y6SQiM2gHiwk/EDDZ+Wf8a5//LeA8QsLF1Vs1cNJj 4hLM0rOd3jnr3BiY+sld9z7ounvYVLhwbFgQndhVSl1Tz6RfFgXIx6gJk9m0Kfi89Qpl sseeDP+sqgjVJXagARmL0Ojnw9BKe+vtAadqPVg95acL7EDbu1YaKLBgCvjTros6eOKM z+Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=utBzZ262iyudqf6n8VjWQNtiFOEjU9SXtwjEPRUVUCc=; b=aAS5Ak8padwWZ8cXlvYCXni49EhzSm6FUClYQLobIZgBm4b7UYuXlbrp9VSRBPPK69 7ef6HG9AYEJnB6RxV4dKzFiH4X9JokzuZ7vnBoSYckTyUr4JZ+owfZlpE4GmIZeBYMIR nJgeGPHOTKzxGTMZNG2WwQfBQvr7iEWP7rMXvEMttbq8JMLsVAaPGcuQax7GZNtkZa0g zCVm+iNaVBVqzpxfPNxNKeUbxPwG59JfvdsrbXI9X1TgvQbaG8OtXifiz8SSsKF/UlaQ zA48OMZPGF7gH4oqyXxROqFlOIb/IzDpUIRPfm0yiRfRYGHCZYqRXMF7ddz+odyk/8lw wMIA== X-Gm-Message-State: AOAM530/kTOAgRZW0uHTvPmjaMpLvrlmBqxxUpRWLq7e0sRPNYP1ZOyC 963Zwahs4ecjzi4XEQmfeFwD2BBhzrBYK8o8lwKJ73N4 X-Google-Smtp-Source: ABdhPJx9crGKg06ih25vONH2l3WQ6jnxfF35f4A9tNs19U3XXt6Y0mEadhajfcI/wNkWhrl/RQdmJg7eokIxAMKNqXs= X-Received: by 2002:ac8:312e:: with SMTP id g43mr4333926qtb.308.1591275414228; Thu, 04 Jun 2020 05:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:2ac7:0:0:0:0:0 with HTTP; Thu, 4 Jun 2020 05:56:53 -0700 (PDT) In-Reply-To: References: From: Sanepara Hardik Date: Thu, 4 Jun 2020 18:26:53 +0530 Message-ID: Subject: Re: freebsd-arm Digest, Vol 736, Issue 5 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49d5QH3mPdz3T0X X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qpcadISb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of hardiksanepara@gmail.com designates 2607:f8b0:4864:20::842 as permitted sender) smtp.mailfrom=hardiksanepara@gmail.com X-Spamd-Result: default: False [-3.73 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.982]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::842:from]; NEURAL_HAM_SHORT(-0.76)[-0.758]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] 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: Thu, 04 Jun 2020 12:56:56 -0000 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 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 > To: myfreeweb > Cc: freebsd-arm > Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X > Message-ID: > > > 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 > To: Dan Kotowski > Cc: freebsd-arm > 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 > 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 > 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 > To: Luke Ross , freebsd-arm@freebsd.org > Subject: Re: Problems with cdce/cdceem as a USB-device on R-Pi > Message-ID: > 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" > Cc: "freebsd-arm" > 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" wrote: > >> On June 3, 2020 1:37:34 PM UTC, Dan Kotowski >> 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 > 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 > To: bob prohaska > 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 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 > To: "greg@unrelenting.technology" > Cc: freebsd-arm > Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X > Message-ID: > > > 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 > ******************************************* >