32-bit powerpc head -r360311: lock order reversal between: "PROC (UMA zone)" and "kernelpmap (kernelpmap)": Is this expected?
Using artifact.ci's head -r360311 debug-kernel materials: https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/kernel*.txz I got the following notice: lock order reversal: 1st 0x1cbb680 PROC (UMA zone) @ /usr/src/sys/vm/uma_core.c:4387 2nd 0x113c99c kernelpmap (kernelpmap) @ /usr/src/sys/powerpc/aim/mmu_oea.c:1524 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x51d774 at __mtx_lock_flags+0xcc #3 0x90902c at moea_kextract+0x5c #4 0x9462ac at pmap_kextract+0x98 #5 0x8a417c at zone_release+0xf0 #6 0x8abc14 at bucket_drain+0x2f0 #7 0x8ab64c at bucket_free+0x54 #8 0x8ab8bc at bucket_cache_reclaim+0x1bc #9 0x8ab3c4 at zone_reclaim+0x128 #10 0x8a7e60 at uma_reclaim+0x1d0 #11 0x8d96ac at vm_pageout_worker+0x4d8 #12 0x8d91c0 at vm_pageout+0x1b0 #13 0x4f67a0 at fork_exit+0xb0 #14 0x94892c at fork_trampoline+0xc Is the above interesting or is it one of the known-safe lock order reversals that should be ignored? (The notice is from something like 4.5 hours before I noticed it.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvme on 2019 macbooks
Yuri Pankov wrote:
I have tried booting latest -current snapshot on 2019 macbook pro 16,
and noticed that nvme driver didn't attach, as class reported is
0x018002 and not 0x010802 that we expect in nvme_pci.c.
The following linux changes seem to be related:
https://github.com/torvalds/linux/commit/66341331ba0d2de4ff421cdc401a1e34de50502a
https://github.com/torvalds/linux/commit/d38e9f04ebf667d9cb8185b45bff747485f1d3e9
I have tried adding the exact PCI IDs, but that also fails as number of
msix vectors seems to be 0 in nvme_ctrlr_setup_interrupts() and
nvme_ctrlr_configure_intx() fails with "unable to allocate shared IRQ".
Any hints on how to proceed here?
So it looks like we need to fallback to MSI if we failed to enable
MSI-X. With the attached patch we still fail to attach the target
device (as below) most likely due to the quirks needed as seen in linux
driver, but it's definitely a start:
nvme0: CREATE IO CQ (05) sqid:0 cid:15 nsid:0 cdw10:0081 cdw11:00010003
nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme0: nvme_create_io_cq failed!
diff --git a/sys/dev/nvme/nvme_pci.c b/sys/dev/nvme/nvme_pci.c
index 448bfda6a718..e609967b53fe 100644
--- a/sys/dev/nvme/nvme_pci.c
+++ b/sys/dev/nvme/nvme_pci.c
@@ -90,6 +90,7 @@ static struct _pcsid
{ 0x05401c5f, 0, 0, "Memblaze Pblaze4",
QUIRK_DELAY_B4_CHK_RDY },
{ 0xa821144d, 0, 0, "Samsung PM1725", QUIRK_DELAY_B4_CHK_RDY
},
{ 0xa822144d, 0, 0, "Samsung PM1725a", QUIRK_DELAY_B4_CHK_RDY
},
+ { 0x2005106b, 0, 0, "ANS2 NVMe Controller" },
{ 0x, 0, 0, NULL }
};
@@ -267,7 +268,7 @@ nvme_ctrlr_setup_interrupts(struct nvme_controller *ctrlr)
force_intx = 0;
TUNABLE_INT_FETCH("hw.nvme.force_intx", _intx);
- if (force_intx || pci_msix_count(dev) < 2) {
+ if (force_intx) {
nvme_ctrlr_configure_intx(ctrlr);
return;
}
@@ -297,9 +298,14 @@ nvme_ctrlr_setup_interrupts(struct nvme_controller *ctrlr)
/* One vector for per core I/O queue, plus one vector for admin queue.
*/
num_vectors_requested = num_io_queues + 1;
num_vectors_allocated = num_vectors_requested;
+
+ /* Try MSI-X */
if (pci_alloc_msix(dev, _vectors_allocated) != 0) {
- nvme_ctrlr_configure_intx(ctrlr);
- return;
+ /* MSI-X failed, try MSI */
+ if (pci_alloc_msi(dev, _vectors_allocated) != 0) {
+ nvme_ctrlr_configure_intx(ctrlr);
+ return;
+ }
}
if (num_vectors_allocated < 2) {
pci_release_msi(dev);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
> On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> > In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste
> > Daroussin wr
> > ites:
> > >
> > >
> > > --vwrr5drfobpkyvop
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > > =20
> > > > depends on devel/ncurses instead of ncureses in base? The reason for
> > > > this=
> > > =20
> > > > is there are screen.* terminfo entries in devel/ncurses that don't
> > > > exist =
> > > in=20
> > > > termcap(5). People who want that extra functionality would be advised
> > > > to=
> > > =20
> > > > install the alternative pkg or build the sysutils/screen port with
> > > > the=20
> > > > appropriate option.
> > > >=20
> > > > Or, simply change the default from whatever ncurses is available to
> > > > alway=
> > > s=20
> > > > install devel/ncurses. People could always select one of the other
> > > > option=
> > > s.=20
> > > > Personally, I'm not enamoured with this approach.
> > >
> > > I think it is a terrible idea, and we should fix the initial problem
> > > instea=
> > > d of
> > > workarounding it.
> > >
> > > 1/ why those are not in our termcap(5) ? they should be added if they are
> > > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
> >
> > I came to this conclusion last night after sending this email thread oud
> > and will test it some time today.
> >
> > >
> > > 2/ we should allow our base ncurses to get informations from newer
> > > termcap(=
> > > 5) if
> > > needed.
> > > So far the default TERMCAP is
> > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> > >
> > > First the user can be advise to point configure the $home/.termcap this
> > > is =
> > > for
> > > quick now.
>
> that is in your scope via a pkg-message :D
>
> > >
> > > Second for later futur proof mechanism we could modify our termcap reader
> > > (=
> > > we
> > > use our own, not the one in provided by ncurses). to be able to fetch
> > > termc=
> > > ap
> > > capabilities from /usr/local/share/misc/termcap/*.conf for example
> > >
> > > This way ports with random termcap info to add would be able to do it
> > > witho=
> > > ut
> > > the requirement to wait for a commit in base and a MFC.
> >
> > This is probably outside of my scope at the moment but, yes, agreed.
> >
> I will then.
> I added that to my TODO
Thank you Bapt, I know a visually impared person that is battling in
this space often that this should help to reduce the pain level a
fair bit.
>
> Bestr regards,
> Bapt
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote:
> In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste
> Daroussin wr
> ites:
> >
> >
> > --vwrr5drfobpkyvop
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > > Would people be open to the idea of a sysutils/screen-ncurses port that=
> > =20
> > > depends on devel/ncurses instead of ncureses in base? The reason for this=
> > =20
> > > is there are screen.* terminfo entries in devel/ncurses that don't exist =
> > in=20
> > > termcap(5). People who want that extra functionality would be advised to=
> > =20
> > > install the alternative pkg or build the sysutils/screen port with the=20
> > > appropriate option.
> > >=20
> > > Or, simply change the default from whatever ncurses is available to alway=
> > s=20
> > > install devel/ncurses. People could always select one of the other option=
> > s.=20
> > > Personally, I'm not enamoured with this approach.
> >
> > I think it is a terrible idea, and we should fix the initial problem instea=
> > d of
> > workarounding it.
> >
> > 1/ why those are not in our termcap(5) ? they should be added if they are
> > missing. and MFC asap (prior 11.4 and 12.2 would be nice)
>
> I came to this conclusion last night after sending this email thread oud
> and will test it some time today.
>
> >
> > 2/ we should allow our base ncurses to get informations from newer termcap(=
> > 5) if
> > needed.
> > So far the default TERMCAP is
> > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
> >
> > First the user can be advise to point configure the $home/.termcap this is =
> > for
> > quick now.
that is in your scope via a pkg-message :D
> >
> > Second for later futur proof mechanism we could modify our termcap reader (=
> > we
> > use our own, not the one in provided by ncurses). to be able to fetch termc=
> > ap
> > capabilities from /usr/local/share/misc/termcap/*.conf for example
> >
> > This way ports with random termcap info to add would be able to do it witho=
> > ut
> > the requirement to wait for a commit in base and a MFC.
>
> This is probably outside of my scope at the moment but, yes, agreed.
>
I will then.
I added that to my TODO
Bestr regards,
Bapt
signature.asc
Description: PGP signature
Re: sysutils/screen-ncurses port
In message <20200430075337.3wdzglshhorcd...@ivaldir.net>, Baptiste
Daroussin wr
ites:
>
>
> --vwrr5drfobpkyvop
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> > Would people be open to the idea of a sysutils/screen-ncurses port that=
> =20
> > depends on devel/ncurses instead of ncureses in base? The reason for this=
> =20
> > is there are screen.* terminfo entries in devel/ncurses that don't exist =
> in=20
> > termcap(5). People who want that extra functionality would be advised to=
> =20
> > install the alternative pkg or build the sysutils/screen port with the=20
> > appropriate option.
> >=20
> > Or, simply change the default from whatever ncurses is available to alway=
> s=20
> > install devel/ncurses. People could always select one of the other option=
> s.=20
> > Personally, I'm not enamoured with this approach.
>
> I think it is a terrible idea, and we should fix the initial problem instea=
> d of
> workarounding it.
>
> 1/ why those are not in our termcap(5) ? they should be added if they are
> missing. and MFC asap (prior 11.4 and 12.2 would be nice)
I came to this conclusion last night after sending this email thread oud
and will test it some time today.
>
> 2/ we should allow our base ncurses to get informations from newer termcap(=
> 5) if
> needed.
> So far the default TERMCAP is
> ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
>
> First the user can be advise to point configure the $home/.termcap this is =
> for
> quick now.
>
> Second for later futur proof mechanism we could modify our termcap reader (=
> we
> use our own, not the one in provided by ncurses). to be able to fetch termc=
> ap
> capabilities from /usr/local/share/misc/termcap/*.conf for example
>
> This way ports with random termcap info to add would be able to do it witho=
> ut
> the requirement to wait for a commit in base and a MFC.
This is probably outside of my scope at the moment but, yes, agreed.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysutils/screen-ncurses port
On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote:
> Would people be open to the idea of a sysutils/screen-ncurses port that
> depends on devel/ncurses instead of ncureses in base? The reason for this
> is there are screen.* terminfo entries in devel/ncurses that don't exist in
> termcap(5). People who want that extra functionality would be advised to
> install the alternative pkg or build the sysutils/screen port with the
> appropriate option.
>
> Or, simply change the default from whatever ncurses is available to always
> install devel/ncurses. People could always select one of the other options.
> Personally, I'm not enamoured with this approach.
I think it is a terrible idea, and we should fix the initial problem instead of
workarounding it.
1/ why those are not in our termcap(5) ? they should be added if they are
missing. and MFC asap (prior 11.4 and 12.2 would be nice)
2/ we should allow our base ncurses to get informations from newer termcap(5) if
needed.
So far the default TERMCAP is
${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db}
First the user can be advise to point configure the $home/.termcap this is for
quick now.
Second for later futur proof mechanism we could modify our termcap reader (we
use our own, not the one in provided by ncurses). to be able to fetch termcap
capabilities from /usr/local/share/misc/termcap/*.conf for example
This way ports with random termcap info to add would be able to do it without
the requirement to wait for a commit in base and a MFC.
Best regards,
Bapt
signature.asc
Description: PGP signature
