Re: Where did the nvd devices go?
On Wed, Jun 21, 2023 at 8:47 PM Kevin Oberman wrote: > > Commands used were "gpart show nvd0" and "geli attach -d -k > /dev/nvd0p7". Also tried both with and without the "/dev" which fail for > nvd* and succeed with nda*. > Ah. I see the problem. libgeom doesn't parse the nodes, nor does it use them when searching for a geom by name... I need to carefully think about how to fix it, though, since it may be an ABI change and we're getting trickily close to 14 to be mucking with this... Warner
Re: Where did the nvd devices go?
On Wed, Jun 21, 2023 at 5:52 PM Warner Losh wrote: > > > On Wed, Jun 21, 2023, 6:22 PM Kevin Oberman wrote: > >> Well, they are still around, but not functional. They are symlinks to nda >> devices, but the symlinks don't work well. >> > > They work for filesystem access. > Not too surprised, but I didn't try it. Should have looked more closely before sending it. > > I have no idea when the symlink of nvd to nda happened, but after updating >> my system to main-n263630-ab3e6234ab6e, at least geom related commands no >> longer function using nvd0p?. I hit this when trying to use gpart and geli. >> gpart claims "gpart: No such geom: /dev/nvd0." geli responds (after >> entering a passphrase) "geli: Provider not found: "/dev/nvd0p7"My previous >> system version was main-n262908-c16e08e5f324. >> > > These will work with nda. They should likely work with the nvd aliases, > but don't it seems (though you don't need the /dev/ for geom commands). > > Was this just a failure of muscle memory, or was there persistent config > that failed? > Yes, I had confirmed that nda worked and I know that /dev is not required for geom commands, but I've never bothered to test whether gpt/label worked and I tend to use labels. > > Was this intentional? If so, why was this change made? If not, could it >> be fixed? Since I usually use geli with the /dev/gpt devices, I didn't >> notice it right away, but it could certainly surprise many users. >> > Commands used were "gpart show nvd0" and "geli attach -d -k /dev/nvd0p7". Also tried both with and without the "/dev" which fail for nvd* and succeed with nda*. All these questions are answered in the UPDATING entry from when I switched > the default: > I should have checked UPDATING. -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: Where did the nvd devices go?
On Wed, Jun 21, 2023, 6:22 PM Kevin Oberman wrote: > Well, they are still around, but not functional. They are symlinks to nda > devices, but the symlinks don't work well. > They work for filesystem access. I have no idea when the symlink of nvd to nda happened, but after updating > my system to main-n263630-ab3e6234ab6e, at least geom related commands no > longer function using nvd0p?. I hit this when trying to use gpart and geli. > gpart claims "gpart: No such geom: /dev/nvd0." geli responds (after > entering a passphrase) "geli: Provider not found: "/dev/nvd0p7"My previous > system version was main-n262908-c16e08e5f324. > These will work with nda. They should likely work with the nvd aliases, but don't it seems (though you don't need the /dev/ for geom commands). Was this just a failure of muscle memory, or was there persistent config that failed? Was this intentional? If so, why was this change made? If not, could it be > fixed? Since I usually use geli with the /dev/gpt devices, I didn't notice > it right away, but it could certainly surprise many users. > All these questions are answered in the UPDATING entry from when I switched the default: 20230612: Belatedly switch the default nvme block device on x86 from nvd to nda. nda created nvd compatibility links by default, so this should be a nop. If this causes problems for your application, set hw.nvme.use_nvd=1 in your loader.conf or add `options NVME_USE_NVD=1` to your kernel config. To disable the nvd compatibility aliases, add kern.cam.nda.nvd_compat=0 to loader.conf. The default has been nda on all non-x86 platforms for some time now. If you need to fall back, please email i...@freebsd.org about why. -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >
Where did the nvd devices go?
Well, they are still around, but not functional. They are symlinks to nda devices, but the symlinks don't work well. I have no idea when the symlink of nvd to nda happened, but after updating my system to main-n263630-ab3e6234ab6e, at least geom related commands no longer function using nvd0p?. I hit this when trying to use gpart and geli. gpart claims "gpart: No such geom: /dev/nvd0." geli responds (after entering a passphrase) "geli: Provider not found: "/dev/nvd0p7"My previous system version was main-n262908-c16e08e5f324. Was this intentional? If so, why was this change made? If not, could it be fixed? Since I usually use geli with the /dev/gpt devices, I didn't notice it right away, but it could certainly surprise many users. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: RTM_NEWNEIGH message for static ARP entry
On Wed, 21 Jun 2023, at 5:19 PM, Hartmut Brandt wrote: > Hi, > > when I set a static ARP entry I see an RTM_NEWNEIGH message on a netlink > socket as expected, but the ndm_state is NUD_INCOMPLETE. Should'nt this be > NUD_NOARP? At least this is what Linux returns. Thanks for the report, I’ll take a look. To me, NUD_REACHABLE | NUD_PERMANENT looks better suited for the particular case, but I’ll dive deeper tomorrow. Anyway NUD_INCOMPLETE is certainly wrong. > > Cheers, > Harti > > /Alexander
Re: panic: ASan: Invalid access, 1-byte read at ...
On Wed, Jun 21, 2023 at 10:06:28AM -0400, Mark Johnston wrote: > On Wed, Jun 21, 2023 at 11:53:44AM +0200, Peter Holm wrote: > > Just got this panic: > > > > 20230621 11:15:23 all (37/912): linux.sh > > panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, > > RedZonePartial(2) > > cpuid = 1 > > time = 1687338930 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame > > 0xfe01f16abc10 > > kdb_backtrace() at kdb_backtrace+0xc7/frame 0xfe01f16abd70 > > vpanic() at vpanic+0x1d7/frame 0xfe01f16abe30 > > panic() at panic+0xb5/frame 0xfe01f16abf00 > > kasan_report() at kasan_report+0xdc/frame 0xfe01f16abfd0 > > pfs_lookup() at pfs_lookup+0x2c2/frame 0xfe01f16ac0f0 > > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x91/frame 0xfe01f16ac130 > > vfs_cache_lookup() at vfs_cache_lookup+0x1f7/frame 0xfe01f16ac210 > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x91/frame 0xfe01f16ac250 > > vfs_lookup() at vfs_lookup+0xa0f/frame 0xfe01f16ac510 > > namei() at namei+0x679/frame 0xfe01f16ac690 > > vn_open_cred() at vn_open_cred+0xa94/frame 0xfe01f16aca10 > > kern_openat() at kern_openat+0x50d/frame 0xfe01f16acc70 > > linux_common_open() at linux_common_open+0x141/frame 0xfe01f16acd30 > > amd64_syscall() amd64_syscall+0x30f/frame 0xfast_syscall_common() at > > fast_syscall_common+0xf8/frame 0xfe01f16acf30 > > --- syscall (2, Linux ELF64, linux_open), rip = 0x8012ef7f0, rsp = > > 0x7fffa238, rbp = 0x7fffa290 --- > > KDB: enter: panic > > [ thread pid 31838 tid 100363 ] > > Stopped at kdb_enter+0x34: movq$0,0x1e3f7c1(%rip) > > db> > > > > Details @ https://people.freebsd.org/~pho/stress/log/log0450.txt > > Hi Peter, > > Thanks for the report. I believe this would be fixed by > https://reviews.freebsd.org/D40692 . Hi Mark, This works for me. - Peter
RTM_NEWNEIGH message for static ARP entry
Hi, when I set a static ARP entry I see an RTM_NEWNEIGH message on a netlink socket as expected, but the ndm_state is NUD_INCOMPLETE. Should'nt this be NUD_NOARP? At least this is what Linux returns. Cheers, Harti
Re: panic: ASan: Invalid access, 1-byte read at ...
On Wed, Jun 21, 2023 at 11:53:44AM +0200, Peter Holm wrote: > Just got this panic: > > 20230621 11:15:23 all (37/912): linux.sh > panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, > RedZonePartial(2) > cpuid = 1 > time = 1687338930 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfe01f16abc10 > kdb_backtrace() at kdb_backtrace+0xc7/frame 0xfe01f16abd70 > vpanic() at vpanic+0x1d7/frame 0xfe01f16abe30 > panic() at panic+0xb5/frame 0xfe01f16abf00 > kasan_report() at kasan_report+0xdc/frame 0xfe01f16abfd0 > pfs_lookup() at pfs_lookup+0x2c2/frame 0xfe01f16ac0f0 > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x91/frame 0xfe01f16ac130 > vfs_cache_lookup() at vfs_cache_lookup+0x1f7/frame 0xfe01f16ac210 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x91/frame 0xfe01f16ac250 > vfs_lookup() at vfs_lookup+0xa0f/frame 0xfe01f16ac510 > namei() at namei+0x679/frame 0xfe01f16ac690 > vn_open_cred() at vn_open_cred+0xa94/frame 0xfe01f16aca10 > kern_openat() at kern_openat+0x50d/frame 0xfe01f16acc70 > linux_common_open() at linux_common_open+0x141/frame 0xfe01f16acd30 > amd64_syscall() amd64_syscall+0x30f/frame 0xfast_syscall_common() at > fast_syscall_common+0xf8/frame 0xfe01f16acf30 > --- syscall (2, Linux ELF64, linux_open), rip = 0x8012ef7f0, rsp = > 0x7fffa238, rbp = 0x7fffa290 --- > KDB: enter: panic > [ thread pid 31838 tid 100363 ] > Stopped at kdb_enter+0x34: movq$0,0x1e3f7c1(%rip) > db> > > Details @ https://people.freebsd.org/~pho/stress/log/log0450.txt Hi Peter, Thanks for the report. I believe this would be fixed by https://reviews.freebsd.org/D40692 .
panic: ASan: Invalid access, 1-byte read at ...
Just got this panic: 20230621 11:15:23 all (37/912): linux.sh panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, RedZonePartial(2) cpuid = 1 time = 1687338930 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfe01f16abc10 kdb_backtrace() at kdb_backtrace+0xc7/frame 0xfe01f16abd70 vpanic() at vpanic+0x1d7/frame 0xfe01f16abe30 panic() at panic+0xb5/frame 0xfe01f16abf00 kasan_report() at kasan_report+0xdc/frame 0xfe01f16abfd0 pfs_lookup() at pfs_lookup+0x2c2/frame 0xfe01f16ac0f0 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x91/frame 0xfe01f16ac130 vfs_cache_lookup() at vfs_cache_lookup+0x1f7/frame 0xfe01f16ac210 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x91/frame 0xfe01f16ac250 vfs_lookup() at vfs_lookup+0xa0f/frame 0xfe01f16ac510 namei() at namei+0x679/frame 0xfe01f16ac690 vn_open_cred() at vn_open_cred+0xa94/frame 0xfe01f16aca10 kern_openat() at kern_openat+0x50d/frame 0xfe01f16acc70 linux_common_open() at linux_common_open+0x141/frame 0xfe01f16acd30 amd64_syscall() amd64_syscall+0x30f/frame 0xfast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f16acf30 --- syscall (2, Linux ELF64, linux_open), rip = 0x8012ef7f0, rsp = 0x7fffa238, rbp = 0x7fffa290 --- KDB: enter: panic [ thread pid 31838 tid 100363 ] Stopped at kdb_enter+0x34: movq$0,0x1e3f7c1(%rip) db> Details @ https://people.freebsd.org/~pho/stress/log/log0450.txt - Peter
Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?
Quoting Gary Jennejohn (from Tue, 20 Jun 2023 14:41:41 +): On Tue, 20 Jun 2023 12:04:13 +0200 Alexander Leidinger wrote: "listen X backlog=y" and "sysctl kern.ipx.somaxconn=X" for FreeBSD On my FreeBSD14 system these things are all under kern.ipc. Typo on my side... it was supposed to read ipc, not ipx. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpTjpqaetzBB.pgp Description: Digitale PGP-Signatur
