head -r355777: Lack of USB keyboard input during loader

I normally use a PS2 keyboard on a Gigabyte Aorus Gaming 7 (with a ThreadRipper 1950X) during its boot sequence. (Most use is via ssh once booted.) But I've used a USB keyboard as well on rare occasion. (Unsure when that last was.) Well, I happened to try using a USB keyboard for head -r355777

FreeBSD head vs. ThreadRipper 1950X X399 AORUS gaming 7's EtherNet : Am I the only one with it not working?

I (sometimes) have access to an Threadripper 1950X based X399 AORUS Gaming 7 system. (Not used for gaming.) The notes below are about that context. Currently, I'm mostly checking if my context is unique for some reason. I'll start off noting that Fedora (currently 31) and Windows 10 Pro x64

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

On 2019-Sep-27, at 15:22, Mark Millard wrote: > On 2019-Sep-27, at 13:52, Mark Millard wrote: > >> On 2019-Sep-27, at 12:24, Mark Johnston wrote: >> >>> On Thu, Sep 26, 2019 at 08:37:39PM -0700, Mark Millard wrote: On 2019-Sep-26, at 17:05, Mark Millard wrote:

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

On 2019-Sep-27, at 13:52, Mark Millard wrote: > On 2019-Sep-27, at 12:24, Mark Johnston > wrote: > >> On Thu, Sep 26, 2019 at 08:37:39PM -0700, Mark Millard wrote: >>> >>> >>> On 2019-Sep-26, at 17:05, Mark Millard >> > wrote: >>> On

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

On 2019-Sep-27, at 12:24, Mark Johnston wrote: > On Thu, Sep 26, 2019 at 08:37:39PM -0700, Mark Millard wrote: >> >> >> On 2019-Sep-26, at 17:05, Mark Millard wrote: >> >>> On 2019-Sep-26, at 13:29, Mark Johnston wrote: One possibility is that these are kernel memory allocations

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

t;>>> On 2019-Sep-25, at 19:26, Mark Millard wrote: >>>> >>>>> On 2019-Sep-25, at 10:02, Mark Johnston wrote: >>>>> >>>>>> On Mon, Sep 23, 2019 at 01:28:15PM -0700, Mark Millard via freebsd-amd64 >>>>>> wrote: >&g

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

On 2019-Sep-25, at 20:27, Mark Millard wrote: > On 2019-Sep-25, at 19:26, Mark Millard wrote: > >> On 2019-Sep-25, at 10:02, Mark Johnston wrote: >> >>> On Mon, Sep 23, 2019 at 01:28:15PM -0700, Mark Millard via freebsd-amd64 >>> wrote: >>>&g

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

On 2019-Sep-25, at 19:26, Mark Millard wrote: > On 2019-Sep-25, at 10:02, Mark Johnston wrote: > >> On Mon, Sep 23, 2019 at 01:28:15PM -0700, Mark Millard via freebsd-amd64 >> wrote: >>> Note: I have access to only one FreeBSD amd64 context, and >>>

Re: head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

On 2019-Sep-25, at 10:02, Mark Johnston wrote: > On Mon, Sep 23, 2019 at 01:28:15PM -0700, Mark Millard via freebsd-amd64 > wrote: >> Note: I have access to only one FreeBSD amd64 context, and >> it is also my only access to a NUMA context: 2 memory >> domains. A Th

head -r352341 example context on ThreadRipper 1950X: cpuset -n prefer:1 with -l 0-15 vs. -l 16-31 odd performance?

Note: I have access to only one FreeBSD amd64 context, and it is also my only access to a NUMA context: 2 memory domains. A Threadripper 1950X context. Also: I have only a head FreeBSD context on any architecture, not 12.x or before. So I have limited compare/contrast material. I present the

FreeBSD-head-amd64-gcc builds are broken since 2019-Aug-17 or so: no previous declaration for '__ashldi3' (stand/i386/boot2 context)

https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/11176/console is for -r351411 and shows: 15:43:33 --- ashldi3.o --- 15:43:33 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc --sysroot=/tmp/obj/workspace/src/amd64.amd64/tmp -B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe

amd64 head -r351153 self-built but via devel/llvm90: 'objcopy: elf_update() failed: Layout constraint violation' for gptboot.bin

I upgraded to head -r351153 and then attempted a buildworld buildkernel via devel/llvm90 (rc2 via ports head -r509054), but that (from scratch) build attempt got: --- gptboot.bin --- objcopy: elf_update() failed: Layout constraint violation *** [gptboot.bin] Error code 1 make[5]: *** gptboot.bin

head -r351102 amd64 rebuilding itself but via devel/xtoolchain-llvm90 ( rc2: ports head -r509054 ) fails for boot2.out: ld.lld: error: undefined symbol: __ashldi3

My attempt to have -r351102 rebuild itself via devel/llvm90 (rc2) got: --- all_subdir_stand --- --- boot2.out --- ld.lld: error: undefined symbol: __ashldi3 >>> referenced by ufsread.c:234 (/usr/src/stand/libsa/ufsread.c:234) >>> boot2.o:(fsread) >>> referenced by ufsread.c:270

amd64 head -r349794 (under Hyper-V): "panic: spin lock held too long" during a buildworld buildkernel

Looks like pmap_invalidate_range using smp_targeted_tlb_shootdown using _mtx_lock_spin_cookie. I'll note that I had no trouble with -r349444 building world or kernel repeatedly, including when I originally build -r349794 to upgrade. The below is from my 2nd buildworld buildkernel under

Does head well-support the old MacPro3,1 (2 sockets of Xeon E5472 Quad-Core Processors)?

Does someone know the status of head relative to supporting the MacPro3,1 ? If yes, please comment on the status. I may be able to get access to one if it is well supported. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)

Re: head -r345758 Ryzen Threadripper 1950X vs. amdtemp.ko : dev.cpu.31 missing

On 2019-Apr-6, at 09:50, Konstantin Belousov wrote: > On Fri, Apr 05, 2019 at 11:47:58AM -0700, Mark Millard wrote: >> >> >> On 2019-Apr-5, at 04:46, Konstantin Belousov wrote: >> >>> On Thu, Apr 04, 2019 at 04:58:15PM -0700, Mark

Re: head -r345758 Ryzen Threadripper 1950X vs. amdtemp.ko : dev.cpu.31 missing

On 2019-Apr-5, at 04:46, Konstantin Belousov wrote: > On Thu, Apr 04, 2019 at 04:58:15PM -0700, Mark Millard via freebsd-amd64 > wrote: >> On a: >> >> CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.70-MHz K8-class >> CPU) >> Origin=&quo

head -r345758 Ryzen Threadripper 1950X vs. amdtemp.ko : dev.cpu.31 missing

On a: CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.70-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended

Re: Ryzen Threadripper 1950X based on head -r340287: sysctl dev.cpu: 0-30 but no 31? (top shows all 0-31 "CPU"s) [subject corrected]

[Fixing dumb, confusing subject typo. No change below.] On 2018-Nov-17, at 12:54, Mark Millard wrote: > For some reason there is no .dev.cpu.31 listed for the 1950X that > I use. This is a native boot, not use under Hyper-V. For > illustration I list: > > # sysctl dev.cpu | grep "desc" >

Ryzen Threadripper 1950X based on head -r340287: sysctl dev.cpu: 0-30 but no 31? (top shows all 31 "CPU"s)

For some reason there is no .dev.cpu.31 listed for the 1950X that I use. This is a native boot, not use under Hyper-V. For illustration I list: # sysctl dev.cpu | grep "desc" dev.cpu.30.%desc: ACPI CPU dev.cpu.29.%desc: ACPI CPU dev.cpu.28.%desc: ACPI CPU dev.cpu.27.%desc: ACPI CPU

Re: svn commit: r335873 - in head: . sys/amd64/amd64 sys/amd64/include sys/conf sys/i386/i386 sys/i386/include sys/sys sys/vm

> Author: mmacy > Date: Mon Jul 2 19:48:38 2018 > New Revision: 335873 > URL: > https://svnweb.freebsd.org/changeset/base/335873 > > > Log: > inline atomics and allow tied modules to inline locks > > - inline atomics in modules on i386 and amd64 (they were always > inline on other

Why https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc builds are failing . . .

/usr/local/bin/x86_64-freebsd-ld: unrecognized option '--no-rosegment' is the message that reports what stops the build. I think this traces back to: /usr/src/share/mk/bsd.sys.mk:LDFLAGS+= ${LDFLAGS.${LINKER_TYPE}} being incorrect for an amd64-gcc / x86_64-freebsd-ld based build. The

Ryzen Threadripper, Hyper-V, and NUMA vs. DIMMs: 3 DIMMs on each side seems to always be in "Local" mode, not "Distributed"

Context: Ryzen Threadripper 1950X under Windows 10 Pro with Hyper-V (used to run FreeBSD). In experimenting with switching a Threadripper 1950X to have ECC RAM I discovered: A) The maximum ECC memory it would put to use was 96 GiBytes (3 DIMMs on each side, a 4th on each side was recognized

"Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected?

For: # uname -apKU FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 1200060 1200060 I get: . . . pci0: at device 7.3 (no driver attached) . . . intsmb0: at device 7.3 on pci0 intsmb0: Could not allocate I/O space device_attach: intsmb0 attach returned 6 on a Ryzen

head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a" would get the "unnecessary swapping" problem in my UFS-only context, -r331499 (non-debug but with symbols), under Hyper-V. This is a Ryzen Threadripper context, but I've no clue if that is important to the problem. This was after