[Bug 271675] cp: Interrupted system call
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675 Ivan Rozhuk changed: What|Removed |Added Attachment #242505|0 |1 is obsolete|| --- Comment #4 from Ivan Rozhuk --- Created attachment 247739 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247739&action=edit patch -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271675] cp: Interrupted system call
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675 Ivan Rozhuk changed: What|Removed |Added Version|13.2-STABLE |14.0-STABLE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276420] zfs panic: VERIFY(zio->io_stage == ZIO_STAGE_VDEV_IO_START) failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276420 Bug ID: 276420 Summary: zfs panic: VERIFY(zio->io_stage == ZIO_STAGE_VDEV_IO_START) failed Product: Base System Version: 13.2-STABLE Hardware: Any OS: Any Status: New Keywords: crash Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: j...@mit.edu I started a dd command to copy data between ZFS volumes in different pools. I returned to find my system had rebooted. Unfortunately there was not enough space to save a dump. All I have is the syslog message: savecore[1921]: reboot after panic: VERIFY(zio->io_stage == ZIO_STAGE_VDEV_IO_START) failed There are two such assertions in sys/contrib/openzfs/module/zfs/zio.c, one in zio_vdev_io_bypass and the other in zio_vdev_io_reissue. dd block size argument was bs=1m. Transfer rate was about 100 MB/s. Server has 160 GB RAM. Source disk was SAS SSD, destination was raidz2 with 5 spinning SATA disks. Both pools have a cache on different partitions of the same NVMe drive. Kernel has 13.2 changes through 4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276420] zfs panic: VERIFY(zio->io_stage == ZIO_STAGE_VDEV_IO_START) failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276420 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|f...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276421] Commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6 inhibits initialization of Xen front and backends
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276421 Bug ID: 276421 Summary: Commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6 inhibits initialization of Xen front and backends Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: trond.endres...@ximalas.info Created attachment 247741 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247741&action=edit Custom kernel configuration file XENGUEST Without backing out commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6, a XENGUEST kernel for amd64 15.0-CURRENT has no disks (ada[0-2], xbd[4-n]) and probably no NICs (xn[0-n]) at boot time on XCP-ng 8.2.1. Custom kernel configuration file is attached in case the problem is there instead. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276422] pam_passwdqc(8) - add more examples
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276422 Bug ID: 276422 Summary: pam_passwdqc(8) - add more examples Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: zarych...@plan-b.pwste.edu.pl A few years ago I created D27656[1]. It did not gain much interest, but it's still relevant. Yesterday I looked at the Security chapter of the FreeBSD Handbook and found no consistent example of enforcing password policies[2]. Where is the problem? When the user's password expires, the password change will be enforced immediately upon logging in and the policy enforcement set in /etc/pam.d/passwd will not be applied. In case of an expired password, password policy enforcement will only work if set in the appropriate pam.d config file corresponding to the authentication method (usually /etc/pam.d/sshd or /etc/pam.d/login). Moreover, in the case of an expired password, the password change will be done under uid 0, so only enforce=everyone makes sense. Maybe we can fix it by extending examples, but probably the right way will be to change PAM modules internally to better handle changing expired passwords. To reproduce: - Configure system following[2] - Set: "pw user mod exampleuser -p 31-Dec-2023" - Login via console or ssh to the system as exampleuser and set password to empty (just press enter twice). Over 3 years ago I found it as a foot-shooting issue and spent a few hours figuring out how was it possible that some users have set empty passwords, but I think that more people enforcing password policies might be affected. 1. https://reviews.freebsd.org/D27656 2. https://docs.freebsd.org/en/books/handbook/security/#security-pwpolicy -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276422] pam_passwdqc(8) - add more examples
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276422 --- Comment #1 from Marek Zarychta --- Created attachment 247742 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247742&action=edit patch extending examples -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276422] pam_passwdqc(8) - add more examples
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276422 Marek Zarychta changed: What|Removed |Added Keywords||accessibility, dogfood, ||patch, security -- You are receiving this mail because: You are the assignee for the bug.
[Bug 222639] fork: Time it takes to allocate random PID approach infinity as num_processes approach PID_MAX (related to: sysctl kern.randompid)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222639 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|m...@freebsd.org Status|New |Closed CC||ma...@freebsd.org Resolution|--- |FIXED --- Comment #3 from Mark Johnston --- I believe this was fixed in https://cgit.freebsd.org/src/commit/?id=34ebdceac09af3d4bc7ac7c16dd7cef2d6fc75f4 Please reopen if that's not the case. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276422] pam_passwdqc(8) - add more examples
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276422 Marek Zarychta changed: What|Removed |Added Status|New |Closed Resolution|--- |Unable to Reproduce --- Comment #2 from Marek Zarychta --- I am sorry for the noise. It looks like in the meantime the flaw got fixed since I am no longer able to reproduce it either on stable/13 or stable/14. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276421] Commit b0165dc4539fdfc84351a719b58850e4e7a6cbb6 inhibits initialization of Xen front and backends
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276421 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|virtualizat...@freebsd.org Keywords||regression --- Comment #1 from Mark Linimon --- ^Triage: to submitter: please let us know which file b0165dc4539fdfc84351a719b58850e4e7a6cbb6 affected. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 Bug ID: 276426 Summary: amd64: microcode update caused a page fault trying to send data to the logger Product: Base System Version: 13.2-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: lini...@freebsd.org (bugmeister note: I am forking this PR from 266730. They may, or may not, be related.) Originally from John F. Carr 2023-07-25 00:46:35 UTC: I saw what may be the same crash on amd64 running 12.4-CURRENT, first boot after upgrading from 12.3. I started the microcode_update service and the system promptly crashed. #4 0x810d66af in trap_fatal (frame=, eva=) at /data/freebsd/12/sys/amd64/amd64/trap.c:921 #5 0x810d66ff in trap_pfault (frame=0xfe002f78f9e0, signo=, ucode=) at pcpu_aux.h:55 #6 0x810aec68 in calltrap () at /data/freebsd/12/sys/amd64/amd64/exception.S:289 #7 0x810d2b73 in copyout_nosmap_std () at /data/freebsd/12/sys/amd64/amd64/support.S:805 #8 0x80c29f2d in uiomove_faultflag (cp=0xfe002686a000, n=98, uio=0xfe002f78fba0, nofault=) at /data/freebsd/12/sys/kern/subr_uio.c:254 #9 0x80c32333 in pipe_read (fp=0xf80012598550, uio=0xfe002f78fba0, active_cred=, flags=, td=) at /data/freebsd/12/sys/kern/sys_pipe.c:712 #10 0x80c2f3a5 in dofileread (td=, fd=0, fp=, auio=0xfe002f78fba0, offset=, flags=) at file.h:317 #11 0x80c2ef20 in sys_read (td=0xf8001cade740, uap=Unhandled dwarf expression opcode 0xa3 ) at /data/freebsd/12/sys/kern/sys_generic.c:289 #12 0x810d7267 in amd64_syscall (td=0xf8001cade740, traced=0) at subr_syscall.c:144 #13 0x810af58e in fast_syscall_common () at /data/freebsd/12/sys/amd64/amd64/exception.S:582 The active process was "logger". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2667 ||30 --- Comment #1 from Mark Linimon --- John F. Carr 2024-01-14 00:58:27 UTC Today I updated my amd64 13.2-STABLE system for the first time in a month. It crashed with a similar error on the first boot. A microcode update caused a page fault trying to send data to the logger. core.txt contents below. This panic hadn't happened before on this system. Maybe the update to llvm17 affected code generation. Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 45; apic id = 3b fault virtual address = 0x388e9756 fault code = supervisor write data, page not present instruction pointer = 0x20:0x81088c43 stack pointer = 0x28:0xfe03a79d7ca0 frame pointer = 0x28:0xfe03a79d7ca0 code segment= base rx0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 145 (logger) trap number = 12 panic: page fault cpuid = 45 time = 1705192820 KDB: stack backtrace: #0 0x80c199b5 at kdb_backtrace+0x65 #1 0x80bcebf2 at vpanic+0x152 #2 0x80bce9f3 at panic+0x43 #3 0x8108c56c at trap_fatal+0x38c #4 0x8108c5d7 at trap_pfault+0x67 #5 0x81060f08 at calltrap+0x8 #6 0x80c337d5 at uiomove_faultflag+0x135 [this is a call to copyout() -jfc] #7 0x80c3de55 at pipe_read+0x2f5 #8 0x80c3a586 at dofileread+0x86 #9 0x80c3a0d2 at sys_read+0xc2 #10 0x8108ced0 at amd64_syscall+0x140 #11 0x8106181b at fast_syscall_common+0xf8 Uptime: 38s -- You are receiving this mail because: You are the assignee for the bug.
[Bug 158340] [rpc] Possible dereference of null pointer by code that calls replay_find()...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158340 Mark Linimon changed: What|Removed |Added Status|Open|Closed Resolution|--- |Overcome By Events Assignee|b...@freebsd.org|bugmeis...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276428] NEC uPD720200 USB 3.0 Host Controller - Controller Halt/Reset
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276428 Bug ID: 276428 Summary: NEC uPD720200 USB 3.0 Host Controller - Controller Halt/Reset Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: verma...@interia.pl Hi, this USB 3.0 controller from ThinkPad W520 often halts/resets itself rendering it unusable till next reboot. # dmesg xhci0: Controller halt timeout. xhci0: Controller reset timeout. xhci0: Controller reset timeout. uhub2 on usbus1 uhub2: <(0x1033) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 uhub2: 4 ports with 4 removable, self powered xhci0: Resetting controller usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) ugen1.2: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) ugen1.2: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device uhub2: at usbus1, port 1, addr 1 (disconnected) uhub2: detached xhci0: Controller halt timeout. xhci0: Controller reset timeout. # pciconf -lv xhci0 xhci0@pci0:14:0:0: class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x1033 device=0x0194 subvendor=0x17aa subdevice=0x21cf vendor = 'NEC Corporation' device = 'uPD720200 USB 3.0 Host Controller' class = serial bus subclass = USB Regards, vermaden -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #2 from Konstantin Belousov --- Is this happens during ucode update while the system is already booted? Can you try to load the update from boot loader? I wonder if the update did something like enabling SMAP. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276428] NEC uPD720200 USB 3.0 Host Controller - Controller Halt/Reset
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276428 Mark Linimon changed: What|Removed |Added Keywords||crash Component|kern|usb Assignee|b...@freebsd.org|u...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 193235] basename(3) potentially failing with ENOMEM, etc is not documented
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193235 Ridge_Sylvester changed: What|Removed |Added CC||denny1wh...@gmail.com --- Comment #2 from Ridge_Sylvester --- Embark on a transformative journey with https://www.waytochanges.com/best-apps-every-student-should-use/ This platform is a beacon for personal growth, offering invaluable resources, strategies, and a supportive community. Navigating change becomes inspiring and manageable through their insightful tools. Linking to WayToChanges.com is an investment in guiding others toward meaningful transformations and empowering self-discovery. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 193235] basename(3) potentially failing with ENOMEM, etc is not documented
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193235 Mark Johnston changed: What|Removed |Added Status|New |Closed CC||ma...@freebsd.org Resolution|--- |Overcome By Events --- Comment #3 from Mark Johnston --- OBE per comment 1. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #3 from John F. Carr --- Microcode update is late in /etc/rc processing after "Mounting local filesytems" but before a login prompt. SMAP is already enabled before the microcode is updated. The copyout call is bound to copyout_smap_std: 0x80c337ca : mov%r15,%rdi 0x80c337cd : mov%r12,%rdx 0x80c337d0 : call 0x81088be0 When the crash is triggered, about once in 15 boots, it happens during /etc/rc script processing just before the system would go multi-user. The active processes in the latest crash are UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 00 25 -16 0 00 swapin DLs - 0:00.17 [kernel] 0 10 0 31 0 11780 836 wait DLs - 0:00.00 [init] 0 20 19 -16 0 00 -DL- 0:00.00 [KTLS] 0 30 47 -16 0 00 crypto_w DL- 0:00.00 [crypto] 0 40 41 -16 0 00 -DL- 0:00.00 [cam] 0 50 14 -16 0 00 -DL- 0:00.00 [rand_harvestq] 0 60 29 -16 0 00 idle DL- 0:00.00 [enc_daemon0] 0 70 3 -16 0 00 psleep DL- 0:00.00 [pagedaemon] 0 80 28 -16 0 00 psleep DL- 0:00.00 [vmdaemon] 0 90 22 -16 0 00 psleep DL- 0:00.00 [bufdaemon] 0 100 37 -16 0 00 audit_wo DL- 0:00.00 [audit] 0 110 0 155 0 00 -RL- 0:00.00 [idle] 0 120 -1 -52 0 00 -WL- 0:00.00 [intr] 0 130 39 20 0 00 -DL- 0:00.00 [geom] 0 140 32 -16 0 00 seqstate DL- 0:00.00 [sequencer 00] 0 150 11 -68 0 00 -DL- 0:00.00 [usb] 0 160 20 -16 0 00 vlruwt DL- 0:00.00 [vnlru] 0 170 14 16 0 00 syncer DL- 0:00.00 [syncer] 0 181 31 52 0 13552 2576 wait Ds+ - 0:00.00 [sh] 0 820 6 -8 0 00 t->zthr_ DL- 0:04.74 [zfskern] 0 139 18 43 52 0 13552 2588 wait D+- 0:00.00 [sh] 0 144 139 0 52 0 12732 1868 pipelk D+- 0:00.00 [cpucontrol] 0 145 139 45 52 0 12872 2176 -RC+ - 0:00.00 [logger] 0 1481 31 52 0 12872 2052 select Ds- 0:00.00 [logger] This is my processor as reported early in boot: CPU: AMD EPYC 7402P 24-Core Processor(2794.96-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x75c237ff Structured Extended Features=0x219c91a9 Structured Extended Features2=0x44 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x18cf757 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics After update I have microcode version 0x830107a. I don't think the boot loader can install microcode on my AMD processor, only on an Intel processor. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 Mark Johnston changed: What|Removed |Added Status|New |Open CC||ma...@freebsd.org --- Comment #4 from Mark Johnston --- > I don't think the boot loader can install microcode on my AMD processor, only > on an Intel processor. That is true, but not for much longer hopefully. You might be willing to test https://reviews.freebsd.org/D43318 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #5 from Konstantin Belousov --- In the first message, the backtrace shows copyout_nosmap_std(). Anyway, do you observe a difference in the reported features before and after ucode load? Also, for the trap, disassemble the copyout function and show which instruction faulted. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #6 from John F. Carr --- The first crash is from AMD Excavator (Family 0x15) running 12.4. That processor is from 2015 and may not have SMAP. The second crash is from AMD Zen 2 (Family 0x17) running 13.2. That processor is from 2020 and has SMAP before microcode is loaded. Features do not change when microcode is loaded. In the code below the marked mov %rdx,(%rdi) at 0x81088c43 is the faulting instruction. The fault address is at the start of a page in the user address space and is the same as uio->uio_iov[0].iov_base, i.e. the first word to be written. The value of td->td_md.md_pcb.pcb_onfault is 0 in the dump image. I can't tell what it was while copyout was running. A comment says it should be non-null. 0x81088c1c :mov%rsi,%rdi 0x81088c1f :mov%r8,%rsi 0x81088c22 :mov%rdx,%rcx 0x81088c25 :stac 0x81088c28 :cmp$0x20,%rcx 0x81088c2c :jbe0x81088c90 0x81088c2e :cmp$0x100,%rcx 0x81088c35 :ja 0x81088d70 0x81088c3b :nopl 0x0(%rax,%rax,1) 0x81088c40 :mov(%rsi),%rdx * 0x81088c43 :mov%rdx,(%rdi) 0x81088c46 : mov0x8(%rsi),%rdx 0x81088c4a : mov%rdx,0x8(%rdi) 0x81088c4e : mov0x10(%rsi),%rdx 0x81088c52 : mov%rdx,0x10(%rdi) 0x81088c56 : mov0x18(%rsi),%rdx 0x81088c5a : mov%rdx,0x18(%rdi) 0x81088c5e : lea0x20(%rsi),%rsi 0x81088c62 : lea0x20(%rdi),%rdi 0x81088c66 : sub$0x20,%rcx -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #7 from John F. Carr --- Other thread fields: td->td_critnest=1 which causes trap_pfault to panic before it even checks pcb_onfault td->td_pflags = 0x140 = TDP_DEADLKTREAT|TDP_SIGFASTBLOCK -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #8 from Konstantin Belousov --- (In reply to John F. Carr from comment #7) And what is the backtrace? td_critnest == 1 is extra strange, but pcb_onfault being NULL is also weird. Might be you are looking at wrong td. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426
--- Comment #9 from John F. Carr ---
Here is the complete backtrace (abbreviated form in comment #2) and evaluation
of the td variable in that stack.
(kgdb) bt
#0 __curthread ()
at /usr/home/jfc/freebsd/src/sys/amd64/include/pcpu_aux.h:53
#1 doadump (textdump=)
at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:394
#2 0x80bce802 in kern_reboot (howto=260)
at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:482
#3 0x80bcec5f in vpanic (fmt=0x812041f3 "%s",
ap=ap@entry=0xfe03a79d7af0)
at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:921
#4 0x80bce9f3 in panic (fmt=)
at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:845
#5 0x8108c56c in trap_fatal (frame=0xfe03a79d7be0,
eva=62185075507200)
at /usr/home/jfc/freebsd/src/sys/amd64/amd64/trap.c:940
#6 0x8108c5d7 in trap_pfault (frame=0xfe03a79d7be0,
usermode=false, signo=, ucode=)
at /usr/home/jfc/freebsd/src/sys/amd64/amd64/trap.c:759
#7
#8 copyout_smap_std ()
at /usr/home/jfc/freebsd/src/sys/amd64/amd64/support.S:849
#9 0x80c337d5 in uiomove_faultflag (cp=0xfe01bedc,
n=n@entry=105, uio=uio@entry=0xfe03a79d7da0, nofault=nofault@entry=0)
at /usr/home/jfc/freebsd/src/sys/kern/subr_uio.c:256
#10 0x80c33699 in uiomove (cp=0x388e9756, n=-1092878336,
n@entry=105, uio=0x636f6c2f7273752f, uio@entry=0xfe03a79d7da0)
at /usr/home/jfc/freebsd/src/sys/kern/subr_uio.c:196
#11 0x80c3de55 in pipe_read (fp=0xf801441abe10,
uio=0xfe03a79d7da0, active_cred=,
flags=, td=0xf80103c48000)
at /usr/home/jfc/freebsd/src/sys/kern/sys_pipe.c:732
#12 0x80c3a586 in fo_read (fp=0xf801441abe10,
uio=0xfe03a79d7da0, active_cred=0x636f6c2f7273752f,
td=0xf80103c48000, flags=)
at /usr/home/jfc/freebsd/src/sys/sys/file.h:336
#13 dofileread (td=td@entry=0xf80103c48000, fd=fd@entry=0,
fp=0xf801441abe10, auio=auio@entry=0xfe03a79d7da0,
offset=offset@entry=-1, flags=flags@entry=0)
at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:367
#14 0x80c3a0d2 in kern_readv (td=0xf80103c48000, fd=0,
auio=0xfe03a79d7da0)
at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:288
#15 sys_read (td=0xf80103c48000, uap=)
at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:204
#16 0x8108ced0 in syscallenter (td=)
at /usr/home/jfc/freebsd/src/sys/amd64/amd64/../../kern/subr_syscall.c:188
#17 amd64_syscall (td=0xf80103c48000, traced=0)
at /usr/home/jfc/freebsd/src/sys/amd64/amd64/trap.c:1181
#18
#19 0x388e94230d9a in ?? ()
Backtrace stopped: Cannot access memory at address 0x388e93262428
(kgdb) up 13
#13 dofileread (td=td@entry=0xf80103c48000, fd=fd@entry=0,
fp=0xf801441abe10, auio=auio@entry=0xfe03a79d7da0,
offset=offset@entry=-1, flags=flags@entry=0)
at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:367
367 if ((error = fo_read(fp, auio, td->td_ucred, flags, td))) {
(kgdb) p td->td_critnest
$22 = 1
(kgdb) p/x td->td_md.md_pcb
$23 = {pcb_r15 = 0xf80101bba000, pcb_r14 = 0x81e97788,
pcb_r13 = 0xfe010aeec0d8, pcb_r12 = 0xfe010aeec0c0,
pcb_rbp = 0xfe03a79d7bb0, pcb_rsp = 0xfe03a79d7b18,
pcb_rbx = 0xf80103c48000, pcb_rip = 0x80bfe4b6,
pcb_fsbase = 0x388e9378c120, pcb_gsbase = 0x0, pcb_kgsbase = 0x0,
pcb_cr0 = 0x0, pcb_cr2 = 0x0, pcb_cr3 = 0x0, pcb_cr4 = 0x0, pcb_dr0 = 0x0,
pcb_dr1 = 0x0, pcb_dr2 = 0x0, pcb_dr3 = 0x0, pcb_dr6 = 0x0, pcb_dr7 = 0x0,
pcb_gdt = {rd_limit = 0x0, rd_base = 0x0}, pcb_idt = {rd_limit = 0x0,
rd_base = 0x0}, pcb_ldt = {rd_limit = 0x0, rd_base = 0x0}, pcb_tr = 0x0,
pcb_flags = 0x19, pcb_initial_fpucw = 0x37f, pcb_onfault = 0x0,
pcb_saved_ucr3 = 0x0, pcb_tssp = 0x0, pcb_efer = 0x0, pcb_star = 0x0,
pcb_lstar = 0x0, pcb_cstar = 0x0, pcb_sfmask = 0x0,
pcb_save = 0xfe02699f4c00, pcb_pad = {0x0, 0x0, 0x0, 0x0, 0x0}}
(kgdb)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #10 from Mark Johnston --- (In reply to Konstantin Belousov from comment #8) td_critnest == 1 is probably a side effect of panic(), which calls spinlock_enter(). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426
--- Comment #11 from John F. Carr ---
The stack trace goes through line 759 in trap.c. In my code that is the if
statement here:
if (td->td_critnest != 0 ||
WITNESS_CHECK(WARN_SLEEPOK | WARN_GIANTOK, NULL,
"Kernel page fault") != 0) {
trap_fatal(frame, eva);
return (-1);
}
That prompted me to check td->td_critnest. The WITNESS_CHECK should return 0.
I have WITNESS disabled. I have INVARIANTS enabled. Otherwise my kernel is
GENERIC.
Could we be getting a page fault handling a page fault? I don't know if that
can be reconciled with the stack.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 276426] amd64: microcode update caused a page fault trying to send data to the logger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276426 --- Comment #12 from Konstantin Belousov --- (In reply to Mark Johnston from comment #10) It could be due to panic(), but then it is not clear why trap_pfault() called trap_fatal() at line 759. Either td_critnest was > 0, or we owned some non-sleepable lock, and the later would only trigger if the witness was compiled in. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 237653] LUA loader cannot choose ZFS pool to boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237653 --- Comment #5 from Vladyslav V. Prodan --- There is no way to repeat it yet. You need to have two copies of the kernel... "can’t load ’kernel’" This error is reproduced after exiting the 6th or 7th menu item. 13.2-STABLE 2cd20d9bc SUPPORT-13-2-0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276057] crash in xa_destroy() while initializing the i915kms module
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276057 --- Comment #11 from Konstantin Belousov --- (In reply to Donn Seeley from comment #10) Loosing witness support is very undesirable. Could you track the state of the xarray and explicitly reinit it when a call detects that xarray was finalized? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 237653] LUA loader cannot choose ZFS pool to boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237653 --- Comment #6 from Warner Losh --- (In reply to Vladyslav V. Prodan from comment #5) Thanks for the details, but I'm afraid that I'm still not sure how to recreate this problem. Do you have a step by step of what you are doing, and what's then failing? I have only a vague idea, and vague notion doesn't match my experience of doing what I think you are doing all the time... so having the exact details will help me track down what's going wrong for you... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276446] make installkernel fails: install: pflow.ko: No such file or directory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276446 Bug ID: 276446 Summary: make installkernel fails: install: pflow.ko: No such file or directory Product: Base System Version: 15.0-CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: warl...@phouka.net # git describe vendor/llvm-project/llvmorg-17.0.6-0-g6009708b4367-288272-g7a4d1d1df0b # (cd /usr/src && git log | head -3) commit 7a4d1d1df0b2e369adcb32aea9ef8c180f885751 Author: Aaron LI Date: Wed Jan 17 23:29:23 2024 + This is a KERNCONF=GENERIC-NODEBUG build. .. ===> pflog (install) install -T release -o root -g wheel -m 444 pflog.ko /boot/kernel/ install -T dbg -o root -g wheel -m 444 pflog.ko.debug /usr/lib/debug/boot/kernel/ ===> pflow (install) install -T release -o root -g wheel -m 444 pflow.ko /boot/kernel/ install: pflow.ko: No such file or directory *** Error code 71 Stop. make[4]: stopped in /usr/src/sys/modules/pflow *** Error code 1 Stop. make[3]: stopped in /usr/src/sys/modules *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/arm64.aarch64/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276446] make installkernel fails: install: pflow.ko: No such file or directory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276446 Gleb Smirnoff changed: What|Removed |Added Assignee|b...@freebsd.org|k...@freebsd.org --- Comment #1 from Gleb Smirnoff --- This might by misconfiguration on submitter side (e.g. not a clean build), but let Kristof decide. -- You are receiving this mail because: You are the assignee for the bug.
