nvdXpY dissapears while ZFS pool on it is imported
Hi. By sets of commits starting from r351355 though r351747, nvd driver creates partitioned GEOM provider like /dev/nvd0p1. Unfortunately, these partitioned GEOM providers dissapears when importing ZFS pool on it leaving /dev/nvd0, and re-appears when exporting the pool. Mounting filesystems other than ZFS (at least msdosfs) doesn't affect. Details: I recently got ThinkPad P52 having one NVMe SSD and one 2.5 inch SATA SSD. NVMe SSD has stable/12 and SATA SSD has head on it. Both are partitioned and installed on old ThinkPad T420, using UltraBay slim adapter for SATA, and USB converter for NVMe, without using installer and placed into P52, removing Windoze HDD. Both are ROOT-on-ZFS. Swap on NVMe SSD is specified using diskid in fstab. At first, I didn't noticed the problem as head with before-mentioned commits gracefully creates nvd0p*. But I noticed stable/12 having before-mentioned commits MFC'ed (r351903 through r351914) creates only nvd0 just as before. Importing pool on SATA SSD from stable/12 on NVMe does NOT affect. I tried importing on NVMe SSD from head on SATA, and noticed nvd0p* disappears leaving nvd0, and re-appears on export. Any solutions? Regards. -- Tomoaki AOKI ___ 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"
FreeBSD CI Weekly Report 2019-09-29
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-09-29 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-09-23 to 2019-09-29. During this period, we have: * 2159 builds (98.6% (-0.4) passed, 1.4% (+0.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 340 test runs (71.5% (-5.7) passed, 20% (-2.8) unstable, 8.5% (+8.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 22 doc builds (100% passed) Test case status (on 2019-09-29 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | -- | -- | | | head/amd64 | 7588 (+21) | 7525 (+21) | 0 (0) | 63 (0) | | head/i386 | 7586 (+21) | 7514 (+21) | 0 (0) | 72 (0) | | 12-STABLE/amd64 | 7474 (0) | 7430 (0) | 0 (0) | 44 (0) | | 12-STABLE/i386 | 7472 (0) | 7421 (0) | 0 (0) | 51 (+3) | | 11-STABLE/amd64 | 6849 (0) | 6805 (0) | 0 (0) | 44 (0) | | 11-STABLE/i386 | 6847 (0) | 6767 (-3) | 34 (0) | 46 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20190929 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * [FCP 20190401-ci_policy: CI policy](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md) is in "feedback" state, please check and provide comments on -fcp@ and -hackers@ mailing lists. ## Fixed Tests * lib.libc.sys.mmap_test.mmap_truncate_signal * https://svnweb.freebsd.org/changeset/base/352807 * https://svnweb.freebsd.org/changeset/base/352869 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.amd64.arrays.t_dtrace_contrib.tst_uregsarray_d * https://bugs.freebsd.org/240358 * Fixed in head https://svnweb.freebsd.org/changeset/base/353107 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.netpfil.pf.forward.v4 (i386 only) * sys.netpfil.pf.forward.v6 (i386 only) * sys.netpfil.pf.set_tos.v4 (i386 only) https://bugs.freebsd.org/239380 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * sys.netpfil.common.tos.pf_tos (i386 only) https://bugs.freebsd.org/240086 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists:
Re: AMD Secure Encrypted Virtualization - FreeBSD Status?
Grarpamp,Tomasz, and all: Thanks for all the reference documents. I looked through them, and did some more research myself: Creating Secure Boot Keys --- 0. https://wiki.freebsd.org/SecureBoot A work in progress. --- 1. http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Need: openssl - pkg on freebsd efitools - not found freebsd, source available elswhere Note that efitools is dependent upon sbsigntool (aka sbsigntools), so you may need to install it, too. sbsigntool - not found freebsd, source available elswhere --- 2. https://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot Similar tools to Rod's, added osslsigncode as possible substitute for sbsigntool --- My situation in life does not really seem to demand secure boot as I can always wipe the drive and rebuild. However it was pointed out that malware can continue to hide in the bios cmos nvram, so there is really no hiding and yes, we do need to consider shaping up. I am a big fan of Rod Smith ( http://www.rodsbooks.com/ ) and use his rEFInd boot loader on both my machines. It was a little trouble to set up the first time, but well worth the effort. I suspect that creating secure boot keys is a bit more complicated, but I'm going to look into it deeper. Any help & suggestions would be appreciated. My trusty old 2014 HP Pavilion has it's HP vendor platform keys, but they are not enabled. I have it in CSM mode, not UEFI mode, hence no secure boot as uefi must be enabled for secure boot. My new Ryzen 7 3700X & MSI X570 motherboard has UEFI boot set, but secure boot is not enabled. I have not even "enrolled" the vendor keys yet. So I have a lab setup to play with two machines, old & new, and the time & patience to play with this. I do welcome any suggestions and help Clay On Thu, Oct 3, 2019 at 7:01 PM grarpamp wrote: > >> Just whose secure keys do you suggest? I go to a lot of trouble to > disable > >> secure boot so I can load any operating system I want. > > Some motherboards have BIOS that allows you to both > - Upload your own keys > - Delete all the spooky Microsoft keys > > Read the UEFI Secure Boot specification document. > Then paste all the key management specs into a ticket > with your motherboard vendor and get on them to publish > a BIOS release that has proper key management functions. > > Some BIOS makers have this as selectable options in their > BIOS reference build routines... ie: the motherboard maker doesn't > have to write any code, they just point and click, and the option > appears in a BIOS release for mobo end user customers. > > Sometimes you have to bug and escalate the mobo makers > and threaten to walk your next purchase to another mobo maker > to get them to cut and post the new BIOS release. > > https://www.uefi.org/ > https://uefi.org/learning_center/papers > https://uefi.org/specsandtesttools > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf > > > https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2019.pdf > > https://uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_2019.pdf > > > > The goal would be not to disable secure boot and have FreeBSD running > > with a secured bootloader :-) > > > > At the moment we have insecure boot + insecure kernel + possible > > encrypted data partition.. > > > would be really nice also to get UEFI BOOT compatible with SECURE BOOT > :-) > > Yes. > ___ > 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" > ___ 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: ZFS with 32-bit, non-x86 kernel
In message , Ian Le pore writes: >There have also been some bug reports as recently as 2017 indicating >that people are still doing this on small armv7 systems. I actually have a potential off-site backup server in my lab right now, consisting of a BeagleBoneBlack and two USB disks, seems to work. The basic scheme is a cronjob which: zfs import inl run various rsyncs zfs snapshot -r inl@$YYMMDDHHMM zfs export inl The import/export is so the USB disks spin down. Not sure if ZFS will croak the 512M RAM on other workloads, but for this one it seems to work fine so far. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: ZFS with 32-bit, non-x86 kernel
On 04.10.2019 21:37, Ian Lepore wrote: > On Fri, 2019-10-04 at 13:27 -0600, Warner Losh wrote: >> On Fri, Oct 4, 2019, 1:07 PM Dennis Clarke wrote: >> >>> On 10/4/19 10:05 AM, Andriy Gapon wrote: Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? If you do, could you please let me know? Along with uname -rmp output. Thank you! >>> >>> I don't know if that has even been attempted by anyone. The ZIL and ZFS >>> log comonents require substantial amounts of memory and I am not aware >>> of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD >>> current on RISC-V running fairly well with ZFS however that was a purely >>> rv64imafdc architecture. >>> >> >> In the FreeBSD 10 time frame I know people were running ZFS on arm7 boards. >> Iirc, there was a long list of tweaks needed to size of the ZIL. A quick >> google didn't find it. >> >> Otoh, I looked at ZFS for NanoBSD when it first came out. I gave up because >> the 256MB boards at the time made any kind of storage traffic ran things >> out of memory. >> >> Warner >> >> >> I will watch this thread with curiosity. > > There have been several threads about using zfs on armv7 over the > years. Some of them are from 2013 and indicate little sucess. Others, > from 2015, indicate it works... > > https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010607.html > https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010649.html > > There have also been some bug reports as recently as 2017 indicating > that people are still doing this on small armv7 systems. > > -- Ian Following this thread, where Bernd Walter wrote small howto: https://lists.freebsd.org/pipermail/freebsd-arm/2019-February/019455.html I had converted root filesystem to ZFS on SD card used with RaspberryPi2, then used it with no issues running 13-CURRENT for 6 months until that old SD card got worn. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: radeon panics kernels
On Fri, Oct 04, 2019 at 12:17:30PM -0700, Johannes Lundberg wrote: > On Fri, Oct 4, 2019 at 11:39 Steve Kargl > wrote: > > > On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > > > On 2019-10-03 22:26, Steve Kargl wrote: > > > > > > > > So, your guess of a NULL pointer seems correct. > > > > > > Can you do: > > > > > > set print pretty on > > > print *rdev > > > > > > > This produces close to 3400 lines of output. Do you want me to > > send it to the list or directly to you? > > Please put on gist, pastebin, etc and share the link. > https://pastebin.com/0iHtWP9C -- Steve ___ 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: ZFS with 32-bit, non-x86 kernel
On Fri, 2019-10-04 at 13:27 -0600, Warner Losh wrote: > On Fri, Oct 4, 2019, 1:07 PM Dennis Clarke wrote: > > > On 10/4/19 10:05 AM, Andriy Gapon wrote: > > > > > > Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? > > > If you do, could you please let me know? Along with uname -rmp output. > > > Thank you! > > > > > > > I don't know if that has even been attempted by anyone. The ZIL and ZFS > > log comonents require substantial amounts of memory and I am not aware > > of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD > > current on RISC-V running fairly well with ZFS however that was a purely > > rv64imafdc architecture. > > > > In the FreeBSD 10 time frame I know people were running ZFS on arm7 boards. > Iirc, there was a long list of tweaks needed to size of the ZIL. A quick > google didn't find it. > > Otoh, I looked at ZFS for NanoBSD when it first came out. I gave up because > the 256MB boards at the time made any kind of storage traffic ran things > out of memory. > > Warner > > > I will watch this thread with curiosity. There have been several threads about using zfs on armv7 over the years. Some of them are from 2013 and indicate little sucess. Others, from 2015, indicate it works... https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010607.html https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010649.html There have also been some bug reports as recently as 2017 indicating that people are still doing this on small armv7 systems. -- Ian ___ 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: ZFS with 32-bit, non-x86 kernel
On Fri, Oct 4, 2019, 1:07 PM Dennis Clarke wrote: > On 10/4/19 10:05 AM, Andriy Gapon wrote: > > > > Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? > > If you do, could you please let me know? Along with uname -rmp output. > > Thank you! > > > > I don't know if that has even been attempted by anyone. The ZIL and ZFS > log comonents require substantial amounts of memory and I am not aware > of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD > current on RISC-V running fairly well with ZFS however that was a purely > rv64imafdc architecture. > In the FreeBSD 10 time frame I know people were running ZFS on arm7 boards. Iirc, there was a long list of tweaks needed to size of the ZIL. A quick google didn't find it. Otoh, I looked at ZFS for NanoBSD when it first came out. I gave up because the 256MB boards at the time made any kind of storage traffic ran things out of memory. Warner I will watch this thread with curiosity. > > > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > GreyBeard and suspenders optional > ___ > 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" > ___ 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: ZFS with 32-bit, non-x86 kernel
On Fri, 4 Oct 2019 15:06:52 -0400 Dennis Clarke wrote: > On 10/4/19 10:05 AM, Andriy Gapon wrote: > > > > Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? > > If you do, could you please let me know? Along with uname -rmp > > output. Thank you! > > > > I don't know if that has even been attempted by anyone. The ZIL and > ZFS log comonents require substantial amounts of memory and I am not > aware of anyone with arm devices that have 8GB+ of memory. I have had > FreeBSD current on RISC-V running fairly well with ZFS however that > was a purely rv64imafdc architecture. > > I will watch this thread with curiosity. > > I did try using ZFS on 32-bit powerpc (8GB RAM), and even got a bugfix pushed into the ZFS/Illumos repo for it, but it was too unstable to be usable. I'd love to try again later though. - Justin ___ 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: radeon panics kernels
On Fri, Oct 4, 2019 at 11:39 Steve Kargl wrote: > On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > > On 2019-10-03 22:26, Steve Kargl wrote: > > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > > >> > > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think > you > > >> can get away with: > > >> > > >> make DEBUG_FLAGS="-g" > > >> > > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > > >> symbol files for the modules loaded. Then get the backtrace using bt > > >> command. > > >> > > >> BTW: Did you try drm-devel-kmod for 13-current? > > >> > > > > > > Took a bit of trial and error. If I skip the panic > > > and trap frames (#0 through #8). I find the backtrace > > > that follows by sig. If I move to frame #11, I see > > > > > > (kgdb) frame 11 > > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) > > > at > /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 > > > 4114writel(reg, ((void __iomem *)rdev->rmmio) + > RADEON_MM_INDEX); > > > (kgdb) p rdev->rmmio > > > $3 = (void *) 0x0 > > > > > > So, your guess of a NULL pointer seems correct. > > > > Can you do: > > > > set print pretty on > > print *rdev > > > > This produces close to 3400 lines of output. Do you want me to > send it to the list or directly to you? Please put on gist, pastebin, etc and share the link. > > -- > Steve > ___ 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: ZFS with 32-bit, non-x86 kernel
On 10/4/19 10:05 AM, Andriy Gapon wrote: Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? If you do, could you please let me know? Along with uname -rmp output. Thank you! I don't know if that has even been attempted by anyone. The ZIL and ZFS log comonents require substantial amounts of memory and I am not aware of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD current on RISC-V running fairly well with ZFS however that was a purely rv64imafdc architecture. I will watch this thread with curiosity. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: radeon panics kernels
On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > On 2019-10-03 22:26, Steve Kargl wrote: > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > >> > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think you > >> can get away with: > >> > >> make DEBUG_FLAGS="-g" > >> > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > >> symbol files for the modules loaded. Then get the backtrace using bt > >> command. > >> > >> BTW: Did you try drm-devel-kmod for 13-current? > >> > > > > Took a bit of trial and error. If I skip the panic > > and trap frames (#0 through #8). I find the backtrace > > that follows by sig. If I move to frame #11, I see > > > > (kgdb) frame 11 > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) > > at > > /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 > > 4114writel(reg, ((void __iomem *)rdev->rmmio) + > > RADEON_MM_INDEX); > > (kgdb) p rdev->rmmio > > $3 = (void *) 0x0 > > > > So, your guess of a NULL pointer seems correct. > > Can you do: > > set print pretty on > print *rdev > This produces close to 3400 lines of output. Do you want me to send it to the list or directly to you? -- Steve ___ 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"
drmn0: failed to add firmware with name radeonlsi58_mc_bin
Failed to load mc firmware ... is what I get when rebuilding kernel and with kmod-legacy: Success: oland_snc.bin si_fw: mixing new and old firmware. suggestions? -- Miranda ___ 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"
ZFS with 32-bit, non-x86 kernel
Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? If you do, could you please let me know? Along with uname -rmp output. Thank you! -- Andriy Gapon ___ 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"
