Re: CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives?
On Jun 29, 2023 at 11:36 AM -0500, FreeBSD User , wrote: > Am Thu, 29 Jun 2023 16:41:51 +0200 > Guido Falsi schrieb: > > > On 29/06/23 16:35, FreeBSD User wrote: > > > Hello, > > > > > > running a recent CURRENT, 14.0-CURRENT #10 main-n263871-fd774e065c5d: Thu > > > Jun 29 05:26:55 > > > CEST 2023 amd64, xfreerdp (net/freerdp) doesn't working anymore on > > > Windows 10 guest in > > > bhyve. It seems OpenSSL 3 is the culprit (see the error message from > > > xfreerdp below). I > > > opened already a PR (see: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272281). In a > > > very quick response I was informed that recent FreeRDP doesn't support > > > OpenSSL 3 yes > > > (https://github.com/FreeRDP/FreeRDP/pull/8920). > > > > > > Checking for HowTo's setting up bhyve guests, I dodn't realise any > > > setting for > > > alternatives to RDP. As I do not fully understand how bhyve passes > > > through its guest's > > > framebuffer device/ or native GUI, I'm a bit helpless in searching for > > > another solution to > > > contact the Windows10 guest from the X11 desktop of the hosts. > > > > > > Trying remmina turns out to be a fail, because in our installation > > > libsoup2 and libsoup3 > > > are installed both and remmina complains about having both symbols, also > > > I realised > > > remmina seems to utilize net/freerdb as the RDP backend. > > > > > > Since I have no clue how to install "blindly" a VNCserver within the > > > Windows10 guest, I > > > presume VNC is not an option in any way. > > > > > > Is there any way to access the bhyve guest's native graphical interface? > > > As in the PR shown > > > above already documented (setup taken from the FreeBSD Wiki/bhyve), a > > > framebuffer is > > > already configured. > > > > > > It would be nice if someone could give a hint. > > > > > > > I had the same issue, with Windows 10 pro hosts, but the fault is in > > windows, which, by default, tries to negotiate an ancient protocol (NTLM > > using RC4 if I understand correctly). > > > > With modern windows RDP servers there are better protocols available, > > you can get them in remmina by forcing "TLS protocolo security" in the > > advanced tab, security protocol negotiation (second row). > > > > Doing this (after some experimentation with various options) solved the > > issue for me. > > > > Thank you very much for the quick response. > > net/remmina is not an option on most of my workstations, since some required > ports install > libsoup3, and remmina complains about having found libsoup2 symbols as well > as libsoup3 > symbols when starting up - and quits. > > Since remmina utilises net/freerdp, I was wondering if I could enforce TLS > security by any > kind of a switch, and trying the following > > xfreerdp /v:192.168.0.128:5900 /u:ohartmann /sec:tls > > resulting in > > [...] > [17:58:18:972] [1702:bb812700] [WARN][com.winpr.utils.ssl] - OpenSSL LEGACY > provider failed to > load, no md4 support available! > [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read > returned an > error: error:12800067:DSO support routines::could not load the shared library > [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read > returned an > error: error:12800067:DSO support routines::could not load the shared library > [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read > returned an > error: error:07880025:common libcrypto routines::reason(524325) [17:58:18:973] > [1702:bb812700] [ERROR][com.freerdp.core] - > transport_read_layer:freerdp_set_last_error_ex > ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] > [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core.transport] - BIO_read > returned a > system error 35: Resource temporarily unavailable > [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] - > transport_read_layer:freerdp_set_last_error_ex > ERRCONNECT_CONNECT_TRANSPORT_FAILED > [0x0002000D] [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] - > freerdp_post_connect > failed > > > My setup is > > bhyve -c 4 -m 4G -w -H \ > -s 0,hostbridge \ > -s 3,ahci-hd,/pool/home/ohartmann/bhyve/win10/disk_win10.img \ > -s 5,virtio-net,tap0 \ > -s 29,fbuf,tcp=0.0.0.0:5900,w=1920,h=1200,vga=io \ > -s 30,xhci,tablet \ > -s 31,lpc \ > -l com1,stdio \ > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ > win10 > > and this is a working image setup a couple of weeks ago when VBox has been > defective on > CURRENT - should say: it worked once. > > I can not interpret the error above. > > bhyve is novel to me and I have to admit that I make some capital mistakes > here - but can't > find satisfying doucumentation ... > > Kind reagrds, > > Oliver RDP would be on the guest's IP using port 3389. Port 5900 on the host's IP is bhyve's VNC port, which speaks VNC, not RDP. If you want to use VNC, try TigerVNC. -Dustin
VNET lock reversal
Just updated my -CURRENT box from a build almost exactly 14 days ago to one just about an hour old. When a VNET jail starts, I'm seeing a lock reversal: lock order reversal: 1st 0x81e893a8 allprison (allprison, sx) @ /usr/src/sys/kern/kern_jail.c:1378 2nd 0x81f99fe8 vnet_sysinit_sxlock (vnet_sysinit_sxlock, sx) @ /usr/src/sys/net/vnet.c:579 lock order allprison -> vnet_sysinit_sxlock attempted at: #0 0x80c9b7c6 at witness_checkorder+0xbd6 #1 0x80c35c67 at _sx_slock_int+0x67 #2 0x80d92185 at vnet_alloc+0x115 #3 0x80be7e02 at kern_jail_set+0x1722 #4 0x80be92f0 at sys_jail_set+0x40 #5 0x811200aa at amd64_syscall+0x13a #6 0x810f12eb at fast_syscall_common+0xf8 I'll try and see if I can get a bisect going if somebody else hasn't seen this yet. -Dustin
Re: Kernel panic in networking code
On Thu, Dec 9, 2021 at 12:35 PM Shawn Webb wrote: > > On Thu, Dec 09, 2021 at 12:05:30PM -0500, Mark Johnston wrote: > > On Thu, Dec 09, 2021 at 10:20:10AM -0500, Shawn Webb wrote: > > > Hey all, > > > > > > It looks like there's a potential deadlock in some networking code, > > > specifically with ipv4 jails. I can reproduce by running Poudriere on > > > 14-CURRENT. > > > > > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > > > any point in the code paths that would trigger/cause this kind of > > > kernel panic. > > > > > > I've uploaded the crash.txt file here: > > > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt > > > > There is some WIP to address this in https://reviews.freebsd.org/D9 > > and its followup revision. > > Awesome. Thanks for the response! I'll follow along. I'm happy to test > out the patch before it lands if needed/wanted. I've been running glebius's revised D9 patch from Friday on my HardenedBSD -CURRENT box since he posted it, and I haven't had any jail related issues since. Granted I'm not running pourdriere builds either, but I guess I could kick one off... -Dustin
Re: 14.0-CURRENT panic in early boot
Just a quick update.. A kernel built from today boots just fine, so whatever the problem was, it's already fixed :). -Dustin On Thu, Nov 18, 2021 at 3:54 PM Dustin Marquess wrote: > > It was 16 days ago, so just a tad over 2 weeks :). > > Indeed, I'll start a bisect here in a few and I'll update as soon as I > know. I figured I'd ask ahead of time before I did the work :). > > Thanks! > -Dustin > > On Thu, Nov 18, 2021 at 12:29 PM Juraj Lutter wrote: > > > > > > > > On 18 Nov 2021, at 18:46, Karel Gardas wrote: > > > > > > Completely speculating, but since you don't see ioapic's are you sure this > > is just ~2 weeks old build? If not, then it may be relevant to: > > > > > > Bisecting would be a better approach. > > > > otis > > > > > > commit 1b7a2680fba589daf6f700565214919cb941ab56 > > Author: Jung-uk Kim > > Date: Thu Sep 30 16:23:21 2021 -0400 > > > >Import ACPICA 20210930 > > > >(cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) > > > > > > > > — > > Juraj Lutter > > XMPP: juraj (at) lutter.sk > > GSM: +421907986576 > >
Re: 14.0-CURRENT panic in early boot
It was 16 days ago, so just a tad over 2 weeks :). Indeed, I'll start a bisect here in a few and I'll update as soon as I know. I figured I'd ask ahead of time before I did the work :). Thanks! -Dustin On Thu, Nov 18, 2021 at 12:29 PM Juraj Lutter wrote: > > > > On 18 Nov 2021, at 18:46, Karel Gardas wrote: > > > Completely speculating, but since you don't see ioapic's are you sure this is > just ~2 weeks old build? If not, then it may be relevant to: > > > Bisecting would be a better approach. > > otis > > > commit 1b7a2680fba589daf6f700565214919cb941ab56 > Author: Jung-uk Kim > Date: Thu Sep 30 16:23:21 2021 -0400 > >Import ACPICA 20210930 > >(cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) > > > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 >
14.0-CURRENT panic in early boot
I just updated a machine from a build that was ~2 weeks old. The latest commit when I built it was 2e946f87055. The system boots using UEFI, if that matters. The system is panicking pretty early in the boot, however: real memory = 137438953472 (131072 MB) avail memory = 133651496960 (127460 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. kernel trap 12 with interrupts disabled panic: vm_fault_lookup: fault on nofault entry, addr: 0x81e1d000 cpuid = 0 time = 1 The backtrace shows: KDB: stack backtrace: #0 0x806deb5b at kdb_backtrace+0x6b #1 0x80693b44 at vpanic+0x184 #2 0x806939b3 at panic+0x43 #3 0x8091d4b3 at vm_fault+0x1423 #4 0x8091bfb0 at vm_fault_trap+0xb0 #5 0x809c0902 at trap_pfault+0x1f2 #6 0x809992b8 at calltrap+0x8 #7 0x806ebcc1 at vsscanf+0x31 #8 0x806ebc7f at sscanf+0x3f #9 0x806bd9ab at validate_uuid+0x8b #10 0x80655be0 at prison0_init+0x90 #11 0x80623aba at proc0_init+0x29a #12 0x80623689 at mi_startup+0xe9 #13 0x802e3062 at btext+0x22 Uptime: 1s Compared to a boot using the old working kernel: real memory = 137438953472 (131072 MB) avail memory = 133651505152 (127460 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-23 ioapic1 irqs 24-47 ioapic2 irqs 48-71 Launching APs: 1 11 28 15 18 6 29 4 16 9 24 7 3 10 27 22 14 13 12 23 25 20 26 30 17 5 2 21 19 8 31 Timecounter "TSC-low" frequency 1197250876 Hz quality 1000 Has anybody else seen this? -Dustin
Re: New loader_lua.efi causes kernels to hang at boot
On Tue, Aug 31, 2021 at 2:06 AM Konstantin Belousov wrote: > On Tue, Aug 31, 2021 at 01:29:27AM -0500, Dustin Marquess wrote: > > On Mon, Aug 30, 2021 at 4:33 AM Konstantin Belousov > wrote: > > > > > On Sun, Aug 29, 2021 at 08:27:02PM -0500, Dustin Marquess wrote: > > > > I am upgrading a -CURRENT box from a build that's exactly 2 weeks > old to > > > > one I built about 2 hours ago. After installkernel I updated the > > > bootloader > > > > the same way I normally do: > > > > > > > > # mount_msdosfs /dev/da8p1 /mnt > > > > # cp /mnt/EFI/BOOT/BOOTX64.efi /mnt/EFI/BOOT/BOOTX64.bak > > > > # cp loader_lua.efi /mnt/EFI/BOOT/BOOTX64.efi > > > > # umount /mnt > > > > > > > > After rebooting, however, the kernel hangs right after: > > > > > > > > real memory = 137438953472 (131072 MB) > > > > avail memory = 133651951616 (127460 MB) > > > > ACPI APIC Table: > > > > > > > > It never makes it to this line: > > > > > > > > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > > > > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > > > > > > > > So I rebooted a selected kernel.old at the boot menu and.. same > thing. > > > > That's strange! > > > > > > > > So I booted off a USB stick, mounted the EFI partition and copied > > > > BOOTX64.bak back to BOOTX64.efi and now the machine booted normally. > > > > > > > > So for some reason the newer loader_lua.efi is causing both the new > > > kernel > > > > AND the old kernel to hang, but the older loader_lua.efi seems to > work > > > with > > > > both no problem. > > > > > > Show your loader.conf. > > > > > > Try to add > > > exec="copy_staging enable" > > > line to it, does it hide the problem? > > > > > > > Indeed, it does! > > > > Full loader.conf is: > > > > I hope that 9939af1a161e5c219ece5e7c5 would fix the problem for you, > i.e. system should boot with and without the exec line in loader.conf. > Indeed it does! Boots perfectly with and without the setting. Thanks for the fast fix! -Dustin
Re: New loader_lua.efi causes kernels to hang at boot
On Mon, Aug 30, 2021 at 4:33 AM Konstantin Belousov wrote: > On Sun, Aug 29, 2021 at 08:27:02PM -0500, Dustin Marquess wrote: > > I am upgrading a -CURRENT box from a build that's exactly 2 weeks old to > > one I built about 2 hours ago. After installkernel I updated the > bootloader > > the same way I normally do: > > > > # mount_msdosfs /dev/da8p1 /mnt > > # cp /mnt/EFI/BOOT/BOOTX64.efi /mnt/EFI/BOOT/BOOTX64.bak > > # cp loader_lua.efi /mnt/EFI/BOOT/BOOTX64.efi > > # umount /mnt > > > > After rebooting, however, the kernel hangs right after: > > > > real memory = 137438953472 (131072 MB) > > avail memory = 133651951616 (127460 MB) > > ACPI APIC Table: > > > > It never makes it to this line: > > > > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > > > > So I rebooted a selected kernel.old at the boot menu and.. same thing. > > That's strange! > > > > So I booted off a USB stick, mounted the EFI partition and copied > > BOOTX64.bak back to BOOTX64.efi and now the machine booted normally. > > > > So for some reason the newer loader_lua.efi is causing both the new > kernel > > AND the old kernel to hang, but the older loader_lua.efi seems to work > with > > both no problem. > > Show your loader.conf. > > Try to add > exec="copy_staging enable" > line to it, does it hide the problem? > Indeed, it does! Full loader.conf is: comconsole_speed="115200" console="comconsole" boot_serial="1" zfs_load="YES" vfs.root.mountfrom="zfs:zroot/ROOT/default" net.isr.maxthreads="32" net.isr.bindthreads="1" net.isr.maxqlimit="60480" net.link.ifqmaxlen="9" kern.eventtimer.et.LAPIC.quality="1" hw.pci.do_power_nodriver="3" vfs.zfs.arc_max="8G" zpool_cache_load="YES" zpool_cache_type="/etc/zfs/zpool.cache" zpool_cache_name="/etc/zfs/zpool.cache" hint.apic.0.clock="0" hint.atrtc.0.clock="0" hint.attimer.0.clock="0" hint.hpet.0.legacy_route="1" kern.geom.label.disk_ident.enable="0" kern.geom.label.gptid.enable="0" if_cxgbe_load="NO" if_vlan_load="YES" if_tap_load="YES" if_bridge_load="YES" if_epair_load="NO" if_lagg_load="YES" vmm_load="YES" ioat_load="YES" hw.x2apic_enable="1" hw.cxgbe.nrxq="32" hw.cxgbe.ntxq="32" hw.cxgbe.fl_pktshift="0" hw.cxgbe.cong_drop="1" hw.cxgbe.pause_settings="0" hw.cxgbe.rdmacaps_allowed="0" hw.cxgbe.iscsicaps_allowed="0" hw.cxgbe.fcoecaps_allowed="0" cc_htcp_load="YES" machdep.hyperthreading_allowed="1" machdep.hyperthreading_intr_allowed="1" cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" vm.pmap.pti="0" machdep.mitigations.rngds.enable="0" machdep.mitigations.taa.enable="0" machdep.mitigations.mds.disable="0" machdep.mitigations.ssb.disable="0" machdep.mitigations.ibrs.disable="1" exec="copy_staging enable"
New loader_lua.efi causes kernels to hang at boot
I am upgrading a -CURRENT box from a build that's exactly 2 weeks old to one I built about 2 hours ago. After installkernel I updated the bootloader the same way I normally do: # mount_msdosfs /dev/da8p1 /mnt # cp /mnt/EFI/BOOT/BOOTX64.efi /mnt/EFI/BOOT/BOOTX64.bak # cp loader_lua.efi /mnt/EFI/BOOT/BOOTX64.efi # umount /mnt After rebooting, however, the kernel hangs right after: real memory = 137438953472 (131072 MB) avail memory = 133651951616 (127460 MB) ACPI APIC Table: It never makes it to this line: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads So I rebooted a selected kernel.old at the boot menu and.. same thing. That's strange! So I booted off a USB stick, mounted the EFI partition and copied BOOTX64.bak back to BOOTX64.efi and now the machine booted normally. So for some reason the newer loader_lua.efi is causing both the new kernel AND the old kernel to hang, but the older loader_lua.efi seems to work with both no problem. Any ideas? Thanks! -Dustin
mtu setting in rc.conf
I upgraded a 14-CURRENT system from a build about 2 months old to current. In my /etc/rc.conf, I have: cloned_interfaces="lagg0 lagg1 tap0 tap1 tap2 bridge0 bridge1 bridge2 vlan1 vlan2" ifconfig_cxl0="txcsum txcsum6 lso mtu 9000 up" ifconfig_cxl1="txcsum txcsum6 lso mtu 9000 up" ifconfig_cxl2="txcsum txcsum6 lso mtu 9000 up" ifconfig_cxl3="txcsum txcsum6 lso mtu 9000 up" ifconfig_lagg0="laggproto lacp lagghash l3,l4 laggport cxl0 laggport cxl1 laggport cxl2 laggport cxl3 txcsum txcsum6 lso mtu 9000" ifconfig_tap2="mtu 9000" ifconfig_bridge2="inet 203.0.113.101/24 addm lagg0 addm tap2 mtu 9000" ifconfig_bridge2_ipv6="inet6 2001:db8::101/64" ifconfig_bridge2_alias0="inet 203.0.113.10 netmask 255.255.255.255" [ Other interfaces trimmed ] This has worked for years. Now, however, bridge2 & lagg0 aren't getting the mtu 9000 setting, therefore tap2 isn't added to the bridge at startup, and somehow the main IP on bridge2 isn't getting set because of that. Removing "addm tap2" from ifconfig_bridge2 allows everything to come up, including the main IP, but lagg0 & bridge2 are still at mtu 1500. Setting them to 9000 by hand and then adding tap2 by hand works. I tried moving the "mtu 9000" to the beginning of the line, but that didn't seem to fix it. Has something changed recently with this? Thanks! -Dustin ___ 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"
How to clear the 'remove:' line from 'zpool status'
So I stupidly did a 'zpool add' instead of a 'zpool attach'. Luckily I was able to 'zpool remove' the device thanks to the remove work done a while back. However, now I can't for the life of me get this part of the 'zpool status' output to go away: pool: zroot state: ONLINE scan: scrub repaired 0B in 00:01:06 with 0 errors on Fri Dec 4 18:18:31 2020 remove: Removal of vdev 1 copied 104K in 0h0m, completed on Fri Dec 4 18:10:08 2020 72 memory used for removed device mappings config: I've tried 'zppol clear', 'zpool scrub', and rebooted. Is there some way to clear that 'remove' line? It's irritating my OCD :(. Thanks! -Dustin ___ 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: iflib/bridge kernel panic
On Sat, Oct 3, 2020 at 2:54 PM Felix Kronlage-Dammers wrote: > > Alexander Leidinger wrote on 03.10.20 17:37: > > > Quoting Kristof Provost (from Sat, 03 Oct 2020 16:06:43 > > +0200): > > >> Okay, let’s abandon that patch. It’s ugly and it doesn’t work. > >> > >> Here’s a different approach that I’m much happier with. > >> https://people.freebsd.org/~kp/0001-bridge-Call-member-interface-ioctl-without-NET_EPOCH.patch > >> > >> > >> It passes the regression tests with WITNESS and INVARIANTS enabled, > >> and a hack in the epair ioctl() handler to make it sleep (to look a > >> bit like the Intel ioctl() handler that currently trips up if_bridge). > > Works for me. > > No crash, no LOR, promisc-mode stays enabled, jails are reachable. > > indeed! I can second that. Works nicely, my machine does not panic > anymore and machines (bhyve vms) behind the bridge are reachable. I third that, it works great for me! -Dustin ___ 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: iflib/bridge kernel panic
On Tue, Sep 29, 2020 at 4:21 PM Kristof Provost wrote: > > On 28 Sep 2020, at 16:44, Alexander Leidinger wrote: > > > Quoting Kristof Provost (from Mon, 28 Sep 2020 > > 13:53:16 +0200): > > > >> On 28 Sep 2020, at 12:45, Alexander Leidinger wrote: > >>> Quoting Kristof Provost (from Sun, 27 Sep 2020 > >>> 17:51:32 +0200): > Here’s an early version of a task queue based approach: > http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch > > That still needs to be cleaned up, but this should resolve the > sleep issue and the LOR. > >>> > >>> There are some issues... seems like inside a jail I can't ping > >>> systems outside of the hardware. So similar to the others, kind of. Using the original https://reviews.freebsd.org/D26418 patch, everything seems to work fine. Using the newer http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch patch, byhve VMs on the bridge attached to the igb/em(5) interfaces don't pass traffic. The bhyve VMs on the bridge attached to the cxgbe(4) interfaces, however, work fine. -Dustin ___ 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"
USB drives & OpenZFS
There seems to be a problem with OpenZFS when shutting down a machine that boots from USB. My machine has two SD cards in an adapter board that plugs into an internal USB port on the motherboard. On these two cards I have the UEFI loader and a mirror zpool containing just the bare minimum to boot. Once the machine boots, it mounts the "big" SAS tank containing everything else. This worked perfectly and still works mostly after the OpenZFS merge. The only problem now is shutting down/rebooting. if I try to reboot, it hangs: Freed UMA keg (rtentry) was not empty (1 items). Lost 1 pages of memory. Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... done All buffers synced. Uptime: 1h52m34s uhub4: detached uhub2: detached uhub3: detached uhub1: detached uplcom0: detached umass0: detached Solaris: WARNING: Pool 'zroot' has encountered an uncorrectable I/O failure and has been suspended. I'm guessing it's because it appears that the USB subsystem shuts down before the pool itself? Once this happens I have to reset the machine via IPMI to get everything to boot back up. Has anybody else seen this? Thanks! -Dustin ___ 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: kldref: too many segments on kernel build
On Tue, Aug 18, 2020 at 3:19 PM Michael Butler wrote: > > Any thoughts as to why this is happening when I build a (custom) kernel? > > kldxref: /boot/kernel/kernel: too many segments I'm seeing this too. I haven't tried actually booting the kernel because of this. -Dustin ___ 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: -CURRENT fatal trap cause by cxgbe module
On Mon, Mar 2, 2020 at 6:55 PM Ryan Libby wrote: > > On Sun, Mar 1, 2020 at 8:07 PM Dustin Marquess wrote: > > > > So I've been fighting with any current from the last month or so > > instantly crashing when I boot it. I did notice that kernels in the > > various snapshot images were working, however, so I was trying to > > figure out why. At first I thought it was because I had INVARIANTS > > and such disabled, but no, I finally figured it out. > > > > I've had in my /boot/loader.conf for a while now: > > > > if_cxgbe_load="YES" > > > > I guess since the stock installer kernels don't have cxgbe enabled by > > default. I added "device cxgbe" to my kernels a while ago. Normally > > the kernel would give some error about the module already being loaded > > or something and just continue. As of last month or so, however, > > instead it just crashes: > > > > FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git > > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > > WARNING: WITNESS option enabled, expect reduced performance. > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x8 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x80622931 > > stack pointer = 0x28:0x8241c9a0 > > frame pointer = 0x28:0x8241c9e0 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = resume, IOPL = 0 > > current process = 0 () > > trap number = 12 > > panic: page fault > > cpuid = 0 > > time = 1 > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0x8241c600 > > vpanic() at vpanic+0x18a/frame 0x8241c660 > > panic() at panic+0x43/frame 0x8241c6c0 > > trap_fatal() at trap_fatal+0x386/frame 0x8241c720 > > trap_pfault() at trap_pfault+0x99/frame 0x8241c7a0 > > trap() at trap+0x4e9/frame 0x8241c8d0 > > calltrap() at calltrap+0x8/frame 0x8241c8d0 > > --- trap 0xc, rip = 0x80622931, rsp = 0x8241c9a0, rbp > > = 0x8241c9e0 --- > > malloc() at malloc+0x51/frame 0x8241c9e0 > > sysctl_handle_string() at sysctl_handle_string+0x12d/frame > > 0x8241ca20 > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0xa2/frame > > 0x8241ca70 > > sysctl_register_oid() at sysctl_register_oid+0x54c/frame 0x8241cd80 > > sysctl_register_all() at sysctl_register_all+0x88/frame 0x8241cda0 > > mi_startup() at mi_startup+0xf2/frame 0x8241cdf0 > > btext() at btext+0x2c > > KDB: enter: panic > > [ thread pid 0 tid 0 ] > > Stopped at kdb_enter+0x37: movq$0,0xa5f4a6(%rip) > > db> > > > > If I take the if_cxgbe_load out, however, it boots fine. > > You maybe also have something defined in your /boot/loader.conf that > causes a tunable to be set? > > It looks like there's just an ordering bug in kern_sysctl.c, where we > call sysctl_register_all() with SI_SUB_KMEM, SI_ORDER_FIRST but we do > MALLOC_DEFINE() with SI_SUB_KMEM, SI_ORDER_THIRD. If > sysctl_register_all() is going to malloc(), it needs to run after > malloc_init(), and it looks like populating a string tunable causes it > to malloc(). Ah, indeed, I do! That explains why Navdeep couldn't reproduce it. -Dustin ___ 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"
-CURRENT fatal trap cause by cxgbe module
So I've been fighting with any current from the last month or so instantly crashing when I boot it. I did notice that kernels in the various snapshot images were working, however, so I was trying to figure out why. At first I thought it was because I had INVARIANTS and such disabled, but no, I finally figured it out. I've had in my /boot/loader.conf for a while now: if_cxgbe_load="YES" I guess since the stock installer kernels don't have cxgbe enabled by default. I added "device cxgbe" to my kernels a while ago. Normally the kernel would give some error about the module already being loaded or something and just continue. As of last month or so, however, instead it just crashes: FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) WARNING: WITNESS option enabled, expect reduced performance. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80622931 stack pointer = 0x28:0x8241c9a0 frame pointer = 0x28:0x8241c9e0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () trap number = 12 panic: page fault cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8241c600 vpanic() at vpanic+0x18a/frame 0x8241c660 panic() at panic+0x43/frame 0x8241c6c0 trap_fatal() at trap_fatal+0x386/frame 0x8241c720 trap_pfault() at trap_pfault+0x99/frame 0x8241c7a0 trap() at trap+0x4e9/frame 0x8241c8d0 calltrap() at calltrap+0x8/frame 0x8241c8d0 --- trap 0xc, rip = 0x80622931, rsp = 0x8241c9a0, rbp = 0x8241c9e0 --- malloc() at malloc+0x51/frame 0x8241c9e0 sysctl_handle_string() at sysctl_handle_string+0x12d/frame 0x8241ca20 sysctl_root_handler_locked() at sysctl_root_handler_locked+0xa2/frame 0x8241ca70 sysctl_register_oid() at sysctl_register_oid+0x54c/frame 0x8241cd80 sysctl_register_all() at sysctl_register_all+0x88/frame 0x8241cda0 mi_startup() at mi_startup+0xf2/frame 0x8241cdf0 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x37: movq$0,0xa5f4a6(%rip) db> If I take the if_cxgbe_load out, however, it boots fine. Thanks! -Dustin ___ 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: GPF just after mounting root at r357726
On Mon, Feb 10, 2020 at 6:53 AM David Wolfskill wrote: > > Looks as if the same thing affected both my laptop and my build machine > -- each updated from r357688 (built yesterday & smoke-tested without > incident). While I got some screenshots for the laptop, I have a serial > console for the build machine, so: > > ... > ---<>--- > Table 'FACP' at 0xde3c1b98 > Table 'APIC' at 0xde3c1ca8 > APIC: Found table at 0xde3c1ca8 > APIC: Using the MADT enumerator. > Copyright (c) 1992-2020 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #817 r357726M/357726: Mon Feb 10 04:09:32 PST 2020 > > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > ... > mountroot: waiting for device /dev/ada0s4a... > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 6; apic id = 06 > instruction pointer = 0x20:0x80c7f97b > stack pointer = 0x28:0xfe00aa965160 > frame pointer = 0x28:0xfe00aa965160 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 1 (kernel) > trap number = 9 > panic: general protection fault > cpuid = 6 > time = 24 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00aa964e40 > vpanic() at vpanic+0x185/frame 0xfe00aa964ea0 > panic() at panic+0x43/frame 0xfe00aa964f00 > trap_fatal() at trap_fatal+0x386/frame 0xfe00aa964f60 > trap() at trap+0x8b/frame 0xfe00aa965090 > calltrap() at calltrap+0x8/frame 0xfe00aa965090 > --- trap 0x9, rip = 0x80c7f97b, rsp = 0xfe00aa965160, rbp = > 0xfe00aa965160 --- > biotrack_buf() at biotrack_buf+0xb/frame 0xfe00aa965160 > g_io_deliver() at g_io_deliver+0x30/frame 0xfe00aa9651b0 > g_io_request() at g_io_request+0x28a/frame 0xfe00aa9651e0 > g_part_start() at g_part_start+0x289/frame 0xfe00aa965260 > g_io_request() at g_io_request+0x28a/frame 0xfe00aa965290 > g_part_start() at g_part_start+0x289/frame 0xfe00aa965310 > g_io_request() at g_io_request+0x28a/frame 0xfe00aa965340 > g_io_getattr() at g_io_getattr+0x6b/frame 0xfe00aa965380 > ffs_mount() at ffs_mount+0x1950/frame 0xfe00aa965530 > vfs_domount() at vfs_domount+0x835/frame 0xfe00aa965760 > vfs_donmount() at vfs_donmount+0x911/frame 0xfe00aa965800 > kernel_mount() at kernel_mount+0x57/frame 0xfe00aa965850 > parse_mount() at parse_mount+0x4a1/frame 0xfe00aa9659a0 > vfs_mountroot() at vfs_mountroot+0x53b/frame 0xfe00aa965b10 > start_init() at start_init+0x28/frame 0xfe00aa965bb0 > fork_exit() at fork_exit+0x80/frame 0xfe00aa965bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00aa965bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 1 tid 12 ] > Stopped at kdb_enter+0x37: movq$0,0x1087a36(%rip) > db> > > > I can leave the build machine in that state for up to a few hours > easily enough, in case there's value in that (so I can do a bit of > directed poking, for example). > > I have yesterday's (verbose) dmesg.boot for the build machine up at > http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_dmesg.txt; > based on that, it looks as if what showed up yesterday at that point > was: > > ... > da3: Delete methods: > GEOM: new disk da3 > (da3:umass-sim0:0:0:3): PREVENT ALLOW MEDIUM REMOVAL not supported. > mountroot: waiting for device /dev/ada0s4a... > atrtc0: providing initial system time > start_init: trying /sbin/init > GEOM_PART: partition 1 on (diskid/DISK-1350095E5057, MBR) is not aligned on > 4096 bytes > GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on > 4096 bytes > ... > GEOM_PART: partition 2 on (diskid/DISK-1350095E5057, MBR) is not aligned on > 4096 bytes > GEOM_PART: partition 3 on (diskid/DISK-1350095E5057, MBR) is not aligned on > 4096 bytes > lo0: link state changed to UP > re0: link state changed to DOWN > cpuctl: access to MSR registers/cpuid info. > CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (3591.76-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 > > Features=0xbfebfbff > > > > I will go ahead and reboot the laptop in the mean time. Mine dies in the same spot, but with a different trap: kernel trap 12 with interrupts disabled -Dustin ___ freebsd-current@freebsd.org mailing list
UEFI booting & serial console
All, I have a couple of Lenovo ThinkServer RD450 servers booting in pure UEFI mode. I'm using serial console redirection over IPMI with these and a fresh install from r298793. When it boots it picks up the right serial settings and I get the menu: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 13 block devices...+...*..+. done ZFS found the following pools: zroot UFS found 1 partition command args: -S115200 -h Consoles: EFI console Command line arguments: loader.efi -S115200 -h Image base: 0x443aa000 EFI version: 2.40 EFI Firmware: American Megatrends (rev 5.11) FreeBSD/amd64 EFI loader, Revision 1.1 (r...@releng2.nyi.freebsd.org, Fri Apr 29 20:40:25 UTC 2016) Loading /boot/defaults/loader.conf \ However I can't seen to interact with it using either IPMI SoL or via the IPKVM. Is this normal? Thanks! -Dustin ___ 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: Mixed ashift?
AH-HA! That makes perfect sense and is entirely obvious.. why didn't I think of that?! Thanks again! -Dustin On Thu, Mar 31, 2016 at 4:06 AM, Steven Hartland <kill...@multiplay.co.uk> wrote: > vfs.zfs.min_auto_ashift is only used when a device is added so you can set > it add, then change. > > > > On 31/03/2016 07:15, Allan Jude wrote: > >> On 2016-03-31 02:13, Dustin Marquess wrote: >> >>> I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 >>> SSDs >>> (one ZIL, one SLOG). >>> >>> The HDDs are standard 512 byte sector drives. The SSDs have 8k page >>> sizes. >>> >>> In Illumos I added the SSDs to sd.conf and created the zpool and it shows >>> the HDDs as ashift 9 and the SSDs as ashift 13, like normal: >>> >>> # zdb -C | grep ashift >>> ashift: 9 >>> ashift: 9 >>> ashift: 9 >>> ashift: 9 >>> ashift: 13 >>> >>> The question is, how to replicate this in FreeBSD? The old "gnop" method >>> doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it >>> to >>> use 13 for the HDDs, which seems like a waste. Is this not supported? >>> >>> Thanks! >>> -Dustin >>> ___ >>> 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" >>> >>> gnop should work, and you'd set the ashift before you add the devices. >> So add the hard drives with it set to 9, then set it to 13 and add the >> SLOG >> >> > ___ > 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"
Mixed ashift?
I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 SSDs (one ZIL, one SLOG). The HDDs are standard 512 byte sector drives. The SSDs have 8k page sizes. In Illumos I added the SSDs to sd.conf and created the zpool and it shows the HDDs as ashift 9 and the SSDs as ashift 13, like normal: # zdb -C | grep ashift ashift: 9 ashift: 9 ashift: 9 ashift: 9 ashift: 13 The question is, how to replicate this in FreeBSD? The old "gnop" method doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it to use 13 for the HDDs, which seems like a waste. Is this not supported? Thanks! -Dustin ___ 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"
