Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)
On 6/8/23 05:48, Warner Losh wrote: On Thu, Jun 8, 2023, 4:35 AM Rebecca Cran wrote: It's ZFS, using the default options when creating it via the FreeBSD installer so I presume TRIM is enabled. Without a reliable way to reproduce the error I'm not sure disabling TRIM will help at the moment. I don't think there's any newer firmware for it. pci gen 4 has a highter error rate so that needs to be managed with retries. There's a whole protocol to do that which linux implements. I suspect the time has come for us to do so too. There's some code floating around I'll have to track down. Thanks. I dropped the configuration down to PCIe gen 3 and the errors have so far gone away. nda0: nvme version 1.3 x8 (max x8) lanes PCIe Gen3 (max Gen4) link nda1: nvme version 1.3 x4 (max x4) lanes PCIe Gen3 (max Gen4) link -- Rebecca Cran
Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)
It's ZFS, using the default options when creating it via the FreeBSD installer so I presume TRIM is enabled. Without a reliable way to reproduce the error I'm not sure disabling TRIM will help at the moment. I don't think there's any newer firmware for it. -- Rebecca Cran On 6/8/23 04:25, Tomek CEDRO wrote: what filesystem? is TRIM enabled on that drive? have you tried disabling trim? i had similar ssd related problem on samsung's ssd long time ago that was related to trim. maybe drive firmware can be updated too? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)
On 6/8/23 00:24, Warner Losh wrote: PCIe 3 or PCIe 4? PCIe 4. nda0 at nvme0 bus 0 scbus0 target 0 lun 1 nda0: nda0: Serial Number S55KNC0TC00168 nda0: nvme version 1.3 x8 (max x8) lanes PCIe Gen4 (max Gen4) link nda0: 6104710MB (12502446768 512 byte sectors) -- Rebecca Cran
Seemingly random nvme (nda) write error on new drive (retries exhausted)
I got a seemingly random nvme data transfer error on my new arm64 Ampere Altra machine, which has a Samsung PM1735 PCIe AIC NVMe drive. Since it's a new drive and smartctl doesn't show any errors I thought it might be worth mentioning here. I'm running 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n263139-baef3a5b585f. dmesg contains: nvme0: WRITE sqid:16 cid:126 nsid:1 lba:2550684560 len:8 nvme0: DATA TRANSFER ERROR (00/04) crd:0 m:0 dnr:0 sqid:16 cid:126 cdw0:0 (nda0:nvme0:0:0:1): WRITE. NCB: opc=1 fuse=0 nsid=1 prp1=0 prp2=0 cdw=98085b90 0 7 0 0 0 (nda0:nvme0:0:0:1): CAM status: CCB request completed with an error (nda0:nvme0:0:0:1): Error 5, Retries exhausted nvmecontrol identify nvme0 shows: Vendor ID: 144d Subsystem Vendor ID: 144d Model Number: SAMSUNG MZPLJ6T4HALA-7 Firmware Version: EPK9CB5Q Recommended Arb Burst: 8 IEEE OUI Identifier: 00 25 38 Multi-Path I/O Capabilities: Multiple controllers, Multiple ports Max Data Transfer Size: 131072 bytes Sanitize Crypto Erase: Supported Sanitize Block Erase: Supported Sanitize Overwrite: Not Supported Sanitize NDI: Not Supported Sanitize NODMMAS: Undefined Controller ID: 0x0041 Version: 1.3.0 -- Rebecca Cran
Re: 20230504 -CURRENT snapshot panics during install at zfs probing
On 5/15/23 07:17, Rebecca Cran wrote: I'll open a bug report so the details don't get lost. I've created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271438 . -- Rebecca Cran
Re: 20230504 -CURRENT snapshot panics during install at zfs probing
On 5/15/23 07:09, José Pérez wrote: I recall exepriencing a similar issue with a SuperMicro server and I think I worked this around by adding hw.mfi.mrsas_enable="1" to /boot/device.hints in order to have FreeBSD booting from the SAS disks. Unfortunately I do not have access to that hardware anymore (it is running AnotherOS and cannot be taken out of production). I still recommend you do open a bug with the details you have so far, having FreeBSD on server with SAS disks is not a sin ;) and software causing memory corruption shall be fixed anyways. Thanks. I wanted to boot FreeBSD from the BOSS-1 drive (NVMe) so I worked around it by disabling the mrsas controller during install then re-enabling it later. I'll open a bug report so the details don't get lost. -- Rebecca Cran
Re: 20230504 -CURRENT snapshot panics during install at zfs probing
I also tried FreeBSD 13.2 and it's unhappy too, and ends up panicing and rebooting when trying to restart the installer after it segfaults. So it's apparently _not_ a new problem. I'm guessing there's something about my disks that's causing memory corruption. The only thing that's changed recently is installing Windows Server 2022 on a different disk. If I disable the mrsas controller, installation proceeds. -- Rebecca Cran On 5/4/23 19:02, Rebecca Cran wrote: I'm seeing a panic during install during the zfs probing on the 14-CURRENT 20230504 amd64 snapshot on a PowerEdge R7525 dual-EPYC system. I haven't submitted a bug report for a while, so let me know what other information is needed. Unfortunately the stack backtrace looks useless: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/kern_clock.c:269 cpuid = 67 time = 1683225642 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe037aa72db0 vpanic() at vpanic+0x152/frame 0xfe037aa72e00 panic() at panic+0x43/frame 0xfe037aa72e60 __mtx_lock_flags() at __mtx_lock_flags+0x13b/frame 0xfe037aa72eb0 deadlkres() at deadlkres+0xef/frame 0xfe037aa72ef0 fork_exit() at fork_exit+0x80/frame 0xfe037aa72f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfe037aa72f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 0 tid 101238 ] Stopped at kdb_enter+0x32: movq $0,0xddd833(%rip) db> Start of dmesg: FreeBSD 14.0-CURRENT #0 main-n262746-4194bbb34c60: Thu May 4 08:05:46 UTC 2023 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git llvmorg-15.0.7-0-g8dfdcc7b7bf6) WARNING: WITNESS option enabled, expect reduced performance. SRAT: Too many memory domains VT(efifb): resolution 1024x768 CPU: AMD EPYC 7713 64-Core Processor (1996.32-MHz K8-class CPU) Origin="AuthenticAMD" Id=0xa00f11 Family=0x19 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7efa320b AMD Features=0x2e500800 AMD Features2=0x75c237ff Structured Extended Features=0x219c97a9 Structured Extended Features2=0x40069c Structured Extended Features3=0x10 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x91bef75f SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 277021196288 (264188 MB) avail memory = 266164191232 (253833 MB) disk info: root@:~ # gpart show => 6 233308149 nvd0 GPT (890G) 6 233308149 - free - (890G) => 6 233308149 diskid/DISK-S61ANA0R100142 GPT (890G) 6 233308149 - free - (890G) => 34 937571901 ada0 GPT (447G) 34 2014 - free - (1.0M) 2048 937568256 1 ms-basic-data (447G) 937570304 1631 - free - (816K) => 34 937571901 diskid/DISK-74ff0e529b990010 GPT (447G) 34 2014 - free - (1.0M) 2048 937568256 1 ms-basic-data (447G) 937570304 1631 - free - (816K) => 34 3125627501 da0 GPT (1.5T) 34 2014 - free - (1.0M) 2048 1048576 1 efi (512M) 1050624 2929686528 2 linux-data (1.4T) 2930737152 62500864 3 linux-swap (30G) 2993238016 132389519 - free - (63G) => 34 3125627501 da1 GPT (1.5T) 34 2014 - free - (1.0M) 2048 32768 1 ms-reserved (16M) 34816 3125592064 2 ms-basic-data (1.5T) 3125626880 655 - free - (328K) => 34 3125627501 diskid/DISK-S61ENE0R302148 GPT (1.5T) 34 2014 - free - (1.0M) 2048 1048576 1 efi (512M) 1050624 2929686528 2 linux-data (1.4T) 2930737152 62500864 3 linux-swap (30G) 2993238016 132389519 - free - (63G) => 34 3125627501 diskid/DISK-202229EBAC90 GPT (1.5T) 34 2014 - free - (1.0M) 2048 32768 1 ms-reserved (16M) 34816 3125592064 2 ms-basic-data (1.5T) 3125626880 655 - free - (328K) => 17 544157 cd0 MBR (1.0G) 17 544157 - free - (1.0G) => 17 544157 iso9660/14_0_CURRENT_AMD64_CD MBR (1.0G) 17 544157 - free - (1.0G)
20230504 -CURRENT snapshot panics during install at zfs probing
I'm seeing a panic during install during the zfs probing on the 14-CURRENT 20230504 amd64 snapshot on a PowerEdge R7525 dual-EPYC system. I haven't submitted a bug report for a while, so let me know what other information is needed. Unfortunately the stack backtrace looks useless: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/kern_clock.c:269 cpuid = 67 time = 1683225642 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe037aa72db0 vpanic() at vpanic+0x152/frame 0xfe037aa72e00 panic() at panic+0x43/frame 0xfe037aa72e60 __mtx_lock_flags() at __mtx_lock_flags+0x13b/frame 0xfe037aa72eb0 deadlkres() at deadlkres+0xef/frame 0xfe037aa72ef0 fork_exit() at fork_exit+0x80/frame 0xfe037aa72f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfe037aa72f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 0 tid 101238 ] Stopped at kdb_enter+0x32: movq $0,0xddd833(%rip) db> Start of dmesg: FreeBSD 14.0-CURRENT #0 main-n262746-4194bbb34c60: Thu May 4 08:05:46 UTC 2023 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git llvmorg-15.0.7-0-g8dfdcc7b7bf6) WARNING: WITNESS option enabled, expect reduced performance. SRAT: Too many memory domains VT(efifb): resolution 1024x768 CPU: AMD EPYC 7713 64-Core Processor (1996.32-MHz K8-class CPU) Origin="AuthenticAMD" Id=0xa00f11 Family=0x19 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7efa320b AMD Features=0x2e500800 AMD Features2=0x75c237ff Structured Extended Features=0x219c97a9 Structured Extended Features2=0x40069c Structured Extended Features3=0x10 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x91bef75f SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 277021196288 (264188 MB) avail memory = 266164191232 (253833 MB) disk info: root@:~ # gpart show => 6 233308149 nvd0 GPT (890G) 6 233308149 - free - (890G) => 6 233308149 diskid/DISK-S61ANA0R100142 GPT (890G) 6 233308149 - free - (890G) => 34 937571901 ada0 GPT (447G) 34 2014 - free - (1.0M) 2048 937568256 1 ms-basic-data (447G) 937570304 1631 - free - (816K) => 34 937571901 diskid/DISK-74ff0e529b990010 GPT (447G) 34 2014 - free - (1.0M) 2048 937568256 1 ms-basic-data (447G) 937570304 1631 - free - (816K) => 34 3125627501 da0 GPT (1.5T) 34 2014 - free - (1.0M) 2048 1048576 1 efi (512M) 1050624 2929686528 2 linux-data (1.4T) 2930737152 62500864 3 linux-swap (30G) 2993238016 132389519 - free - (63G) => 34 3125627501 da1 GPT (1.5T) 34 2014 - free - (1.0M) 2048 32768 1 ms-reserved (16M) 34816 3125592064 2 ms-basic-data (1.5T) 3125626880 655 - free - (328K) => 34 3125627501 diskid/DISK-S61ENE0R302148 GPT (1.5T) 34 2014 - free - (1.0M) 2048 1048576 1 efi (512M) 1050624 2929686528 2 linux-data (1.4T) 2930737152 62500864 3 linux-swap (30G) 2993238016 132389519 - free - (63G) => 34 3125627501 diskid/DISK-202229EBAC90 GPT (1.5T) 34 2014 - free - (1.0M) 2048 32768 1 ms-reserved (16M) 34816 3125592064 2 ms-basic-data (1.5T) 3125626880 655 - free - (328K) => 17 544157 cd0 MBR (1.0G) 17 544157 - free - (1.0G) => 17 544157 iso9660/14_0_CURRENT_AMD64_CD MBR (1.0G) 17 544157 - free - (1.0G) -- Rebecca Cran
Re: zfs: zpool status says I have unactivated features, but upgrade says I don't
On 2/26/2021 4:25 PM, Ryan Moeller wrote: On 2/26/21 5:14 PM, Rebecca Cran wrote: I'm seeing a mismatch on 14-CURRENT between 'zpool status' saying I have features that aren't enabled, and 'zpool upgrade' which says I don't. [bcran@smic ~]$ zpool status pool: spool state: ONLINE status: Some supported and requested features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. scan: scrub repaired 0B in 01:20:51 with 0 errors on Thu Feb 11 16:48:07 2021 config: NAME STATE READ WRITE CKSUM spool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p2 ONLINE 0 0 0 ada1p2 ONLINE 0 0 0 ada2p2 ONLINE 0 0 0 ada3p2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 ada4p2 ONLINE 0 0 0 ada5p2 ONLINE 0 0 0 ada6p2 ONLINE 0 0 0 ada7p2 ONLINE 0 0 0 errors: No known data errors [bcran@smic ~]$ sudo zpool upgrade spool This system supports ZFS pool feature flags. Pool 'spool' already has all supported and requested features enabled. Should be fixed now, see https://reviews.freebsd.org/D28935 Great - thanks! -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
zfs: zpool status says I have unactivated features, but upgrade says I don't
I'm seeing a mismatch on 14-CURRENT between 'zpool status' saying I have features that aren't enabled, and 'zpool upgrade' which says I don't. [bcran@smic ~]$ zpool status pool: spool state: ONLINE status: Some supported and requested features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. scan: scrub repaired 0B in 01:20:51 with 0 errors on Thu Feb 11 16:48:07 2021 config: NAMESTATE READ WRITE CKSUM spool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p2 ONLINE 0 0 0 ada1p2 ONLINE 0 0 0 ada2p2 ONLINE 0 0 0 ada3p2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 ada4p2 ONLINE 0 0 0 ada5p2 ONLINE 0 0 0 ada6p2 ONLINE 0 0 0 ada7p2 ONLINE 0 0 0 errors: No known data errors [bcran@smic ~]$ sudo zpool upgrade spool This system supports ZFS pool feature flags. Pool 'spool' already has all supported and requested features enabled. -- Rebecca Cran ___ 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: any images for freebsd-current?
On 2/6/2021 1:33 PM, Dennis Clarke via freebsd-current wrote: On 2/6/21 2:59 PM, Steve Kargl wrote: Any one aware of where images from freebsd-current? freebsd.org appears to offer no images. try https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ Also .. have you tried RISC-V ?? FreeBSD -CURRENT is 14.0 now. It looks like there aren't any snapshots yet. -- Rebecca Cran ___ 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: Waiting for bufdaemon
On 1/15/21 3:26 AM, Jakob Alvermark wrote: > > When rebooting my thinkpad the 'bufdaemon' times out: > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... > timed out I'm glad other people are seeing this: I was about to report it to the list! I'm running an AMD Threadripper 2990WX. I can trigger it by running a buildworld/buildkernel and then rebooting. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPF on boot with devmatch
On 10/12/20 12:13 PM, Warner Losh wrote: > Xin Li's traceback lead to code I just rewrote in current, while this code > leads to code that's been there for a long time and hasn't been MFC'd. This > suggests that Xin Li's backtrace isn't to be trusted, or there's two issues > at play. Both are plausible. I've fixed a minor signedness bug and a > possible one byte overflow that might have happened in the code I just > rewrote. But I suspect this is due to something else related to how > children are handled after we've raced. Maybe there's something special > about how USB does things, because other buses will create the child early > and the child list is stable. If USB's discovery code is adding something > and is racing with devd's walking of the tree, that might explain it... It > would be nice if there were some way to provoke the race on a system I > could get a core from for deeper analysis I'm seeing this crash on 13-CURRENT main-c255937-g818390ce0ca-dirty when running GENERIC (but not on GENERIC-NODEBUG). I've uploaded the core dump etc. to https://bsdio.com/freebsd/crashes/2021-01-13-devmatch/ . -- Rebecca Cran ___ 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: (244906) installers for FreeBSD fail to boot HP Elitebook 830 G7
On 12/11/2020 8:03 PM, Graham Perrin wrote: On 11/12/2020 18:26, Ludovit Koren wrote: I am trying to install FreeBSD-12.2-RELEASE, FreeBSD-13.0-CURRENT-amd64-20201203-f659bf1d31c The image starts booting and it hangs in: Loading kernel... /boot/kernel/kernel text=0x16bdcc4 data 0x140 data 0x75fe80 Loading configured modules... can't find '/etc/hostid' can't find '/boot/entropy' Start @ 0x80373000 ... EFI framebuffer information: addr, size 0xa000, 0x7e9000 dimensions 1920 x 1080 stride 1920 masks 0x00ff, 0xff00, 0x00ff, 0xff00 Probably <https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077759.html> This crash also happens on VMware Workstation 16 Pro with 13-CURRENT. I'm hoping to find some time to debug it. -- Rebecca Cran ___ 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 shortly after boot when amdgpu.ko is loaded (fpu?)
On 11/27/20 11:10 AM, Konstantin Belousov wrote: And what is the instruction at 0x81002dcf ? I got a much clearer panic by running "sysctl sys" which shows it's more likely a problem for the amdgpu folks and not an underlying FreeBSD problem. #7 0x810295cd in trap (frame=0xfe016e360760) at /usr/src/sys/amd64/amd64/trap.c:398 #8 #9 0x in ?? () #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count () from /boot/modules/amdgpu.ko #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000, arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980, tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184 #13 0x80c0610c in sysctl_root (oidp=, arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980) at /usr/src/sys/kern/kern_sysctl.c:2211 #14 0x80c06783 in userland_sysctl (td=0xfe00f00b6100, name=0xfe016e360a40, namelen=4, old=, oldlenp=, inkernel=, new=0x0, newlen=0, retval=0xfe016e360aa8, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2368 #15 0x80c065cf in sys___sysctl (td=0xfe00f00b6100, uap=0xfe00f00b64e8) at /usr/src/sys/kern/kern_sysctl.c:2241 #16 0x8102a81c in syscallenter (td=0xfe00f00b6100) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #17 amd64_syscall (td=0xfe00f00b6100, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #18 #19 0x0008003819ca in ?? () Backtrace stopped: Cannot access memory at address 0x7fffb618 (kgdb) ___ 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 shortly after boot when amdgpu.ko is loaded (fpu?)
On 11/27/20 4:29 AM, Hans Petter Selasky wrote: Is the problem always triggered by hald? If you disable hald in rc.conf, does the system run for a longer period of time? It turns out that disabling ntpd let the system run for a longer period of time - until I ran "sysctl sys" at which point I got a panic. And this time the panic actually implicates amdgpu.ko, which is an improvement: #9 0x in ?? () #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count () from /boot/modules/amdgpu.ko #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000, arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980, tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184 #13 0x80c0610c in sysctl_root (oidp=, arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980) at /usr/src/sys/kern/kern_sysctl.c:2211 Since it _is_ a problem in amdgpu, I'll stop this thread and re-post on freebsd-x11. -- Rebecca Cran ___ 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 shortly after boot when amdgpu.ko is loaded (fpu?)
I have a Threadripper 2990WX system that I recently installed an AMD Radeon Pro W5700 into. It runs fine unless I load the amdgpu driver, at which point it panics several seconds after boot: I have enough time to login and run a few commands, but even if I just leave it it'll panic. I'm running: FreeBSD photon.int.bluestop.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 6db1a3e8098-c273171(master): Thu Nov 26 01:26:17 MST 2020 bc...@photon.int.bluestop.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 I rebuilt the drm-current-kmod-5.4.62.g20201109_1 port today. The panic is: Fatal trap 9: general protection fault while in kernel mode cpuid = 24; apic id = 18 instruction pointer = 0x20:0x81002dcf stack pointer = 0x0:0xfe016e6ffaa0 frame pointer = 0x0:0xfe016e6ffaa0 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 = 4372 (hald) trap number = 9 panic: general protection fault cpuid = 24 time = 1606450595 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe016e6ff7b0 vpanic() at vpanic+0x181/frame 0xfe016e6ff800 panic() at panic+0x43/frame 0xfe016e6ff860 trap_fatal() at trap_fatal+0x387/frame 0xfe016e6ff8c0 trap() at trap+0x8e/frame 0xfe016e6ff9d0 calltrap() at calltrap+0x8/frame 0xfe016e6ff9d0 --- trap 0x9, rip = 0x81002dcf, rsp = 0xfe016e6ffaa0, rbp = 0xfe016e6ffaa0 --- fpurestore_xrstor3264() at fpurestore_xrstor3264+0x2f/frame 0xfe016e6ffaa0 restore_fpu_curthread() at restore_fpu_curthread+0x85/frame 0xfe016e6ffac0 fpudna() at fpudna+0x3a/frame 0xfe016e6ffae0 trap() at trap+0x246/frame 0xfe016e6ffbf0 calltrap() at calltrap+0x8/frame 0xfe016e6ffbf0 --- trap 0x16, rip = 0x80067137f, rsp = 0x7fffd8b0, rbp = 0x7fffd8f0 --- Uptime: 1m4s Dumping 4193 out of 130894 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% I've uploaded details (core.txt, dmesg.txt etc.) to https://bsdio.com/freebsd/crashes/2020-11-26-amdgpu/ and the vmcore file is available on request. -- Rebecca Cran ___ 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: Deprecating ftpd in the FreeBSD base system?
On 9/17/20 8:04 AM, Cy Schubert wrote: We should also deprecate the FTP client. I've been advocating removing FTP (and HTTP) from libfetch as well. People should be using HTTPS only. (libfetch could support a plugin that might be supplied by a port should someone be inclined to write one.) As an aside, are there any plans to remove the word "ftp" from the FreeBSD download sites. e.g. https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.1/ ? -- Rebecca Cran ___ 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
On 6/22/2020 6:18 PM, Warner Losh wrote: On Mon, Jun 22, 2020 at 6:18 PM Rebecca Cran <mailto:rebe...@bsdio.com>> wrote: On 6/22/2020 10:12 AM, Warner Losh wrote: > I believe so. However, I've not dived deeply enough into this problem to > understand if it is a bug in our code or theirs.freebsd.org <http://theirs.freebsd.org>" As I've said before, at least under bhyve it's a bug in the UEFI firmware that we currently use. Is that fixed in the -devel version? I think I missed you saying this in the past... No, but I hope to update that port in the next week or so to include the fix. -- Rebecca Cran ___ 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
On 6/22/2020 10:12 AM, Warner Losh wrote: I believe so. However, I've not dived deeply enough into this problem to understand if it is a bug in our code or theirs.freebsd.org" As I've said before, at least under bhyve it's a bug in the UEFI firmware that we currently use. -- Rebecca Cran ___ 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
On 6/21/20 12:37 AM, Olivier Cochard-Labbé wrote: 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. The problem on FreeBSD CURRENT at least is caused by the bhyve UEFI firmware that's running: I've committed a fix upstream to fix it (https://github.com/tianocore/edk2/commit/f159102a130fac9b416418eb9b6fa35b63426ca5), but still need to get CSM support working again before we can switch everyone over from the UDK2014.SP1 build to the newer code. -- Rebecca Cran ___ 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: CTF: UEFI HTTP boot support
On 6/17/20 2:11 PM, Rodney W. Grimes wrote: Does freeBSD have any way to access these "Virtual Disk" or Virtual CD images once we leave the world of the loader? I believe we do not, as these are BIOS/UEFI devices that require calls into the UEFI code, which, IIRC is gone once we exit the loader and start the kernel proper, or shortly there after. As far as I know these devices well not be found by the FreeBSD cam layer ATA or AHCI drivers as they do not present an actual PCI device to find. I just tried it on my Supermicro server and you're right, it doesn't show up under FreeBSD. I'm not sure if there's a way to access them via UEFI Runtime Services or if it's designed purely as a boot-time thing. -- Rebecca Cran ___ 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: CTF: UEFI HTTP boot support
> On Jun 17, 2020, at 12:12 PM, Warner Losh wrote: > > I missed the start of this thread, so maybe I'm missing a key detail. > However, I thought UEFI didn't have a RAM-disk, per se, but that we could > load memory areas and pass that into the kernel using freebsd-only methods. > But UEFI is a bit weird, so maybe it will generate a virtual cdrom... See https://uefi.org/sites/default/files/resources/FINAL%20Pres4%20UEFI%20HTTP%20Boot.pdf “ RAM Disk Standard • UEFI 2.5 defined RAM Disk device path nodes - Standard access to a RAM Disk in UEFI - Supports Virtual Disk and Virtual CD (ISO image) in persistent or volatile memory” — Rebecca Cran ___ 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: CTF: UEFI HTTP boot support
> On Jun 17, 2020, at 11:40 AM, Rodney W. Grimes > wrote: > > Does FreeBSD kernel have a driver that can talk to the UEFI ramdisk? I’m fairly sure UEFI generates it as a standard CD drive. — Rebecca Cran ___ 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: CTF: UEFI HTTP boot support
On 6/16/20 5:17 AM, Miguel C wrote: I've been trying out FreeBSD with raspberry Pi4 (4GB) and wanted to see what the state of HTTP BOOT is in FreeBSD, so I bumped into this! I'm curious if it should be possible to point to a img/iso directly (I tried to use the img.xz unpacked it and make it available on a local web server and that didn't seem to work for me) but maybe thats cause those images miss something, so arm64 aside does that work for amd64? I.E. using the bootonly.iso? Unfortunately HTTP boot only works as far as the kernel: UEFI fetches loader.efi, the loader fetches and runs the kernel over HTTP -- and then you need to use NFS to mount the filesystem (or have a local root filesystem). UEFI also has RamDisk support, but I don't think that's for remote ISO/disk files, just local files. -- Rebecca Cran ___ 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: When will the FreeBSD (u)EFI work?
> On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn wrote: > > The problem then is that we have treated loader as a > continuously-updatable part of the OS, like the kernel, and the update > system and development process assumes they get updated in sync. But at the moment how often do users mount the ESP and update loader.efi on it? So it seems it rarely _needs_ to be updated at the moment. — Rebecca Cran ___ 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: When will the FreeBSD (u)EFI work?
On 3/29/20 8:09 PM, Kyle Evans wrote: I'd be in favor of installing to \EFI\BOOT\... as well if and only if the file doesn't already exist, assuming we can figure out how to make it not a maintenance nightmare -- which I suspect would just mean that we have some tool that users use to update the ESP rather than instructing them to examine/replace files manually. Or if, as you say, we can determine that it's _our_ bootx64.efi! That's pretty simple, since we have strings such as "FreeBSD/amd64 EFI loader, Revision 1.1" in the binary. We'll also want to embed a better version string to determine that it's our bootx64.efi _and_ for a version of FreeBSD that we're wanting to update. -- Rebecca Cran ___ 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: When will the FreeBSD (u)EFI work?
On 3/29/20 6:11 AM, Tomoaki AOKI wrote: 3. based solution looks good to me. IMHO, assuming /efi/bootx[64|32].efi is boot1.efi or loader.efi or EFI environment pointing to either one is properly used, That's another thing: we should be installing loader.efi as \efi\boot\bootx64.efi (as well as \boot\freebsd\loader.efi) since it's entirely possible to lose the Boot Manager entry and end up with an unbootable system as a result. Unfortunately people have had bad experiences with other operating systems overwriting bootx64.efi and don't believe we should do that. Perhaps I just need to come up with a proof of concept or demo to show that it is possible without breaking other OSes. -- Rebecca Cran ___ 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: mouse is broken
On 3/9/2020 7:38 PM, AN wrote: Thank you for the reply. I enabled moused in rc.conf. However mouse is still broken. I see the following: service moused restart moused not running? (check /var/run/moused.pid). Starting default mousedmoused: unable to open /dev/psm0: No such file or directory. You most likely have a USB mouse, while the default is (still! why?) for a PS/2 style mouse. So you probably need to set moused_port="/dev/ums0" in /etc/rc.conf . -- Rebecca Cran ___ 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: mouse is broken
On 3/9/2020 7:12 PM, AN wrote: After an update today to world, kernel, and ports my mouse no longer works. Mouse works on console. I use startx, mouse seems to break after startx is issued. Is any one else seeing anything similar? Any help is appreciated, thanks in advance. I saw something similar recently, but when using "moused_nondefault_enable="NO"" in /etc/rc.conf to disable moused. With moused disabled, Xorg would log something like "System mouse disabled" in /var/log/Xorg.0.log, and the mouse didn't work. But when I enabled moused, Xorg found and used it. -- Rebecca Cran ___ 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
On 2019-09-18 16:29, Yuri Pankov wrote: > Yes, exactly, sorry for not mentioning it. > > ESXi version: 6.7.0 > ESXi build number: 13006603 Sorry, I've realized it's _not_ crashing when we call ExitBootServices after all: it's just that we can't call printf after that point. I've found it gets to the point of executing the kernel and then crashes. I've had it booting a couple of times by setting console=comconsole, but I'm not sure if that's relevant. -- Rebecca Cran ___ 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
On 2019-09-18 18:36, Rebecca Cran wrote: > > So far, it looks to be a problem with the GetMemoryMap/ExitBootServices > loop in bi_load_efi_data. So, it's crashing when we call BS->ExitBootServices. Of course, the problem isn't really _in_ that code (it hasn't changed since March), but that's just where it ends up crashing. I'll look through the rest of the loader and see if I can spot any problems. -- Rebecca Cran ___ 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
On 2019-09-18 16:29, Yuri Pankov wrote: > > Yes, exactly, sorry for not mentioning it. > > ESXi version: 6.7.0 > ESXi build number: 13006603 Thanks. I've been able to replicate the problem, and am currently debugging it. So far, it looks to be a problem with the GetMemoryMap/ExitBootServices loop in bi_load_efi_data. -- Rebecca Cran ___ 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
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? -- Rebecca Cran ___ 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: Building world with gcc9 not working
On 2019-09-09 23:08, Warner Losh wrote: > >> Aspirationally, yes. I did a successful CROSS_TOOLCHAIN=amd64-gcc >> buildworld earlier this week. (It doesn't play well with binary pkg's >> built with Clang, so I ended up replacing it with a Clang-built world >> instead, but it compiled.) >> >> Unfortunately, amd64-xtoolchain-gcc is stuck on GCC 6.4.0, while >> you're running the much more recent GCC9. I think GCC6.4.0 is more or >> less expected to build world today, but I don't think many people are >> building with GCC9. I would love for amd64-xtoolchain to move to a >> newer version, but I don't know what is blocking that — it seems like >> it should be straightforward. >> > I did a gcc8 build about a year or so ago, though I had to turn off Werror > to complete the build... Thanks. I kept running into build errors with gcc 8 and 9 (even with WERROR= in src.conf), but building with gcc 6 from the amd64-gcc port worked. -- Rebecca Cran ___ 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"
Building world with gcc9 not working
Is building world with gcc still supported? I'm getting an error running the following: make XCC=/usr/local/bin/gcc9 XCXX=/usr/local/bin/g++9 buildworld /usr/local/bin/gcc9 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DNO__SCCSID -DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 -I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd -I/usr/src/contrib/jemalloc/include -DMALLOC_PRODUCTION -I/usr/src/contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -g -MD -MF.depend.jemalloc_malloc_io.o -MTjemalloc_malloc_io.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c jemalloc_malloc_io.c -o jemalloc_malloc_io.o jemalloc_malloc_io.c: In function '__je_malloc_vsnprintf': jemalloc_malloc_io.c:383:2: error: case label value exceeds maximum value for type [-Werror] 383 | case '?' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:401:2: error: case label value exceeds maximum value for type [-Werror] 401 | case 'j' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:389:2: error: case label value exceeds maximum value for type [-Werror] 389 | case 'l' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:395:2: error: case label value exceeds maximum value for type [-Werror] 395 | case 'q' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ jemalloc_malloc_io.c:410:2: error: case label value exceeds maximum value for type [-Werror] 410 | case 'z' | 0x80: \ | ^~~~ jemalloc_malloc_io.c:595:5: note: in expansion of macro 'GET_ARG_NUMERIC' 595 | GET_ARG_NUMERIC(val, 'p'); | ^~~ cc1: all warnings being treated as errors *** Error code 1 -- Rebecca Cran ___ 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: Host machines reboots when running bhyve VM
On 2019-08-28 13:50, Konstantin Belousov wrote: > > Try https://reviews.freebsd.org/D21418 Thanks! That fixed it. -- Rebecca Cran ___ 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"
Host machines reboots when running bhyve VM
I recently upgraded to r351575 and now when I run a Bhyve VM, the host machine instantly reboots. The command-line I'm running is: bhyve -c 2 -m 8G -w -H -s 0,hostbridge -s 4,virtio-blk,/home/bcran/cube/opensuse-jenkins-node.img -s 15,virtio-net,tap0 -s 28,virtio-rnd -s 29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768 -s 31,lpc -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd vm0 And the system (I've tried both GENERIC-NODEBUG and GENERIC) is: FreeBSD 13.0-CURRENT r351575 GENERIC-NODEBUG amd64 FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1) VT(efifb): resolution 1024x768 CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.44-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f82 Family=0x17 Model=0x8 Stepping=2 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 137438953472 (131072 MB) avail memory = 133601013760 (127411 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs FreeBSD/SMP: 1 package(s) x 4 groups x 2 cache groups x 4 core(s) x 2 hardware threads -- Rebecca Cran ___ 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found
> On Aug 26, 2019, at 11:43 PM, Toomas Soome wrote: > > For me it is still confusing if this is path versus upper-lower capital > chars. > > If that vendor is using suggestion from UEFI Spec 2.7A section 3.5.1.1 (page > 91), then the file name should also end with .EFI. (and yes, I know, that > section is talking about removable media). > > Therefore the question is, does lenovo accept name like > EFI/FREEBSD/LOADER.EFI? Or what form is used there for windows paths? > > If we should or should not use EFI/BOOT path - perhaps the installer should > prefer vendor path by default. But till there is confusion, there should be > some notes in some documentation... Being a FAT filesystem I don’t think upper/lower case matters. Personally I think we should always install to the vendor path, and also install to EFI/BOOT if somebody else hasn’t already got files there. — Rebecca ___ 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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found
On 2019-08-26 23:08, Warner Losh wrote:
>
> That's the first machine I've seen where you have to set the name like
> that... there is a larger story here and we are getting incomplete reports
> because it doesn't quite make sense yet...
>
> But there are enough reasons not to do that by default. For one thing, it
> messes up rEFInd, or can. Windows doesn't install there. At most we should
> prompt for older machines. We shouldn't mortgage our future to cope with a
> legacy we know will sunset soon...
Both Windows and Linux install \EFI\BOOT\BOOTx64.efi because that's the
default that gets run if there aren't any Boot variables.
And yes, Windows 10 does install there. On my system I have
/EFI/Boot/bootx64.efi and \EFI\Microsoft\{Boot,Recovery}, where
/EFI/Boot/bootx64.efi is the same binary as bootmgfw.efi.
I'm not convinced this is something that's about older systems, and that
will go away.
--
Rebecca Cran
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found
On 8/26/19 5:22 AM, O. Hartmann wrote: the other thing is the weird Lenovo handling of the UEFI vars. The only way to boot the E540 (after(!) disabling _BEARSSL in src.conf and rebuilding everything) was to set the loader's name to EFI/BOOT/BOOTx64.efi. Setting the variable to contain EFI/BOOT/loader.efi failed as well as setting EFI/FreeBSD/loader.efi. I've been suggesting FreeBSD should install the loader as \EFI\BOOT\BOOTx64.efi for a while (as long as there's not already a different vendor's loader there), without much success. Hopefully this finding can cause us to reconsider. -- Rebecca Cran ___ 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 on boot with r351461 (AMD ThreadRipper 2990WX)
On 2019-08-25 10:55, Mark Johnston wrote: > > Can you please try applying this patch as well? Thanks, that fixed the panic and allows the system to fully boot again. -- Rebecca Cran ___ 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 on boot with r351461 (AMD ThreadRipper 2990WX)
On 2019-08-25 08:30, Konstantin Belousov wrote: > > So what happens, IMO, is that for memory-less domains ds_cnt is zero > because ds_mask is zero, which causes the exception on divide. You > can try the following combined patch, but I really dislike the fact > that I cannot safely use DOMAINSET_FIXED (if my diagnosis is correct). With that patch applied, boot gets a lot further but eventually panics after probing pcm devices: panic: vm_domainset_iter_first: Unknown policy 0 cpuid = 49 time = 1 KDB: stack backtrace: ... vm_domainset_iter_first() vm_domainset_iter_page_init() vm_page_grab_pages() vm_thread_stack_create() kstack_import() uma_zalloc_arg() vm_thread_new() thread_alloc() kthread_add() vm_pageout() fork_exit() fork_trampoline() -- Rebecca Cran ___ 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 on boot with r351461 (AMD ThreadRipper 2990WX)
On 2019-08-25 00:24, Konstantin Belousov wrote: > What are the panic messages ? Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0x80f1027c stack pointer = 0x28:0x845809f0 frame pointer = 0x28:0x84580a00 code segment = base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () trap number = 18 panic: integer divide fault cpuid = 0 time = 1 > What is the source line ? (gdb) info line *0x80f1027c Line 102 of "/usr/src/sys/vm/vm_domainset.c" starts at address 0x80f10267 and ends at 0x80f1027f . -- Rebecca Cran ___ 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 on boot with r351461 (AMD ThreadRipper 2990WX)
On 2019-08-24 17:08, Konstantin Belousov wrote: > > Do you happen to have NUMA node without any local memory ? (Look at the > SRAT table). If yes, try this patch. I've just remembered, that's one of the big differences between ThreadRipper and EPYC: the EPYC has memory links on all four dies, while the ThreadRipper 2990WX only has links on half. From https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/15 "With the new processors, we have the situation on the right, where only some cores are directly attached to memory, and others are not. In order to go from one of these cores to main memory, it requires an extra hop, which adds latency. When all the cores are requesting access, this causes congestion." -- Rebecca Cran ___ 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 on boot with r351461 (AMD ThreadRipper 2990WX)
On 2019-08-24 17:08, Konstantin Belousov wrote:
>
> Use gdb instead.
Ah, thanks.
(gdb) info line *0x8117f67c
Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts at address
0x8117f674 and ends at
0x8117f69a
> What was the previous bootable version of the kernel ?
I attempted to upgrade from r350575.
> Do you happen to have NUMA node without any local memory ? (Look at the
> SRAT table). If yes, try this patch.
After applying the patch, I get a crash with the following backtrace:
vm_domainset_iter_first()
vm_domainset_iter_policy_init()
kmem_malloc_domainset()
native_start_all_aps()
cpu_mp_start()
mp_start()
mi_startup()
(gdb) info line *0x80f1027c
Line 102 of "/usr/src/sys/vm/vm_domainset.c" starts at address
0x80f10267
and ends at 0x80f1027f .
The SRAT contains:
Type=Memory
Flags={ENABLED}
Base Address=0x
Length=0x000a
Proximity Domain=0
Type=Memory
Flags={ENABLED}
Base Address=0x0010
Length=0x7ff0
Proximity Domain=0
Type=Memory
Flags={ENABLED}
Base Address=0x0001
Length=0x000f8000
Proximity Domain=0
Type=Memory
Flags={ENABLED}
Base Address=0x00108000
Length=0x0010
Proximity Domain=2
--
Rebecca Cran
___
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 on boot with r351461 (AMD ThreadRipper 2990WX)
On 2019-08-24 14:33, Konstantin Belousov wrote: > On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote: >> instruction pointer = 0x20: 0x811bc664 > So what is the source line for this address ? I built a new kernel and got a new panic instruction pointer address of 0x8117f67c, but running it through addr2line only gave a function name, not a line number: addr2line -af -e /usr/lib/debug/boot/kernel/kernel.debug 0x8117f67c mp_realloc_pcpu /usr/src/sys/amd64/amd64/mp_machdep.c:0 -- Rebecca Cran ___ 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 on boot with r351461 (AMD ThreadRipper 2990WX)
I updated my kernel to r351461 today and now get a panic on boot. CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f82 Family=0x17 Model=0x8 Stepping=2 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 137438953472 (131072 MB) avail memory = 133711564800 (127517 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20: 0x811bc664 stack pointer = 0x28:0x8441faa0 frame pointer = 0x28:0x8441fae0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () tral number = 12 panic: page fault cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() ... --- trap 0xc, rip = 0x811bc664, rsp = 0x8441faa0, rbp = 0x8441fae0 --- native_start_all_aps() cpu_mp_start() mp_start() mi_startup() -- Rebecca Cran ___ 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 loader hangs after update to r349350
On 2019-06-25 13:57, Guido Falsi wrote: > > I'm having thee same issue. UEFI system, ZFS on root, two mirrored disks. > > Reverting 349349 fixes it. Sorry, that was my commit. I'm debugging it now. -- Rebecca Cran ___ 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: UEFI firmware and getting FreeBSD recognized by default: who to talk to?
On 2019-06-22 13:34, Karl Denninger wrote: > > All I had to do was put the EFI loader in a directory under the UEFI > partition and Refind found it. I didn't have to specifically tell it > that it was there. Sorry, I'm not talking about rEFInd. I know how great it is. I'm talking about systems without rEFInd, using only the default OEM supplied system firmware, since we can't rely on everyone having rEFInd installed. -- Rebecca Cran ___ 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: UEFI firmware and getting FreeBSD recognized by default: who to talk to?
On 2019-06-22 12:59, Karl Denninger wrote: > > I use Refind for this sort of thing and it has (thus far!) survived > upgrades. The only "gotcha" is that I had a Windows 10 "Feature" > upgrade that reset the default boot in the firmware to Windows; it > didn't damage anything but did require that I go reset the UEFI default > to boot the Refind EFI loader instead of the Windows one. I do like that rEFInd knows about FreeBSD, and it's one of the "UEFI OS" entries that remains. But I'd prefer it if a "FreeBSD" entry was automatically created! -- Rebecca Cran ___ 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"
UEFI firmware and getting FreeBSD recognized by default: who to talk to?
I just upgraded my UEFI system firmware, and not unexpectedly lost the "FreeBSD" boot manager entry after the settings got reset to default. I was left with "Windows", "opensuse" and two "UEFI OS" entries. The "opensuse-secureboot" entry wasn't automatically recreated, but since the "opensuse" entry uses the shim (https://github.com/rhboot/shim) it will be created when I boot "opensuse". I'm wondering if anyone knows who we should talk to in order to get \EFI\FreeBSD\loader.efi recognized by firmware as something to be added as a boot option by default? I plan to import the shim into the tree sometime so that we too can automatically recreate boot manager entries if they're deleted. -- Rebecca Cran ___ 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"
CTF: UEFI HTTP boot support
I've been working with D Scott Phillips to test the UEFI HTTP loader code he's written, and we're now ready for wider testing. In the testing I've done I've discovered a couple of bugs in the TianoCore EDK2 firmware, so I'd appreciate any testing people can do on various different systems to check how well they work. In theory HTTPS is also supported, but at least on TianoCore firmware it looks like TLS has a bug which means the second connection causes the system to crash. Also, this current work is IPv4 only: I hope to add IPv6 in the near future. The patches can be found at: https://reviews.freebsd.org/D20642 https://reviews.freebsd.org/D20643 There's a good guide to setting up the DHCP and HTTP servers at https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup . -- Rebecca Cran signature.asc Description: OpenPGP digital signature
Re: panic booting with if_tap_load="YES" in loader.conf
On 2019-05-18 02:55, Konstantin Belousov wrote: > Try this instead. I will revert r347931 after this landed, or could keep > it alone. That works - thanks! -- Rebecca Cran ___ 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 booting with if_tap_load="YES" in loader.conf
I just updated from r346856 to r347950 and ran into a new panic, caused by having if_tap_load="YES" in /boot/loader.conf - because it's already built-in to the kernel: module if_tuntap already present! kernel trap 12 with interrupts disabled The backtrace is: vpanic() panic() trap_fatal() trap_pfault() trap() calltrap() --- trap 0xc _thread_lock() pmap_delayed_invl_start_u() pmap_remove() kmem_bootstrap_free() preload_delete_name() linker_file_unload() linker_preload() mi_startup() btext() Uptime: 1s -- Rebecca Cran ___ 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 booting with if_tap_load="YES" in loader.conf
I just updated from r346856 to r347950 and ran into a new panic, caused by having if_tap_load="YES" in /boot/loader.conf - because it's already built-in to the kernel: module if_tuntap already present! kernel trap 12 with interrupts disabled The backtrace is: vpanic() panic() trap_fatal() trap_pfault() trap() calltrap() --- trap 0xc _thread_lock() pmap_delayed_invl_start_u() pmap_remove() kmem_bootstrap_free() preload_delete_name() linker_file_unload() linker_preload() mi_startup() btext() Uptime: 1s -- Rebecca Cran ___ 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"
i386 EFI booting is broken (ExitBootServices called in two places)
I've been working on some EFI changes, and in the process found that i386 booting is broken. On real hardware - my MinnowBoard Turbot - the loader hangs when calling ExitBootServices, while in a VM I get a panic saying "exec returned". The problem appears to be that ExitBootServices is called twice: elf32_exec in arch/i386/efimd.c calls bi_load which calls bi_load_efi_data in bootinfo.c - which calls ExitBootServices the first time. Then elf32_exec keeps going, and after printing "Start @ 0x." calls ldr_enter which tries to call ExitBootServices again - this time with a mapkey whose value is zero since it never attempts to fetch the memory map. I'm guessing that subsequently causes the exec to fail. -- Rebecca Cran ___ 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 images install broken bootx64.efi
On 2/11/19 12:18 PM, Rebecca Cran wrote: I’ll take a look later today, since it’s likely related to my changes. On January 26, 2019 at 6:43:49 PM, Yuri Pankov (yur...@yuripv.net(mailto:yur...@yuripv.net)) wrote: 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)? Sorry for the delay. I just tried booting the FreeBSD-13.0-CURRENT-amd64-20190123-r343372-memstick.img on my MinnowBoard Turbot and it worked. Could your download have been corrupted? -- Rebecca Cran ___ 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: USB problems on -CURRENT (controller keeps getting reset)
That works, thanks. Rebecca On February 12, 2019 at 1:24:15 AM, Hans Petter Selasky (h...@selasky.org(mailto:h...@selasky.org)) wrote: > The USB timeout error might indicate an IRQ issue. > > Can you try setting: > > hw.usb.xhci.use_polling=1 > > In /boot/loader.conf and reboot. > > --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
USB problems on -CURRENT (controller keeps getting reset)
I’m having problems with USB devices on -CURRENT on my ThreadRipper system. The controller keeps on getting reset. I thought it might be related to my iogear KVM, but disconnecting it doesn’t help. Feb 12 00:59:47 photon kernel: xhci0: Resetting controller Feb 12 00:59:47 photon kernel: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Feb 12 00:59:49 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 00:59:51 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 00:59:52 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 00:59:54 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 00:59:56 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 00:59:57 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 00:59:59 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:01 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:02 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:02 photon kernel: ugen0.2: at usbus0 (disconnected) Feb 12 01:00:03 photon kernel: uhub_reattach_port: could not allocate new device Feb 12 01:00:04 photon kernel: usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:04 photon kernel: ugen0.2: at usbus0 (disconnected) Feb 12 01:00:04 photon kernel: uhub_reattach_port: could not allocate new device Feb 12 01:00:05 photon kernel: usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:05 photon kernel: ugen0.2: at usbus0 (disconnected) Feb 12 01:00:05 photon kernel: uhub_reattach_port: could not allocate new device Feb 12 01:00:05 photon kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Feb 12 01:00:05 photon kernel: uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Feb 12 01:00:06 photon kernel: uhub0: 22 ports with 22 removable, self powered Feb 12 01:00:08 photon kernel: xhci0: Resetting controller Feb 12 01:00:08 photon kernel: usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:09 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:11 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:13 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:15 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:16 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:18 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:19 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:21 photon kernel: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:23 photon kernel: usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Feb 12 01:00:23 photon kernel: ugen0.2: at usbus0 (disconnected) Feb 12 01:00:23 photon kernel: uhub_reattach_port: could not allocate new device Feb 12 01:00:24 photon kernel: usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:24 photon kernel: ugen0.2: at usbus0 (disconnected) Feb 12 01:00:24 photon kernel: uhub_reattach_port: could not allocate new device Feb 12 01:00:25 photon kernel: usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) Feb 12 01:00:25 photon kernel: ugen0.2: at usbus0 (disconnected) Feb 12 01:00:25 photon kernel: uhub_reattach_port: could not allocate new device Feb 12 01:00:25 photon kernel: uhub0: at usbus0, port 1, addr 1 (disconnected) Feb 12 01:00:25 photon kernel: uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Feb 12 01:00:26 photon kernel: uhub0: 22 ports with 22 removable, self powered Feb 12 01:00:28 photon kernel: xhci0: Resetting controller — Rebecca Cran ___ 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 images install broken bootx64.efi
I’ll take a look later today, since it’s likely related to my changes. — Rebecca On January 26, 2019 at 6:43:49 PM, Yuri Pankov (yur...@yuripv.net(mailto:yur...@yuripv.net)) wrote: > 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" ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Saturday, 19 January 2019 13:54:25 MST Lev Serebryakov wrote:
> Yes, I know. But what should I do next? There is no "Set UEFI Boot Var"
> item in it. You could select different physical drives (but not partitions
> of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI
> Shell" which is not documented anywhere, and it doesn't work always.
>
> When I google "ASUS EFI Shell", for example, all results says about
> preparing USB stick with EFI shell and such, not about commands and
> variables of EFI shell.
>
> I don't say, that it is impossible, I only could not find good (or any)
> documentation.
Yeah, the documentation is definitely lacking.
If you want to specifically run the EFI Shell, then you'll need to either
install Shell_Full.efi from https://github.com/tianocore/edk2/tree/UDK2014.SP1/
EdkShellBinPkg/FullShell/X64 as Shellx64.efi on a USB stick formatted as FAT16
or FAT32 - or, install the shell as EFI/BOOT/BOOTx64.efi on an ESP.
For booting FreeBSD, you might want to consider installing rEFInd (http://
www.rodsbooks.com/refind/), since it can find the loader in EFI/freebsd/
loader.efi and displays the FreeBSD logo - see https://bluestop.org/files/
rEFInd_FreeBSD.jpeg . For comparison, my ASUS UEFI firmware doesn't find
FreeBSD
at all in /EFI/freebsd, and when installed as /EFI/boot/BOOTx64.efi just
displays a "UEFI OS" entry.
Ultimately, UEFI doesn't care about disks and partitions: it only really knows
about ESPs -- FAT12/16/32 formatted partitions that contain the EFI directory
structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi, the
Microsoft boot loader in /EFI/Microsoft and GRUB/shim in /EFI/fedora, /EFI/
opensuse etc.
--
Rebecca Cran
signature.asc
Description: This is a digitally signed message part.
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org(mailto:l...@freebsd.org)) wrote: > I have never seen such item in BIOS Setup. I've checked two MoBos now (one is > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > like Intel NUK): both have one knob in setup about boot type > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > one) could be booted to "UEFI Console" which is not documented anywhere. > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > On ASUS systems you normally press F8 during POST to bring up the boot menu, and F11 on Supermicro systems. — Rebecca ___ 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: UEFI, loader.efi and /boot.config
On Thursday, 17 January 2019 20:02:46 MST David Wolfskill wrote: > Does the above only apply to UEFI booting, or also to booting from > BIOS/MBR? It's only for UEFI booting. -- Rebecca Cran signature.asc Description: This is a digitally signed message part.
Re: UEFI, loader.efi and /boot.config
On Friday, 18 January 2019 00:48:02 MST Kurt Jaeger wrote: > > With a recent change I made for UEFI, we now install loader.efi onto the > > ESP and don???t run boot1. That means that /boot.config is no longer > > read, and so console settings need to be put in /boot/loader.conf > Which change is that ? The change is https://svnweb.freebsd.org/base?view=revision&revision=342283 . -- Rebecca Cran signature.asc Description: This is a digitally signed message part.
UEFI, loader.efi and /boot.config
With a recent change I made for UEFI, we now install loader.efi onto the ESP and don’t run boot1. That means that /boot.config is no longer read, and so console settings need to be put in /boot/loader.conf. I was wondering if people will expect /boot.config to still be read and so code should be added to loader to continue to parse it, or if loader.conf can be considered the correct place and boot.config forgotten about? — Rebecca Cran ___ 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 getblkx() booting from disc1.iso in Qemu VM
On Thursday, 20 December 2018 18:28:45 MST Kirk McKusick wrote: > Thanks Rebecca for the report and Mark for the analysis of the problem. > This should be fixed in -r342290. Thanks! That did fix it. -- Rebecca ___ 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 getblkx() booting from disc1.iso in Qemu VM
I know booting from the cd/dvd iso worked fairly recently, but today booting a new build of -CURRENT in a Qemu VM resulted in a panic: FreeBSD 13.0-CURRENT 19a6ceb89db(HEAD) GENERIC amd64 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 800x600 CPU: QEMU Virtual CPU version 2.5+ (2994.86-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x663 Family=0x6 Model=0x6 Stepping=3 Features=0x783fbfd Features2=0x80002001 AMD Features=0x20100800 AMD Features2=0x5 SVM: NAsids=16 Hypervisor: Origin = "TCGTCGTCGTCG" real memory = 8589934592 (8192 MB) avail memory = 8227643392 (7846 MB) ... WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from cd9660:/dev/iso9660/13_0_CURRENT_AMD64_DVD [ro]... panic: bsize == 0, check bo->bo_bsize cpuid = 0 time = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0041189270 vpanic() at vpanic+0x1b4/frame 0xfe00411892d0 panic() at panic+0x43/frame 0xfe0041189330 getblkx() at getblkx+0x807/frame 0xfe00411893f0 breadn_flags() at breadn_flags+0x3d/frame 0xfe0041189460 cd9660_blkatoff() at cd9660_blkatoff+0x53/frame 0xfe00411894d0 cd9660_vget_internal() at cd9660_vget_internal+0x26b/frame 0xfe0041189550 vfs_domount() at vfs_domount+0x7d3/frame 0xfe0041189770 vfs_donmount() at vfs_donmount+0x7b9/frame 0xfe0041189810 kernel_mount() at kernel_mount+0x58/frame 0xfe0041189860 parse_mount() at parse_mount+0x469/frame 0xfe00411899a0 vfs_mountroot() at vfs_mountroot+0x67f/frame 0xfe0041189b10 start_init() at start_init+0x28/frame 0xfe0041189bb0 fork_exit() at fork_exit+0x84/frame 0xfe0041189bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0041189bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 1 tid 12 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why db> -- Rebecca ___ 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: UEFI GOP: screen goes blank during boot after loader is finished
On Saturday, 17 November 2018 09:29:34 MST Subbsd wrote: > Thus, perhaps the root of this problem should be sought in > uefi-edk2-bhyve the package. Latest CBSD release (12.0.1) fixed this > problem by disabling serial console. However, CBSD uses an alternative > boot method for bhyve ( uefi-edk2-bhyve + reFIND ) Another data point is that OVMF (UEFI version 2.70) running under Qemu the problem doesn't occur. -- Rebecca ___ 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 amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Wednesday, 14 November 2018 12:41:53 MST Stefan Ehmann wrote: > On 11/14/18 5:41 AM, Conrad Meyer wrote: > > Ok I'll go ahead and commit that too. > > Applied to 12.0-BETA, Ryzen 7 2700 values are now in the 30-55C range. > Looks reasonable. Much better here, too: dev.amdtemp.3.core0.sensor0: 38.1C dev.amdtemp.3.sensor_offset: -27 dev.amdtemp.2.core0.sensor0: 39.0C dev.amdtemp.2.sensor_offset: -27 dev.amdtemp.1.core0.sensor0: 37.5C dev.amdtemp.1.sensor_offset: -27 dev.amdtemp.0.core0.sensor0: 40.1C dev.amdtemp.0.sensor_offset: -27 Thanks! Rebecca ___ 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: UEFI GOP: screen goes blank during boot after loader is finished
On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote: > What is the ConOut evifar look like? We set serial when the UEFI env says > to do so. Booting with: sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci- cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l bootrom,/usr/local/share/uefi- firmware/BHYVE_UEFI.fd -u vm5 dh in the shell shows: 7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput) PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0)) 84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn DevicePath(t(115200,8,N,1)/VenVt100Plus()) 89: SimpleTextOut SimpleTextInEx SimpleTextIn DevicePath(Uart(115200,8,N,1)/ VenPcAnsi()) -- Rebecca ___ 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: UEFI GOP: screen goes blank during boot after loader is finished
On November 14, 2018 at 2:18:04 PM, Subbsd (sub...@gmail.com(mailto:sub...@gmail.com)) wrote: > > My current host: FreeBSD 13.0-CURRENT r340319 and the problem is > still present. Rod was asking about the guest OS version, not the host though. ___ 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 amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote: > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > I.e., sometimes the CPU chooses to report on a range from 0-225C and > sometimes -49C-206C. I think someone else's 2990WX did the same > thing. I guess that patch never landed? 102°C - 49°C is the very > reasonable 53°C. > > Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 Thanks, that's it: setting the sensor_offset sysctls to -76 results in FreeBSD reporting 51.1C while the readout on the motherboard shows 51C :) I'll fetch and build r340426 tomorrow. -- Rebecca ___ 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 amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote: > Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat > plausible 75?C (still pretty warm even for load). How good is your > cooling solution? D'oh, of course it's -54 instead of +54 (For some reason I presumed a positive offset would be *subtracted*)! I have an all-in-one liquid thermaltake cooler installed, and under Windows it reports reaching 67C when running flat out, which doesn't seem bad. > (The references I can find with a quick search suggest TR 29xx should > also be -27? rather than -54?C, but they may be mistaken. 183-54-27 > is still 102?C ? extremely hot!) That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores instead of 2 units and 16 cores for other models, so I guessed that perhaps I should double the 27 value other people had said should be used. -- Rebecca ___ 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 amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote: > The 2700 has an offset of 0 though (2700X has 10). > And I'm seeing a difference of more than 30 degrees. I guess something > else must be happening here. I had thought 54 was the right offset for my 2990WX system, but now it's under load building ports the temperature reported via dev.amdtemp is 183C! Meanwhile the readout on the motherboard says "CPU Temp 53 C". -- Rebecca ___ 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: UEFI GOP: screen goes blank during boot after loader is finished
On Tuesday, 13 November 2018 18:57:25 MST Kyle Evans wrote: > However, because loader-land is funny in a not-ha-ha kind of way, can > you try replacing loader.efi on your guest VM with the Forth-flavored > version to rule that out or narrow it down, please? That didn't help. As probably expected, the last output before the screen goes blank is framebuffer information: /boot/kernel/kernel text=0x16776f0 data=0x1cd288+0x768b40 syms=[0x8+0x174ca8+0x8+0x192218] Booting... Start @ 0x80341000 ... EFI framebuffer information: addr, size 0xc100, 0x100 dimensions 800 x 600 stride 800 masks 0x00ff, 0xff00, 0x00ff, 0xff00 -- Rebecca ___ 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: UEFI: How to go about updating the ESP with loader.efi during installworld
On Sunday, 4 November 2018 16:07:17 MST Warner Losh wrote: > Finally, I have a /dev/efi/esp pseudo label support coded up for geom > (along with /dev/efi/boot for the putative root device). There's some > issues with it, so I set it aside some time ago to work on other higher > priority things. We could assume that if there's a filesystem mounted on > /dev/efi/esp, we should update the boot blocks there. We could, by default, > mount it as /efi. A weaker test, though one also in keeping with tradition, > would be to only install into /efi if it's a directory, and it's also a > mount point. that would preserve the status quo and not even need my > /dev/efi/esp code so would work out better from a number of assumptions > point of view. I wonder if we could coordinate our efforts and push to get this finished off in the next few months? I've been pushing my changes to https://github.com/bcran/freebsd/tree/efi-esp-generation . -- Rebecca ___ 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: UEFI: How to go about updating the ESP with loader.efi during installworld
On Sunday, 4 November 2018 15:56:25 MST Warner Losh wrote: > I think that's a really really bad idea. We should *NEVER* create them by > default. We are only sliding by on the coat-tails of compatibility by using > efi/boot/boot*.efi. We shouldn't use those at all, unless there's a > compelling reason (like BIOS bogosity) for doing so. I had no plans to > update or use those, at least by default. We should *ONLY* be using those > for *REMOVABLE* media, since that's the only place they are well defined in > the standard. Thanks, I had wrongly presumed it was in the spec for fixed storage as well given that Windows, Linux etc. creates them. Looking at the 2.7 specification I can see I was wrong and agree we should only create files in efi/freebsd. -- Rebecca ___ 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: UEFI: How to go about updating the ESP with loader.efi during installworld
On Sunday, 4 November 2018 14:36:13 MST Toomas Soome wrote:
> it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi is
> hard one of course. But then again, it is problem only when we can not
> setup EFI bootmanager variables ? the bootx64.efi is default when bootmgr
> is not set up.
Yes, I think we should only create efi/boot/boot{x64,ia32,aa64,arm}.efi if it
doesn't already exist in which case we're likely the only OS on the system.
--
Rebecca
___
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: UEFI: How to go about updating the ESP with loader.efi during installworld
On Sunday, 4 November 2018 14:25:26 MST Allan Jude wrote: > I wouldn't depend on the /etc/fstab entry existing. I am not sure I want > installworld randomly fobbing around in my EFI partition. Especially if, > for example, my EFI/BOOT is not FreeBSD, but rEFInd or something. I tend to agree. I have work planned in the near future to teach FreeBSD that EFI/BOOT may _not_ be FreeBSD and to play nice with other bootloaders, whether that be reFIND, GRUB, Windows etc. But yes, the big difference with this is there's much more code in loader.efi than we currently put in the bootblocks with boot0cfg or "gpart bootcode" and we might run into problems if we don't at least warn users that they'll need to update it. -- Rebecca ___ 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"
UEFI: How to go about updating the ESP with loader.efi during installworld
I'm currently working on creating and updating the ESP (EFI System Partition) for UEFI booting during installation and installworld. During installation, with my changes it gets mounted on /boot/efi and loader.efi copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets added to /etc/fstab as noauto. The issue comes during installworld, where we'll need to update the loader, and I'm not sure how we should handle that. If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the files then unmount it? What should we do if NO_ROOT _is_ defined? -- Rebecca ___ 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"
"arc4random: no preloaded entropy cache" printed once per CPU on startup
On a normal boot (not verbose) of -CURRENT from today's sources I'm getting the following message printed once for each logical CPU: arc4random: no preloaded entropy cache Since other messages, including the same one in random_harvestq.c are under bootverbose, should this one in arc4random.c be too? I guess another question is _why_ this message is being displayed, since it looks like it should only happen if an entropy stash (/entropy?) is missing: /* * This is making the best of what may be an insecure * Situation. If the loader(8) did not have an entropy * stash from the previous shutdown to load, then we will * be improperly seeded. The answer is to make sure there * is an entropy stash at shutdown time. */ -- Rebecca ___ 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-CURRENT lua loader complains dynamic libs not supported
On 10/27/18 10:34 AM, Kyle Evans wrote: Hmm... something's definitely amiss here- there's no reason this should be munging through /usr/local/... at all- it's not in the LUA_PATH. I'd be interested in knowing if there's anything funky about your build or run setup- I have lua53 installed, but I don't seem to have any odd interactions. I don't even have lua installed: /usr/local/lib/lua doesn't exist! I just updated to b9d1ddaf9ff163befda062c8c272fc91b176ac0a from github and verified that "git diff master..upstream/master" doesn't show any changes. "strings /boot/loader_lua" shows "/usr/local/lib/lua/5.3/?.so;/usr/local/lib/lua/5.3/loadall.so;./?.so" grepping for "usr/local" in the source tree (stand/) shows: ./liblua/luaconf.h:205:#define LUA_ROOT "/usr/local/" -- Rebecca ___ 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"
13-CURRENT lua loader complains dynamic libs not supported
When booting a recent 13-CURRENT installation, I’m seeing the following: Startup error in /boot/lua/loader.lua: LUA ERROR: /boot/lua/loader.lua:45: error loading module ‘local’ from file ‘/usr/local/lib/lua/5.3/local.so’: dynamic libraries not enabled: check your Lua installation. I then have to load the zfs module manually. — Rebecca ___ 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: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1
On 10/26/18 10:48 AM, Dag-Erling Smørgrav wrote: Rebecca Cran writes: After installing 12.0-BETA1, on the first boot I noticed a warning about $local_unbound_tls not being set properly. Ah, I should probably have added it to /etc/defaults/rc.conf. Can you do that (just set it to “no”) and let me know if it helps? That worked: the warning disappeared. -- Rebecca ___ 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"
Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1
After installing 12.0-BETA1, on the first boot I noticed a warning about $local_unbound_tls not being set properly. It looks like that flag was only added recently by Dag-Erling, in "Add support for DNS-over-TLS to the local_unbound service." -- Rebecca ___ 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: 12-BETA1 contains warning about non-PNP ISA device
On 10/25/18 10:46 AM, Warner Losh wrote: Oh! that looks mostly right, though IIRC the higher UIDs might be something else. Harmless enough for now, though. Thanks. I also think you might be able to test if we can remove a special case kludge we have for the AMDI0020 device since it looks like it has STA_ that might be sane now. Are you up for that? Sure! -- Rebecca ___ 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: 12-BETA1 contains warning about non-PNP ISA device
On 10/25/18 10:20 AM, Rebecca Cran wrote: uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0 uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1 uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2 uart3 pnpinfo _HID=AMDI0020 _UID=3 at handle=\_SB_.FUR3 Also, in case it's useful - the output of "devinfo -v | grep -i uart": uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0 unknown pnpinfo _HID=UTK0001A _UID=0 at handle=\_SB_.FUR0.UART (disabled) uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1 unknown pnpinfo _HID=UTK0001B _UID=1 at handle=\_SB_.FUR1.UART (disabled) uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2 uart3 pnpinfo _HID=AMDI0020 _UID=3 at handle=\_SB_.FUR3 -- Rebecca ___ 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: 12-BETA1 contains warning about non-PNP ISA device
On 10/25/18 10:18 AM, Warner Losh wrote: That seems incorrect. It looks like we're attaching too much. what does devinfo -v | grep uart tell you? uart0 pnpinfo _HID=AMDI0020 _UID=0 at handle=\_SB_.FUR0 uart1 pnpinfo _HID=AMDI0020 _UID=1 at handle=\_SB_.FUR1 uart2 pnpinfo _HID=AMDI0020 _UID=2 at handle=\_SB_.FUR2 uart3 pnpinfo _HID=AMDI0020 _UID=3 at handle=\_SB_.FUR3 -- Rebecca ___ 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: 12-BETA1 contains warning about non-PNP ISA device
On 10/25/18 10:00 AM, Warner Losh wrote: I suspect you can just lose those hints in the hints file and be fine. The uart should attach via acpi. The keyboard won't, however, since it isn't enabled. Can you try removing these lines from your hints file and see if the problem persists? Note this is for debugging purposes only. hint.atkbdc.0.at="isa" hint.uart.0.at="isa" That seems to work. After also removing uart1 from the hints file, I get: uart0: <16x50 with 256 byte FIFO> iomem 0xfedc9000-0xfedc9fff,0xfedc7000-0xfedc7fff irq 3 on acpi0 uart1: <16x50 with 256 byte FIFO> iomem 0xfedca000-0xfedcafff,0xfedc8000-0xfedc8fff irq 4 on acpi0 uart2: <16x50 with 256 byte FIFO> iomem 0xfedce000-0xfedcefff,0xfedcc000-0xfedccfff irq 3 on acpi0 uart3: <16x50 with 256 byte FIFO> iomem 0xfedcf000-0xfedc,0xfedcd000-0xfedcdfff irq 4 on acpi0 -- Rebecca ___ 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: 12-BETA1 contains warning about non-PNP ISA device
On 10/25/18 5:02 AM, Rodney W. Grimes wrote: Can you please reply with the specific device. If you have seen one it may be an issue to removing it, especially if this is on a "new AMD" system. This is a new Ryzen system. For me, I get warnings about atkbdc0 and uart0: atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. uart0: <16550 or compatible> at port 0x3f8 irq 4 flags 0x10 on isa0 uart0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. Yes, and they well be removed from GENERIC in BETA2, as I just approved the RFA to merge that fix to stable/12. Thanks, good to know they haven't been forgotten about. -- Rebecca ___ 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"
12-BETA1 contains warning about non-PNP ISA device
I noticed a warning on a new AMD system running 12-BETA1: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. It looks like it was introduced by Warner in r327120. Should those devices have been removed already? — Rebecca ___ 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: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On 9/27/18 9:00 PM, Allan Jude wrote: > > It doesn't appear like ZFS is dominating memory usage there. Using less > than the 8GB you indicated that setting the max to solved the problem... You're right, the problem appeared again despite having limited ZFS: FreeBSD tau.bluestop.org 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 dc3b1a4cf0e(master) MYKERNEL amd64 vfs.zfs.arc_max: 8589934592 Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(14): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(8): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(8): failed Oct 9 22:17:50 tau syslogd: last message repeated 1 times Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(4): failed Oct 9 22:17:50 tau syslogd: last message repeated 2 times Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(5): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(4): failed Oct 9 22:17:50 tau syslogd: last message repeated 1 times Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed Oct 9 22:17:50 tau syslogd: last message repeated 1 times Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(5): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed Oct 9 22:17:50 tau syslogd: last message repeated 1 times Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed Oct 9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed Oct 9 22:21:51 tau kernel: swap_pager_getswapspace(1): failed Oct 9 22:36:03 tau kernel: pid 9236 (cc1plus), uid 0, was killed: out of swap space Oct 9 22:40:55 tau kernel: pid 29131 (cc1plus), uid 0, was killed: out of swap space Oct 9 22:40:56 tau kernel: pid 82673 (firefox), uid 1001, was killed: out of swap space Oct 9 22:40:57 tau kernel: pid 30363 (firefox), uid 1001: exited on signal 11 (core dumped) Oct 9 22:40:59 tau kernel: pid 46714 (firefox), uid 1001: exited on signal 11 (core dumped) Oct 9 22:41:00 tau kernel: pid 62612 (firefox), uid 1001: exited on signal 11 (core dumped) -- Rebecca Cran ___ 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: Problem compiling rust
On 10/6/18 6:40 AM, Greg V wrote: > > BTW, this error message doesn't say much, but if cargo fails, you > might be out of memory. I was going to suggest being out of memory too. I've seen the rust build cause my system to run out of all 32GB RAM and 2GB swap. -- Rebecca Cran ___ 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: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
On 9/27/18 9:00 PM, Allan Jude wrote: > > It doesn't appear like ZFS is dominating memory usage there. Using less > than the 8GB you indicated that setting the max to solved the problem... Yeah, I'm not sure how that works. -- Rebecca ___ 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"
12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory
I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap. I've found it running out of memory when building ports via synth: I think I've also seen it when running a buildworld. Johannes on FreeBSDDesktop suggested it might be related to ZFS, and setting vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem. Shortly after running out of memory (with |"swap_pager_getswapspace(32): failed" messages)|, the first few lines of 'top' were: Mem: 4335M Active, 4854M Inact, 7751M Laundry, 9410M Wired, 48K Buf, 5332M Free ARC: 5235M Total, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other 3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse I've not seen this happen before on ZFS systems, so is it a regression in 12? -- Rebecca Cran ___ 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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 10:10 PM, Rebecca Cran wrote: > On 9/21/18 10:00 PM, Warner Losh wrote: > >> That may be the issue... Does the patch I included help? I'm building now >> on my stable system, but it's slow... > > It does seem to have got further this time, so a cautious yes. I can change that to a definite yes: >>> World build completed on Fri Sep 21 22:48:30 MDT 2018 -- Rebecca ___ 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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 10:00 PM, Warner Losh wrote: > That may be the issue... Does the patch I included help? I'm building now > on my stable system, but it's slow... It does seem to have got further this time, so a cautious yes. -- Rebecca ___ 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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 9:57 PM, Warner Losh wrote: > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? > > They look good for me, but the only way you get this error is if they > are wrong. bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE bfd bcran@cube:~/workspace/freebsd % make -V LINKER_FEATURES filter -- Rebecca ___ 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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 9:34 PM, Warner Losh wrote: > What does ld.lld say? > > However, it shouldn't matter: we don't build libc until *AFTER* we > build ld.lld, so this error is bogusly triggering. I suspect that it > needs to be limited to only building targets, since tree traversal > ones, as well as install targets don't have this dependency. LLD 6.0.0 (FreeBSD 326565-111) (compatible with GNU linkers) -- Rebecca ___ 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"
