Re: linking to git revisions in bugzilla
Oleksandr Tymoshenko wrote: > Kubilay Kocak (ko...@freebsd.org) wrote: >> On 12/04/2021 9:02 am, Yuri Pankov wrote: >>> While filing a bug, I noticed that the help only mentions svn revision >>> numbers, and "Preview" tab had no output when I tried putting "base >>> ", so I'm wondering how do you link to git revisions? >> >> We'll (bugmeister) be adding parsing support for it (along with a few >> other related auto-linking things) >> >> I'd encourage people to use " " (repo = src|doc|ports) >> where short hash is at least 8 chars in the meantime. Once parsing is >> added all previous references will be linked. > > Links to git hashes should work now, please test and let us > know if feature works as expected. As Michael mentioned - preview > is a different matter, I'll try to look into it later. Hi Oleksandr, It seems to work except when the git hash starts with a digit, it then tries to link to subversion revision using all available digits at the start of the hash. Or, at least, that's what I'm seeing in preview tab, not sure if it has been fixed yet? ___ 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: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool)
Mark Millard via freebsd-current wrote: > Context: > > # gpart show -pl da0 > => 40 468862048da0 GPT (224G) > 40 532480 da0p1 efiboot0 (260M) > 532520 2008 - free - (1.0M) > 534528 25165824 da0p2 swp12a (12G) >25700352 25165824 da0p4 swp12b (12G) >50866176 417994752 da0p3 zfs0 (199G) > 468860928 1160 - free - (580K) > > There is just one pool: zroot and it is on zfs0 above. > > # zpool list -p > NAME SIZEALLOC FREE CKPOINT EXPANDSZ FRAG > CAP DEDUPHEALTH ALTROOT > zroot 213674622976 71075655680 142598967296- - 28 > 33 1.00ONLINE - > > So FREE: 142_598_967_296 > (using _ to make it more readable) > > # zfs list -p zroot > NAME USED AVAIL REFER MOUNTPOINT > zroot 71073697792 135923593216 98304 /zroot > > So AVAIL: 135_923_593_216 > > FREE-AVAIL == 6_675_374_080 > > > > The questions: > > Is this sort of unavailable pool-free-space normal? > Is this some sort of expected overhead that just is > not explicitly reported? Possibly a "FRAG" > consequence? >From zpoolprops(8): freeThe amount of free space available in the pool. By contrast, the zfs(8) available property describes how much new data can be written to ZFS filesystems/volumes. The zpool free property is not generally useful for this purpose, and can be substantially more than the zfs available space. This discrepancy is due to several factors, including raidz parity; zfs reservation, quota, refreservation, and refquota properties; and space set aside by spa_slop_shift (see zfs-module-parameters(5) for more information). ___ 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"
git magic in contrib/bc
Not sure if it's just me, but I'm seeing a bit of git weirdness in contrib/bc: $ cd freebsd-src $ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean $ cd .. $ cp -a freebsd-src freebsd-src-copy $ cd freebsd-src-copy $ git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) modified: contrib/bc/bc.vcxproj modified: contrib/bc/bc.vcxproj.filters modified: contrib/bc/bcl.vcxproj modified: contrib/bc/bcl.vcxproj.filters no changes added to commit (use "git add" and/or "git commit -a") I can't figure what exactly changed in these files, diff (normal command, not git diff) does not show any differences, they are not symlinks. This happens with clean clones from git.freebsd.org, gitrepo.freebsd.org, and github; it did not happen previously (not sure when it started though) -- I was usually just copying the whole tree into ~/ws/. Any hints? ___ 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: catch-all daemon.info entry in syslog.conf is a bit unhelpful
Yuri Pankov wrote: > I understand it's been quite some time since it was added, but I have > been bitten by it just now. I am adding per-daemon .conf files for > ports in /usr/local/etc/syslog.d/ and noticed that none of them were > working. > > An example entry is: > > $ cat /usr/local/etc/syslog.d/dhcpd.conf > !dhcpd > *.* /var/log/dhcpd.log > > Then I noticed the daemon.info entry in /etc/syslog.conf and had to > workaround it like below: > > !-dhcpd > daemon.info /var/log/daemon.log > !+dhcpd > > Given the above, I'm wondering if we could move the daemon.info entry to > the bottom *after* we read the include dirs, so it would only select > everything that is not handled already? Or, better yet, ignore this; I'm not sure what exactly I was doing wrong, but after I sent the mail it all started working as it should (happens all the time for me), sorry for the noise. ___ 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"
catch-all daemon.info entry in syslog.conf is a bit unhelpful
I understand it's been quite some time since it was added, but I have been bitten by it just now. I am adding per-daemon .conf files for ports in /usr/local/etc/syslog.d/ and noticed that none of them were working. An example entry is: $ cat /usr/local/etc/syslog.d/dhcpd.conf !dhcpd *.* /var/log/dhcpd.log Then I noticed the daemon.info entry in /etc/syslog.conf and had to workaround it like below: !-dhcpd daemon.info /var/log/daemon.log !+dhcpd Given the above, I'm wondering if we could move the daemon.info entry to the bottom *after* we read the include dirs, so it would only select everything that is not handled already? ___ 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: Trying to build Current
Willem Jan Withagen via freebsd-current wrote: > On 15-4-2021 11:47, Gary Jennejohn wrote: >> On Thu, 15 Apr 2021 10:51:39 +0200 >> Willem Jan Withagen via freebsd-current >> wrote: >> >>> Hi, >>> >>> I actually went completely back to the basic setup with directories >>> /usr/src and /usr/obj >>> But even then I do not manage to buildworld. >>> The process keeps bumping into missing bsm/audit. >>> >>> First case was when it tried to build the 64bit libc. >>> I copied the bsm directory into >>> __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ >>> >>> Which allowed it to continue. >>> But then a bit further on it halts again in 32bit libc. >>> Whcih I could fix the same way. >>> >>> --- fts.o --- >>> In file included from /usr/src/lib/libc/gen/fts.c:40: >>> In file included from >>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: >>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: >>> >>> fatal error: 'bsm/audit.h' file not found >>> #include >>> ^ >>> >>> Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing >>> 'make world' >>> >>> So why is this include file missing? >>> >> Try running make includes first. This step is missing because you are NOT >> doing a buildworld. >> > Well actual the commands were: > > rm -rf /usr/src /usr/obj > mkdir -p /usr/src /usr/obj > cd /usr/src > git clone https://git.freebsd.org/src.git . > make -j16 buildworld > > But I'll give it a shot anyways. Anything in /etc/make.conf and /etc/src.conf? ___ 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"
"ahci0: AHCI v1.30 with 6 6Gbps ports" while only 2 of those are SATA3
That is on somewhat older Supermicro X9DRI-LN4F+ board: ahci0: port 0x9050-0x9057,0x9040-0x9043,0x9030-0x9037,0x9020-0x9023,0x9000-0x901f mem 0xdfa21000-0xdfa217ff irq 18 at device 31.2 numa-domain 0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported and then I was confused by messages about SATA3 drives connected to ports 2-5 (see the "transfers" line): ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 ada1: ACS-3 ATA SATA 3.x device ada1: Serial Number WD-WX32D7088CCV ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 3815447MB (7814037168 512 byte sectors) Checking the board manual made it clear than only ports 0-1 are SATA3, and 2-5 are indeed SATA2. While the issue is purely cosmetic, I wonder if it's possible to print real port speeds for the controller, i.e. if this information is available to driver? ___ 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"
linking to git revisions in bugzilla
While filing a bug, I noticed that the help only mentions svn revision numbers, and "Preview" tab had no output when I tried putting "base ", so I'm wondering how do you link to git revisions? ___ 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 not mount at boot
beepc.ch wrote: > Dear list, > > I've freshly installed FreeBSD 13-RC5 following this wiki for ZFS manual > configuration: > > https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > > After restart, the ZFS datasets aren't mount at boot: > > # mount > zroot/ROOT/default on / (zfs, local, nfsv4acls) > devfs on /dev (devfs) > > Doing a zfs mount -a, then everything is there: > zroot/ROOT/default on / (zfs, local, nfsv4acls) > devfs on /dev (devfs) > zroot/tmp on /tmp (zfs, local, nosuid, nfsv4acls) > zroot on /zroot (zfs, local, nfsv4acls) > zroot/var/log on /var/log (zfs, local, noexec, nosuid, nfsv4acls) > zroot/usr/ports on /usr/ports (zfs, local, nosuid, nfsv4acls) > zroot/usr/home on /usr/home (zfs, local, nfsv4acls) > zroot/var/mail on /var/mail (zfs, local, noexec, nosuid, nfsv4acls) > zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > zroot/var/crash on /var/crash (zfs, local, noexec, nosuid, nfsv4acls) > zroot/usr/obj on /usr/obj (zfs, local, nfsv4acls) > zroot/var/tmp on /var/tmp (zfs, local, nosuid, nfsv4acls) > zroot/var/audit on /var/audit (zfs, local, noexec, nosuid, nfsv4acls) > zroot/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noexec, > nosuid, nfsv4acls) > zroot/usr/ports/packages on /usr/ports/packages (zfs, local, noexec, > nosuid, nfsv4acls) > > - in /boot/loader.conf > zfs_load="YES" > > - in /etc/rc.conf: > zfs_enabled="YES" If this is exactly what you have in rc.conf, then it's the problem -- it should be "enable", not "enabled". > I don't know what is missing. ___ 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: no time selection screen in installer anymore
Yuri Pankov wrote: > Installing from > FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, I > noticed that there's no time selection screen anymore; TZ is there, date > is there, and only time is missing. > > Not that I miss it much, but it does not seem to be removed from source, > so I'm wondering if it's recent dialog update that broke it? Apparently dialog does not like the height of 2 anymore here (while it still works for --calendar): usr.sbin/bsdinstall/scripts/time: TIME=$(dialog --backtitle 'FreeBSD Installer' \ --title 'Time & Date' \ --ok-label 'Set Time' \ --cancel-label 'Skip' \ --defaultno \ --time-format '%H%M.%S' \ --timebox '' 2 40 \ 2>&1 1>&3) && date $TIME We could use a height of 0 for minimal possible size. ___ 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: [Bug 254395] bsdinstall: fail script install after BETA3
Chris wrote: > On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 >> >> Nathan Whitehorn changed: >> >> What |Removed |Added >> >> >> Severity|Affects Only Me |Affects Some People >> CC| |i...@freebsd.org >> Priority|--- |Normal >> >> --- Comment #6 from Nathan Whitehorn --- >> Thanks for the suggestion about the documentation -- I've updated the >> man page. >> >> The core problem here is that our tar can't extract archives to FAT32 >> with >> default options, since it treats inability to set modification time as >> a fatal >> error and FAT32 doesn't let you do that on the root directory. As >> such, any >> file in the release tarballs can't be extracted to FAT32. For interactive >> installations, the bsdinstall distextract tool, a CURSES-y frontend to >> libarchive, solves this by ignoring ctime/mtime errors. >> >> Some extra commentary on solutions, so it can be in one place. >> Possibilities >> are: >> >> 1. We drop /boot/efi from mtree. That will result in it not existing in >> base.txz, solving this issue, but will result in it not being in >> mtree. It will >> also leave in place an identical bug that will break scripted >> installation on >> bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform. >> >> 2. We add an option to tar to ignore failure in setting ctime/mtime, >> like the >> interactive installer uses. This has the difficulty that the patch is >> hacky and >> would have to go through upstream. >> >> 3. We go back to using distextract for scripted installations as well as >> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7. >> This >> fixes this issue but will result in installation failures for scripted >> installs >> without a controlling tty. (It will also add nice progress bars to >> scripted >> installs). >> >> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand >> afterward. This is incredibly hacky and otherwise essentially >> functionally >> equivalent to #1. Like #1, it will fix this issue and has no obvious >> functional >> downside, but leaves scripted installs bare-metal POWER8 and POWER9 >> broken. >> >> 5. We patch the file system driver to (pretend to) allow setting times >> on the >> mount point. I don't want to do this, since I don't want to solve this >> in the >> kernel at RC3 and I don't like it pretending to do things it can't do. > > 6. (my favorite) do NOT require that the efi/ partition be in strictly a > fat32 format. I mean fat32 is not strictly required as the format for > the efi > partition. It is simply _assumed_ to be the required format and as > such, the > one used in so many cases. Wrong, see "13.3 File System Format" in UEFI specification. > Whould it actually be that much harder to use ffs/ufs? > > You asked. ;-) > >> >> >> >> Of these, 1, 3, and 4 are quite easy to implement, but all have some >> downside. >> My temptation is to do 4 for 13.0, since it will definitely work but >> is just >> lame, then either do #2 or a variant on #3 where distextract notices >> there is >> no tty and doesn't try to set up a dialog as a longer-term fix in >> HEAD. Any >> thoughts? ___ 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"
no time selection screen in installer anymore
Installing from FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, I noticed that there's no time selection screen anymore; TZ is there, date is there, and only time is missing. Not that I miss it much, but it does not seem to be removed from source, so I'm wondering if it's recent dialog update that broke it? ___ 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: panic: malloc(M_WAITOK) with sleeping prohibited
Yuri Pankov wrote: > H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using > FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso. Somehow I missed that it was already reported (a lot) and seems to be already fixed with FreeBSD-14.0-CURRENT-amd64-20210318-a771bf748f9-245511-disc1.iso, sorry for the noise. ___ 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"
panic: malloc(M_WAITOK) with sleeping prohibited
H/W: Supermicro X9DRI-LN4F+, booting from IPMI Virtual CD-ROM using FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-disc1.iso. Root mount waiting for: usbus0 ugen0.4: at usbus0 umass0 numa-domain 0 on uhub2 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc101 umass0:7:0: Attached to scbus7 umass1 numa-domain 0 on uhub2 umass1: on usbus0 umass1: 8070i (ATAPI) over Bulk-Only; quirks = 0xc101 umass1:8:1: Attached to scbus8 panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 37 time = 9 KDB: stack backtrace: db_trace_self_wrapper() vpanic() malloc_dbg() malloc() disk_alloc() cdregister() cam_periph_alloc() cdasync() xpt_async_process_dev() xpt_async_process() xpt_done_process() xpt_done_td() fork_exit() fork_trampoline() --- trap 0, rip = 0, rsp = 0, rbp =0 --- KDB: enter: panic [ thread pid 49 tid 100383 ] ___ 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"
loader/boot fonts are painfully small (again)
Lenovo P51 laptop, 15'' 4k (3840x2160) display. Booting from the latest available current snapshot (20210107), fonts were at least readable; updating to the latest bits (manually installing new loader as well) made them really small -- terminal size reported by stty is 480x135. I have also noticed large delays between different loader screens, probably caused by very slow screen blanking given the terminal size? ___ 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: regression in /etc/rc.d/linux
Sergey V. Dyatko wrote: Hi, Subj was introduced in e40787f900f3c262d5134d342e5a16757dd2193c compat.linux.emul_path isn't defined before kldload`ing linux/linux64 kernel. Looks like it's already fixed: https://cgit.freebsd.org/src/commit/?id=07cac176fba947381c8111b8e02e8067e7fa542a ___ 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: Boot panic on Lenovo P50s since r367998
Yuri Pankov wrote: Tomoaki AOKI wrote: On Thu, 24 Dec 2020 10:34:49 +0100 Marc Veldman wrote: Hello, since r367998 my Lenovo P50s panics on boot: mmc0: detached panic: Bad link elm 0xf80003a73300 next->prep != elm cupid=3 time=2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8299a9c0 vpanic() at vpanic+0x181/frame 0x8299aa10 panic() at panic+0x43/frame 0x8299aa70 config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0x8299aa90 config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0x8299aab0 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0x8299aad0 boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0x8299ab60 mi_startup() at mi_startup+0xec/frame 0x8299abb0 btext() at btext+0x2c KDB: enter: panic [thread pid 0 tid 10] Stopped at kdb_enter+0x37: movq $0,0x10ada46(%rip) If needed, I can test patches Dmesg (with r367977 kernel) ---<>--- 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 #0 r367997: Tue Dec 22 16:47:30 CET 2020 root@devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1920x1080 CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16421109760 (15660 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 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-119 Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1296050980 Hz quality 1000 random: entropy device external interface WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. kbd1 at kbdmux0 000.45 [4346] netmap_init netmap: loaded module [ath_hal] loaded nexus0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: aesni0: acpi0: acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xe000-0xe03f mem 0xf200-0xf2ff,0xd000-0xdfff irq 16 at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0xf422-0xf422 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich1: at channel 1 on ahci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 28.2 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: at device 29.0 on pci0 pci3: on pcib3 vgapci1: port 0xd000-0xd07f mem 0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at device 0.0 on pci3 isab0: at dev
Re: Boot panic on Lenovo P50s since r367998
Tomoaki AOKI wrote: On Thu, 24 Dec 2020 10:34:49 +0100 Marc Veldman wrote: Hello, since r367998 my Lenovo P50s panics on boot: mmc0: detached panic: Bad link elm 0xf80003a73300 next->prep != elm cupid=3 time=2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8299a9c0 vpanic() at vpanic+0x181/frame 0x8299aa10 panic() at panic+0x43/frame 0x8299aa70 config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0x8299aa90 config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0x8299aab0 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0x8299aad0 boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0x8299ab60 mi_startup() at mi_startup+0xec/frame 0x8299abb0 btext() at btext+0x2c KDB: enter: panic [thread pid 0 tid 10] Stopped at kdb_enter+0x37: movq $0,0x10ada46(%rip) If needed, I can test patches Dmesg (with r367977 kernel) ---<>--- 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 #0 r367997: Tue Dec 22 16:47:30 CET 2020 root@devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 1920x1080 CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16421109760 (15660 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 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-119 Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1296050980 Hz quality 1000 random: entropy device external interface WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. kbd1 at kbdmux0 000.45 [4346] netmap_init netmap: loaded module [ath_hal] loaded nexus0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: aesni0: acpi0: acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xe000-0xe03f mem 0xf200-0xf2ff,0xd000-0xdfff irq 16 at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0xf422-0xf422 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich1: at channel 1 on ahci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 28.2 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: at device 29.0 on pci0 pci3: on pcib3 vgapci1: port 0xd000-0xd07f mem 0xf300-0xf3ff,0xe000-0xefff,0xf000-0xf1ff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0xf424-0xf4243fff,0xf423-0xf423 at device 31.3 on pci0 em0: mem 0xf420-0xf421 at device 31.6
Re: Boot panic on Lenovo P50s since r367998
Marc Veldman wrote: Hello, since r367998 my Lenovo P50s panics on boot: mmc0: detached panic: Bad link elm 0xf80003a73300 next->prep != elm cupid=3 time=2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x8299a9c0 vpanic() at vpanic+0x181/frame 0x8299aa10 panic() at panic+0x43/frame 0x8299aa70 config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0x8299aa90 config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0x8299aab0 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0x8299aad0 boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0x8299ab60 mi_startup() at mi_startup+0xec/frame 0x8299abb0 btext() at btext+0x2c KDB: enter: panic [thread pid 0 tid 10] Stopped at kdb_enter+0x37: movq $0,0x10ada46(%rip) r367998 adds rtsx driver for card reader, seems to work for me on P51 (as in "detected and does not panic", I don't have any cards around to really test it): rtsx0@pci0:63:0:0: class=0xff rev=0x01 hdr=0x00 vendor=0x10ec device=0x525a subvendor=0x17aa subdevice=0x224d vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS525A PCI Express Card Reader' To confirm the issue is indeed in rtsx, does disabling the card reader in bios help? If it does, what is the device exactly (`pciconf -lv` when booted on pre-r367998)? ___ 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: referencing one commit in another for git
Warner Losh wrote: On Wed, Dec 23, 2020 at 6:22 PM Jan Beich wrote: Warner Losh writes: On Wed, Dec 23, 2020, 3:21 PM Alan Somers wrote: On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem wrote: Hi, So I just did my first git commit. Pretty scary, but it looks ok. Now, how do I reference one commit in another related commit's log? By the long winded hash or ?? I'm not sure if I should ask here or on the git mailing list, but I figured this isn't a technical git question... Thanks for any help with this, rick Yeah, you should use the full hash. For temporary references, like during a code review, you can use the first "several" digits of the hash. For a project of FreeBSD's size, "several" is probably 11-13. But in permanent contexts, like commit logs, you should use the full hash. When somebody views the commit on a platform like Github, Github will automatically turn it into a hyperlink, and display only the first "several" digits. For MFCs we are recommending the first 11. I think this will likely suffice and matches the git client behavior. Mercurial defaults to 12 digit abbreviation. Git abbreviates linux, freebsd-legacy, freebsd-ports repos on GitHub to 12 digit. I've updated to 12. That sounds like a good number of digits...Thanks. I think the common way is to use `git rev-parse --short `, though we are likely to recommend increasing the core.abbrev value which sets the minimum length of unique prefix (default is 4). ___ 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: installation on pvscsi fails with "The request was too large for this host"
Andriy Gapon wrote: On 17/12/2020 07:02, Yuri Pankov wrote: Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs with pvscsi fails on bootloader step, and the following is in dmesg: pvscsi0: pvscsi_execute_ccb error 27 pvscsi0: pvscsi_execute_ccb error 27 (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host (da0:pvscsi0:0:0:0): Error 22, Unretryable error (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host (da0:pvscsi0:0:0:0): Error 22, Unretryable error That is the first I'm trying installing on pvscsi since it was integrated, so no idea if it worked previously. If yes, I have not tried to bisect this yet hoping that it could be identified as related to any of the recent changes. The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks. Not an expert in this areas, but that command tried to transfer 0x400 / 1024 blocks, which is 512KB of data. Could it be that the problem is revealed by the MAXPHYS increase? There might be a bug in pvscsi where it does not respect or correctly advertise some limit. There could be a similar issue with VMware itself (its emulation of a disk / target). Yes, it looks like reverting MAXPHYS back to 128K made the problem disappear, successfully installed VM from resulting cdrom image. ___ 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: acpi_wmi noisy without EC
Yuri Pankov wrote:
On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
On 2020-11-17 15:29, Yuri Pankov wrote:
On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
On 2020-11-17 10:57, Vladimir Kondratyev wrote:
On 2020-11-17 03:00, Yuri Pankov wrote:
I have started seeing the following on boot since some time:
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
Likely following this commit:
commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev
Date: Sat Oct 31 22:19:39 2020 +
acpi_wmi(4): Add ACPI_PNP_INFO
While the reason is obvious -- there's no EC in this system (Gigabyte
X299X AORUS MASTER desktop motherboard), at least searching the
`acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
looks like "something is broken" when first noticed. I wonder if we
could/should handle this gracefully -- no EC, do nothing, simply exit?
Following patch should ignore missing EC like Linux does. Could you
test it?
diff --git a/sys/dev/acpi_support/acpi_wmi.c
b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status =
AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
@#@##! Web client ate all the tabs.
Patch is in attachment.
Output changed, though it's still somewhat noisy -- I guess there
isn't a way to NOT report the device that we are not going to attach
to, or do that e.g. only for verbose boot?
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
object (Buffer) (20201113/nsarguments-361)
acpi_wmi1: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: on acpi0
acpi_wmi3: cannot find EC device
acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
in OpRegion handler.
WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
successfully attached to 4 nodes.
Oh great, I misunderstood then. And indeed, sysctl -b dev.acpi_wmi.0.bmof |
bmf2mof provides some interesting information. All other 3 instances do not
though. In any case, it seems to work now.
Verbosity can be reduced with attached patch if current level is too
high for you.
Works for me both ways, I simply had the wrong impression that if we don't have
EC, we can't attach at all.
Could you commit this, or is it incomplete fix?
___
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"
installation on pvscsi fails with "The request was too large for this host"
Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs with pvscsi fails on bootloader step, and the following is in dmesg: pvscsi0: pvscsi_execute_ccb error 27 pvscsi0: pvscsi_execute_ccb error 27 (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host (da0:pvscsi0:0:0:0): Error 22, Unretryable error (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00 (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host (da0:pvscsi0:0:0:0): Error 22, Unretryable error That is the first I'm trying installing on pvscsi since it was integrated, so no idea if it worked previously. If yes, I have not tried to bisect this yet hoping that it could be identified as related to any of the recent changes. The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks. ___ 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: port build fails with missing sys/smr_types.h
Alan Somers wrote: On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli wrote: Hi I'm trying to fix the build of qemu-utils but am seeing failures on CURRENT (13.0-HEAD-9e082d278b9) like: In file included from util/oslib-posix.c:50: In file included from /usr/include/sys/user.h:51: In file included from /usr/include/sys/proc.h:50: /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not found #include ^ # uname -a FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27 00:09:50 PST 2020 root@freebsd :/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 # ls -l /usr/include/sys/*smr* -r--r--r-- 1 root wheel 1988 Nov 30 14:04 /usr/include/sys/_smr.h -r--r--r-- 1 root wheel 7822 Nov 30 14:04 /usr/include/sys/smr.h So it appears the file is missing. Any ideas? --chuck That file doesn't get installed into /usr/include, but it exists in /usr/src. A few ports need /usr/src. See devel/py-libzfs/Makefile for an example of how to find it. But it's included from the header that *is* in /usr/include/, not directly by external code. Should not such dependencies all be in /usr/include/? ___ 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: acpi_wmi noisy without EC
On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
> On 2020-11-17 15:29, Yuri Pankov wrote:
> > On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
> >> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> >> > On 2020-11-17 03:00, Yuri Pankov wrote:
> >> >> I have started seeing the following on boot since some time:
> >> >>
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >> acpi_wmi0: on acpi0
> >> >> acpi_wmi0: cannot find EC device
> >> >> device_attach: acpi_wmi0 attach returned 6
> >> >>
> >> >> Likely following this commit:
> >> >>
> >> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
> >> >> Author: Vladimir Kondratyev
> >> >> Date: Sat Oct 31 22:19:39 2020 +
> >> >>
> >> >> acpi_wmi(4): Add ACPI_PNP_INFO
> >> >>
> >> >> While the reason is obvious -- there's no EC in this system (Gigabyte
> >> >> X299X AORUS MASTER desktop motherboard), at least searching the
> >> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
> >> >> looks like "something is broken" when first noticed. I wonder if we
> >> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
> >> >
> >> > Following patch should ignore missing EC like Linux does. Could you
> >> > test it?
> >> >
> >> > diff --git a/sys/dev/acpi_support/acpi_wmi.c
> >> > b/sys/dev/acpi_support/acpi_wmi.c
> >> > index 379cfd1705f1..efae96cdcc9a 100644
> >> > --- a/sys/dev/acpi_support/acpi_wmi.c
> >> > +++ b/sys/dev/acpi_support/acpi_wmi.c
> >> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> >> > if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> >> > == NULL)
> >> > device_printf(dev, "cannot find EC device\n");
> >> > - else if (ACPI_FAILURE((status =
> >> > AcpiInstallNotifyHandler(sc->wmi_handle,
> >> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> >> > ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> >> > device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> >> > AcpiFormatException(status));
> >> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> >> > ACPI_PHYSICAL_ADDRESS address,
> >> > return (AE_BAD_PARAMETER);
> >> > if (address + (width / 8) - 1 > 0xFF)
> >> > return (AE_BAD_ADDRESS);
> >> > + if (sc->ec_dev == NULL)
> >> > + return (AE_NOT_FOUND);
> >> > if (function == ACPI_READ)
> >> > *value = 0;
> >> > ec_addr = address;
> >>
> >> @#@##! Web client ate all the tabs.
> >>
> >> Patch is in attachment.
> >
> > Output changed, though it's still somewhat noisy -- I guess there
> > isn't a way to NOT report the device that we are not going to attach
> > to, or do that e.g. only for verbose boot?
> >
> > acpi_wmi0: on acpi0
> > acpi_wmi0: cannot find EC device
> > acpi_wmi0: Embedded MOF found
> > ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
> > object (Buffer) (20201113/nsarguments-361)
> > acpi_wmi1: on acpi0
> > acpi_wmi1: cannot find EC device
> > acpi_wmi2: on acpi0
> > acpi_wmi2: cannot find EC device
> > acpi_wmi3: on acpi0
> > acpi_wmi3: cannot find EC device
>
> acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
> in OpRegion handler.
> WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
> successfully attached to 4 nodes.
Oh great, I misunderstood then. And indeed, sysctl -b dev.acpi_wmi.0.bmof |
bmf2mof provides some interesting information. All other 3 instances do not
though. In any case, it seems to work now.
> Verbosity can be reduced with attached patch if current level is too
> high for you.
Works for me both ways, I simply had the wrong impression that if we don't have
EC, we can't attach at all.
___
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: acpi_wmi noisy without EC
On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> > On 2020-11-17 03:00, Yuri Pankov wrote:
> >> I have started seeing the following on boot since some time:
> >>
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >> acpi_wmi0: on acpi0
> >> acpi_wmi0: cannot find EC device
> >> device_attach: acpi_wmi0 attach returned 6
> >>
> >> Likely following this commit:
> >>
> >> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
> >> Author: Vladimir Kondratyev
> >> Date: Sat Oct 31 22:19:39 2020 +
> >>
> >> acpi_wmi(4): Add ACPI_PNP_INFO
> >>
> >> While the reason is obvious -- there's no EC in this system (Gigabyte
> >> X299X AORUS MASTER desktop motherboard), at least searching the
> >> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
> >> looks like "something is broken" when first noticed. I wonder if we
> >> could/should handle this gracefully -- no EC, do nothing, simply exit?
> >
> > Following patch should ignore missing EC like Linux does. Could you
> > test it?
> >
> > diff --git a/sys/dev/acpi_support/acpi_wmi.c
> > b/sys/dev/acpi_support/acpi_wmi.c
> > index 379cfd1705f1..efae96cdcc9a 100644
> > --- a/sys/dev/acpi_support/acpi_wmi.c
> > +++ b/sys/dev/acpi_support/acpi_wmi.c
> > @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> > if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> > == NULL)
> > device_printf(dev, "cannot find EC device\n");
> > - else if (ACPI_FAILURE((status =
> > AcpiInstallNotifyHandler(sc->wmi_handle,
> > + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> > ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> > device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> > AcpiFormatException(status));
> > @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> > ACPI_PHYSICAL_ADDRESS address,
> > return (AE_BAD_PARAMETER);
> > if (address + (width / 8) - 1 > 0xFF)
> > return (AE_BAD_ADDRESS);
> > + if (sc->ec_dev == NULL)
> > + return (AE_NOT_FOUND);
> > if (function == ACPI_READ)
> > *value = 0;
> > ec_addr = address;
>
> @#@##! Web client ate all the tabs.
>
> Patch is in attachment.
Output changed, though it's still somewhat noisy -- I guess there isn't a way
to NOT report the device that we are not going to attach to, or do that e.g.
only for verbose boot?
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI object
(Buffer) (20201113/nsarguments-361)
acpi_wmi1: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: on acpi0
acpi_wmi3: cannot find EC device
___
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"
acpi_wmi noisy without EC
I have started seeing the following on boot since some time: acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 Likely following this commit: commit 708d048ccfdacf6199cc08a56aa05a9c899441fd Author: Vladimir Kondratyev Date: Sat Oct 31 22:19:39 2020 + acpi_wmi(4): Add ACPI_PNP_INFO While the reason is obvious -- there's no EC in this system (Gigabyte X299X AORUS MASTER desktop motherboard), at least searching the `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly looks like "something is broken" when first noticed. I wonder if we could/should handle this gracefully -- no EC, do nothing, simply exit? ___ 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: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
driesm.michi...@gmail.com wrote: I just want to add a "me to" here. With a recent upgrade of CURRENT on my laptop, these error messages started popping up. Possibly not really harming anything under the hood though. Looks like r365029 fixed it for me, and even ubt0 is back happily spamming console with netgraph warnings; didn't notice its absence as I'm not using bluetooth at the moment. -Original Message- From: owner-freebsd-curr...@freebsd.org On Behalf Of Yuri Pankov Sent: Thursday, 27 August 2020 21:18 To: bob prohaska Cc: curr...@freebsd.org Subject: Re: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR bob prohaska wrote: On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote: Another issue that I started seeing lately, didn't try finding out when exactly in case someone knows what it's about: Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR [details snipped] So far not seeing any ill effects from this, i.e. I can connect USB HDD to these ports, and it's successfully detected. If it's convenient, connecting a USB-serial adapter and rebooting might be interesting. I'm having trouble with FT232 obstructing disk detection in some cases and self-disconnecting in others on a Pi3B. Don't have one. It is "desktop" PC, so the only USB devices I have/need are keyboard/mouse and memsticks. ___ 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: panic in range_tree_seg64_compare()
Matthew Macy wrote:
On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov wrote:
Yet another issue I'm seeing after last update (currently running
r364870), hit it 2 times today:
Fatal trap 12: page fault while in kernel mode
cpuid = 19; apic id = 0d
fault virtual address = 0xf819e2ecdc40
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8277fa64
stack pointer = 0x28:0xfe01f9ff2d90
frame pointer = 0x28:0xfe01f9ff2d90
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 = 48792 (blk-3:0-0)
trap number = 12
panic: page fault
cpuid = 19
time = 1598577675
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe01f9ff2a40
vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
panic() at panic+0x43/frame 0xfe01f9ff2af0
trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
--- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
0xfe01f9ff2d90 ---
range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
0xfe01f9ff2d90
zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30
range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
0xfe01f9ff3030
dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
0xfe01f9ff3180
g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
physio() at physio+0x4f8/frame 0xfe01f9ff3270
devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
--- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
Uptime: 4h13m43s
Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
for bhyve VM. Anything known?
Not really. A reproduction scenario would be very helpful. This was
seen once by someone at iX - I committed some additional asserts to
the truenas tree, but haven't heard further.
+++ b/module/zfs/dbuf.c
@@ -3192,7 +3192,7 @@
dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
* scheduled its write with its buffer, we must
* disassociate by replacing the frontend.
*/
- ASSERT(db->db_state & (DB_READ|DB_PARTIAL));
+ ASSERT3U(db->db_state, &, (DB_READ|DB_PARTIAL));
ASSERT3U(db->db_dirtycnt, ==, 1);
dbuf_dirty_set_data(dds);
} else {
@@ -3238,18 +3238,24 @@ dbuf_dirty_record_create_leaf(dbuf_dirty_state_t *dds)
dr = dbuf_dirty_record_create(dds);
+ /*
+* XXX - convert to ASSERT after dn_free_ranges fix
+*/
+ VERIFY(db->db_level == 0);
+ VERIFY(db->db_blkid != DMU_BONUS_BLKID);
Can't find context for both chunks, there are simply no such functions
in sys/contrib/openzfs/module/zfs/dbuf.c, and yes, note that I'm running
the in-tree version.
___
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"
panic in range_tree_seg64_compare()
Yet another issue I'm seeing after last update (currently running r364870), hit it 2 times today: Fatal trap 12: page fault while in kernel mode cpuid = 19; apic id = 0d fault virtual address = 0xf819e2ecdc40 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8277fa64 stack pointer = 0x28:0xfe01f9ff2d90 frame pointer = 0x28:0xfe01f9ff2d90 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 = 48792 (blk-3:0-0) trap number = 12 panic: page fault cpuid = 19 time = 1598577675 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01f9ff2a40 vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90 panic() at panic+0x43/frame 0xfe01f9ff2af0 trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50 trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0 trap() at trap+0x2ab/frame 0xfe01f9ff2cc0 calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0 --- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp = 0xfe01f9ff2d90 --- range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame 0xfe01f9ff2d90 zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0 range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30 range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70 range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80 dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0 dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0 dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame 0xfe01f9ff3030 dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0 dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100 zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame 0xfe01f9ff3180 g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0 g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0 physio() at physio+0x4f8/frame 0xfe01f9ff3270 devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0 dofileread() at dofileread+0x81/frame 0xfe01f9ff3320 kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360 sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390 amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0 --- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp = 0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 --- Uptime: 4h13m43s Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using for bhyve VM. Anything known? ___ 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: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
bob prohaska wrote: On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote: Another issue that I started seeing lately, didn't try finding out when exactly in case someone knows what it's about: Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR [details snipped] So far not seeing any ill effects from this, i.e. I can connect USB HDD to these ports, and it's successfully detected. If it's convenient, connecting a USB-serial adapter and rebooting might be interesting. I'm having trouble with FT232 obstructing disk detection in some cases and self-disconnecting in others on a Pi3B. Don't have one. It is "desktop" PC, so the only USB devices I have/need are keyboard/mouse and memsticks. ___ 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"
usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
Another issue that I started seeing lately, didn't try finding out when exactly in case someone knows what it's about: Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR ugen0.7: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: usbus0 ugen0.7: at usbus0 ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0310 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0003 bMaxPacketSize0 = 0x0009 idVendor = 0x0bda idProduct = 0x0423 bcdDevice = 0x0103 iManufacturer = 0x0001 iProduct = 0x0002 <2-Port USB 3.1 Hub> iSerialNumber = 0x bNumConfigurations = 0x0001 So far not seeing any ill effects from this, i.e. I can connect USB HDD to these ports, and it's successfully detected. ___ 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: can't handle raw ops yet!!!
Matthew Macy wrote: Expected. I'm working on it. It's just a friendly reminder when INVARIANTS is enabled. Good, thanks. On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov wrote: After OpenZFS merge, during boot I'm getting several occurrences of what seems to be the following: http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207 And, yes, I'm running GENERIC, so with INVARIANTS. Should I be worried? ___ 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"
can't handle raw ops yet!!!
After OpenZFS merge, during boot I'm getting several occurrences of what seems to be the following: http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207 And, yes, I'm running GENERIC, so with INVARIANTS. Should I be worried? ___ 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: FreeBSD Quarterly Status Report - Second Quarter 2020
Daniel Ebdrup Jensen wrote: [nothing] At least in Thunderbird the text is not inline, and rather shows as attachment. ___ 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: svn commit: r352558 - head/usr.bin/top
Steve Wills wrote: Hi, On 7/10/20 7:12 PM, Yuri Pankov wrote: Thanks. The attached diff seems to take care of the issue for me, adding VIS_TAB and removing VIS_SAFE, which can be blamed for passing through the following: VIS_SAFE Currently this form allows space, tab, newline, backspace, bell, and return — in addition to all graphic characters — unencoded. That does seem to fix it for me. Please commit. :) Done, please report if it's still not completely fixed. ___ 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 panics on connecting disks to a LSI-3108 controller
Willem Jan Withagen wrote: Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul 9 04:13:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc730-0xc730,0xc720-0xc72f irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 . mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at: www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? I guess it's not the answer you are looking for, but you could try the mrsas driver and check if it's behaves better for you, by setting 'set hw.mfi.mrsas_enable=1' from loader prompt. ___ 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: svn commit: r352558 - head/usr.bin/top
Mark Millard wrote: On 2020-Jul-10, at 16:12, Yuri Pankov wrote: Mark Millard wrote: On 2020-Jul-10, at 11:05, Yuri Pankov wrote: Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558 Log: top(1): support multibyte characters in command names (ARGV array) depending on locale. - add setlocale() - remove printable() function - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display non-printable characters that do not use C-style backslash sequences in three digit octal sequence, or remove it This change allows multibyte characters to be displayed according to locale. If it is recognized as a non-display character according to the locale, it is displayed in three digit octal sequence. Initially picking on tab characters as an example of what is probably a somewhat broader issue . . . Ever since this change, characters like tabs that do not fit in the next character cell when output, but for which they are !isprintable(...), now mess up the top display. Again using tab as an example: line wrapping from the text having been shifted over by more than one character cell. top does not track the line wrapping result in how it decides what to output for the following display updates. Apologies for the way late reply here, but I just now bothered tracking this down. This commit seems to be the cause of some corruption I'm seeing in long running top(1) as well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla bug? I can share screenshots of the corruption, such as: https://i.imgur.com/Xqlwf9h.png https://i.imgur.com/Jv0d5NU.png Does removing VIS_SAFE fixes the issue for you? As for original Mark's report (which I missed), removing isprintable() doesn't look wrong as vis(3) should take of its functionality (and in multibyte-aware way). vis (as used) and the old isprintable logic are not equivalent when multi-byte is not needed/involved. Otherwise I'd not have had anything to ever report. If vis can do what is needed, more work needed to be done when the change was made in order to avoid msesed up displays in single-byte contexts. Also, is there an easy way to reproduce this? The following sort of command (the empty space inside quoted text are tab characters): # tr '0\n 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > /dev/null causes my 200 character wide window running top to show: 32920 root1000 12764Ki2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0 \\t1 \\t2\\t3\\t4\\t5\\t6\\t733 \\t8 207172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid But that does not show where the lines wrap at the edges of the window, so breaking it up explicitly after the first "\" in \\7: 32920 root1000 12764Ki2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0 \\t1 \\t2\\t3\\t4\\t5\\t6\ \t733 \\t8 207172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid Note how \n turned into \\n , taking an extra character for each \n . Similarly for \t vs. \\t . (Other examples do similarly.) The tab characters really do use more than one character cell on the display (sometimes). The text from the tr command ends up spread across 2 lines as things look like in the window where top is running. I ran top in another ssh session first and then the tr command. Before running the tr command, top showed as: 33019 root 200 17172Ki5448Ki CPU24 24 0:00 0.05% top -HiSCazopid If you do not end up with top listed just after tr in top's output, then it will not be top's line that ends up partially overwritten. If you have wider windows, you may need more text in the tr quoted strings. In another experiment I inserted a large number of backspace characters (control-H's) at the front of the first quoted string in the tr command. The top output displayed: 0\\n5 ro1\\n2\\93 3\\n12764\\n 25\\ni CP6\\n 97\\n:12 100.00\t0r \nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t 33094 root 200 17172Ki5488Ki CPU21 21 0:00 0.06% top -HiSCazopid In other words, backspace moved the cursor position back over prior fields on the line and then the later line content overwrote those fields instead of being after "tr" someplace (or truncated off). Note that part of "-HiSCazopid" shows up on both lines. The extra is from when top was running but tr had not started yet. top is not managing text replacement correctly for output characters that end up not being just "in
Re: svn commit: r352558 - head/usr.bin/top
Mark Millard wrote: On 2020-Jul-10, at 11:05, Yuri Pankov wrote: Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558 Log: top(1): support multibyte characters in command names (ARGV array) depending on locale. - add setlocale() - remove printable() function - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display non-printable characters that do not use C-style backslash sequences in three digit octal sequence, or remove it This change allows multibyte characters to be displayed according to locale. If it is recognized as a non-display character according to the locale, it is displayed in three digit octal sequence. Initially picking on tab characters as an example of what is probably a somewhat broader issue . . . Ever since this change, characters like tabs that do not fit in the next character cell when output, but for which they are !isprintable(...), now mess up the top display. Again using tab as an example: line wrapping from the text having been shifted over by more than one character cell. top does not track the line wrapping result in how it decides what to output for the following display updates. Apologies for the way late reply here, but I just now bothered tracking this down. This commit seems to be the cause of some corruption I'm seeing in long running top(1) as well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla bug? I can share screenshots of the corruption, such as: https://i.imgur.com/Xqlwf9h.png https://i.imgur.com/Jv0d5NU.png Does removing VIS_SAFE fixes the issue for you? As for original Mark's report (which I missed), removing isprintable() doesn't look wrong as vis(3) should take of its functionality (and in multibyte-aware way). vis (as used) and the old isprintable logic are not equivalent when multi-byte is not needed/involved. Otherwise I'd not have had anything to ever report. If vis can do what is needed, more work needed to be done when the change was made in order to avoid msesed up displays in single-byte contexts. Also, is there an easy way to reproduce this? The following sort of command (the empty space inside quoted text are tab characters): # tr '0\n 1\n 2\n 3\n 4\n 5\n 6\n 7\n 8\n' '\t0 \t1 \t2 \t3 \t4 \t5 \t6 \t7 \t8' < /dev/zero > /dev/null causes my 200 character wide window running top to show: 32920 root1000 12764Ki2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0 \\t1 \\t2\\t3\\t4\\t5\\t6\\t733 \\t8 207172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid But that does not show where the lines wrap at the edges of the window, so breaking it up explicitly after the first "\" in \\7: 32920 root1000 12764Ki2420Ki CPU3 3 2:22 99.87% tr 0\\n 1\\n2\\n3\\n4\\n5\\n6\\n7\\n8\\n \\t0 \\t1 \\t2\\t3\\t4\\t5\\t6\ \t733 \\t8 207172 5448Ki CPU23 23 0:00 0.04% top -HiSCazopid Note how \n turned into \\n , taking an extra character for each \n . Similarly for \t vs. \\t . (Other examples do similarly.) The tab characters really do use more than one character cell on the display (sometimes). The text from the tr command ends up spread across 2 lines as things look like in the window where top is running. I ran top in another ssh session first and then the tr command. Before running the tr command, top showed as: 33019 root 200 17172Ki5448Ki CPU24 24 0:00 0.05% top -HiSCazopid If you do not end up with top listed just after tr in top's output, then it will not be top's line that ends up partially overwritten. If you have wider windows, you may need more text in the tr quoted strings. In another experiment I inserted a large number of backspace characters (control-H's) at the front of the first quoted string in the tr command. The top output displayed: 0\\n5 ro1\\n2\\93 3\\n12764\\n 25\\ni CP6\\n 97\\n:12 100.00\t0r \nHiS\\t1pid \\t2\\t3\\t4\\t5\\t6\\t 33094 root 200 17172Ki5488Ki CPU21 21 0:00 0.06% top -HiSCazopid In other words, backspace moved the cursor position back over prior fields on the line and then the later line content overwrote those fields instead of being after "tr" someplace (or truncated off). Note that part of "-HiSCazopid" shows up on both lines. The extra is from when top was running but tr had not started yet. top is not managing text replacement correctly for output characters that end up not being just "in" the next character-cell on the terminal. The
Re: DRM Project report (week of July 6th)
Emmanuel Vadot wrote: [...] Hi Emmanuel, Sorry for somewhat hijacking the thread, but as you mentioned (IIRC) testing the vmwgfx in one of the previous mails, I'd like to ask if any work/fixes is done for that. Currently I don't have a VM with X11 installed as all my attempts didn't succeed -- it's either a hard hang, panic, or VM dying with exception, even with a workaround of 1 CPU (core) provided in the Wiki. I can reinstall and provide panic info if you are interested in looking into it. ___ 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: svn commit: r352558 - head/usr.bin/top
Steve Wills wrote: On 11/28/19 4:08 PM, Mark Millard via svn-src-head wrote: Author: daichi Date: Fri Sep 20 17:37:23 2019 New Revision: 352558 URL: https://svnweb.freebsd.org/changeset/base/352558 Log: top(1): support multibyte characters in command names (ARGV array) depending on locale. - add setlocale() - remove printable() function - add VIS_OCTAL and VIS_SAFE to the flag of strvisx() to display non-printable characters that do not use C-style backslash sequences in three digit octal sequence, or remove it This change allows multibyte characters to be displayed according to locale. If it is recognized as a non-display character according to the locale, it is displayed in three digit octal sequence. Initially picking on tab characters as an example of what is probably a somewhat broader issue . . . Ever since this change, characters like tabs that do not fit in the next character cell when output, but for which they are !isprintable(...), now mess up the top display. Again using tab as an example: line wrapping from the text having been shifted over by more than one character cell. top does not track the line wrapping result in how it decides what to output for the following display updates. Apologies for the way late reply here, but I just now bothered tracking this down. This commit seems to be the cause of some corruption I'm seeing in long running top(1) as well. As Mark mentions, if I use "hh" it clears up. Should I open a bugzilla bug? I can share screenshots of the corruption, such as: https://i.imgur.com/Xqlwf9h.png https://i.imgur.com/Jv0d5NU.png Does removing VIS_SAFE fixes the issue for you? As for original Mark's report (which I missed), removing isprintable() doesn't look wrong as vis(3) should take of its functionality (and in multibyte-aware way). Also, is there an easy way to reproduce this? ___ 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: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)
Mark Millard wrote:
On 2020-Jul-8, at 20:35, Yuri Pankov wrote:
Mark Millard wrote:
This seems to have broken doing buildworld buildkernel and
other things using make:
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
operator should be either == or !=
. . .
Using -d c shows the likes of:
. . .
lhs = "clang", rhs = "clang", op = ==
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op
= ==
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
lhs = "LD", rhs = "LD", op = ==
. . .
left = 6.00, right = 2.00, op = <=
left = 6.00, right = 1.00, op = <=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "clang",
op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
operator should be either == or !=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op
= ==
lhs = "clang", rhs = "gcc", op = ==
. . .
left = 0.00, right = 6.00, op = <=
left = 0.00, right = 3.00, op = <=
lhs = "clang", rhs = "gcc", op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
left = 11.00, right = 7.00, op = >=
lhs = "amd64", rhs = "arm", op = ==
(Now I just need to figure out how to get back to a working context.)
For me, buildworld/buildkernel produced only warnings,
But, looking at the code in bmake, the expression is also
evaluated differently/incorrectly when it is classified as
having the problem of having a incorrect operator. In other
words: the behavior in make changes via misevaluated
expressions.
though the one in ports is real issue:
$ make config
make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison
operator should be either == or !=
make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional
(defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} < ${_MAKE_JOBS_NUMBER} ))
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/devel/subversion
Not the only "real issue", I'm afraid.
Yeah, sorry, looks like I'm late to the party, and it was already
discussed and reverted.
___
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: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)
Mark Millard wrote:
This seems to have broken doing buildworld buildkernel and
other things using make:
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
operator should be either == or !=
. . .
Using -d c shows the likes of:
. . .
lhs = "clang", rhs = "clang", op = ==
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op
= ==
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
lhs = "LD", rhs = "LD", op = ==
. . .
left = 6.00, right = 2.00, op = <=
left = 6.00, right = 1.00, op = <=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "clang",
op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
operator should be either == or !=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op
= ==
lhs = "clang", rhs = "gcc", op = ==
. . .
left = 0.00, right = 6.00, op = <=
left = 0.00, right = 3.00, op = <=
lhs = "clang", rhs = "gcc", op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
left = 11.00, right = 7.00, op = >=
lhs = "amd64", rhs = "arm", op = ==
(Now I just need to figure out how to get back to a working context.)
For me, buildworld/buildkernel produced only warnings, though the one in
ports is real issue:
$ make config
make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison
operator should be either == or !=
make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional
(defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} <
${_MAKE_JOBS_NUMBER} ))
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/devel/subversion
___
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: `shutdown -p now` fails to power off with VirtualBox UEFI boot
Olivier Cochard-Labbé wrote: On Thu, Jun 18, 2020 at 10:26 PM Yasuhiro KIMURA wrote: I have VirtualBox VM running 13-CURRENT. In order to switch from legacy BIOS to UEFI I reinstalled OS by using FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that `shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power off. Shutdown itself completes successfully. But power off never happens and CPU usage keeps high until either closing or resetting VM. I reinstalled OS by using FreeBSD-13.0-CURRENT-amd64-20200618-r362292-disc1.iso but the problem still happens. If I switch back to legacy BIOS then the problem disappears. And it doesn't happen with either 11.4-RELEASE and 12.1-RELEASE. Hi, Same problem using FreeBSD current UEFI guests with bhyve, so it should happen in any kind of hypervisor. It is an old regression (in the sense of -current, so older than 6 months). My idea was to generate very light UEFI VM images (because the snapshot VM images are BIOS based) and scripting a bisector tool, but I never took the time to do it. FWIW, shutdown works for me in VMware Workstation (Windows) and ESXi VMs, UEFI boot. ___ 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"
uma_zalloc_debug warnings after r362231
I've started getting the following after r362231 (I think) when plugging USB drive, not seeing any real issues though: ugen0.9: at usbus0 umass0 numa-domain 0 on uhub4 umass0: 10> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc101 umass0:2:0: Attached to scbus2 uma_zalloc_debug: zone "kenv" with the following non-sleepable locks held: exclusive sleep mutex CAM device lock (CAM device lock) r = 0 (0xf8000dcb6cd0) locked @ /usr/src/sys/cam/scsi/scsi_pass.c:674 stack backtrace: #0 0x80c32981 at witness_debugger+0x71 #1 0x80c3391d at witness_warn+0x40d #2 0x80efe426 at uma_zalloc_arg+0x46 #3 0x80b741da at getenv_string_buffer+0x3a #4 0x80b74907 at getenv_quad+0x17 #5 0x80b748d2 at getenv_int+0x12 #6 0x803a7f1a at daregister+0x1ea #7 0x8037445b at cam_periph_alloc+0x57b #8 0x803a7872 at daasync+0x2c2 #9 0x80381aa2 at xpt_async_process_dev+0x152 #10 0x8037d682 at xpt_async_process+0x312 #11 0x8037ddf2 at xpt_done_process+0x382 #12 0x8037fdb5 at xpt_done_td+0xf5 #13 0x80b831e0 at fork_exit+0x80 #14 0x810413ce at fork_trampoline+0xe da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 575845314136394150553136 da0: 40.000MB/s transfers da0: 953837MB (1953458176 512 byte sectors) da0: quirks=0x2 ___ 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: lockups on lenovo p43s under current
Pete Wright wrote: hello, i have a lenovo thinkpad P43s that exhibits lockups under CURRENT but behaves fine when running STABLE. i've tried to find a fully reproducible situation to get this system to lockup but haven't found anything yet. i am starting to suspect that the changes implemented in this review may be the issue though: https://reviews.freebsd.org/D23728 my reasoning is that i've observed issues when: - removing AC power from the laptop, or inserting AC power - when the system display has gone to sleep - randomly hanging during boot with this as last line: battery0: battery enitialization start unfortunately while the above seem to be cases where this has happened i haven't been able to %100 reproduce yet. so my first question is - would it be possible to just revert the changes in that diff, or has too much time gone past to just back out that single change. alternatively, is there any debugging information i can get on my end that might help figure out what the root cause is? Not really what you are asking, but it's possible to disable ACPI subdevices, so you could check if disabling cmbat completely helps and it's indeed the suspect: debug.acpi.disabled="cmbat" ___ 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"
nvme on 2019 macbooks
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? pciconf excerpt: none7@pci0:4:0:0: class=0x018002 rev=0x01 hdr=0x00 vendor=0x106b device=0x2005 subvendor=0x106b subdevice=0x1800 vendor = "Apple Inc." device = "ANS2 NVMe Controller" class = mass storage bar [10] = type Prefetchable Memory, range 64, base 0xc040, size 419304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xc140, size 524288, enabled bar [20] = type Prefetchable Memory, range 64, base 0xc160, size 65536, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 8 messages, 64 bit cap 10[70] = PCI-Express 2 endpoint max data 256(256) RO NS link x4(x4) speed 8.0(8.0) ASPM L1(L1) ClockPM enabled ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0019[148] = PCIe Sec 1 lane errors 0 ecap 0018[168] = LTR 1 ecap 001e[170] = L1 PM Substated 1 ecap 000b[180] = Vendor [1] ID 0002 Rev 1 Length 256 ecap 0015[280] = Resizable BAR 1 ___ 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: installkernel ignoring WITHOUT_DEBUG_FILES?
Mark Johnston wrote: On Wed, Apr 29, 2020 at 08:49:00AM +0300, Yuri Pankov wrote: I'm trying to replace the kernel on memstick image with the help of mdconfig, and installkernel runs out of space despite WITHOUT_DEBUG_FILES= added to /etc/src.conf. /usr/src$ make -V MK_DEBUG_FILES no /usr/src$ sudo rm -rf /mnt/usr/lib/debug /usr/src$ sudo make DESTDIR=/mnt installkernel You need WITHOUT_KERNEL_SYMBOLS= instead for the kernel. I'm not sure why it's a different option. Thank you, somehow I missed it, and its description is a bit misleading as well. ___ 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"
installkernel ignoring WITHOUT_DEBUG_FILES?
I'm trying to replace the kernel on memstick image with the help of mdconfig, and installkernel runs out of space despite WITHOUT_DEBUG_FILES= added to /etc/src.conf. /usr/src$ make -V MK_DEBUG_FILES no /usr/src$ sudo rm -rf /mnt/usr/lib/debug /usr/src$ sudo make DESTDIR=/mnt installkernel -- >>> Install check kernel -- -- >>> Installing kernel GENERIC on Wed Apr 29 08:43:19 MSK 2020 -- cd /usr/obj/usr/src/amd64.amd64/sys/GENERIC; MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++ -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" PATH=/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ ! "`dirname "$thiskernel"`" -ef /mnt/boot/kernel ] ; then chflags -R noschg /mnt/boot/kernel ; rm -rf /mnt/boot/kernel ; rm -rf /mnt/usr/lib/debug/boot/kernel ; else if [ -d /mnt/boot/kernel.old ] ; then chflags -R noschg /mnt/boot/kernel.old ; rm -rf /mnt/boot/kernel.old ; fi ; mv /mnt/boot/kernel /mnt/boot/kernel.old ; if [ -n "/usr/lib/debug" -a -d /mnt/usr/lib/debug/boot/kernel ]; then rm -rf /mnt/usr/lib/debug/boot/kernel.old ; mv /mnt/usr/lib/debug/boot/kernel /mnt/usr/lib/debug/boot/kernel.old ; fi ; sysctl kern.bootfile=/mnt/boot/kernel.old/"`basename "$thiskernel"`" ; fi mkdir -p /mnt/boot/kernel install -p -m 555 -o root -g wheel kernel /mnt/boot/kernel/ mkdir -p /mnt/usr/lib/debug/boot/kernel install -p -m 555 -o root -g wheel kernel.debug /mnt/usr/lib/debug/boot/kernel/ cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 MACHINE=amd64 MACHINE_ARCH=amd64 MODULES_EXTRA="" WITHOUT_MODULES="" ARCH_FLAGS="" DEBUG_FLAGS="-g" __MPATH="" DESTDIR="/mnt" KERNBUILDDIR="/usr/obj/usr/src/amd64.amd64/sys/GENERIC" SYSDIR="/usr/src/sys" MODULE_TIED=yes WITH_CTF="1" KCSAN_ENABLED="yes" make install ===> aac (install) install -T release -o root -g wheel -m 555 aac.ko /mnt/boot/kernel/ install -T debug -o root -g wheel -m 555 aac.ko.debug /mnt/usr/lib/debug/boot/kernel/ ... ===> dummynet (install) install -T release -o root -g wheel -m 555 dummynet.ko /mnt/boot/kernel/ /mnt: write failed, filesystem is full install: /mnt/boot/kernel/dummynet.ko: No space left on device ___ 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: Outdated jemalloc in CURRENT
Gordon Bergling wrote: I am not sure, that this info is correct. As far as I remember the update for jemalloc was reverted due to build problems, on some architecture. An updated revision has still to be commited to -CURRENT. That's exactly what the commit log says, yes? On Sat, Apr 18, 2020 at 07:20:03AM -0700, Steve Kargl wrote: On Sat, Apr 18, 2020 at 03:05:25PM +0300, nonamel...@ukr.net wrote: Hi everyone! As I see, CURRENT still uses outdated jemalloc 5.1.0 with some performance regressions that was fixed in 5.2.1. Are there some issues that blocking update jemalloc to recent version? r354606 | jasone | 2019-11-10 21:06:49 -0800 (Sun, 10 Nov 2019) | 4 lines Revert r354605: Update jemalloc to version 5.2.1. Compilation fails for non-llvm-based platforms. r354605 | jasone | 2019-11-10 19:27:14 -0800 (Sun, 10 Nov 2019) | 2 lines Update jemalloc to version 5.2.1. ___ 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: PCIe NVME drives not detected on Dell R6515
Scott Long wrote: On Apr 17, 2020, at 3:07 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 23:04: On Apr 17, 2020, at 2:45 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Over 3000 lines long but I finally managed to make SOL work so I have it as text! https://pastebin.pl/view/90fdaafb This helped a lot, thanks. It looks like these PCIe buses are marked as being hotplug, and for some reason we’re not probing them. At this point, I’d need to feed you some kernel patches that will dump out more info, but you’d have to compile them and get them onto your boot media. Is that a possibility? Currently I have all machines on 11.3 (where I can rebuild kernel without problem) If CURRENT is required I would need to setup some CURRENT VM in VirtualBox. Can you send me some link to documentation who should I create new ISO after rebuild? I don’t know of any docs for doing custom releases, and it looks like it’s harder than it used to be to insert custom patches. That said, I recommend doing the following on your 11.x build system: 1. Do a clean `make buildworld` with an up-to-date tree 2. change into the `release` directory that you just did the buildworld from 3. `sudo make release NOPORTS= NODOC= CHROOTDIR=/usr/tmp/release SRCBRANCH="base/stable/11@rHEAD”` You can set CHROOTDIR to whatever you want that has a few GB of space, but remember where you’ve set it for later steps. This will build a release with stock sources. Let it complete, both to prepare for the next step and to ensure that it works. It’ll take an hour or two depending on your machine speed 4. Take the patch that I’ll send you shortly and apply it to $CHROOTDIR/usr/src 5. `sudo make memstick NOPORTS= NODOC= SRC_UPDATE_SKIP= CHROOTDIR=/usr/tmp/release` Just a thought - it could possibly be easier to build just the patched kernel and try booting it (11.3 userland should work with CURRENT kernel, right?), doing the kernel-toolchaing target first, and using INSTKERNNAME with the installkernel target to temporary select it from loader menu. ___ 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: buildkernel failure because ctfconvert not installed
Trond Endrestøl wrote: On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: OK, I figured it out. I used to have MK_CTF=no in src.conf, but I recently changed it to WITH_CTF=no. It's either WITH_xxx=yes or WITHOUT_xxx=yes. Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that value is NOT checked: The values of variables are ignored regardless of their setting; even if they would be set to "FALSE" or "NO". The presence of an option causes it to be honored by make(1). /sys/conf/kern.post.mk checks whether MK_CTF is no and apparently does not invoke ctfconvert if that is the case. I put MK_CTF=no back into src.conf. So, now everything works without having cftconvert installed. ___ 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 crashes if loader.conf contains «net.isr.dispatch="direct"»
Lev Serebryakov wrote: Hello FreeBSD-Current, CURRENT (and64, r359632) crashes very early on boot if `/boot/loader.conf` contains this line: net.isr.dispatch="direct" Stacktrace (manually transcribed from photo of screen, as it is very early stage of boot, so no crashdump possible): calltrap() --- trap 0xc malloc() sysctl_handle_string() sysctl_netisr_dispatch_policy() sysctl_root_handler_locked() sysctl_register_oid() sysctl_regioster_all() mi_startup() btext() It is 100% reproducable for me, with GENERIC kernel. Sorry, it is very hard to bisect across clang10 import commit :-( But I suspect, it is very long-standing problem, at least 3 or 4 months. It's likely r357614, reverting that commit helps. ___ 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: can't build rust -- out of swap space
On 03.03.2020 15:27, Trond Endrestøl wrote: On Tue, 3 Mar 2020 12:56+0300, Yuri Pankov wrote: On 03.03.2020 12:44, Trond Endrestøl wrote: On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote: On 03.03.2020 11:49, Yuri Pankov wrote: With recent pkg fallout, I'm trying to build rust myself first time ever (as far as I can remember), and it's failing running out of swap on the following step: Building stage0 std artifacts (x86_64-unknown-freebsd -> x86_64-unknown-freebsd) running: "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" "--message-format" "json-render-diagnostics" ^C^C^C Build completed unsuccessfully in 0:00:55 Here I pressed ^C as the build actually continues despite several rustdoc, python, and other processes being killed. swap_pager: out of swap space swp_pager_getswapspace(20): failed swap_pager: out of swap space swp_pager_getswapspace(11): failed The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto installation option), top shows about 28G of memory free at that moment, so I'm wondering why the swap is being used, and if 2G should be enough to build rust. Looks like I got this wrong, adding a file-backed swap space I was actually able to run top, and seeing only 100M of memory being "Free", ~20G memory reported as "Active", and swap usage constantly growing being consumed by rustdoc process; something is really wrong here. Run top(1), hit the o key, type in size, and hit enter to have top sort the process list according to their virtual size. The culprit will eventually work its way to the top. Yes, it's rustdoc, and I'm seeing the same behavior as you described in your other reply. What's more interesting, having a little swap, processes get killed almost immediately, and the build happily continues resulting successful rust package. In my case, I see this behaviour twice during the build. I'll try and reduce my swap partition to 2 GiB and see if that makes a difference during the build. I wonder if you are seeing the problem for a long time, or it's something recent for you? I just tried reinstalling the system from 20200227 snapshot, and NOT seeing it, with or w/o the swap. Once I have everything installed, I'll update to latest and re-check (note that I had WITH_CTF defined in src.conf, though I doubt it's related). ___ 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: can't build rust -- out of swap space
On 03.03.2020 12:44, Trond Endrestøl wrote: On Tue, 3 Mar 2020 12:40+0300, Yuri Pankov wrote: On 03.03.2020 11:49, Yuri Pankov wrote: With recent pkg fallout, I'm trying to build rust myself first time ever (as far as I can remember), and it's failing running out of swap on the following step: Building stage0 std artifacts (x86_64-unknown-freebsd -> x86_64-unknown-freebsd) running: "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" "--message-format" "json-render-diagnostics" ^C^C^C Build completed unsuccessfully in 0:00:55 Here I pressed ^C as the build actually continues despite several rustdoc, python, and other processes being killed. swap_pager: out of swap space swp_pager_getswapspace(20): failed swap_pager: out of swap space swp_pager_getswapspace(11): failed The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto installation option), top shows about 28G of memory free at that moment, so I'm wondering why the swap is being used, and if 2G should be enough to build rust. Looks like I got this wrong, adding a file-backed swap space I was actually able to run top, and seeing only 100M of memory being "Free", ~20G memory reported as "Active", and swap usage constantly growing being consumed by rustdoc process; something is really wrong here. Run top(1), hit the o key, type in size, and hit enter to have top sort the process list according to their virtual size. The culprit will eventually work its way to the top. Yes, it's rustdoc, and I'm seeing the same behavior as you described in your other reply. What's more interesting, having a little swap, processes get killed almost immediately, and the build happily continues resulting successful rust package. ___ 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: can't build rust -- out of swap space
On 03.03.2020 11:49, Yuri Pankov wrote: With recent pkg fallout, I'm trying to build rust myself first time ever (as far as I can remember), and it's failing running out of swap on the following step: Building stage0 std artifacts (x86_64-unknown-freebsd -> x86_64-unknown-freebsd) running: "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" "--message-format" "json-render-diagnostics" ^C^C^C Build completed unsuccessfully in 0:00:55 Here I pressed ^C as the build actually continues despite several rustdoc, python, and other processes being killed. swap_pager: out of swap space swp_pager_getswapspace(20): failed swap_pager: out of swap space swp_pager_getswapspace(11): failed The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto installation option), top shows about 28G of memory free at that moment, so I'm wondering why the swap is being used, and if 2G should be enough to build rust. Looks like I got this wrong, adding a file-backed swap space I was actually able to run top, and seeing only 100M of memory being "Free", ~20G memory reported as "Active", and swap usage constantly growing being consumed by rustdoc process; something is really wrong here. Tried building both as root and user, DISABLE_MAKE_JOBS has no effect. ___ 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"
can't build rust -- out of swap space
With recent pkg fallout, I'm trying to build rust myself first time ever (as far as I can remember), and it's failing running out of swap on the following step: Building stage0 std artifacts (x86_64-unknown-freebsd -> x86_64-unknown-freebsd) running: "/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-freebsd" "-Zbinary-dep-depinfo" "-j" "1" "-v" "--release" "--frozen" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/usr/ports/lang/rust/work/rustc-1.41.1-src/src/libtest/Cargo.toml" "--message-format" "json-render-diagnostics" ^C^C^C Build completed unsuccessfully in 0:00:55 Here I pressed ^C as the build actually continues despite several rustdoc, python, and other processes being killed. swap_pager: out of swap space swp_pager_getswapspace(20): failed swap_pager: out of swap space swp_pager_getswapspace(11): failed The system has 32G of RAM and 2GB swap partition (as advised by zfs-auto installation option), top shows about 28G of memory free at that moment, so I'm wondering why the swap is being used, and if 2G should be enough to build rust. Tried building both as root and user, DISABLE_MAKE_JOBS has no effect. Any hints? ___ 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: 13.0-CURRENT r356767 wanted ZFS
David Wolfskill wrote: On Fri, Jan 17, 2020 at 12:18:41AM +, Clay Daniels wrote: 13.0-CURRENT r356767 would not take NO for an answer, and kept up a loop until I gave up trying to use UFS. No big deal, seems to work fine... Clay Err...? Is there some additional context that I'm missing? I've been tracking head daily for ... longer than I really want to think about, including on at least one system that has no ZFS file systems; the last couple of smoke-tests were at: FreeBSD g1-53.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #7 r356758M/356758: Wed Jan 15 03:49:49 PST 2020 r...@g1-53.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300076 1300076 and FreeBSD g1-53.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #8 r356786M/356787: Thu Jan 16 03:56:45 PST 2020 r...@g1-53.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300076 1300076 It is not clear to me at what point anything might have a chance to indicate that it "wanted ZFS" and request an action. Likely it's about the latest 13.0-CURRENT snapshot image (r356767) and the change to bsdinstall to make ZFS default partitioning scheme, now discussed on arch@. ___ 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: DRM-current-kmod is still a problem at r353339
Niclas Zeising wrote: On 2019-10-20 08:45, Yuri Pankov wrote: On 10/18/2019 8:01 AM, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. Confirmed that it worked for me too on P51. Sorry for offtopic, but do you see the console getting "stuck" after loading i915kms, i.e. for input to show you need to switch to another console and back? This is a known regression with drm-devel-kmod, and one of the reasons it hasn't made it past devel yet. Got it, thanks. I'm only seeing it on the lenovo laptop with hd630 and not on the intel nuc with iris plus 650 graphics, so I thought it's that laptop specific. ___ 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: DRM-current-kmod is still a problem at r353339
On 10/21/2019 4:14 AM, Neel Chauhan wrote:
For me, the following code is still necessary for me (HP Spectre x360
2018), which is the remaining parts of the patches not committed if you
are using a recent kernel. I don't know about you all ThinkPad users, it
should still apply as it's Intel in general not just HP or Lenovo.
Without these patches, I get a kernel panic.
Keep in mind that the patch may render as spaces, but it should be tabs.
Index: amd64/pmap.c
===
--- amd64/pmap.c (revision 353788)
+++ amd64/pmap.c (working copy)
@@ -355,8 +355,9 @@
} \
} while (0)
-#define CHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) \
- CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m))
+#define CHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) do { \
+ CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m)); \
+} while (0)
#define RELEASE_PV_LIST_LOCK(lockp) do { \
struct rwlock **_lockp = (lockp); \
@@ -951,8 +952,16 @@
static u_long *
pmap_delayed_invl_genp(vm_page_t m)
{
+ vm_paddr_t pa;
+ u_long *gen;
- return (_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
+ pa = VM_PAGE_TO_PHYS(m);
+ if (__predict_false((pa) > pmap_last_pa))
+ gen = _dummy_large.pv_invl_gen;
+ else
+ gen = &(pa_to_pmdp(pa)->pv_invl_gen);
+
+ return (gen);
}
#else
static u_long *
If you look below, that's exactly the patch mjg@ provided and Xin
pointed you at.
On 2019-10-20 02:45, Yuri Pankov wrote:
On 10/18/2019 8:01 AM, Xin Li wrote:
Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
-> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) ,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.
Confirmed that it worked for me too on P51.
Sorry for offtopic, but do you see the console getting "stuck" after
loading i915kms, i.e. for input to show you need to switch to another
console and back?
___
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: DRM-current-kmod is still a problem at r353339
On 10/18/2019 8:01 AM, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. Confirmed that it worked for me too on P51. Sorry for offtopic, but do you see the console getting "stuck" after loading i915kms, i.e. for input to show you need to switch to another console and back? ___ 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: memstick installer doesn't install loader.efi into ESP
On 10/8/2019 9:07 AM, Yuri Pankov wrote: On Mon, Oct 7, 2019, at 5:23 AM, Yuri Pankov wrote: Just tried reinstalling the system on my laptop using the latest available memstick snapshot (https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20191004-r353072-memstick.img), using UEFI boot, and default ZFS partitioning, and it didn't boot after installation. Booting into the installer again, I noticed that ESP is empty. Reinstalling again after wiping pool labels and clearing partitions didn't change anything, though I noticed the "/tmp/bsdinstall-esps: no such file or directory" in the installer log. Mounting ESP, creating EFI/FreeBSD/ directory, copying /boot/loader.efi there, and creating appropriate Boot variable solves it, of course, but I'm wondering what have gone wrong. Laptop has NVMe drive (nvd0, empty, gpart destroy -F nvd0), SATA drive (ada0, empty, gpart destroy -F ada0), and is booting from USB memstick (da0); no Boot variables defined when booting to installer (other than defaults ones for laptop). Any other details I should provide here? I think I see the problem, bootconfig script uses ZFSBOOT_DISKS variable that isn't defined and always empty and auto-detection must be unreliable in some cases, at least for me as I reproduced it on another system with NVMe device adding a SATA disk as well (didn't look into the details). Should be easy to fix, review incoming. https://reviews.freebsd.org/D21930 ___ 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: memstick installer doesn't install loader.efi into ESP
On Mon, Oct 7, 2019, at 5:23 AM, Yuri Pankov wrote: > Just tried reinstalling the system on my laptop using the latest > available memstick snapshot > (https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20191004-r353072-memstick.img), > > using UEFI boot, and default ZFS partitioning, and it didn't boot after > installation. Booting into the installer again, I noticed that ESP is > empty. > > Reinstalling again after wiping pool labels and clearing partitions > didn't change anything, though I noticed the "/tmp/bsdinstall-esps: no > such file or directory" in the installer log. > > Mounting ESP, creating EFI/FreeBSD/ directory, copying /boot/loader.efi > there, and creating appropriate Boot variable solves it, of course, but > I'm wondering what have gone wrong. > > Laptop has NVMe drive (nvd0, empty, gpart destroy -F nvd0), SATA drive > (ada0, empty, gpart destroy -F ada0), and is booting from USB memstick > (da0); no Boot variables defined when booting to installer (other than > defaults ones for laptop). Any other details I should provide here? I think I see the problem, bootconfig script uses ZFSBOOT_DISKS variable that isn't defined and always empty and auto-detection must be unreliable in some cases, at least for me as I reproduced it on another system with NVMe device adding a SATA disk as well (didn't look into the details). Should be easy to fix, review incoming. ___ 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"
memstick installer doesn't install loader.efi into ESP
Just tried reinstalling the system on my laptop using the latest available memstick snapshot (https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20191004-r353072-memstick.img), using UEFI boot, and default ZFS partitioning, and it didn't boot after installation. Booting into the installer again, I noticed that ESP is empty. Reinstalling again after wiping pool labels and clearing partitions didn't change anything, though I noticed the "/tmp/bsdinstall-esps: no such file or directory" in the installer log. Mounting ESP, creating EFI/FreeBSD/ directory, copying /boot/loader.efi there, and creating appropriate Boot variable solves it, of course, but I'm wondering what have gone wrong. Laptop has NVMe drive (nvd0, empty, gpart destroy -F nvd0), SATA drive (ada0, empty, gpart destroy -F ada0), and is booting from USB memstick (da0); no Boot variables defined when booting to installer (other than defaults ones for laptop). Any other details I should provide here? ___ 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: ESXi VM does not boot in UEFI mode from 20190906 snapshot ISO
Rebecca Cran wrote: On 2019-09-18 09:01, Yuri Pankov wrote: Any hints on debugging this further? Are you running ESXi 6.7 Update 2? Or, what version of ESXi are you using that has the problem? Yes, exactly, sorry for not mentioning it. ESXi version: 6.7.0 ESXi build number: 13006603 ___ 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: ESXi VM does not boot in UEFI mode from 20190906 snapshot ISO
Toomas Soome wrote: On 18 Sep 2019, at 18:01, Yuri Pankov wrote: I have tested several snapshot ISOs available for download: FreeBSD-13.0-CURRENT-amd64-20190822-r351363-disc1.iso - OK FreeBSD-13.0-CURRENT-amd64-20190829-r351591-disc1.iso - OK FreeBSD-13.0-CURRENT-amd64-20190906-r351901-disc1.iso - FAIL FreeBSD-13.0-CURRENT-amd64-20190913-r352265-disc1.iso - FAIL FAIL being VM shutdown after loading kernel/modules and displaying "EFI framebuffer information". Relevant messages in the VM log are rather unhelpful: 2019-09-18T14:47:12.397Z| vcpu-0| I125: Guest: Firmware has transitioned to runtime. 2019-09-18T14:47:12.434Z| vcpu-0| I125: Msg_Post: Error 2019-09-18T14:47:12.434Z| vcpu-0| I125: [msg.efi.exception] The firmware encountered an unexpected exception. The virtual machine cannot boot. Any hints on debugging this further? Im not really sure about debugging; I can not tell about early kernel, but I’d check if the kernel/module locations conflict with efi memory map items… The same issue can be seen with vmware fusion, it is not 100% repeatable but I’d say, 95%, starting grab_faults, perhaps ls or some other random command, and boot -v may actually start the system up. OK. It's 100% reproducible here, going from 20190829 (which works) to 20190906 (which doesn't), so I was wondering if anything in r351591-r351901 range could be pointed at as a likely offender. ___ 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"
ESXi VM does not boot in UEFI mode from 20190906 snapshot ISO
I have tested several snapshot ISOs available for download: FreeBSD-13.0-CURRENT-amd64-20190822-r351363-disc1.iso - OK FreeBSD-13.0-CURRENT-amd64-20190829-r351591-disc1.iso - OK FreeBSD-13.0-CURRENT-amd64-20190906-r351901-disc1.iso - FAIL FreeBSD-13.0-CURRENT-amd64-20190913-r352265-disc1.iso - FAIL FAIL being VM shutdown after loading kernel/modules and displaying "EFI framebuffer information". Relevant messages in the VM log are rather unhelpful: 2019-09-18T14:47:12.397Z| vcpu-0| I125: Guest: Firmware has transitioned to runtime. 2019-09-18T14:47:12.434Z| vcpu-0| I125: Msg_Post: Error 2019-09-18T14:47:12.434Z| vcpu-0| I125: [msg.efi.exception] The firmware encountered an unexpected exception. The virtual machine cannot boot. Any hints on debugging this further? ___ 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: panic: rcv_start < rcv_end
Michael Tuexen wrote: On 10. Sep 2019, at 14:37, Yuri Pankov wrote: Just seen this almost immediately after booting the system installed from amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap. Sadly, I didn't have the swap/dump device configured at the time, so no dump was saved. But it looks like I'm not alone, seeing the https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/ topic. Note that I'm running on bare metal, so bhyve isn't involved. My panic screenshot is at https://pasteboard.co/IwLaXXb.jpg. In (the most likely) case it's not helpful enough, I'm now running with dump device configured, and will update if/when the panic reproduces. This panic should be fixed by: https://svnweb.freebsd.org/changeset/base/352072 Please drop me a note if not. Good to know, thanks! I only seen it once after installing the snapshot that didn't include the fix, and didn't notice that the fix is already committed. ___ 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"
panic: rcv_start < rcv_end
Just seen this almost immediately after booting the system installed from amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap. Sadly, I didn't have the swap/dump device configured at the time, so no dump was saved. But it looks like I'm not alone, seeing the https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/ topic. Note that I'm running on bare metal, so bhyve isn't involved. My panic screenshot is at https://pasteboard.co/IwLaXXb.jpg. In (the most likely) case it's not helpful enough, I'm now running with dump device configured, and will update if/when the panic reproduces. ___ 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/lsof: VOP_FSYNC definition moved?
Larry Rosenman wrote:
> http://home.lerctr.org:/data/live-host-ports/2019-08-30_20h25m06s/logs/errors/lsof-4.93.2_4,8.log
>
> --- dnode2.o ---
> In file included from dnode2.c:56:
> In file included from
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h:33:
> In file included from
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h:47:
> In file included from
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_context.h:73:
> In file included from /usr/src/sys/cddl/compat/opensolaris/sys/vfs.h:37:
> /usr/src/sys/cddl/compat/opensolaris/sys/vnode.h:243:10: warning:
> implicit declaration of function 'VOP_FSYNC' is invalid in C99
> [-Wimplicit-function-declaration]
> error = VOP_FSYNC(vp, MNT_WAIT, curthread);
> ^
> 1 warning generated.
> A failure has been detected in another branch of the parallel make
Real error seems to be way above that (see below), and VOP_FSYNC one is
just a fallout from that. It is likely related to r351594 by
Konstantin, but I didn't look into the details. You could try defining
_SYS_PCPU_H_ before including in dlsof.h with _KERNEL
defined -- this seems to fix the lsof build for me.
-
In file included from ckkv.c:43:
In file included from ./../lsof.h:221:
In file included from ./../dlsof.h:412:
In file included from /usr/src/sys/sys/file.h:44:
In file included from /usr/src/sys/sys/refcount.h:36:
In file included from /usr/src/sys/sys/systm.h:126:
In file included from /usr/src/sys/sys/pcpu.h:223:
/usr/include/machine/pcpu_aux.h:55:55: error: expected expression
__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
^
/usr/include/machine/pcpu_aux.h:56:6: error: use of undeclared
identifier 'pc_curthread'; did you mean '__curthread'?
pc_curthread)));
^
/usr/include/machine/pcpu_aux.h:51:1: note: '__curthread' declared here
__curthread(void)
^
/usr/include/machine/pcpu_aux.h:66:56: error: expected expression
__asm("movq %%gs:%P1,%0" : "=r" (pcb) : "n" (offsetof(struct pcpu,
^
/usr/include/machine/pcpu_aux.h:67:6: error: use of undeclared
identifier 'pc_curpcb'; did you mean '__curpcb'?
pc_curpcb)));
^
/usr/include/machine/pcpu_aux.h:62:1: note: '__curpcb' declared here
__curpcb(void)
___
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: Kernel-Crash when working with ubt0
Warner Losh wrote: > Is it from read_connection_list? If so I have a 'patch' that I'm using but > haven't committed because it's just too gross: drop the lock before the > copyout and pick it up again after... > > Warner > > On Mon, Aug 26, 2019 at 1:23 AM Hans Petter Selasky wrote: > >> Do you have a backtrace? I think it's https://forums.freebsd.org/threads/kernel-crash-with-ubt0.72049/, not sure why OP didn't provide details here. ___ 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"
memstick images install broken bootx64.efi
Hi, Looks like installations from snapshot memstick images (tried all available ones for amd64 from http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/) put broken bootx64.efi to ESP -- the system in question simply tries to boot via PXE. Fixing this is simple -- mounting the ESP, and copying /boot/loader.efi from installation media (the same memstick) to efi/boot/bootx64.efi. And diff shows that the two actually differ, having the same size and file(1) output though. Anyone seeing the same and/or knows what's wrong here (before I try looking into that)? ___ 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: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Dag-Erling Smørgrav wrote: > Yuri Pankov writes: >> There's apparently a bug in VMware Workstation NAT implementation, >> [...] The patch itself is attached. > > Could you please open a differential and add me as reviewer? https://reviews.freebsd.org/D18636 And there's already a PR for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234426 signature.asc Description: OpenPGP digital signature
Re: head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)
Yuri Pankov wrote: > Mark Millard wrote: >> >> >> On 2018-Dec-24, at 13:49, Yuri Pankov wrote: >> >>> Mark Millard wrote: >>>> From my from=source head -r3418363 context, top with -opid does not >>>> seem to sort in a coherent order, not time of process creation order >>>> (either direction) and not in just-PID numeric order (either >>>> direction). For example: >>>> >>>> PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU >>>> COMMAND >>>>0 root 24 -16- 0 368K swapin 1 0:00 0.00% >>>> [kernel] >>>> 16 root 1 -16- 016K -3 0:00 0.00% >>>> [soaiod2] >>>> 752 root 1 20018M18M select 1 0:07 0.01% >>>> /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -g >>>> 800 root 1 20011M 908K nanslp 1 0:01 0.00% >>>> /usr/sbin/cron -s >>>>1 root 1 200 9900K 132K wait 3 0:00 0.00% >>>> [init] >>>> 17 root 1 -16- 016K -0 0:00 0.00% >>>> [soaiod3] >>>>2 root 1 -16- 016K crypto 0 0:00 0.00% >>>> [crypto] >>>> 18 root 1 -16- 016K -0 0:00 0.00% >>>> [soaiod4] >>>> 850 root 1 20013M 2756K wait 3 0:00 0.00% >>>> login [pam] (login) >>>>3 root 1 -16- 016K crypto 0 0:00 0.00% >>>> [crypto returns 0] >>>> 19 root 1 -16- 016K mmcsd0 0:25 0.00% >>>> [mmcsd0: mmc/sd card] >>>> 643 root 1 20011M 1124K select 2 0:01 0.00% >>>> /usr/sbin/syslogd -s >>>>4 root 1 -16- 016K crypto 0 0:00 0.00% >>>> [crypto returns 1] >>>> 20 root 1 -16- 016K mmcsd0 0:00 0.00% >>>> [mmcsd0boot0: mmc/sd] >>>>5 root 1 -16- 016K crypto 0 0:00 0.00% >>>> [crypto returns 2] >>>> 21 root 1 -16- 016K mmcsd0 0:00 0.00% >>>> [mmcsd0boot1: mmc/sd] >>>>6 root 1 -16- 016K crypto 0 0:00 0.00% >>>> [crypto returns 3] >>>> 22 root 3 -16- 048K psleep 3 0:12 0.00% >>>> [pagedaemon] >>>> 5270 root 1 20014M 3780K CPU2 2 0:00 0.14% top >>>> -Saopid >>>> 662 root 1 20011M 680K select 0 0:00 0.00% >>>> /usr/sbin/rpcbind >>>>7 root 2 -16- 032K -0 0:00 0.00% [cam] >>>> 23 root 1 -16- 016K psleep 2 0:00 0.00% >>>> [vmdaemon] >>>> 5255 root 1 20012M 3092K wait 0 0:00 0.00% -sh >>>> (sh) >>>>8 root 1 -16- 016K waitin 0 0:00 0.00% >>>> [sctp_iterator] >>>> 24 root 3 -16- 048K qsleep 3 0:12 0.01% >>>> [bufdaemon] >>>> 712 root 1 52012M 616K select 0 0:00 0.00% >>>> /usr/sbin/mountd -r >>>>9 root 1 -16- 016K -1 0:04 0.00% >>>> [rand_harvestq] >>>> 25 root 1 20- 016K vlruwt 0 0:04 0.00% >>>> [vnlru] >>>> 10 root 1 -16- 016K audit_ 0 0:00 0.00% >>>> [audit] >>>> 26 root 1 16- 016K syncer 0 1:45 0.00% >>>> [syncer] >>>> 714 root 1 52012M 728K select 3 0:00 0.00% >>>> nfsd: master (nfsd) >>>> 11 root 4 155 ki31 064K CPU0 0 144.6H 397.09% >>>> [idle] >>>> 235 root 1 20011M 564K select 3 0:00 0.00% >>>> dhclient: system.syslog (dhclient) >>>> 715 root 32 52011M 1120K rpcsvc 3 0:00 0.00% >>>> nfsd: server (nfsd) >>>> 12 root 18 -52- 0 288K WAIT 2 2:29 1.43% >>>> [intr] >>>> 412 root 1 20010M72K select 2 0:00 0.00% >>>> /sbin/devd >>>> 796 root 1 52020M 672K select 0 0:0
Re: head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)
Mark Millard wrote: > > > On 2018-Dec-24, at 13:49, Yuri Pankov wrote: > >> Mark Millard wrote: >>> From my from=source head -r3418363 context, top with -opid does not >>> seem to sort in a coherent order, not time of process creation order >>> (either direction) and not in just-PID numeric order (either >>> direction). For example: >>> >>> PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU >>> COMMAND >>>0 root 24 -16- 0 368K swapin 1 0:00 0.00% >>> [kernel] >>> 16 root 1 -16- 016K -3 0:00 0.00% >>> [soaiod2] >>> 752 root 1 20018M18M select 1 0:07 0.01% >>> /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -g >>> 800 root 1 20011M 908K nanslp 1 0:01 0.00% >>> /usr/sbin/cron -s >>>1 root 1 200 9900K 132K wait 3 0:00 0.00% [init] >>> 17 root 1 -16- 016K -0 0:00 0.00% >>> [soaiod3] >>>2 root 1 -16- 016K crypto 0 0:00 0.00% >>> [crypto] >>> 18 root 1 -16- 016K -0 0:00 0.00% >>> [soaiod4] >>> 850 root 1 20013M 2756K wait 3 0:00 0.00% login >>> [pam] (login) >>>3 root 1 -16- 016K crypto 0 0:00 0.00% >>> [crypto returns 0] >>> 19 root 1 -16- 016K mmcsd0 0:25 0.00% >>> [mmcsd0: mmc/sd card] >>> 643 root 1 20011M 1124K select 2 0:01 0.00% >>> /usr/sbin/syslogd -s >>>4 root 1 -16- 016K crypto 0 0:00 0.00% >>> [crypto returns 1] >>> 20 root 1 -16- 016K mmcsd0 0:00 0.00% >>> [mmcsd0boot0: mmc/sd] >>>5 root 1 -16- 016K crypto 0 0:00 0.00% >>> [crypto returns 2] >>> 21 root 1 -16- 016K mmcsd0 0:00 0.00% >>> [mmcsd0boot1: mmc/sd] >>>6 root 1 -16- 016K crypto 0 0:00 0.00% >>> [crypto returns 3] >>> 22 root 3 -16- 048K psleep 3 0:12 0.00% >>> [pagedaemon] >>> 5270 root 1 20014M 3780K CPU2 2 0:00 0.14% top >>> -Saopid >>> 662 root 1 20011M 680K select 0 0:00 0.00% >>> /usr/sbin/rpcbind >>>7 root 2 -16- 032K -0 0:00 0.00% [cam] >>> 23 root 1 -16- 016K psleep 2 0:00 0.00% >>> [vmdaemon] >>> 5255 root 1 20012M 3092K wait 0 0:00 0.00% -sh >>> (sh) >>>8 root 1 -16- 016K waitin 0 0:00 0.00% >>> [sctp_iterator] >>> 24 root 3 -16- 048K qsleep 3 0:12 0.01% >>> [bufdaemon] >>> 712 root 1 52012M 616K select 0 0:00 0.00% >>> /usr/sbin/mountd -r >>>9 root 1 -16- 016K -1 0:04 0.00% >>> [rand_harvestq] >>> 25 root 1 20- 016K vlruwt 0 0:04 0.00% >>> [vnlru] >>> 10 root 1 -16- 016K audit_ 0 0:00 0.00% >>> [audit] >>> 26 root 1 16- 016K syncer 0 1:45 0.00% >>> [syncer] >>> 714 root 1 52012M 728K select 3 0:00 0.00% nfsd: >>> master (nfsd) >>> 11 root 4 155 ki31 064K CPU0 0 144.6H 397.09% [idle] >>> 235 root 1 20011M 564K select 3 0:00 0.00% >>> dhclient: system.syslog (dhclient) >>> 715 root 32 52011M 1120K rpcsvc 3 0:00 0.00% nfsd: >>> server (nfsd) >>> 12 root 18 -52- 0 288K WAIT 2 2:29 1.43% [intr] >>> 412 root 1 20010M72K select 2 0:00 0.00% >>> /sbin/devd >>> 796 root 1 52020M 672K select 0 0:00 0.00% >>> /usr/sbin/sshd >>> 13 root 3 -8- 048K -1 0:11 0.00% [geom] >>> 14 root 20 -68- 0 320K -0 0:02 0.00% [usb] >>> 238 root 1 52012M 416K select 1 0:00 0.00% >>> dhclient: awg0 [priv] (dhclient) >>> 15 root 1 -16- 0
Re: head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)
Mark Millard wrote:
> From my from=source head -r3418363 context, top with -opid does not
> seem to sort in a coherent order, not time of process creation order
> (either direction) and not in just-PID numeric order (either
> direction). For example:
>
> PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU COMMAND
> 0 root 24 -16- 0 368K swapin 1 0:00 0.00%
> [kernel]
>16 root 1 -16- 016K -3 0:00 0.00%
> [soaiod2]
> 752 root 1 20018M18M select 1 0:07 0.01%
> /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -g
> 800 root 1 20011M 908K nanslp 1 0:01 0.00%
> /usr/sbin/cron -s
> 1 root 1 200 9900K 132K wait 3 0:00 0.00% [init]
>17 root 1 -16- 016K -0 0:00 0.00%
> [soaiod3]
> 2 root 1 -16- 016K crypto 0 0:00 0.00%
> [crypto]
>18 root 1 -16- 016K -0 0:00 0.00%
> [soaiod4]
> 850 root 1 20013M 2756K wait 3 0:00 0.00% login
> [pam] (login)
> 3 root 1 -16- 016K crypto 0 0:00 0.00%
> [crypto returns 0]
>19 root 1 -16- 016K mmcsd0 0:25 0.00%
> [mmcsd0: mmc/sd card]
> 643 root 1 20011M 1124K select 2 0:01 0.00%
> /usr/sbin/syslogd -s
> 4 root 1 -16- 016K crypto 0 0:00 0.00%
> [crypto returns 1]
>20 root 1 -16- 016K mmcsd0 0:00 0.00%
> [mmcsd0boot0: mmc/sd]
> 5 root 1 -16- 016K crypto 0 0:00 0.00%
> [crypto returns 2]
>21 root 1 -16- 016K mmcsd0 0:00 0.00%
> [mmcsd0boot1: mmc/sd]
> 6 root 1 -16- 016K crypto 0 0:00 0.00%
> [crypto returns 3]
>22 root 3 -16- 048K psleep 3 0:12 0.00%
> [pagedaemon]
> 5270 root 1 20014M 3780K CPU2 2 0:00 0.14% top
> -Saopid
> 662 root 1 20011M 680K select 0 0:00 0.00%
> /usr/sbin/rpcbind
> 7 root 2 -16- 032K -0 0:00 0.00% [cam]
>23 root 1 -16- 016K psleep 2 0:00 0.00%
> [vmdaemon]
> 5255 root 1 20012M 3092K wait 0 0:00 0.00% -sh
> (sh)
> 8 root 1 -16- 016K waitin 0 0:00 0.00%
> [sctp_iterator]
>24 root 3 -16- 048K qsleep 3 0:12 0.01%
> [bufdaemon]
> 712 root 1 52012M 616K select 0 0:00 0.00%
> /usr/sbin/mountd -r
> 9 root 1 -16- 016K -1 0:04 0.00%
> [rand_harvestq]
>25 root 1 20- 016K vlruwt 0 0:04 0.00% [vnlru]
>10 root 1 -16- 016K audit_ 0 0:00 0.00% [audit]
>26 root 1 16- 016K syncer 0 1:45 0.00%
> [syncer]
> 714 root 1 52012M 728K select 3 0:00 0.00% nfsd:
> master (nfsd)
>11 root 4 155 ki31 064K CPU0 0 144.6H 397.09% [idle]
> 235 root 1 20011M 564K select 3 0:00 0.00%
> dhclient: system.syslog (dhclient)
> 715 root 32 52011M 1120K rpcsvc 3 0:00 0.00% nfsd:
> server (nfsd)
>12 root 18 -52- 0 288K WAIT 2 2:29 1.43% [intr]
> 412 root 1 20010M72K select 2 0:00 0.00%
> /sbin/devd
> 796 root 1 52020M 672K select 0 0:00 0.00%
> /usr/sbin/sshd
>13 root 3 -8- 048K -1 0:11 0.00% [geom]
>14 root 20 -68- 0 320K -0 0:02 0.00% [usb]
> 238 root 1 52012M 416K select 1 0:00 0.00%
> dhclient: awg0 [priv] (dhclient)
>15 root 1 -16- 016K -0 0:00 0.00%
> [soaiod1]
> 239 _dhcp 1 20012M 484K select 1 0:00 0.00%
> dhclient: awg0 (dhclient)
>
> (Basically the Pine64+ 2GB [aarch64] above was idle after boot other than
> some runs of top.)
>
> I see this oddity across architectures, for example amd64, powerpc64,
> aarch64, armv7.
No wonder, it doesn't seem to have worked ever (?) as the compare_pid is
simply not defined in compares list. Try attached patch.
diff --git a/usr.bin/top/machine.c b/usr.bin/top/machine.c
index 374c9da0edf4..cd17f2f5dc3a 100644
--- a/usr.bin/top/machine.c
+++ b/usr.bin/top/machine.c
@@ -1511,6 +1511,7 @@ int (*compares[])(const void *arg1, const void *arg2) = {
compare_ivcsw,
compare_jid,
compare_swap,
+ compare_pid,
NULL
};
signature.asc
Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message , Yuri > Pankov write > s: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH >> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi"; >> protected-headers="v1" >> From: Yuri Pankov >> To: Cy Schubert >> Cc: Mark Peek , Enji Cooper , >> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= >> , freebsd-current >> Message-ID: >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 >> changes >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi >> Content-Type: text/plain; charset=utf-8 >> Content-Language: en-US >> Content-Transfer-Encoding: quoted-printable >> >> Cy Schubert wrote: >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20 >>> Pankov write >>> s: >>>> Yuri Pankov wrote: >>>>> In-Reply-To: > >>> l.gmail. >>>>> com> >>>>> Mark Peek wrote: >>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper >>> wro=3D >>>>> te: >>>>>> =3D20 >>>>>>> >>>>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>>>>>>> >>>>>>>> Mark Peek wrote: >>>>>>>>> Thanks for the cc:. I forwarded the original report on to an=20 >>> interna=3D >>>>> l >>>>>>>>> VMware desktop product contact. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>>> What version of Workstation or Fusion is this occurring on? I=20 >>> saw >>>>>>>>> Workstation 14 mentioned but curious if it occurs on=20 >>> Workstation 15 >>>>>>>>> (latest). >>>>>>>> >>>>>>>> Running the latest available for download: 15.0.2 build-10952284. >>>>>>> >>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20 >>> wasn=3DE2=3D >>>>> =3D80=3D99t >>>>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20 >>> don=3DE2=3D80=3D99=3D >>>>> t know if it >>>>>>> affects that version... >>>>>>> >>>>>>> Thanks so much! >>>>>>> >>>>>>> -Enji >>>>>> =3D20 >>>>>> =3D20 >>>>>> BTW, there appears to be a workaround here using -o=20 >>> 'IPQoS=3D3Dthroughput=3D >>>>> ' >>>>>> (untested by me). I've seen the issue forwarded internally but no=20 >>> furth=3D >>>>> er >>>>>> discussions yet. >>>>>> =3D20 >>>>>> https://communities.vmware.com/thread/590825 >>>> >>>> Yes, that's exactly what the patch attached to original message does i= >> f >>>> we are running as a VMware guest. The workaround is known and it work= >> s, >>>> but it's not immediately clear and I just wanted it to be the default >>>> for the time being. >>> =20 >>> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20 >>> intended? >> >> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can >> be ripped out easily when no longer needed, and yes, it's enabled >> unconditionally for now. And the check itself is if 'kern.vm_guest' >> reports 'vmware'. > > It doesn't look that conditional to me. Indeed, and that's what I said exactly :-) The added code is enabled unconditionally, and the added code also has a check for vmware guest. The ifdefs are there only to show that this is local addition, nothing else. I'm not saying it needs to be done this way, this is just something I did quickly after installing yet another VM and forgetting to modify my ~/.ssh/config to include the workaround. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri > Pankov write > s: >> Yuri Pankov wrote: >>> In-Reply-To: l.gmail. >>> com> >>> Mark Peek wrote: >>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wro= >>> te: >>>> =20 >>>>> >>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>>>>> >>>>>> Mark Peek wrote: >>>>>>> Thanks for the cc:. I forwarded the original report on to an > interna= >>> l >>>>>>> VMware desktop product contact. >>>>>> >>>>>> Thank you. >>>>>> >>>>>>> What version of Workstation or Fusion is this occurring on? I > saw >>>>>>> Workstation 14 mentioned but curious if it occurs on > Workstation 15 >>>>>>> (latest). >>>>>> >>>>>> Running the latest available for download: 15.0.2 build-10952284. >>>>> >>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it > wasn=E2= >>> =80=99t >>>>> affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I > don=E2=80=99= >>> t know if it >>>>> affects that version... >>>>> >>>>> Thanks so much! >>>>> >>>>> -Enji >>>> =20 >>>> =20 >>>> BTW, there appears to be a workaround here using -o > 'IPQoS=3Dthroughput= >>> ' >>>> (untested by me). I've seen the issue forwarded internally but no > furth= >>> er >>>> discussions yet. >>>> =20 >>>> https://communities.vmware.com/thread/590825 >> >> Yes, that's exactly what the patch attached to original message does if >> we are running as a VMware guest. The workaround is known and it works, >> but it's not immediately clear and I just wanted it to be the default >> for the time being. > > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this > intended? It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can be ripped out easily when no longer needed, and yes, it's enabled unconditionally for now. And the check itself is if 'kern.vm_guest' reports 'vmware'. > Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and > Windows) running on VMware clusters with NSX network (with plans to > totally virtualize the network), we've noticed other network > quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris > <--> Linux. I'm not surprised that this regression also exists. > > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > >> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>> >>> Mark Peek wrote: >>>> Thanks for the cc:. I forwarded the original report on to an internal >>>> VMware desktop product contact. >>> >>> Thank you. >>> >>>> What version of Workstation or Fusion is this occurring on? I saw >>>> Workstation 14 mentioned but curious if it occurs on Workstation 15 >>>> (latest). >>> >>> Running the latest available for download: 15.0.2 build-10952284. >> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t >> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it >> affects that version... >> >> Thanks so much! >> >> -Enji > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > (untested by me). I've seen the issue forwarded internally but no further > discussions yet. > > https://communities.vmware.com/thread/590825 Yes, that's exactly what the patch attached to original message does if we are running as a VMware guest. The workaround is known and it works, but it's not immediately clear and I just wanted it to be the default for the time being. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > Thanks for the cc:. I forwarded the original report on to an internal > VMware desktop product contact. Thank you. > What version of Workstation or Fusion is this occurring on? I saw > Workstation 14 mentioned but curious if it occurs on Workstation 15 > (latest). Running the latest available for download: 15.0.2 build-10952284. > On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > >> I've been hit by this as well. At least two others on IRC have had the >> same issue. >> >> Warner >> >> On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: >> >>> >>>> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: >>>> >>>> Hi, >>>> >>>> There's apparently a bug in VMware Workstation NAT implementation, made >>>> visible by the change to default values of IPQoS in OpenSSH 7.8p1, >>>> making all ssh connections from the guest behind the NAT to fail with >>>> obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: >>>> Broken pipe". >>>> >>>> I wonder if we could integrate the attached patch (or some smarter >>>> version of it) for the time being as the bug affects several major WS >>>> releases, and it's not immediately clear where the problem is. >>>> >>>> The change itself: >>>> >>>> >>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 >>>> >>>> The bug reports (some of them): >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1624437 >>>> https://communities.vmware.com/message/2803219#2803219 >>>> >>>> The patch itself is attached. >>>> >>> >>> Cool… yeah… I’ve been running into this issue for a while with >>> VMware Fusion 11.0.1. >>> I CCed mp@ for visibility. >>> Thanks! >>> -Enji >>> >> > ___ > 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" > signature.asc Description: OpenPGP digital signature
workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Hi,
There's apparently a bug in VMware Workstation NAT implementation, made
visible by the change to default values of IPQoS in OpenSSH 7.8p1,
making all ssh connections from the guest behind the NAT to fail with
obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
Broken pipe".
I wonder if we could integrate the attached patch (or some smarter
version of it) for the time being as the bug affects several major WS
releases, and it's not immediately clear where the problem is.
The change itself:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
The bug reports (some of them):
https://bugzilla.redhat.com/show_bug.cgi?id=1624437
https://communities.vmware.com/message/2803219#2803219
The patch itself is attached.
diff --git a/crypto/openssh/readconf.c b/crypto/openssh/readconf.c
index f97a6ac72a95..9ed6902a0f46 100644
--- a/crypto/openssh/readconf.c
+++ b/crypto/openssh/readconf.c
@@ -16,6 +16,9 @@
__RCSID("$FreeBSD$");
#include
+#ifdef VMWARE_GUEST_WORKAROUND
+#include
+#endif
#include
#include
#include
@@ -1954,6 +1957,15 @@ fill_default_options(Options * options)
{
char *all_cipher, *all_mac, *all_kex, *all_key;
int r;
+#ifdef VMWARE_GUEST_WORKAROUND
+ char scval[7]; /* "vmware\0" */
+ size_t scsiz = sizeof(scval);
+ int vmwguest = 0;
+
+ if (sysctlbyname("kern.vm_guest", scval, , NULL, 0) == 0 &&
+ strcmp(scval, "vmware") == 0)
+ vmwguest = 1;
+#endif
if (options->forward_agent == -1)
options->forward_agent = 0;
@@ -2088,8 +2100,18 @@ fill_default_options(Options * options)
if (options->visual_host_key == -1)
options->visual_host_key = 0;
if (options->ip_qos_interactive == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_interactive = IPTOS_LOWDELAY;
+ else
+#endif
options->ip_qos_interactive = IPTOS_DSCP_AF21;
if (options->ip_qos_bulk == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_bulk = IPTOS_THROUGHPUT;
+ else
+#endif
options->ip_qos_bulk = IPTOS_DSCP_CS1;
if (options->request_tty == -1)
options->request_tty = REQUEST_TTY_AUTO;
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+= crypto
CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
.endif
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
.include
.PATH: ${SSHDIR}
signature.asc
Description: OpenPGP digital signature
Re: Whine: "Could not open /dev/crypto: No such file or directory"
David Wolfskill wrote: After update from r341844 to r342042, I see the above-cited "whine" when I attempt to use an SSH client on the upgraded machine. SSH client function seems OK, so the message is (apparently) merely annoying: freebeast(13.0-C)[2] uname -a FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #403 r342042M/342042: Thu Dec 13 04:50:25 PST 2018 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 freebeast(13.0-C)[3] ssh albert hostname Could not open /dev/crypto: No such file or directory albert.catwhisker.org freebeast(13.0-C)[4] echo $? 0 freebeast(13.0-C)[5] It's r342009, and I followed up on that commit. ___ 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: cannot build i386 12.0-RELEASE kernel on -current
Henry Vogt wrote: > Hi, > > my build machine (FreeBSD:13:amd64 r341429) builds world/kernel ok for amd64, > world for i386 ok, but fails 'make buildkernel' for i386: > > -- snip > > ... > > --- if_vte.o --- > /usr/src/12/sys/dev/vte/if_vte.c:76:10: fatal error: 'miibus_if.h' file not > found > #include "miibus_if.h" > ^ > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_denode.o > --- modules-all --- > --- all_subdir_accf_dns --- > ===> accf_dns (all) > Building /usr/obj/usr/src/12/i386.i386/sys/MODULAR/msdosfs_fat.o > --- if_vte.o --- > 1 error generated. > *** [if_vte.o] Error code 1 > > ... > > -- snip > > Is this known - did i miss something ? > Howto fix ? Does your "MODULAR" config file include "device miibus"? signature.asc Description: OpenPGP digital signature
Re: nda(4) does not work (reliably) in VMware Workstation
Chuck Tuffli wrote: > On Sat, Dec 8, 2018 at 12:28 PM Yuri Pankov <mailto:yur...@yuripv.net>> wrote: > > Hi, > > Running -HEAD in VMware Workstation 15.0.2 VM. Trying to use nda(4) > instead of nvd(4) shows the following list of errors, and eventually > panics: > > https://people.freebsd.org/~yuripv/nda1.png > https://people.freebsd.org/~yuripv/nda2.png > > nvd(4) works without issues in this VM. nda(4) works as well in VMware > ESXi VMs. Is this a problem with WS NVMe emulation? > > > Since I don't have access to ESXi, the attached is a speculative fix. If > it works, I'll clean this up a bit and get it committed. If not, please > post the output from: > nvmecontrol identtify nvme0 Thank you, it seems to help (was seeing the issue previously immediately after boot). BTW, the ESXi VM works fine with nda, it's only the Workstation that had the problem. Comparing `nvmecontrol identify` output from both, the only difference is (first is WS, second is ESXi): -Dataset Management Command: Not Supported +Dataset Management Command: Supported signature.asc Description: OpenPGP digital signature
nda(4) does not work (reliably) in VMware Workstation
Hi, Running -HEAD in VMware Workstation 15.0.2 VM. Trying to use nda(4) instead of nvd(4) shows the following list of errors, and eventually panics: https://people.freebsd.org/~yuripv/nda1.png https://people.freebsd.org/~yuripv/nda2.png nvd(4) works without issues in this VM. nda(4) works as well in VMware ESXi VMs. Is this a problem with WS NVMe emulation? signature.asc Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
Warner Losh wrote:
> On Mon, Dec 3, 2018 at 11:14 AM Yuri Pankov wrote:
>
>> Warner Losh wrote:
>>> On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote:
>>>
>>>> Yuri Pankov wrote:
>>>>> Warner Losh wrote:
>>>>>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin >>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Building disc1.iso using `make release` and having WITH_CTF set in
>>>>>>>>> src.conf leads to "File too big" displayed when booting the image.
>>>>>>>>>
>>>>>>>>> Would it make sense to build loader and related parts without CTF
>>>>>>>>> unconditionally as it doesn't look useful there?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Fully agree with you
>>>>>>>>
>>>>>>>
>>>>>>> What a great Idea. We already turn it off in defs.mk:
>>>>>
>>>>> Sorry about that, I incorrectly assumed it wasn't done yet as there was
>>>>> a difference for me.
>>>>>
>>>>>>> MK_CTF= no
>>>>>>>
>>>>>>> which should be global to every single Makefile under stand. I'm not
>>>> sure
>>>>>>> why that's turning it back on.
>>>>>>>
>>>>>>
>>>>>> % cat /etc/src.conf
>>>>>> WITH_CTF=yes
>>>>>> FRED=present
>>>>>> % cd stand/cdboot
>>>>>> % make -V MK_CTF
>>>>>> no
>>>>>> % make -V FRED
>>>>>> present
>>>>>> %
>>>>>>
>>>>>> So this sure sounds like a false positive to me. Do you have logs
>>>> showing
>>>>>> cdboot building with MK_CTF=yes?
>>>>>
>>>>> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
>>>>> ctfconvert calls in the latter case. Attached is the diff of binary
>>>>> sizes in obj/ for stand/i386; could one of those be the problem I'm
>>>> seeing?
>>>>
>>>> If ctfconvert calls are indeed the source of problem, then something
>>>> seems to be wrong here (I didn't mention the "cdboot" binary exactly,
>>>> rather the binary it's trying to load):
>>>>
>>>> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
>>>> no
>>>>
>>>> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
>>>> CTFCONVERT_CMD
>>>> no
>>>> ctfconvert -L VERSION ${.TARGET}
>>>>
>>>
>>> Ding! We have a winner: order of operations not quite right. We included
>>> src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and
>> then
>>> we change the MK_CTF value which has no effect. Unlike the lazy
>> evaluation
>>> in makefile rules, where the last one wins, when we're parsing stuff for
>>> .if, it's the current value that's used. The solution is to include
>>> src.opts.mk later after we set the MK_foo overrides.
>>>
>>> r341433 should fix that.
>>
>> Thank you.
>>
>
> Please give it a spin and let me know if we're golden. I'll MFC it then
> since this should be in 12.1.
Done. Everything looks good now - having clean /usr/obj/; world/kernel
built with WITH_CTF= in /etc/src.conf; successfully booted the disc1.iso
built using `make cdrom`.
signature.asc
Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
Warner Losh wrote:
> On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote:
>
>> Yuri Pankov wrote:
>>> Warner Losh wrote:
>>>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>>>>
>>>>>
>>>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin
>>>>> wrote:
>>>>>
>>>>>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Building disc1.iso using `make release` and having WITH_CTF set in
>>>>>>> src.conf leads to "File too big" displayed when booting the image.
>>>>>>>
>>>>>>> Would it make sense to build loader and related parts without CTF
>>>>>>> unconditionally as it doesn't look useful there?
>>>>>>>
>>>>>>
>>>>>> Fully agree with you
>>>>>>
>>>>>
>>>>> What a great Idea. We already turn it off in defs.mk:
>>>
>>> Sorry about that, I incorrectly assumed it wasn't done yet as there was
>>> a difference for me.
>>>
>>>>> MK_CTF= no
>>>>>
>>>>> which should be global to every single Makefile under stand. I'm not
>> sure
>>>>> why that's turning it back on.
>>>>>
>>>>
>>>> % cat /etc/src.conf
>>>> WITH_CTF=yes
>>>> FRED=present
>>>> % cd stand/cdboot
>>>> % make -V MK_CTF
>>>> no
>>>> % make -V FRED
>>>> present
>>>> %
>>>>
>>>> So this sure sounds like a false positive to me. Do you have logs
>> showing
>>>> cdboot building with MK_CTF=yes?
>>>
>>> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
>>> ctfconvert calls in the latter case. Attached is the diff of binary
>>> sizes in obj/ for stand/i386; could one of those be the problem I'm
>> seeing?
>>
>> If ctfconvert calls are indeed the source of problem, then something
>> seems to be wrong here (I didn't mention the "cdboot" binary exactly,
>> rather the binary it's trying to load):
>>
>> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
>> no
>>
>> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
>> CTFCONVERT_CMD
>> no
>> ctfconvert -L VERSION ${.TARGET}
>>
>
> Ding! We have a winner: order of operations not quite right. We included
> src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and then
> we change the MK_CTF value which has no effect. Unlike the lazy evaluation
> in makefile rules, where the last one wins, when we're parsing stuff for
> .if, it's the current value that's used. The solution is to include
> src.opts.mk later after we set the MK_foo overrides.
>
> r341433 should fix that.
Thank you.
signature.asc
Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
Yuri Pankov wrote:
> Warner Losh wrote:
>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote:
>>
>>>
>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin
>>> wrote:
>>>
>>>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote:
>>>>> Hi,
>>>>>
>>>>> Building disc1.iso using `make release` and having WITH_CTF set in
>>>>> src.conf leads to "File too big" displayed when booting the image.
>>>>>
>>>>> Would it make sense to build loader and related parts without CTF
>>>>> unconditionally as it doesn't look useful there?
>>>>>
>>>>
>>>> Fully agree with you
>>>>
>>>
>>> What a great Idea. We already turn it off in defs.mk:
>
> Sorry about that, I incorrectly assumed it wasn't done yet as there was
> a difference for me.
>
>>> MK_CTF= no
>>>
>>> which should be global to every single Makefile under stand. I'm not sure
>>> why that's turning it back on.
>>>
>>
>> % cat /etc/src.conf
>> WITH_CTF=yes
>> FRED=present
>> % cd stand/cdboot
>> % make -V MK_CTF
>> no
>> % make -V FRED
>> present
>> %
>>
>> So this sure sounds like a false positive to me. Do you have logs showing
>> cdboot building with MK_CTF=yes?
>
> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of
> ctfconvert calls in the latter case. Attached is the diff of binary
> sizes in obj/ for stand/i386; could one of those be the problem I'm seeing?
If ctfconvert calls are indeed the source of problem, then something
seems to be wrong here (I didn't mention the "cdboot" binary exactly,
rather the binary it's trying to load):
yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD
no
yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V
CTFCONVERT_CMD
no
ctfconvert -L VERSION ${.TARGET}
signature.asc
Description: OpenPGP digital signature
Re: WITH_CTF breaks CD loader: "File too big"
Warner Losh wrote: > On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote: > >> >> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin >> wrote: >> >>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote: >>>> Hi, >>>> >>>> Building disc1.iso using `make release` and having WITH_CTF set in >>>> src.conf leads to "File too big" displayed when booting the image. >>>> >>>> Would it make sense to build loader and related parts without CTF >>>> unconditionally as it doesn't look useful there? >>>> >>> >>> Fully agree with you >>> >> >> What a great Idea. We already turn it off in defs.mk: Sorry about that, I incorrectly assumed it wasn't done yet as there was a difference for me. >> MK_CTF= no >> >> which should be global to every single Makefile under stand. I'm not sure >> why that's turning it back on. >> > > % cat /etc/src.conf > WITH_CTF=yes > FRED=present > % cd stand/cdboot > % make -V MK_CTF > no > % make -V FRED > present > % > > So this sure sounds like a false positive to me. Do you have logs showing > cdboot building with MK_CTF=yes? Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of ctfconvert calls in the latter case. Attached is the diff of binary sizes in obj/ for stand/i386; could one of those be the problem I'm seeing? --- siz12018-12-03 18:49:01.764091000 +0300 +++ siz22018-12-03 18:49:39.666198000 +0300 @@ -22,28 +22,28 @@ /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/isoboot/isoboot 14395 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/isoboot/isoboot.8.gz 1324 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/isoboot/isoboot.bin 12553 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/libi386/libi386.a 318926 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/libi386/libi386.a 358146 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader/.depend 213 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/.depend 212 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th 380928 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.bin 369808 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.sym 1213320 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th 598016 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.bin 584344 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/loader_4th.sym 1427856 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_4th/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/.depend 213 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua 434176 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.bin 422992 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.sym 1508144 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua 716800 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.bin 706132 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/loader_lua.sym 1791284 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_lua/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/.depend 150 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp 319488 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.bin 308304 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.sym 991168 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp 495616 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.bin 484536 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/loader_simp.sym 1167400 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/loader_simp/vers.c 99 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/mbr/mbr 512 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pmbr/pmbr 512 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/loader 434176 -/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeboot 436224 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/loader 716800 +/usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeboot 718848 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeboot.8.gz 2311 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/pxeldr/pxeldr 512 /usr/obj/home/yuripv/ws/ctf/amd64.amd64/stand/i386/zfsboot/zfsboot 262656 signature.asc Description: OpenPGP digital signature
WITH_CTF breaks CD loader: "File too big"
Hi, Building disc1.iso using `make release` and having WITH_CTF set in src.conf leads to "File too big" displayed when booting the image. Would it make sense to build loader and related parts without CTF unconditionally as it doesn't look useful there? signature.asc Description: OpenPGP digital signature
Re: SCSI and dmesg
Yuri Pankov wrote: > Warner Losh wrote: >> Greetings >> >> a few weeks ago I pointed people to the nycbug dmesg service. I said I was >> looking at data to drive SCSI retirement. I've gatherd some preliminary >> data, which I've uploaded to >> https://github.com/bsdimp/device-data/blob/master/cam.md along with some >> preliminary notions of disposition for the hardware. I'm still working out >> the kinks in the dmesg parsing, but this is interesting data. >> >> If you've not recently submitted, please consider doing so. We'll be >> finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a >> few weeks, and I'm going to base much of what list I come up with based on >> what is submitted. The glitches with FreeBSD dmesgs have been cleared up as >> well. >> >> http://dmesgd.nycbug.org/index.cgi >> >> or >> >> curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d >> "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv >> smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ >> /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi > > Got another system to submit, but continuously getting "500 Internal > Server Error" using the curl one-liner. dmesg.boot attached in case > it's the source of the problem. It works now, sorry for the noise. signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
Renato Botelho wrote: > On 26/11/18 19:32, Florian Limberger wrote: >> Hi, >> >> On 20.11.18 14:46, Charlie Li wrote: >>> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >>> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >>> (ID=3) has no handler (20181031/exfldio-428) >>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >>> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) >> >> On my Thinkpad T410 I get exactly the same error, but it prevents the >> ACPI poweroff. Instead following lines are printed: > > I'm seeing it on my ThinkPad x230 as well Looks like r340993 should be the fix? signature.asc Description: OpenPGP digital signature
Re: SCSI and dmesg
Warner Losh wrote: > Greetings > > a few weeks ago I pointed people to the nycbug dmesg service. I said I was > looking at data to drive SCSI retirement. I've gatherd some preliminary > data, which I've uploaded to > https://github.com/bsdimp/device-data/blob/master/cam.md along with some > preliminary notions of disposition for the hardware. I'm still working out > the kinks in the dmesg parsing, but this is interesting data. > > If you've not recently submitted, please consider doing so. We'll be > finalizing the scsi SIMs that I'm going to propose retiring in 13 here in a > few weeks, and I'm going to base much of what list I come up with based on > what is submitted. The glitches with FreeBSD dmesgs have been cleared up as > well. > > http://dmesgd.nycbug.org/index.cgi > > or > > curl -v -d "nickname=$USER" -d "email=$USER@$(hostname)" -d > "description=FreeBSD/$(uname -m) on $(kenv smbios.system.maker) $(kenv > smbios.system.product)" -d "do=addd" --data-urlencode 'dmesg@ > /var/run/dmesg.boot' http://dmesgd.nycbug.org/index.cgi Got another system to submit, but continuously getting "500 Internal Server Error" using the curl one-liner. dmesg.boot attached in case it's the source of the problem. ---<>--- Copyright (c) 1992-2018 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 r340744 GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(efifb): resolution 3440x1440 CPU: Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz (3504.14-MHz K8-class CPU) Origin="GenuineIntel" Id=0x806e9 Family=0x6 Model=0x8e Stepping=9 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c67af Structured Extended Features3=0x9c00 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16472522752 (15709 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 3 2 Timecounter "TSC-low" frequency 1752072050 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8113f150, 0) error 19 kbd0 at kbdmux0 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" netmap: loaded module nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 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 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-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf03f mem 0x2ffe00-0x2ffeff,0x2f-0x2f7fff at device 2.0 on pci0 vgapci0: Boot video device xhci0: mem 0x2fff01-0x2fff01 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xde424000-0xde425fff,0xde427000-0xde4270ff,0xde426000-0xde4267ff at device 23.0 on pci0 ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.5 on pci0 pci1: on pcib2 pci1: at device 0.0 (no driver attached) pcib3: at device 28.7 on pci0 pci2: on pcib3 pci2: at device 0.0 (no driver attached) pcib4: at device 29.0 on pci0 pci3: on pcib4 nvme0: mem 0xde10-0xde103fff at device 0.0 on pci3 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.2 (no driver attached) hdac0: mem 0x2fff02-0x2fff023fff,0x2fff00-0x2fff00 at device 31.3 on pci0 em0: mem 0xde40-0xde41 at device 31.6 on pci0
Re: C.UTF-8 as default locale
Baptiste Daroussin wrote: > On Sun, Nov 04, 2018 at 09:35:48AM +0300, Yuri Pankov wrote: >> Hi, >> >> Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the >> following entry: >> >> - Make C.UTF-8 the default locale (conrad, dteske(installer)) >> >> As this sort of change is better done early, I have put togetger a >> simple change introducing C.UTF-8 locale using the same common LC_CTYPE >> map as other UTF-8 locales (and it's now the source of symlinks instead >> of en_US one), and having all other components use C locale: >> >> https://reviews.freebsd.org/D17833 >> >> With that in place, next step is likely to be updating 'default' entry >> in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and >> changes to installer are likely to be not needed? >> > > > Hey I never thought it could be done in such an easy way! don't know why, > I was always looking at it in a complex way, thus never started it. > > Thank you very much, this looks fine to me! and that is imho a great addition Thank you (and others) for the quick review. I was also wondering, with this now in place, is anyone else working on this? Are there any known issues possibly preventing this from happening now? signature.asc Description: OpenPGP digital signature
C.UTF-8 as default locale
Hi, Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the following entry: - Make C.UTF-8 the default locale (conrad, dteske(installer)) As this sort of change is better done early, I have put togetger a simple change introducing C.UTF-8 locale using the same common LC_CTYPE map as other UTF-8 locales (and it's now the source of symlinks instead of en_US one), and having all other components use C locale: https://reviews.freebsd.org/D17833 With that in place, next step is likely to be updating 'default' entry in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and changes to installer are likely to be not needed? signature.asc Description: OpenPGP digital signature
installer loader hangs going from 20181026 to 20181101 snapshot with Supermicro virtual IPMI disks
Hi, Trying to boot latest -current snapshot (20181101) on Supermicro H8DG6 using the IPMI virtual CD hangs after displaying the disks information, however booting the previous one (20181026) works. The difference is that newer one displays the "BIOS drive A:", so it could be related to recent changes by Toomas (CC'ed). The screenshots are: https://people.freebsd.org/~yuripv/sm-13-20181026.jpg https://people.freebsd.org/~yuripv/sm-13-20181101.jpg signature.asc Description: OpenPGP digital signature
Re: UEFI boot hangs after loader
Warner Losh wrote: > On Sun, Oct 28, 2018, 10:39 AM Yuri Pankov wrote: > >> Jung-uk Kim wrote: >>> On 18. 10. 24., Warner Losh wrote: >>>> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton wrote: >>>> >>>>> gryphon# efivar -N --hex $(efivar | grep Boot0002) >>>>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00 >>>>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00 >>>>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00 >>>>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00 >>>>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00 >>>>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05 >>>>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00 >>>>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90 >>>>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff >>>>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19 >>>>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00 >>>>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00 >>>>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00 >>>>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00 >>>>> 00e0: 7f ff 04 00 00 00 42 4f >>>>> gryphon# >>>>> >>>> >>>> Perfect. I'll decode this and see if I can figure out where we're going >> AFU. >>> >>> It looks familiar. >>> >>> http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa >> >> I have an output looking similar, but not exactly: >> >> : 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00 >> 0010: 4f 00 53 00 00 00 04 01 2a 00 01 00 00 00 28 00 >> 0020: 00 00 00 00 00 00 00 40 06 00 00 00 00 00 f1 84 >> 0030: d7 13 ca da e8 11 94 1d 30 85 a9 40 0a 5c 02 02 >> 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 >> 0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 >> 0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 >> 0070: 7f ff 04 00 aa 55 18 0f >> >> Same problem with ASUS P8H77-I. >> > > Do the latest fixes help? Sorry, I missed those commits and was using 20181026 snapshot, which obviously didn't include them. Now, just to be sure, I built memstick image from latest checkout, and yes, both installer and installed system are able to boot, thank you! signature.asc Description: OpenPGP digital signature
Re: UEFI boot hangs after loader
Jung-uk Kim wrote: > On 18. 10. 24., Warner Losh wrote: >> On Wed, Oct 24, 2018 at 10:33 AM Harry Newton wrote: >> >>> gryphon# efivar -N --hex $(efivar | grep Boot0002) >>> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00 >>> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00 >>> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00 >>> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00 >>> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00 >>> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05 >>> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00 >>> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90 >>> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff >>> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19 >>> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00 >>> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00 >>> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00 >>> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00 >>> 00e0: 7f ff 04 00 00 00 42 4f >>> gryphon# >>> >> >> Perfect. I'll decode this and see if I can figure out where we're going AFU. > > It looks familiar. > > http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa I have an output looking similar, but not exactly: : 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00 0010: 4f 00 53 00 00 00 04 01 2a 00 01 00 00 00 28 00 0020: 00 00 00 00 00 00 00 40 06 00 00 00 00 00 f1 84 0030: d7 13 ca da e8 11 94 1d 30 85 a9 40 0a 5c 02 02 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 0070: 7f ff 04 00 aa 55 18 0f Same problem with ASUS P8H77-I. >>> On 24 October 2018 at 15:09, Warner Losh wrote: >>> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton wrote: > Booted with the installer image makes efibootmgr to work as you said: > > gryphon# efibootmgr -v > BootCurrent: 0002 > Timeout : 2 seconds > BootOrder : 0001, 0002 > Boot0001* UEFI OS > > HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI) > ada0p1:/EFI/BOOT/BOOTX64.EFI (null) > > However it (efibootmgr) hangs and doesn't return to the shell, though it > is > interruptible with ^C. > > The partition listed against Boot0001 is my efi partition. > Can you do something like: sudo efivar -N --hex `sudo efivar | grep Boot0002` so I can have an example of a naughty boot variable? That's almost certainly causing the heart-burn. Warner > /H > > On 23 October 2018 at 22:51, Kyle Evans wrote: > >> Hi, >> >> I suspect 4th vs. lua has no impact here, given the output shown -- >> can you throw one of the installer images [0] on some removable media >> and give that a shot for booting? If that works, we can explore UEFI >> variables from there. >> >> efibootmgr will only work on a successful UEFI boot, unfortunately- if >> we didn't make uefi loader -> kernel transition, then we don't have >> access to runtime services. >> >> Thanks, >> >> Kyle Evans >> >> [0] > https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/ >> >> On Tue, Oct 23, 2018 at 4:23 PM Harry Newton wrote: >>> >>> I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and > re-made >> the >>> binaries in /boot but this doesn't solve the problem. It did copy >>> /boot/loader_4th.efi to /boot/loader.efi which is (according to > uefi(8) >>> which is what is called from /boot/boot1.efi and which contains the >> strings >>> I see on the console before the hang. But it must then call / read >>> something else and I don't think it can find it. Not sure why it > doesn't >>> produce an error message. I *think* it may be something to do with > EFI >>> variables, but as efibootmgr doesn't work I can't explore this, > despite >>> efirt being in the kernel. >>> >>> Suggestions received welcomed, and new suggestions / leads to follow > also >>> very much welcomed. >>> >>> /H >>> >>> >>> On 23 October 2018 at 21:33, Harry Newton wrote: >>> Right ... I've the binaries in /boot, freshly made. This might be > a >> silly question ... do I not need to copy them (or dd the boot1.efifat > image) >> to the EFI partition ? /H On 23 October 2018 at 21:30, Toomas Soome wrote: > you should have the binaries in boot - just ln (or copy) one to >> loader.efi > > rgds, > toomas > > > On 23 Oct 2018, at 23:22, Harry Newton wrote: > > Yes ... so as everything is built, can I just alter >> LOADER_DEFAULT_INTERP > in
Re: vm_fault on boot with NVMe/nda
Daniel Nebdal wrote:
> Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9),
> with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card.
>
> By default, it shows up as /dev/nvd0, and this is how I installed the
> system. It has a single large UFS2 (with SJ and TRIM support) partition
> mounted as /. (There's also a few other partitions on it that should be
> irrelevant for this.) This works, but it does sometimes slow down for
> minutes at the time with disturbing queue lengths in gstat; on the order of
> tens of thousands. As I understand it, this is due to how TRIM operations
> take precedence over everything else when using nvd ?
>
> Looking around, I noticed the nda driver for NVMe-through-CAM. To test it,
> I added hw.nvme.use_nvd=0 to loader.conf. On one level, this works: The
> drive shows up as /dev/nda0 . On the other hand, trying to mount nda0p2 as
> / floods the console with "vm_fault: pager read error, pid 1 (init)", and
> never finishes booting.
>
> What is more interesting is that if I boot from the drive, but mount an
> alpha9 usb stick as /, I can then mount the nda device just fine, and the
> very minimal testing I did (using bin/cat and COPYRIGHT on the NVMe drive)
> seems to work.
>
> So - is nda meant to be bootable, or am I a bit over-eager in trying to do
> so?
> If not, is there anything smart I can do to get better performance out of
> nvd?
> (Or have I just overlooked something obvious?)
>
> Dmesg from a normal nvd boot here:
> https://openbenchmarking.org/system/1810159-RA-SSD30089593/SSD/dmesg
FWIW, I set hw.nvme.use_nvd=0 in the installer, got 12-ALPHA8 installed
on nda0, and it's happily booting from it (using ZFS, though), so it's
certainly meant to be bootable.
signature.asc
Description: OpenPGP digital signature
