Re: pkg does not recognize correct kernel version
Am 19.02.2018 um 21:24 schrieb Ronald Klop: > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling wrote: > >> Hi Ronald, >> >> Am 19.02.2018 um 20:27 schrieb Ronald Klop: >>> I just did this. >>> >>> root@sjakie ~]# pkg upgrade >>> Updating FreeBSD repository catalogue... >>> Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 >>> Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01 >>> Processing entries: 0% >>> pkg: Newer FreeBSD version for package gnome-menus: >>> - package: 1200058 >>> - running kernel: 1200056 >>> pkg: repository FreeBSD contains packages for wrong OS version: >>> FreeBSD:12:amd64 >>> Processing entries: 100% >>> Unable to update repository FreeBSD >>> Error updating repositories! >>> >>> [root@sjakie ~]# uname -UK >>> 1200058 1200058 >>> >>> [root@sjakie ~]# uname -a >>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18 >>> 12:37:36 CET 2018 >>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64 >>> >>> >>> >>> So uname gives a different version than pkg detects. >>> >>> What is happening? pkg update -f gives the same result. -o >>> OSVERSION=1200058 helps, but does not feel like the right solution. >>> >>> Regards, >>> Ronald. >> >> Please try >> >> #sysctl kern.osreldate >> kern.osreldate: 1200058 >> >> HTH, >> Rainer Hurling > > > [root@sjakie ~]# sysctl kern.osreldate > kern.osreldate: 1200058 > > Regards, > Ronald. On my kernel patchlevel 1200058 (r329446) I get: #pkg update -f Updating FreeBSD repository catalogue... Fetching meta.txz: 100%944 B 0.9kB/s00:01 Fetching packagesite.txz: 100%6 MiB 1.2MB/s00:05 Processing entries: 100% FreeBSD repository update completed. 28645 packages processed. All repositories are up to date. Perhaps more a local problem :( ___ 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: buildworld: "cp: /dev/null: Invalid argument"
Am 12.09.20 um 11:05 schrieb Hartmann, O.: > On Sat, 12 Sep 2020 10:03:18 +0200 > Michael Gmelin wrote: > >>> On 12. Sep 2020, at 09:55, Hartmann, O. >>> wrote: >>> >>> On Fri, 11 Sep 2020 07:18:33 -0600 >>> Alan Somers wrote: >>> > On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann > wrote: > > On Thu, 10 Sep 2020 10:44:08 -0600 > Alan Somers wrote: > >> No, it's devfs. I'll fix it. >> >> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone >> wrote: >>> I'm curious: does this give a similar issue? >>> >>> touch /tmp/foo >>> cp /tmp/foo /tmo/foo2 >>> >>> I'm wondering if the issue is that copy_file_range isn't >>> handling empty files, or if it's a devfs issue. >>> >>> >>> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler >>> wrote: It seems that SVN r365549 broke "cp /dev/null ..." imb On 9/10/20 10:35 AM, Michael Butler wrote: > Is anyone else seeing failures like this in building world > and, in > my > case, cron jobs as well? > > > Building > /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > --- all_subdir_sbin --- > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > --- all_subdir_stand --- > --- zfsboot.ldr --- > cp: /dev/null: Invalid argument > *** [zfsboot.ldr] Error code 1 > make[5]: *** zfsboot.ldr removed > --- all_subdir_kerberos5 --- > Building >>> /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log >>> > --- all_subdir_stand --- > > make[5]: stopped in /usr/src/stand/i386/zfsboot > .ERROR_TARGET='zfsboot.ldr' > >>> > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > >>> > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes > silent=yes >>> verbose' > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > .CURDIR='/usr/src/stand/i386/zfsboot' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20200902' > > ___ > 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" >>> >> ___ >> 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" > > I still get this error on a couple of boxes, while others seem to > buildworld > fine. All boxes are at CURRENT revision 365625. It is a bit > looking weird to > me. Running now a make cleanworld/cleandir on the specific boxes > and start building OS again. > > oh > I don't know why it's intermittent, but in any case this patch should fix it: https://reviews.freebsd.org/D26395 -Alan >>> >>> I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or >>> just deleting usr/obj/) and starting a fresh build, those boxes >>> with an newer kernel all fail at the very same point. We use >>> META_MODE on some boxes, switched to WITHOUT_CLEAN these days and >>> cleanded up on some systems therefore. That might be the reason why >>> the problem occurs not consistently on all systems. >>> >>> When will the pacth be committed? >>> >> >> Alan already committed it: >> >> https://svnweb.freebsd.org/base?view=revision&revision=365643 >> >> -m >> >>> Thanks in advance, >>> >>> oh >> ___ >> 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" > > Sources at: > > At revision 365652. > > Host is running kernel FreeBSD 13.0-CURRENT #20 r365382: Fri Sep 11 > 19:01:26 CEST 2020 amd64. > > make -j4 buildworld buildkernel > > quit with same error as shown below. > > Is there anything that has to prepa
r365488 page faults on AMD Ryzen 9 3950X
Since r365488 (and above until recent) my box breaks with the following error when starting: Fatal trap 12: page fault while in kernel mode cpuid = 31; apic id = 1f fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x808f452b stack pointer = 0x28:0x81711800 frame pointer = 0x28:0x81711800 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 = 0 (swapper) trap number = 12 panic: page fault cpuid = 31 time = 1 Some infos about the system, the page fault occurs: CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x870f10 Family=0x17 Model=0x71 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=0x108b657 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 68717379584 (65534 MB) avail memory = 66756149248 (63663 MB) Event timer "LAPIC" quality 600 #cat /etc/sysctl.conf security.bsd.map_at_zero=1 kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules kern.evdev.rcpt_mask=6 kern.maxfiles=49312 kern.ipc.shm_allow_removed=1 kern.ipc.maxsockbuf=16777216 vfs.usermount=1 net.inet.tcp.rfc1323=1 net.inet.tcp.sack.enable=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 Please let me know, if I should provide more info or test something. Thanks in advance, Rainer ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
Hi, I am AFK until Sunday, so can't investigate ATM. And no, I haven't solved it until now. Thanks for your report. Rainer Am 18. September 2020 00:38:31 MESZ schrieb monochrome : > >forgot you > > Forwarded Message >Subject: Re: r365488 page faults on AMD Ryzen 9 3950X >Date: Thu, 17 Sep 2020 17:03:49 -0400 >From: monochrome >To: freebsd-current@freebsd.org > >I am also having this problem. Have you resolved it? Mine is a Ryzen 5 2400G > >On 9/12/20 5:22 AM, Rainer Hurling wrote: >> Since r365488 (and above until recent) my box breaks with the following >> error when starting: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 31; apic id = 1f >> fault virtual address = 0x0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0x808f452b >> stack pointer = 0x28:0x81711800 >> frame pointer = 0x28:0x81711800 >> 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 = 0 (swapper) >> trap number = 12 >> panic: page fault >> cpuid = 31 >> time = 1 >> >> >> >> Some infos about the system, the page fault occurs: >> >> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz >> K8-class CPU) >>Origin="AuthenticAMD" Id=0x870f10 Family=0x17 Model=0x71 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=0x108b657 >>SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 >>TSC: P-state invariant, performance statistics >> real memory = 68717379584 (65534 MB) >> avail memory = 66756149248 (63663 MB) >> Event timer "LAPIC" quality 600 >> >> >> #cat /etc/sysctl.conf >> security.bsd.map_at_zero=1 >> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules >> kern.evdev.rcpt_mask=6 >> kern.maxfiles=49312 >> kern.ipc.shm_allow_removed=1 >> kern.ipc.maxsockbuf=16777216 >> vfs.usermount=1 >> net.inet.tcp.rfc1323=1 >> net.inet.tcp.sack.enable=1 >> net.inet.tcp.sendbuf_auto=1 >> net.inet.tcp.recvbuf_auto=1 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> net.inet6.ip6.use_tempaddr=1 >> net.inet6.ip6.prefer_tempaddr=1 >> net.local.stream.recvspace=65536 >> net.local.stream.sendspace=65536 >> >> >> Please let me know, if I should provide more info or test something. >> Thanks in advance, >> Rainer >> ___ >> 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" ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
Hi monochrome, back to keyboard, it tried newest CURRENT (r365920) on my box and even with newest sources the error occurs. After looking around somewhat more, I found some hints about Virtualbox kernel module having problems with r365488. Unfortunately, I am not able to find the thread again :( What seems to help as a workaround is to disable the loading of VirtualBox in /boot/loader.conf #vboxdrv_load="YES" and in /etc/rc.conf #vboxnet_enable="YES" #vboxguest_enable="YES" So probably, this page fault is not restricted to AMD Ryzen? HTH, Rainer Am 20.09.20 um 08:04 schrieb monochrome: > I have confirmed that r365487 is the last kernel that will boot on my > 2400G. These are the files changed between r365487 and r365488: > > U sys/vm/phys_pager.c > U sys/vm/vm_object.c > U sys/vm/vm_object.h > U sys/vm/vm_pager.h > > > > On 9/18/20 8:57 AM, Rainer Hurling wrote: >> Hi, >> I am AFK until Sunday, so can't investigate ATM. >> And no, I haven't solved it until now. Thanks for your report. >> Rainer >> >> Am 18. September 2020 00:38:31 MESZ schrieb monochrome >> : >>> >>> forgot you >>> >>> Forwarded Message >>> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X >>> Date: Thu, 17 Sep 2020 17:03:49 -0400 >>> From: monochrome >>> To: freebsd-current@freebsd.org >>> >>> I am also having this problem. Have you resolved it? Mine is a Ryzen >>> 5 2400G >>> >>> On 9/12/20 5:22 AM, Rainer Hurling wrote: >>>> Since r365488 (and above until recent) my box breaks with the following >>>> error when starting: >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address = 0x0 >>>> fault code = supervisor read data, page not present >>>> instruction pointer = 0x20:0x808f452b >>>> stack pointer = 0x28:0x81711800 >>>> frame pointer = 0x28:0x81711800 >>>> 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 = 0 (swapper) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 31 >>>> time = 1 >>>> >>>> >>>> >>>> Some infos about the system, the page fault occurs: >>>> >>>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz >>>> K8-class CPU) >>>> Origin="AuthenticAMD" Id=0x870f10 Family=0x17 Model=0x71 >>>> 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=0x108b657 >>>> SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 >>>> TSC: P-state invariant, performance statistics >>>> real memory = 68717379584 (65534 MB) >>>> avail memory = 66756149248 (63663 MB) >>>> Event timer "LAPIC" quality 600 >>>> >>>> >>>> #cat /etc/sysctl.conf >>>> security.bsd.map_at_zero=1 >>>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules >>>> kern.evdev.rcpt_mask=6 >>>> kern.maxfiles=49312 >>>> kern.ipc.shm_allow_removed=1 >>>> kern.ipc.maxsockbuf=16777216 >>>> vfs.usermount=1 >>>> net.inet.tcp.rfc1323=1 >>>> net.inet.tcp.sack.enable=1 >>>> net.inet.tcp.sendbuf_auto=1 >>>> net.inet.tcp.recvbuf_auto=1 >>>> net.inet.tcp.sendbuf_max=16777216 >>>> net.inet.tcp.recvbuf_max=16777216 >>>> net.inet6.ip6.use_tempaddr=1 >>>> net.inet6.ip6.prefer_tempaddr=1 >>>> net.local.stream.recvspace=65536 >>>> net.local.stream.sendspace=65536 >>>> >>>> >>>> Please let me know, if I should provide more info or test something. >>>> Thanks in advance, >>>> Rainer >>>> ___ >>>> 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" ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > On 2020-09-20 10:05, Rainer Hurling wrote: >> Hi monochrome, >> >> back to keyboard, it tried newest CURRENT (r365920) on my box and even >> with newest sources the error occurs. >> >> After looking around somewhat more, I found some hints about Virtualbox >> kernel module having problems with r365488. Unfortunately, I am not able >> to find the thread again :( >> >> What seems to help as a workaround is to disable the loading of >> VirtualBox in /boot/loader.conf >> >> #vboxdrv_load="YES" >> >> and in /etc/rc.conf >> >> #vboxnet_enable="YES" >> #vboxguest_enable="YES" >> >> >> So probably, this page fault is not restricted to AMD Ryzen? >> > > Possibly you need to rebuild that kernel module. Maybe the FreeBSD > version was not bumped correctly. > > --HPS > Thanks for the hint. But I did rebuild all kernel modules before rebooting, in my case vbox*.ko, nvidia*.ko. Best wishes, Rainer ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
Am 20.09.20 um 11:38 schrieb Konstantin Belousov: > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: >>> On 2020-09-20 10:05, Rainer Hurling wrote: >>>> Hi monochrome, >>>> >>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even >>>> with newest sources the error occurs. >>>> >>>> After looking around somewhat more, I found some hints about Virtualbox >>>> kernel module having problems with r365488. Unfortunately, I am not able >>>> to find the thread again :( >>>> >>>> What seems to help as a workaround is to disable the loading of >>>> VirtualBox in /boot/loader.conf >>>> >>>> #vboxdrv_load="YES" >>>> >>>> and in /etc/rc.conf >>>> >>>> #vboxnet_enable="YES" >>>> #vboxguest_enable="YES" >>>> >>>> >>>> So probably, this page fault is not restricted to AMD Ryzen? >>>> >>> >>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD >>> version was not bumped correctly. >>> >>> --HPS >>> >> >> Thanks for the hint. But I did rebuild all kernel modules before >> rebooting, in my case vbox*.ko, nvidia*.ko. > > Provide backtrace of the panic. > Hi Konstantin, Thanks for your response. After trying several ways to produce a core dump or a working kdb prompt without success, all I can offer is the following screen contents. I built a GENERIC kernel with debugging enabled, enable loading of vboxdrv via /boot/loader.conf and /etc/rc.conf as described above: [..snip..] procfs registered modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060, 0x82520a70) error 17 Timecounters tick every 1.000 msec lo0: bpf attached vlan: initialized, using hash tables with chaining Fatal trap 12: page fault while in kernel mode cpuid = 31; apic id = 1f fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80ea889b stack pointer = 0x20:0x826017e0 frame pointer = 0x20:0x826017e0 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 = 0 (swapper) trap number = 12 panic: page fault cpuid = 31 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82601490 vpanic() at vpanic+0x182/frame 0x826014e0 panic() at panic+0x43/frame 0x82601540 trap_fatal() at trap_fatal+0x387/frame 0x826015a0 trap_pfault() at trap_pfault+0x97/frame 0x82601600 calltrap() at calltrap+0x8/frame 0x82601710 --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp = 0x826017e0 --- phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0 vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830 vm_fault() at vm_fault+0x5d6/frame 0x82601940 vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0 vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20 rtR0MemObjFreeBSDAllocHelper() at rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70 rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame 0x82601ac0 supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60 supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0 VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame 0x82601bf0 module_register_init() at module_register_init+0xbd/frame 0x82601c20 mi_startup() at mi_startup+0xec/frame 0x82601c70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x37: movq$0,0x10b5796(%rip9 db> The system freezes at this point, no core dump is generated ;) This does not happen without loading VBoxDrv. At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope, this is of some help. Best regards, Rainer ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
On 20.09.20 22:07, Konstantin Belousov wrote: > On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote: >> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: >>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov: >>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: >>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: >>>>>> On 2020-09-20 10:05, Rainer Hurling wrote: >>>>>>> Hi monochrome, >>>>>>> >>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even >>>>>>> with newest sources the error occurs. >>>>>>> >>>>>>> After looking around somewhat more, I found some hints about Virtualbox >>>>>>> kernel module having problems with r365488. Unfortunately, I am not able >>>>>>> to find the thread again :( >>>>>>> >>>>>>> What seems to help as a workaround is to disable the loading of >>>>>>> VirtualBox in /boot/loader.conf >>>>>>> >>>>>>> #vboxdrv_load="YES" >>>>>>> >>>>>>> and in /etc/rc.conf >>>>>>> >>>>>>> #vboxnet_enable="YES" >>>>>>> #vboxguest_enable="YES" >>>>>>> >>>>>>> >>>>>>> So probably, this page fault is not restricted to AMD Ryzen? >>>>>>> >>>>>> >>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD >>>>>> version was not bumped correctly. >>>>>> >>>>>> --HPS >>>>>> >>>>> >>>>> Thanks for the hint. But I did rebuild all kernel modules before >>>>> rebooting, in my case vbox*.ko, nvidia*.ko. >>>> >>>> Provide backtrace of the panic. >>>> >>> >>> Hi Konstantin, >>> >>> Thanks for your response. >>> >>> After trying several ways to produce a core dump or a working kdb prompt >>> without success, all I can offer is the following screen contents. I >>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv >>> via /boot/loader.conf and /etc/rc.conf as described above: >>> >>> >>> [..snip..] >>> procfs registered >>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060, >>> 0x82520a70) error 17 >>> Timecounters tick every 1.000 msec >>> lo0: bpf attached >>> vlan: initialized, using hash tables with chaining >>> >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address = 0x0 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0x80ea889b >>> stack pointer = 0x20:0x826017e0 >>> frame pointer = 0x20:0x826017e0 >>> 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 = 0 (swapper) >>> trap number = 12 >>> panic: page fault >>> cpuid = 31 >>> time = 1 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0x82601490 >>> vpanic() at vpanic+0x182/frame 0x826014e0 >>> panic() at panic+0x43/frame 0x82601540 >>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0 >>> trap_pfault() at trap_pfault+0x97/frame 0x82601600 >>> calltrap() at calltrap+0x8/frame 0x82601710 >>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp = >>> 0x826017e0 --- >>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0 >>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830 >>> vm_fault() at vm_fault+0x5d6/frame 0x82601940 >>> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0 >>> vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20 >>> rtR0MemObjFreeBSDAllocHelper() at >>> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70 >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>&
Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
On 20.09.20 22:35, Rainer Hurling wrote: > On 20.09.20 22:07, Konstantin Belousov wrote: >> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote: >>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: >>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov: >>>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: >>>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: >>>>>>> On 2020-09-20 10:05, Rainer Hurling wrote: >>>>>>>> Hi monochrome, >>>>>>>> >>>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even >>>>>>>> with newest sources the error occurs. >>>>>>>> >>>>>>>> After looking around somewhat more, I found some hints about Virtualbox >>>>>>>> kernel module having problems with r365488. Unfortunately, I am not >>>>>>>> able >>>>>>>> to find the thread again :( >>>>>>>> >>>>>>>> What seems to help as a workaround is to disable the loading of >>>>>>>> VirtualBox in /boot/loader.conf >>>>>>>> >>>>>>>> #vboxdrv_load="YES" >>>>>>>> >>>>>>>> and in /etc/rc.conf >>>>>>>> >>>>>>>> #vboxnet_enable="YES" >>>>>>>> #vboxguest_enable="YES" >>>>>>>> >>>>>>>> >>>>>>>> So probably, this page fault is not restricted to AMD Ryzen? >>>>>>>> >>>>>>> >>>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD >>>>>>> version was not bumped correctly. >>>>>>> >>>>>>> --HPS >>>>>>> >>>>>> >>>>>> Thanks for the hint. But I did rebuild all kernel modules before >>>>>> rebooting, in my case vbox*.ko, nvidia*.ko. >>>>> >>>>> Provide backtrace of the panic. >>>>> >>>> >>>> Hi Konstantin, >>>> >>>> Thanks for your response. >>>> >>>> After trying several ways to produce a core dump or a working kdb prompt >>>> without success, all I can offer is the following screen contents. I >>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv >>>> via /boot/loader.conf and /etc/rc.conf as described above: >>>> >>>> >>>> [..snip..] >>>> procfs registered >>>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060, >>>> 0x82520a70) error 17 >>>> Timecounters tick every 1.000 msec >>>> lo0: bpf attached >>>> vlan: initialized, using hash tables with chaining >>>> >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address = 0x0 >>>> fault code = supervisor read data, page not present >>>> instruction pointer = 0x20:0x80ea889b >>>> stack pointer = 0x20:0x826017e0 >>>> frame pointer = 0x20:0x826017e0 >>>> 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 = 0 (swapper) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 31 >>>> time = 1 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0x82601490 >>>> vpanic() at vpanic+0x182/frame 0x826014e0 >>>> panic() at panic+0x43/frame 0x82601540 >>>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0 >>>> trap_pfault() at trap_pfault+0x97/frame 0x82601600 >>>> calltrap() at calltrap+0x8/frame 0x82601710 >>>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp = >>>> 0x826017e0 --- >>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0 >>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830 &g
Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
Am 22.09.20 um 00:13 schrieb Konstantin Belousov: On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: Fatal trap 12: page fault while in kernel mode cpuid = 31; apic id = 1f fault virtual address = 0x25407efa This address is very suspicious. I cannot claim it as the fact, but most likely cause for such garbage pointer value is mismatched ABI between kernel and module. In other words, the module was built against headers from different kernel. Hmm, thanks for the pointer. I will double check this evening and reporting back. Normally, this module should have been built and installed with the kernel build. fault code = supervisor read data, page not present instruction pointer = 0x20:0x80ec0b63 stack pointer = 0x28:0x826018b0 frame pointer = 0x28:0x82601940 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 = 0 (swapper) trap number = 12 panic: page fault cpuid = 31 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82601560 vpanic() at vpanic+0x182/frame 0x826015b0 panic() at panic+0x43/frame 0x82601610 trap_fatal() at trap_fatal+0x387/frame 0x82601670 trap_pfault() at trap_pfault+0x97/frame 0x826016d0 trap() at trap+0x2ab/frame 0x826017e0 calltrap() at calltrap+0x8/frame 0x826017e0 --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp = 0x82601940 --- vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940 vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00 rtR0MemObjFreeBSDAllocHelper() at rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70 rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame 0x82601ac0 supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60 supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0 VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame 0x82601bf0 module_register_init() at module_register_init+0xbd/frame 0x82601c20 mi_startup() at mi_startup+0xec/frame 0x82601c70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x37: movq$0,0x10b5616(%rip) db> Perhaps this gives some more insight into the problem? I can't assess, sorry. ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
On 22.09.20 07:06, Rainer Hurling wrote: > Am 22.09.20 um 00:13 schrieb Konstantin Belousov: >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address = 0x25407efa >> This address is very suspicious. >> >> I cannot claim it as the fact, but most likely cause for such garbage >> pointer value is mismatched ABI between kernel and module. In other >> words, the module was built against headers from different kernel. > > Hmm, thanks for the pointer. I will double check this evening and > reporting back. > > Normally, this module should have been built and installed with the > kernel build. As I said, the module was rebuild and reinstalled with the kernel build, and I double checked, the module was the patched version. So the boot messages about the page fault should be created by the rebuild, patched module. > >> >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0x80ec0b63 >>> stack pointer = 0x28:0x826018b0 >>> frame pointer = 0x28:0x82601940 >>> 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 = 0 (swapper) >>> trap number = 12 >>> panic: page fault >>> cpuid = 31 >>> time = 1 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0x82601560 >>> vpanic() at vpanic+0x182/frame 0x826015b0 >>> panic() at panic+0x43/frame 0x82601610 >>> trap_fatal() at trap_fatal+0x387/frame 0x82601670 >>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0 >>> trap() at trap+0x2ab/frame 0x826017e0 >>> calltrap() at calltrap+0x8/frame 0x826017e0 >>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp = >>> 0x82601940 --- >>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940 >>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00 >>> rtR0MemObjFreeBSDAllocHelper() at >>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70 >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>> 0x82601ac0 >>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60 >>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0 >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>> 0x82601bf0 >>> module_register_init() at module_register_init+0xbd/frame >>> 0x82601c20 >>> mi_startup() at mi_startup+0xec/frame 0x82601c70 >>> btext() at btext+0x2c >>> KDB: enter: panic >>> [ thread pid 0 tid 10 ] >>> Stopped at kdb_enter+0x37: movq $0,0x10b5616(%rip) >>> db> >>> >>> >>> Perhaps this gives some more insight into the problem? I can't assess, >>> sorry. ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
On 22.09.20 07:51, monochrome wrote: > Rainer, I'm all up and running and clean with the latest again, if it > still doesn't work after your next try, send me your step-by-step to > patch and i'll try it here. I'm using ryzen video so I have to disable > stuff to even see the fault messages. Hi monochrome, The attached file is the patched version, I put in the files dir of emulators/virtualbox-ose (the main port, not the kernel modules one). Then I rebuilt and reinstall the ports mulators/virtualbox-ose-kmod and mulators/virtualbox-ose and rebooted the box. In my case, the boot process freezes after the page fault messages. > > On 9/22/20 1:06 AM, Rainer Hurling wrote: >> Am 22.09.20 um 00:13 schrieb Konstantin Belousov: >>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 31; apic id = 1f >>>> fault virtual address = 0x25407efa >>> This address is very suspicious. >>> >>> I cannot claim it as the fact, but most likely cause for such garbage >>> pointer value is mismatched ABI between kernel and module. In other >>> words, the module was built against headers from different kernel. >> >> Hmm, thanks for the pointer. I will double check this evening and >> reporting back. >> >> Normally, this module should have been built and installed with the >> kernel build. >> >>> >>>> fault code = supervisor read data, page not present >>>> instruction pointer = 0x20:0x80ec0b63 >>>> stack pointer = 0x28:0x826018b0 >>>> frame pointer = 0x28:0x82601940 >>>> 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 = 0 (swapper) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 31 >>>> time = 1 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0x82601560 >>>> vpanic() at vpanic+0x182/frame 0x826015b0 >>>> panic() at panic+0x43/frame 0x82601610 >>>> trap_fatal() at trap_fatal+0x387/frame 0x82601670 >>>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0 >>>> trap() at trap+0x2ab/frame 0x826017e0 >>>> calltrap() at calltrap+0x8/frame 0x826017e0 >>>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp = >>>> 0x82601940 --- >>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940 >>>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00 >>>> rtR0MemObjFreeBSDAllocHelper() at >>>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70 >>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame >>>> 0x82601ac0 >>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60 >>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0 >>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame >>>> 0x82601bf0 >>>> module_register_init() at module_register_init+0xbd/frame >>>> 0x82601c20 >>>> mi_startup() at mi_startup+0xec/frame 0x82601c70 >>>> btext() at btext+0x2c >>>> KDB: enter: panic >>>> [ thread pid 0 tid 10 ] >>>> Stopped at kdb_enter+0x37: movq $0,0x10b5616(%rip) >>>> db> >>>> >>>> >>>> Perhaps this gives some more insight into the problem? I can't assess, >>>> sorry. >> ___ 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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X
On 23.09.20 00:51, Mark Johnston wrote: > On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote: >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 31; apic id = 1f >>> fault virtual address = 0x25407efa >> This address is very suspicious. >> >> I cannot claim it as the fact, but most likely cause for such garbage >> pointer value is mismatched ABI between kernel and module. In other >> words, the module was built against headers from different kernel. > > For some reason clang is not complaining about a missing declaration for > vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS... > > This patch is required on top of a patched extract of the vbox sources: > > --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400 > +++ the-freebsd-kernel.h 2020-09-22 18:49:55.317615000 -0400 > @@ -68,6 +68,7 @@ > #include > #include /* KERN_SUCCESS ++ */ > #include > +#include > #include /* vm_phys_alloc_* */ > #include/* kmem_alloc_attr */ > #include /* vm_contig_grow_cache */ > --- memobj-r0drv-freebsd.c.orig 2020-09-22 18:49:25.010456000 -0400 > +++ memobj-r0drv-freebsd.c2020-09-22 18:49:47.462276000 -0400 > @@ -323,7 +323,8 @@ > size_t cPages = atop(pMemFreeBSD->Core.cb); > int rc; > > -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages); > +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > /* No additional object reference for auto-deallocation upon unmapping. > */ > #if __FreeBSD_version >= 155 > @@ -457,7 +458,8 @@ > return VERR_NO_MEMORY; > } > > -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb)); > +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL, > +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred); > > if (PhysHighest != NIL_RTHCPHYS) > VmPhysAddrHigh = PhysHighest; > I can confirm that these patches (two files) work for me. The system reboots with loaded vbox kernel modules. Many thanks for your help and investigations! Best regards, Rainer ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
Am 23.12.20 um 21:55 schrieb Ulrich Spörlein: > On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote: >> On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote: >>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: >>> > The FreeBSD project will be moving it's source repo from subversion >>> to git >>> > starting this this weekend. The docs repo was moved 2 weeks ago. >>> The ports >>> > repo will move at the end of March, 2021 due to timing issues. ... >>> >>> I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when >>> clean), >>> but that's just a trivial issue with my source tree being marked -dirty >>> when it isn't, and that would have been part of r368709 anyway. All my >>> other git nits have been my own (refs/notes and origin name). >> >> Warner/others, up to r368820, we had log entries that looked like this: >> >> commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a >> Author: Li-Wen Hsu >> Date: Sun Dec 20 02:59:44 2020 + >> >> Mark the repository as being converted to Git. >> >> This is the last Subversion commit to src. >> >> Sponsored by: The FreeBSD Foundation >> >> Notes: >> svn path=/head/; revision=368820 >> >> Now, our git logs look like this: >> >> commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc >> Author: Ed Maste >> Date: Tue Dec 22 23:31:15 2020 -0500 >> >> newvers.sh: fix sense of git dirty check >> >> Previously we reported -dirty for an unmodified tree, and no >> -dirty if >> there were changes. >> >> PR: 252028 >> Reported by: John Kennedy >> >> (Specifically, no Notes: with revision= value) > > Yes, these notes are merely pointers to the SVN revisions. Without SVN, > we will of course not get any new notes. > >> For the kernel I compiled today, the uname output dumps out: >> >> FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ... >> >> Last kernel was (-dirty since fixed): >> >> FreeBSD 13.0-CURRENT #244 >> r368820+3cc0c0d66a06-c255241(main)-dirty: ... >> >> So, the r368820-value isn't being updated for it to find anymore. >> The middle >> value corresponds to the git commit and does have value (878d53410f75 >> is your >> "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the >> repository >> as being converted to Git" r368820 commit). > > Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds > "some" note in the last 10k revs and then uses that, instead of properly > falling back to counting from HEAD, which would result in -c255126 or > something around that. I built HEAD this afternoon and got 'FreeBSD 13.0-CURRENT #0 92be2847e84-c255272(main): Wed Dec 23 17:39:31 CET 2020'. The counting seems more correct here? > We'll fix it ... > > Cheers > Uli ___ 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
Am 15.01.21 um 16:45 schrieb Konstantin Belousov: > On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: >> On 15/01/2021 16:02, Konstantin Belousov wrote: >>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: >>>> On 15/01/2021 11:26, Jakob Alvermark wrote: >>>>> Hi, >>>>> >>>>> >>>>> When rebooting my thinkpad the 'bufdaemon' times out: >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed >>>>> out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop >>>>> ... timed out >>>>> >>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop >>>>> ... timed out >>>>> >>>>> >>>>> This started happening recently (within the last week I think). >>>> >>>> Hi, >>>> >>>> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. >>>> >>>> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of >>>> orphaned >>>> groups) "seems" ok >>>> >>>> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP >>>> support), affected by the timeout. >>>> >>>> I haven't tried the intermediate commit yet. >>>> >>>> My intel machine doesn't seem to be affected >>> >>> If you revert only 9e680e4005b7, is it fixed ? >>> >> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, >> I can do more if you want) > Please show me the output from sysctl > kern.timecounter > kern.eventtimer > and first 100 lines of dmesg from the verbose boot (that contains the CPU > ident lines). I also have this timeout issue only on AMD, here Ryzen 3950X: [...] Waiting for PIDS: 2905 90 seconds watchdog timeout expired. Shutdown terminated. Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated abnormally, going to single user mode Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15 wg0: link state changed to DOWN Waiting (max 69 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... timeout Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... timeout Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... You will find the wanted output from sysctl and boot -v in the attachment. HTH, Rainer Hurling #sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 3355373301 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.counter: 3626460971 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 21196 kern.timecounter.tc.i8254
Re: Waiting for bufdaemon
Am 15.01.21 um 19:48 schrieb Rainer Hurling: > Am 15.01.21 um 16:45 schrieb Konstantin Belousov: >> On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote: >>> On 15/01/2021 16:02, Konstantin Belousov wrote: >>>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote: >>>>> On 15/01/2021 11:26, Jakob Alvermark wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> When rebooting my thinkpad the 'bufdaemon' times out: >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed >>>>>> out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop >>>>>> ... timed out >>>>>> >>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop >>>>>> ... timed out >>>>>> >>>>>> >>>>>> This started happening recently (within the last week I think). >>>>> >>>>> Hi, >>>>> >>>>> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal. >>>>> >>>>> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of >>>>> orphaned >>>>> groups) "seems" ok >>>>> >>>>> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP >>>>> support), affected by the timeout. >>>>> >>>>> I haven't tried the intermediate commit yet. >>>>> >>>>> My intel machine doesn't seem to be affected >>>> >>>> If you revert only 9e680e4005b7, is it fixed ? >>>> >>> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests, >>> I can do more if you want) >> Please show me the output from sysctl >> kern.timecounter >> kern.eventtimer >> and first 100 lines of dmesg from the verbose boot (that contains the CPU >> ident lines). > > > I also have this timeout issue only on AMD, here Ryzen 3950X: > > [...] > Waiting for PIDS: 2905 > 90 seconds watchdog timeout expired. Shutdown terminated. > Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated > abnormally, going to single user mode > Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15 > wg0: link state changed to DOWN > Waiting (max 69 seconds) for system process `vnlru' to stop... done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done > Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done > Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop... > timeout > Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop... > timeout > Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop... > done > Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop... > > > You will find the wanted output from sysctl and boot -v in the attachment. > > HTH, > Rainer Hurling > During another shutdown after heavy usage of the box, the following messages were also seen: [...] Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14 efirtc0: CLOCK_SETTIME error 14 ___ 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
Am 17.01.21 um 05:33 schrieb Konstantin Belousov: > On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote: >> During another shutdown after heavy usage of the box, the following >> messages were also seen: >> >> >> [...] >> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14 >> efirtc0: CLOCK_SETTIME error 14 > > This means that BIOS code faulted during RTC settime call. I doubt that > it is related. > > On the other hand, it is good that the onfault EFI RT code got tested finally. > Thanks for clarification :) Any chance of getting a fix for the AMD CPUs in the foreseeable future? Or should I revert commit 9e680e4005b7 on affected boxes until further notice (as a workaround)? ___ 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
Am 17.01.21 um 10:49 schrieb Konstantin Belousov:
> On Sun, Jan 17, 2021 at 10:37:18AM +0100, Rainer Hurling wrote:
>> Am 17.01.21 um 05:33 schrieb Konstantin Belousov:
>>> On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote:
>>>> During another shutdown after heavy usage of the box, the following
>>>> messages were also seen:
>>>>
>>>>
>>>> [...]
>>>> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
>>>> efirtc0: CLOCK_SETTIME error 14
>>>
>>> This means that BIOS code faulted during RTC settime call. I doubt that
>>> it is related.
>>>
>>> On the other hand, it is good that the onfault EFI RT code got tested
>>> finally.
>>>
>>
>> Thanks for clarification :)
>>
>>
>> Any chance of getting a fix for the AMD CPUs in the foreseeable future?
>>
>> Or should I revert commit 9e680e4005b7 on affected boxes until further
>> notice (as a workaround)?
>
> I am working on it, no ETA.
>
> Interesting point would be to check on machines of other testers,
> if the following hides the problem.
>
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 85924df98312..5700a8ca98e5 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -639,7 +639,7 @@ init_TSC_tc(void)
>* on Intel, and MFENCE;RDTSC on AMD.
>* - For really old CPUs, just use RDTSC.
>*/
> - if ((cpu_vendor_id == CPU_VENDOR_AMD ||
> + if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
> cpu_vendor_id == CPU_VENDOR_HYGON) &&
> CPUID_TO_FAMILY(cpu_id) >= 0x17) {
> tsc_timecounter.tc_get_timecount = shift > 0 ?
>
I tried the above patch on a Ryzen 3950X.
After reboot (again with long waiting for bufdaemon and more) the box
had some heavy load with several jobs (llvm on Poudriere, building
qt5-webengine, libreoffice and some more in parallel). All went fine.
Afterwards I rebooted again. This time, the shutdown was fast without
any unusual delays :)
Many thanks!
___
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
Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>> This patch hides the problem for me. The system seems to work better now.
>>
>> No waiting on reboot, and the webcam works better.
> I am curious what do you mean by the above reference to webcam.
> Can you explain it with more details, even if only the impressions?
I should mention, that beside the already discussed timing problem with
bufdaemon, I also have problems with several apps:
After a high system load, several programs only react very slowly (e.g.
Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
not update their windows anymore, they freeze. After some time, Firefox
updates its screen content only after switching back from another window ...
When such frozen programs are killed and restarted, they run normally
again for an indefinite time before they freeze again.
These symptoms completely disappeared, after I patched the Ryzen box as
suggested on 01/17:
diff --git a/sys/x86/tsc.c b/sys/x86/tsc.c
index 85924df98312..5700a8ca98e5 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -639,7 +639,7 @@ init_TSC_tc(void)
* on Intel, and MFENCE;RDTSC on AMD.
* - For really old CPUs, just use RDTSC.
*/
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
+ if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_HYGON) &&
CPUID_TO_FAMILY(cpu_id) >= 0x17) {
tsc_timecounter.tc_get_timecount = shift > 0 ?
HTH,
Rainer
>
> I probably going to commit the following patch in the next 24 hours.
>
> commit 02505d07bca320a638c96918ac9076c6eece2fff
> Author: Konstantin Belousov
> Date: Wed Jan 20 11:32:21 2021 +0200
>
> AMD Zen CPUs: switch TSC timecounter to RDTSCP
>
> Reported by:many
> MFC after: 1 weel
> Sponsored by: The FreeBSD Foundation
>
> diff --git a/lib/libc/x86/sys/__vdso_gettc.c b/lib/libc/x86/sys/__vdso_gettc.c
> index 7f224f8758cb..7a64f2a0b556 100644
> --- a/lib/libc/x86/sys/__vdso_gettc.c
> +++ b/lib/libc/x86/sys/__vdso_gettc.c
> @@ -125,7 +125,7 @@ struct tsc_selector_tag {
> };
>
> static const struct tsc_selector_tag tsc_selector[] = {
> - [0] = { /* Intel or AMD Zen+, LFENCE */
> + [0] = { /* Intel, LFENCE */
> .ts_rdtsc32 = rdtsc32_mb_lfence,
> .ts_rdtsc_low = rdtsc_low_mb_lfence,
> },
> @@ -164,9 +164,6 @@ tsc_selector_idx(u_int cpu_feature)
> do_cpuid(1, p);
> cpu_id = p[0];
>
> - if (amd_cpu && CPUID_TO_FAMILY(cpu_id) >= 0x17)
> - return (0);
> -
> if (cpu_feature != 0) {
> do_cpuid(0x8000, p);
> cpu_exthigh = p[0];
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 85924df98312..de0a1505c2f6 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -633,19 +633,12 @@ init_TSC_tc(void)
>
> /*
>* Timecounter implementation selection, top to bottom:
> - * - For AMD Zens and newer, use LFENCE;RDTSC.
>* - If RDTSCP is available, use RDTSCP.
>* - If fence instructions are provided (SSE2), use LFENCE;RDTSC
>* on Intel, and MFENCE;RDTSC on AMD.
>* - For really old CPUs, just use RDTSC.
>*/
> - if ((cpu_vendor_id == CPU_VENDOR_AMD ||
> - cpu_vendor_id == CPU_VENDOR_HYGON) &&
> - CPUID_TO_FAMILY(cpu_id) >= 0x17) {
> - tsc_timecounter.tc_get_timecount = shift > 0 ?
> - tsc_get_timecount_low_lfence :
> - tsc_get_timecount_lfence;
> - } else if ((amd_feature & AMDID_RDTSCP) != 0) {
> + if ((amd_feature & AMDID_RDTSCP) != 0) {
> tsc_timecounter.tc_get_timecount = shift > 0 ?
> tscp_get_timecount_low : tscp_get_timecount;
> } else if ((cpu_feature & CPUID_SSE2) != 0 && mp_ncpus > 1) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Waiting for bufdaemon
Am 20.01.21 um 13:34 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >>>> This patch hides the problem for me. The system seems to work better now. >>>> >>>> No waiting on reboot, and the webcam works better. >>> I am curious what do you mean by the above reference to webcam. >>> Can you explain it with more details, even if only the impressions? >> >> I should mention, that beside the already discussed timing problem with >> bufdaemon, I also have problems with several apps: >> >> >> After a high system load, several programs only react very slowly (e.g. >> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >> not update their windows anymore, they freeze. After some time, Firefox >> updates its screen content only after switching back from another window ... >> >> When such frozen programs are killed and restarted, they run normally >> again for an indefinite time before they freeze again. >> >> These symptoms completely disappeared, after I patched the Ryzen box as >> suggested on 01/17: > > Do you load latest microcode update from devcpu-data? Yes, sysutils/devcpu-data is installed and the following to lines are in /boot/loader.conf cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" But isn't this just for Intel (i387 and amd64), not AMD cpus? > It might be not enough, which means that additionally latest BIOS needs > to be flushed. > I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" mainboard. ___ 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
Am 20.01.21 um 14:12 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >>>>>> This patch hides the problem for me. The system seems to work better now. >>>>>> >>>>>> No waiting on reboot, and the webcam works better. >>>>> I am curious what do you mean by the above reference to webcam. >>>>> Can you explain it with more details, even if only the impressions? >>>> >>>> I should mention, that beside the already discussed timing problem with >>>> bufdaemon, I also have problems with several apps: >>>> >>>> >>>> After a high system load, several programs only react very slowly (e.g. >>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >>>> not update their windows anymore, they freeze. After some time, Firefox >>>> updates its screen content only after switching back from another window >>>> ... >>>> >>>> When such frozen programs are killed and restarted, they run normally >>>> again for an indefinite time before they freeze again. >>>> >>>> These symptoms completely disappeared, after I patched the Ryzen box as >>>> suggested on 01/17: >>> >>> Do you load latest microcode update from devcpu-data? >> >> Yes, sysutils/devcpu-data is installed and the following to lines are in >> /boot/loader.conf >> >> cpu_microcode_load="YES" >> cpu_microcode_name="/boot/firmware/intel-ucode.bin" >> >> But isn't this just for Intel (i387 and amd64), not AMD cpus? > You need microcode_update_enable="YES" in /etc/rc.conf for late microcode > update. > > I think that early boot update should work on AMD, bit for this you need to > select and put right blob. It is enough to load late to answer my question. Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in /etc/rc.conf for a late update. Should I try again without your patch of sys/x86/tsc.c, whether the problem still occurs? And for the early boot update, how do I know about the right blob? > >> >>> It might be not enough, which means that additionally latest BIOS needs >>> to be flushed. >>> >> >> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" >> mainboard. ___ 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
Am 20.01.21 um 14:52 schrieb Konstantin Belousov: > On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: >> Am 20.01.21 um 14:12 schrieb Konstantin Belousov: >>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: >>>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >>>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >>>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >>>>>>>> This patch hides the problem for me. The system seems to work better >>>>>>>> now. >>>>>>>> >>>>>>>> No waiting on reboot, and the webcam works better. >>>>>>> I am curious what do you mean by the above reference to webcam. >>>>>>> Can you explain it with more details, even if only the impressions? >>>>>> >>>>>> I should mention, that beside the already discussed timing problem with >>>>>> bufdaemon, I also have problems with several apps: >>>>>> >>>>>> >>>>>> After a high system load, several programs only react very slowly (e.g. >>>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >>>>>> not update their windows anymore, they freeze. After some time, Firefox >>>>>> updates its screen content only after switching back from another window >>>>>> ... >>>>>> >>>>>> When such frozen programs are killed and restarted, they run normally >>>>>> again for an indefinite time before they freeze again. >>>>>> >>>>>> These symptoms completely disappeared, after I patched the Ryzen box as >>>>>> suggested on 01/17: >>>>> >>>>> Do you load latest microcode update from devcpu-data? >>>> >>>> Yes, sysutils/devcpu-data is installed and the following to lines are in >>>> /boot/loader.conf >>>> >>>> cpu_microcode_load="YES" >>>> cpu_microcode_name="/boot/firmware/intel-ucode.bin" >>>> >>>> But isn't this just for Intel (i387 and amd64), not AMD cpus? >>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode >>> update. >>> >>> I think that early boot update should work on AMD, bit for this you need to >>> select and put right blob. It is enough to load late to answer my question. >> >> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in >> /etc/rc.conf for a late update. >> >> Should I try again without your patch of sys/x86/tsc.c, whether the >> problem still occurs? Unfornately, without the patch from 01/17 the problem is _not_ solved. Next I will try your patch from today, f lib/libc/x86/sys/__vdso_gettc.c an lib/libc/x86/sys/__vdso_gettc.c ... > Yes. > >> >> >> And for the early boot update, how do I know about the right blob? > I am not aware of the mechanism. My best suggestion is that you match > the blob against your CPU family/model id manually. > >> >>> >>>> >>>>> It might be not enough, which means that additionally latest BIOS needs >>>>> to be flushed. >>>>> >>>> >>>> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" >>>> mainboard. ___ 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
Am 20.01.21 um 15:42 schrieb Mark Johnston: > On Wed, Jan 20, 2021 at 03:12:27PM +0200, Konstantin Belousov wrote: >> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >>>>>>> This patch hides the problem for me. The system seems to work better >>>>>>> now. >>>>>>> >>>>>>> No waiting on reboot, and the webcam works better. >>>>>> I am curious what do you mean by the above reference to webcam. >>>>>> Can you explain it with more details, even if only the impressions? >>>>> >>>>> I should mention, that beside the already discussed timing problem with >>>>> bufdaemon, I also have problems with several apps: >>>>> >>>>> >>>>> After a high system load, several programs only react very slowly (e.g. >>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >>>>> not update their windows anymore, they freeze. After some time, Firefox >>>>> updates its screen content only after switching back from another window >>>>> ... >>>>> >>>>> When such frozen programs are killed and restarted, they run normally >>>>> again for an indefinite time before they freeze again. >>>>> >>>>> These symptoms completely disappeared, after I patched the Ryzen box as >>>>> suggested on 01/17: >>>> >>>> Do you load latest microcode update from devcpu-data? >>> >>> Yes, sysutils/devcpu-data is installed and the following to lines are in >>> /boot/loader.conf >>> >>> cpu_microcode_load="YES" >>> cpu_microcode_name="/boot/firmware/intel-ucode.bin" >>> >>> But isn't this just for Intel (i387 and amd64), not AMD cpus? >> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode >> update. >> >> I think that early boot update should work on AMD, bit for this you need to >> select and put right blob. It is enough to load late to answer my question. > > The early microcode loader still doesn't support AMD. I did not do it > for lack of a test system at the time. > Thanks for the info. So for now, I can remove microcode_update_enable="YES" in /boot/loader.conf ... Is there anything, I can test for you (without having skills in the area ;) )? ___ 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
Am 20.01.21 um 15:36 schrieb Rainer Hurling: > Am 20.01.21 um 14:52 schrieb Konstantin Belousov: >> On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote: >>> Am 20.01.21 um 14:12 schrieb Konstantin Belousov: >>>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote: >>>>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov: >>>>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote: >>>>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov: >>>>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote: >>>>>>>>> This patch hides the problem for me. The system seems to work better >>>>>>>>> now. >>>>>>>>> >>>>>>>>> No waiting on reboot, and the webcam works better. >>>>>>>> I am curious what do you mean by the above reference to webcam. >>>>>>>> Can you explain it with more details, even if only the impressions? >>>>>>> >>>>>>> I should mention, that beside the already discussed timing problem with >>>>>>> bufdaemon, I also have problems with several apps: >>>>>>> >>>>>>> >>>>>>> After a high system load, several programs only react very slowly (e.g. >>>>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do >>>>>>> not update their windows anymore, they freeze. After some time, Firefox >>>>>>> updates its screen content only after switching back from another >>>>>>> window ... >>>>>>> >>>>>>> When such frozen programs are killed and restarted, they run normally >>>>>>> again for an indefinite time before they freeze again. >>>>>>> >>>>>>> These symptoms completely disappeared, after I patched the Ryzen box as >>>>>>> suggested on 01/17: >>>>>> >>>>>> Do you load latest microcode update from devcpu-data? >>>>> >>>>> Yes, sysutils/devcpu-data is installed and the following to lines are in >>>>> /boot/loader.conf >>>>> >>>>> cpu_microcode_load="YES" >>>>> cpu_microcode_name="/boot/firmware/intel-ucode.bin" >>>>> >>>>> But isn't this just for Intel (i387 and amd64), not AMD cpus? >>>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode >>>> update. >>>> >>>> I think that early boot update should work on AMD, bit for this you need to >>>> select and put right blob. It is enough to load late to answer my >>>> question. >>> >>> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in >>> /etc/rc.conf for a late update. >>> >>> Should I try again without your patch of sys/x86/tsc.c, whether the >>> problem still occurs? > > Unfornately, without the patch from 01/17 the problem is _not_ solved. > > Next I will try your patch from today, f lib/libc/x86/sys/__vdso_gettc.c > an lib/libc/x86/sys/__vdso_gettc.c ... I can confirm that this patch also works for me on Ryzen 3950X. No more bufdaemon waitings, no frozen apps, ... > > >> Yes. >> >>> >>> >>> And for the early boot update, how do I know about the right blob? >> I am not aware of the mechanism. My best suggestion is that you match >> the blob against your CPU family/model id manually. >> >>> >>>> >>>>> >>>>>> It might be not enough, which means that additionally latest BIOS needs >>>>>> to be flushed. >>>>>> >>>>> >>>>> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite" >>>>> mainboard. ___ 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"
sys/sys/param.h: 'main' instead of 'Master'?
While viewing sys/sys/param.h I noticed that the comment of the definition of __FreeBSD_version is probably out of date. Since the switch to Git, doesn't it have to be 'main' instead of 'master'? #cd /usr/src #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 @@ -60,7 +60,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 147 /* Master, propagated to newvers */ +#define __FreeBSD_version 147 /* main, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, ___ 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: sys/sys/param.h: 'main' instead of 'Master'?
Am 16.04.21 um 18:38 schrieb Kyle Evans: > n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote: >> >> While viewing sys/sys/param.h I noticed that the comment of the >> definition of __FreeBSD_version is probably out of date. >> >> Since the switch to Git, doesn't it have to be 'main' instead of 'master'? >> > > This isn't based on a branch name, though I guess if one were going to > touch it anyways then "Authoritative" would be a better descriptor. Sounds reasonable. Thanks for the explanation. > >> #cd /usr/src >> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff >> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200 >> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200 >> @@ -60,7 +60,7 @@ >> * in the range 5 to 9. >> */ >> #undef __FreeBSD_version >> -#define __FreeBSD_version 147 /* Master, propagated to newvers */ >> +#define __FreeBSD_version 147 /* main, propagated to newvers */ >> >> /* >> * __FreeBSD_kernel__ indicates that this system uses the kernel of >> FreeBSD, >> ___ 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: What happen to mailing list archives?
Hi Steve, Am 06.06.21 um 01:13 schrieb Steve Kargl: > On Sun, Jun 06, 2021 at 01:00:40AM +0200, Michael Gmelin wrote: >> >> >>> On 6. Jun 2021, at 00:53, Steve Kargl >>> wrote: >>> >>> It seems someone has tried to migrate the mailing list archives >>> from mailman to some new fangle code. This has broken the archives >>> for at least freebsd-numerics@, freebsd-office@, freebsd-net@ >>> >>> As a comparison, simply go to >>> >>> https://lists.freebsd.org/mailman/listinfo >>> >>> and follow the links to freebsd-numerics and freebsd-toolchain. >>> >>> Can this be fixed? >>> >> >> New archives are here: >> https://lists.freebsd.org/archives/ >> > > If I go to https://www.freebsd.org/community/mailinglists/ > > I see the lines > > Mailing list archives > > You can search or browse the mailing list archives at www.FreeBSD.org. > It is also possible to browse the mailing lists via the Mailman Web > interface. > > Both instances of the word "browse" are hyperlinks. If I click of the > second "browse" link, then I end up at > > https://lists.freebsd.org/mailman/listinfo > > which presents a list of archives, you'll see freebsd-numerics > is a hyperlink (as well as many others). If I click on freebsd-numerics, > this takes me to > > https://lists.freebsd.org/subscription/freebsd-numerics > > which displays > > Subscription for freebsd-numerics > > Browse the archives: here > (and 6 hyperlinks for subscribing and unsubscribing). > > If I click on "here", I get When I click on "here" I also get a "404 Not Found" at first, but only for about 5 seconds. This is followed by a redirect to the archive list. Maybe try it again? If that doesn't work for you: I have saved some threads with Bruce Evans locally. I could provide them, hoping that there is something useful? Regards, Rainer > > 404 Not Found > > Ergo, the freebsd-numerics archive is unreachable from the "here" link. > Shouldn't this redirect to the new fangle way? >
Re: Build faulure of editors/libreoffice only on src main (stable/13 is OK)
Am 26.02.22 um 14:14 schrieb Tomoaki AOKI: Thanks. But unfortunately, as I've described at Comment 21 [2] of Bug 262008, setting kern.elf64.aslr.enable=0 didn't help. As I'm building on amd64 and not built for compat32, I've not touched kern.elf32.aslr.enable. And as these are regular writable sysctl (and also are tunables, too), setting these in /boot/loader.conf and reboot before build is not tested. I just tried building _after a reboot_ whith kern.elf64.aslr.enable=0 on recent CURRENT and it doesn't work for me. 14.0-CURRENT #0 main-n253393-2bfdc1ee9b1 amd64 Best wishes, Rainer Should I set more sysctl's? I thought setting above actually disable all aslr related features (for 64bit), regardless its 1 ro 0. Error messages (with "MAKE_JOBS_UNSAFE=yes") and backtraces are described at Comment 20 [3]. [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c21 [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c20 On Sat, 26 Feb 2022 13:29:26 +0100 Michael Gmelin wrote: Maybe it’s related to ASLR? (or is it also enabled in 13/stable?) On 26. Feb 2022, at 13:05, Tomoaki AOKI wrote: 〓(Re-sent as not yet delivered in more than 5 hours) Hi. I have a build failure of editors/libreoffice on src main, amd64. As I've reported on Bug 262008 [1], problems on stable/13 is already fixed, but still fails on main with different faulure mode. A tool gengal.bin, built within whole libreoffice build, coredumps but it went OK on stable/13. Port options are now default on both main and stable/13. I now come to suspect the differences about toolchains within main and stable/13, but as editors/libreoffivce is giant and this failure happenes almost at the end of build, usual bisecting is not realistic. (Would require tens of weekends, maybe.) Any thoughts? Or am I missing something to check for? Regards. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008 -- Tomoaki AOKI
Re: dmesg: ACPI Warning: Firmware issue warning spaming
Am 14.06.22 um 04:00 schrieb Jung-uk Kim: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. I found the author actually filed a pull request to revert the commit. https://github.com/acpica/acpica/pull/780 FYI, I removed the message. https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 Thank you! This message bothered me a lot on two notebooks, Dell Latitude 6520 and Dell Latitude 5521. Greetings, Rainer Jung-uk Kim
