Re: questions re updating to -CURRENT
Jakub Lach writes: > Are you sure you are not using drm2 already? I would check > with kldstat. Ckecked; it's there. > The message in UPDATING is about removing > old code from the tree. Maybe ... but this is one of those things that (in my experience) either Just Work or Go Horribly Wrong. The latter is not nearly as much fun as it says in the brochure. Respectfully, Robert Huff ___ 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"
Stack trace
Hi, I moved to 12-Current after my systems kept freezing with 11.1-Release and -Stable. Basically it seemed to only affect two of the machines that I upgraded recently to 11.1-Release branch. These are embedded Intel J1900 motherboards from SuperMicro. Currently on 12-Current they seem to be doing really well like with the previous 10.x-Release. Though I am seeing a kernel stack trace: lock order reversal: 1st 0xf80106be25f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:849 2nd 0xf80106c53068 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2606 stack backtrace: #0 0x80ac52d3 at witness_debugger+0x73 #1 0x80ac5152 at witness_checkorder+0xe02 #2 0x80a392fe at lockmgr_lock_fast_path+0x1ae #3 0x8106a060 at VOP_LOCK1_APV+0xe0 #4 0x80b3df56 at _vn_lock+0x66 #5 0x80b2cac2 at vget+0x82 #6 0x809325bd at devfs_allocv+0xcd #7 0x809320c3 at devfs_root+0x43 #8 0x80b234cc at vfs_donmount+0x11ec #9 0x80b222b2 at sys_nmount+0x72 #10 0x80eee83b at amd64_syscall+0x79b #11 0x80eccebb at Xfast_syscall+0xfb Should I be alarmed about this? Dmesg output from boot: Copyright (c) 1992-2017 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 12.0-CURRENT #0 r323168: Tue Sep 5 09:56:32 BST 2017 root@<>:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 5.0.0 (branches/release_50 312293) (based on LLVM 5.0.0svn) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x30678 Family=0x6 Model=0x37 Stepping=8 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8084115456 (7709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20170831/tbfadt-748) ioapic0 irqs 0-86 on motherboard SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC" frequency 249192 Hz quality 1000 random: entropy device external interface netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x80f6d6a0, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 atrtc0: port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff irq 8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xe080-0xe087 mem 0x9000- 0x903f,0x8000-0x8fff irq 16 at device 2.0 on pci0 vgapci0: Boot video device ahci0: port 0xe070-0xe077,0xe060-0xe063,0xe050- 0xe057,0xe040-0xe043,0xe020-0xe03f mem 0x90a06000-0x90a067ff irq 19 at device 19.0 on pci0 ahci0: AHCI v1.30 with 2 3Gbps ports, Port Multiplier not supported ahcich1: at channel 1 on ahci0 pci0: at device 26.0 (no driver attached) hdac0: mem 0x90a0-0x90a03fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci2: on pcib2 igb0: port 0xd000-0xd01f mem 0x9090-0x9097,0x9098-0x90983fff irq 18 at device 0.0 on pci2 igb0: attach_pre capping queues at 4 igb0: using 1024 tx descriptors and 1024 rx descriptors igb0: msix_init qsets capped at 4 igb0: pxm cpus: 4 queue msgs: 4 admincnt: 1 igb0: using 4 rx queues 4 tx queues igb0: Using MSIX interrupts with 5 vectors igb0: allocated for 4 tx_queues igb0: allocated for 4 rx_queues igb0: Ethernet address: 0c:c4:7a:b0:5f:30 igb0: netmap queues/slots: TX 4/1024, RX 4/1024 pcib3: irq 19 at device 2
Re: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64
On 2017-Sep-10, at 10:26 AM, Tim Kientzle wrote: >> On Sep 9, 2017, at 4:35 PM, Mark Millard wrote: >> >> crochet goes to the trouble to have logic to >> build and install pine64_plus.dtb (based on >> arm64/pine64_plus.dts ). >> > > I'm not sure about Pine64 in particular, but generally > only the DTS file is actually required. [Note: I used crochet source code to figure out a set of manual steps sufficient to produce a pine64_plus.dtb to copy to the boot msdosfs file system.] Some of the #include structure that the existing pine64_plus.dts.dts depends on: # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include "sun50i-a64-pine64-plus.dts" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include "a64.dtsi" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts:#include "sun50i-a64-pine64-common.dtsi" # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include "sun50i-a64-pine64-plus.dts" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include "a64.dtsi" /usr/src/sys/boot/fdt/dts/arm64/pine64_plus.dts:#include # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-plus.dts:#include "sun50i-a64-pine64-common.dtsi" # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-common.dtsi /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64-pine64-common.dtsi:#include "sun50i-a64.dtsi" # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi:#include /usr/src/sys/boot/fdt/dts/arm64/sun50i-a64.dtsi:#include # grep "#include" /usr/src/sys /usr/src/sys/boot/fdt/dts/arm64/a64.dtsi (Yep: nothing for that last one.) I would not guess that the full structure is a appropriate as a substitute for the dtb/pine64_plus.dtb part of the msdosfs partition for booting the Pine64+ 2GB : # find /mnt -print /mnt /mnt/startup.nsh /mnt/EFI /mnt/EFI/BOOT /mnt/EFI/BOOT/bootaa64.efi /mnt/dtb /mnt/dtb/pine64_plus.dtb /mnt/System Volume Information /mnt/System Volume Information/WPSettings.dat # ls -lt /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin -rw-r--r-- 1 root wheel 505940 Sep 6 00:49 /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin (*.bin dd'd appropriately.) So there still seems to be a lack of appropriate .dt* material for direct use/placement on the boot media. Instead manual extra steps are required relative to *.dt* files. > Crochet tries to provide a dtb file (converting the dts if necessary) > partly for documentation and partly to make it easier to edit the > device tree file. > > This is especially convenient in cases where the > original DTB file depends heavily on other include files; > converting DTS to DTB gives you a fully standalone DTB > file that can be edited (for example, to enable additional > serial ports) and recompiled without having the full source > tree available. The above is the kind of context that the Pine64+'s have. It does not appear to me that the existing pine64_plus.dts is set up for more direct use (even with other supporting files). > This is probably less important now that overlay DTBs are > more commonly supported. Whatever this is, it seems to not be in use for much (any?) of the Pine64+ structuring of such things in head -r323246 . === Mark Millard markmi at dsl-only.net ___ 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: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64
> On Sep 9, 2017, at 4:35 PM, Mark Millard wrote: > > crochet goes to the trouble to have logic to > build and install pine64_plus.dtb (based on > arm64/pine64_plus.dts ). > I'm not sure about Pine64 in particular, but generally only the DTS file is actually required. Crochet tries to provide a dtb file (converting the dts if necessary) partly for documentation and partly to make it easier to edit the device tree file. This is especially convenient in cases where the original DTB file depends heavily on other include files; converting DTS to DTB gives you a fully standalone DTB file that can be edited (for example, to enable additional serial ports) and recompiled without having the full source tree available. This is probably less important now that overlay DTBs are more commonly supported. Tim ___ 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"
SSH from WSL acts as if overwrite were enabled while actually inserting
Hello all, Sorry about the confusing subject line, it’s the best I could think of to succinctly summarize the issue at hand. I’ve been running into an issue with FreeBSD from 10.x to 12-CURRENT and wanted to check with the mailing list before I bugged it to make sure it is a FreeBSD bug and not a WSL (the new Linux subsystem for Windows) bug. When I ssh into a FreeBSD host from a TERM=xterm-256color host that has no problem SSHing into Linux machines, the following behavior is observed (regardless of the $TERM value under FreeBSD or the SSH shell I’m logging into). Imagine the prompt currently reads as follows with the cursor at the space denoted by _ in the text below: user@freebsd % foo_bar If I type in ` foo` at this point, the prompt now reads user@freebsd % foo foo_ However, the _actual_ contents of the prompt are really user@freebsd % foo foo bar_ i.e. the _displayed_ prompt acted as if OVERWRITE were on, but the actual behavior is that INSERT was enabled. The actual behavior is the expected behavior, which is what the prompt should have shown. I do not experience this behavior when using, say, Putty instead of OpenSSH under WSL. I also do not experience this behavior when SSHing into a non-FreeBSD host. If this is not a FreeBSD bug, I’ll raise it with the WSL team who have proven to be very earnest in their attempts at fixing all compatibility issues via their GitHub presence. (A screenshot of the observed behavior, if it helps: http://i.imgur.com/k6hVtbQ.png ) Thank you, Mahmoud Al-Qudsi NeoSmart Technologies ___ 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"
