Re: mips32 + gcc9 -- still broken
On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > So, the big list of unknown symbols was my fault! Whoops. > > i've gotten further using gcc-6.4 by fixing some of the warnings/issues > that have crept up. > > Here's a review for one of them: > > https://reviews.freebsd.org/D26504 > > However, now I've hit: > > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_fetch_sub_8' > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_load_8' > /usr/local/bin/mips-unknown-freebsd13.0-ld: > > /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/tmp/usr/lib/libc++.so.1: > undefined reference to `__atomic_fetch_add_8' > > .. looks like we need some 64 bit atomics now in mips32 for libc++ / devd > Those are now provided by compiler-rt when using clang. With GCC you'll have to link libatomic. I had a quick look at the code in libc++ that uses the 64-bit atomics a few weeks ago and I believe it's the futex fallback code. The best solution would probably be to port it to use umtx but for MIPS32 it might be fine to use a 32 bit atomic instead. Alex > ___ 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: iflib/bridge kernel panic
On 21 Sep 2020, at 2:52, Shawn Webb wrote: >> From latest HEAD on a Dell Precision 7550 laptop: > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > The last working boot environment was 14 Aug 2020. If I get some time to > bisect commits, I'll try to figure out the culprit. > Try https://reviews.freebsd.org/D26418 Best regards, Kristof ___ 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: Plans for git
Quoting Pete Wright (from Sun, 20 Sep 2020 08:41:13 -0700): Not responding to Pete directly, but in general to this topic with some parts of what Pete considers good as something to hook into. making quarterly reports about this for almost a years as well. We put out calls for people to help with the efforts about the same time. We have tried at every step of the way to be open and honest that this was going to happen. All developer centric communications I fail to see why it is important to non-developers, which (D)VCS the developers of the product they use are using. It may be interesting, yes. It may have an impact on some (see the announcement of deprecation of portsnap), but those which put their craftmanship into it, are the important ones. Not to tell that we don't need to inform (or to let them repeat all the arguments we provided internally already), but the main use case for the VCS is to have those with commit privilegues handle version control. I do not go to a lot of in-person meetings, I just follow the internal and the official mailinglists, and there was communication for a lng time (and no, I do not use git for FreeBSD stuff so far, so you can not consider myself as someone who is eager to get FreeBSD moved to git and as such has an interest in it --- but I do understand the reasoning and can agree to it). Any FreeBSD committer who tells he was not aware of it, has simply not paid attention to it. For any non-committer see below. I would argue that quarterly reports are actually one of the few [...] honestly there has to be *some* responsibility of operators to at least make an effort to keep up to date on the status of the various efforts in such a large project. and as an outsider the idea that comms can only happen on the mailing list isn't the greatest - how am i to know that the idea of one person on the ML carries more weight than another, or one persons opinion is the "official" stated opinion of the core group? I agree to that. And I agree that the status reports are a nice way of getting some kind of inside-information in a central way. And in my opinion we gave early enough information about the migration to git. Maybe it can be organized, so that some guides for users (again, deprecation of portsnap and such) are published first via the status reports (and other channels), before the switch to the git-repo happens. We have no other official channel which is suitable for such way-ahead announcements IMO (yes, we should send a mail to freebsd-announce when we switch + an entry in the news section of the website, and /maybe/ we should send a mail some weeks before the switch too, but so far, I do not think this info should have been send to freebsd-announce, or be published on the website). In my opinion the people which drive this didn't keep it behind closed curtains, and they went step by step more public, as they made progress. To me it looks like now, that they have something which is presentable to the world (and not only to committers), they presented it to the world. I do not think we can hold them responsible that we do not have "the one official channel" for this (hey... anyone feel free to create it for the next big change, and document what shall be announced how via this channel). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpKrb4jx5cwo.pgp Description: Digitale PGP-Signatur
Re: iflib/bridge kernel panic
On Mon, Sep 21, 2020 at 09:57:40AM +0200, Kristof Provost wrote: > On 21 Sep 2020, at 2:52, Shawn Webb wrote: > >> From latest HEAD on a Dell Precision 7550 laptop: > > > > https://gist.github.com/lattera/a0803f31f58bcf8ead51ac1ebbc447e2 > > > > The last working boot environment was 14 Aug 2020. If I get some time to > > bisect commits, I'll try to figure out the culprit. > > > Try https://reviews.freebsd.org/D26418 That seems to fix the kernel panic. dmesg gets spammed with a freak ton of these LOR messages now: BEGIN LOG 01 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] Sleeping on "e1000_delay" with the following non-sleepable locks held: Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] exclusive sleep mutex if_bridge (if_bridge) r = 0 (0xf8001ea07218) locked @ /usr/src/sys/net/if_bridge.c:827 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] stack backtrace: Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #0 0x80c6c4a1 at witness_debugger+0x71 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #1 0x80c6d5bd at witness_warn+0x40d Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #2 0x80c09b8b at _sleep+0x5b Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #3 0x80c0a38e at pause_sbt+0xfe Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #4 0x80652b2d at e1000_write_phy_reg_mdic+0xed Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #5 0x80656bde at __e1000_write_phy_reg_hv+0x1ce Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #6 0x80640ea9 at e1000_lv_jumbo_workaround_ich8lan+0x799 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #7 0x8062329e at em_if_init+0x151e Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #8 0x80d347a9 at iflib_init_locked+0x2d9 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #9 0x80d36b08 at iflib_if_ioctl+0x1b8 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #10 0x83c582ac at bridge_set_ifcap+0x8c Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #11 0x83c544c8 at bridge_ioctl_add+0x4c8 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #12 0x83c560ff at bridge_ioctl+0x2df Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #13 0x80d9f1a1 at in_control+0x341 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #14 0x80d16266 at ifioctl+0x766 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #15 0x80c715a0 at kern_ioctl+0x290 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #16 0x80c71267 at sys_ioctl+0x127 Sep 21 08:08:28 hbsd-laptop-02 kernel: [25] #17 0x8122bf4c at amd64_syscall+0x14c END LOG 01 BEGIN LOG 02 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] lock order reversal: (sleepable after non-sleepable) Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] 1st 0xf800374616a0 ure0 (ure0, sleep mutex) @ /usr/src/sys/dev/usb/usb_request.c:714 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] 2nd 0x81eb1ab8 sysctl lock (sysctl lock, sleepable rm) @ /usr/src/sys/kern/kern_sysctl.c:837 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] lock order ure0 -> sysctl lock attempted at: Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #0 0x80c6c1dc at witness_checkorder+0xdcc Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #1 0x80bf76bb at _rm_wlock_debug+0x6b Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #2 0x80c0c7a6 at sysctl_add_oid+0x46 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #3 0x83c64ea1 at ure_attach_post+0x1a91 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #4 0x83c6a1af at ue_attach_post_task+0x2f Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #5 0x80a2b749 at usb_process+0xf9 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #6 0x80bb9fe5 at fork_exit+0x85 Sep 21 08:08:28 hbsd-laptop-02 kernel: [29] #7 0x81200a9e at fork_trampoline+0xe END LOG 02 At work, I have two ethernet interfaces: the onboard em0 and a usb ethernet dongle. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: objcopy "text file busy" build failure with populated /usr/obj
Le dim. 20 sept. 2020 à 16:59, Mark Murray a écrit :
>
> Hi *
>
> I've been getting these build failures for a while (weeks/months). The
> machine is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and
> zfs filesystem. If I empty out /usr/obj, then the build works, but takes a
> few hours. If I do a no-clean build with /obj/obj populated with he contents
> of a previous build, and /usr/src with updated ("svn update") sources, then
> the below nearly always happens early in the rebuild. It is in "stage 4.4:
> building everything" that this happens. The build is parallel (-j8), and I
> have manually de-threaded the output.
>
> The generated command-line from the logfile is:
>
> cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64 MACHINE=arm64
> CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target
> aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++
> -target aarch64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target
> aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" LD="ld"
> LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size"
> STRIPBIN="strip" INSTALL="install -U"
> PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
> SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make -f Makefile.inc1
> BWPHASE=everything DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all
>
> Anyone else seeing this?
>
> objcopy --strip-debug --add-gnu-debuglink=objcopy.debug objcopy.full objcopy
> objcopy: open objcopy failed: Text file busy
> --- all_subdir_usr.bin/objcopy ---
> *** [objcopy] Error code 1
>
> make[4]: stopped in /usr/src/usr.bin/objcopy
>
> M
> --
Hi
I got the same on amd64 with a meta mode build, on zfs as well. Oddly
(or not), it happens only if I make buildworld as a normal user, but
not as root. A second make buildworld always succeed.
___
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: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 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. >>> Yes it seems to be enough for me to see where the possible issue is. >>> Try this patch, I did not even compiled it. Probably you need to put >>> it into ports/emulators/virtualbox-ose-kmod/files with the name ending >>> with .patch. >> This seems to be wrong, name
Re: Plans for git
On 2020-09-21, Alexander Leidinger wrote: > In my opinion the people which drive this didn't keep it behind > closed curtains, and they went step by step more public, as they > made progress. To me it looks like now, that they have something > which is presentable to the world (and not only to committers), > they presented it to the world. Since I am one of the sad people who managed to miss all this public information, where can we find a summary of what's planned for the switch? -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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: Plans for git
> On Sep 21, 2020, at 4:22 AM, Alexander Leidinger > wrote: > > Quoting Pete Wright (from Sun, 20 Sep 2020 08:41:13 > -0700): > > Not responding to Pete directly, but in general to this topic with some parts > of what Pete considers good as something to hook into. > making quarterly reports about this for almost a years as well. We put out calls for people to help with the efforts about the same time. We have tried at every step of the way to be open and honest that this was going to happen. >>> All developer centric communications > > I fail to see why it is important to non-developers, which (D)VCS the > developers of the product they use are using. (…) I'm speaking only for myself but a change in (D)VCS used by FreeBSD changes the workflow I use when I use FreeBSD here internally. -- rollingbits — 📧 rollingb...@gmail.com 📧 rollingb...@terra.com.br 📧 rollingb...@yahoo.com 📧 rollingb...@globo.com 📧 rollingb...@icloud.com ___ 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: Plans for git
On 9/21/20 12:49 PM, Christian Weisgerber wrote: On 2020-09-21, Alexander Leidinger wrote: In my opinion the people which drive this didn't keep it behind closed curtains, and they went step by step more public, as they made progress. To me it looks like now, that they have something which is presentable to the world (and not only to committers), they presented it to the world. Since I am one of the sad people who managed to miss all this public information, where can we find a summary of what's planned for the switch? I believe the most detailed report on this was in the 2020-04 quarterly status report: https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Git-Migration-Working-Group before this, work was mentioned in previous updates as part of the core teams status update. there is also the freebsd-git@ mailing list here: https://lists.freebsd.org/pipermail/freebsd-git/ i don't subscribe to that list personally but i have checked the archives periodically when i have questions that pop up. hope this helps, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: Plans for git
Lev Serebryakov wrote in <23e7fc1c-6769-ceaf-4089-46e5cc575...@freebsd.org>: |On 19.09.2020 19:05, Bakul Shah wrote: |>> These are the main ones. The three down sides are lack of $FreeBSD$ \ |>> support |>> and tags in general. |> |> Can a git hook be used for this? | |git filters could be used for that, problem is it should be local config\ |uration. You could not configure filters in clones automatically :-( I do not think you can do that. Once i switched to git (2011 or a bit before) i even looked around for this, because i have been educated by BSD and used such tags everywhere, and found a thread with the Linus from where the elks live regarding this topic. I guess that $SHA-1$ git (supported by git by then) is the outcome of this thread, offered as a compromise. That mail thread exists. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ 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: Plans for git
On Mon, Sep 21, 2020 at 2:55 PM Steffen Nurpmeso wrote: > Lev Serebryakov wrote in > <23e7fc1c-6769-ceaf-4089-46e5cc575...@freebsd.org>: > |On 19.09.2020 19:05, Bakul Shah wrote: > |>> These are the main ones. The three down sides are lack of $FreeBSD$ \ > |>> support > |>> and tags in general. > |> > |> Can a git hook be used for this? > | > |git filters could be used for that, problem is it should be local config\ > |uration. You could not configure filters in clones automatically :-( > > I do not think you can do that. Once i switched to git (2011 or > a bit before) i even looked around for this, because i have been > educated by BSD and used such tags everywhere, and found a thread > with the Linus from where the elks live regarding this topic. > I guess that $SHA-1$ git (supported by git by then) is the outcome > of this thread, offered as a compromise. That mail thread exists. > It's documented to be the hash of the blob, not the hash of the commit., which makes it basically useless for our purposes... Warner ___ 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: Plans for git
On 2020-09-21, Pete Wright wrote: > I believe the most detailed report on this was in the 2020-04 quarterly > status report: > https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Git-Migration-Working-Group I saw that at the time. It basically says that the conversion of the repository is feasible. > there is also the freebsd-git@ mailing list here: > https://lists.freebsd.org/pipermail/freebsd-git/ Well, I was asking for a summary. For instance, I don't know if the Git migration is merely a switch of the version control system or what other changes will be layered on top of it as a matter of course, e.g. will the development infrastructure move to GitHub? Don't answer that, just point me to the information. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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 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. > 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: Plans for git
Warner Losh wrote in : |On Mon, Sep 21, 2020 at 2:55 PM Steffen Nurpmeso \ |wrote: |> Lev Serebryakov wrote in |> <23e7fc1c-6769-ceaf-4089-46e5cc575...@freebsd.org>: |>|On 19.09.2020 19:05, Bakul Shah wrote: |>|>> These are the main ones. The three down sides are lack of $FreeBSD$ \ |>|>> support |>|>> and tags in general. |>|> |>|> Can a git hook be used for this? |>| |>|git filters could be used for that, problem is it should be local config\ |>|uration. You could not configure filters in clones automatically :-( |> |> I do not think you can do that. Once i switched to git (2011 or |> a bit before) i even looked around for this, because i have been |> educated by BSD and used such tags everywhere, and found a thread |> with the Linus from where the elks live regarding this topic. |> I guess that $SHA-1$ git (supported by git by then) is the outcome |> of this thread, offered as a compromise. That mail thread exists. |> | |It's documented to be the hash of the blob, not the hash of the commit., |which makes it basically useless for our purposes... Never used that. Even if it requires additional tooling and/or the repository, whereas the BSD way is that you can take such a freely licensed file, include it somewhere, and strings(1) etc. still gives you an immediately human graspable output. I mean, if the project agrees by policy then of course the master copy at freebsd.org can expand such things when commits are merged. There are now also many more hooks available, in fact i have no idea of what i am talking about ^_^ --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Can't forward X11 apps over ssh since migrating to 13-CURRENT
I don't know if it's just coincidental or if it's because of some change in 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable to forward X11 apps over ssh. The only app I was accustomed to running this way was Handbrake. It worked fine before, but now i get this: $ ghb Unable to init server: Could not connect to 127.0.0.1: Connection refused (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display: I have tried other apps like Wireshark and even xclock just to see, but they won't work either. Has anyone else had problems with X11 forwarding on 13-CURRENT? If it's working for everyone else, at least I can know it's probably not 13-CURRENT's fault, and I need to look elsewhere for the cause. And yes, my sshd_config has it enabled. It worked fine before, and I made sure to keep the same config. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't forward X11 apps over ssh since migrating to 13-CURRENT
Possibly check ForwardX11Timeout . ___ 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"
Odd diff -qr / /mnt "Only in " results
Context: head -r365932 (on a Rock64). But this could well not be new. First a look at the / context and then the /mnt/ : # ls -laT / total 225 drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 . drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. -rw-r--r-- 2 root wheel 1083 Jul 8 23:53:07 2020 .cshrc drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile -rw--- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd drwxrwxr-x 2 root operator512 Aug 8 19:02:22 2020 .snap -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Sep 21 01:56:39 2020 bin drwxr-xr-x 24 root wheel 1536 Sep 21 01:58:43 2020 boot dr-xr-xr-x 18 root wheel 512 Sep 21 02:20:24 2020 dev -rw--- 1 root wheel 4096 Sep 21 02:20:37 2020 entropy drwxr-xr-x 27 root wheel 2560 Sep 21 01:58:16 2020 etc drwxr-xr-x 5 root wheel 2048 Sep 21 01:56:39 2020 lib drwxr-xr-x 3 root wheel 512 Sep 21 01:56:38 2020 libexec drwx-- 2 root wheel 98816 Jul 24 21:28:53 2020 lost+found drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media drwxr-xr-x 6 root wheel 512 Sep 21 01:49:57 2020 microsd_ufs drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 mnt drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 rescue drwxr-xr-x 17 root wheel 2560 Mar 30 05:23:44 2020 root drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 sbin lrwxr-xr-x 1 root wheel11 May 1 19:22:54 2018 sys -> usr/src/sys drwxrwxrwt 59 root wheel 3584 Sep 21 04:16:21 2020 tmp drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 usb_efi drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr drwxr-xr-x 26 root wheel 512 Sep 21 02:20:36 2020 var drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs # ls -laT /mnt total 120 drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 . drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. -rw-r--r-- 2 root wheel 1083 Jul 16 16:41:10 2020 .cshrc drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile -rw--- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd drwxrwxr-x 2 root operator 512 Mar 14 19:02:19 2020 .snap -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Sep 21 03:32:17 2020 bin drwxr-xr-x 13 root wheel 1024 Sep 21 03:32:17 2020 boot dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 dev -rw--- 1 root wheel 4096 Sep 13 14:02:57 2020 entropy drwxr-xr-x 27 root wheel 2560 Sep 21 03:36:49 2020 etc drwxr-xr-x 5 root wheel 2048 Sep 21 03:32:16 2020 lib drwxr-xr-x 3 root wheel 512 Sep 21 03:32:16 2020 libexec drwx-- 2 root wheel 512 Mar 17 16:16:42 2020 lost+found drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media drwxr-xr-x 2 root wheel 512 Mar 17 16:16:08 2020 microsd_ufs drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 mnt drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:16 2020 rescue drwxr-x--- 18 root wheel 2048 Mar 30 05:23:44 2020 root drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:13 2020 sbin lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> usr/src/sys drwxrwxrwt 60 root wheel 5120 Mar 30 05:23:44 2020 tmp drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr drwxr-xr-x 26 root wheel 512 Mar 30 05:23:44 2020 var drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/Rock64root 195378 105474 7427359%/ devfs 0 0 0 100%/dev /dev/label/Rock64root 109101362 100010 0%/microsd_ufs /dev/msdosfs/RPI4EFIFS99 7 92 8%/usb_efi /dev/gpt/PINE642Groot 195378 76731 10301643%/mnt But when I do the "diff -qr / /mnt" I get the following "Only in " notices: Only in /mnt: .cshrc Only in /mnt: .libs Only in /mnt: .profile Only in /mnt: .rnd Only in /mnt: .snap Only in /mnt: COPYRIGHT Only in /mnt: bin Only in /mnt: boot Only in /mnt: dev Only in /mnt: entropy Only in /mnt: etc Only in /mnt: lib Only in /mnt: libexec Only in /mnt: lost+found Only in /mnt: media Only in /mnt: microsd_ufs Only in /mnt: mnt Only in /mnt: net Only in /mnt: proc Only in /mnt: rescue Only in /mnt: sbin Only in /mnt: sys Only in /mnt: tmp Only in /mnt: usr Only in /mnt: var Only in /mnt: wrkdirs It still does the diff's inside the likes of /usr/ and /mnt/usr
review of mountd.c change
Hi, I just put a patch up in phabricator (D26521) which avoids always malloc()'ng a large MAX_NGROUPS sized groups list by having a small one in the structure and then only malloc()'ng when a large groups list is needed. I've listed kib@ and freqlabs@ as reviewers, but anyone else is welcome to review it. The review is probably about the technique I used. (Alternately, the could just always malloc() the groups array the correct size instead of using the SMALLNGROUPS one or malloc()'ng.) Thanks in advance to anyone that reviews it, rick ___ 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: Odd diff -qr / /mnt "Only in " results
On 2020-Sep-21, at 13:38, Mark Millard wrote: > Context: head -r365932 (on a Rock64). But this could well not > be new. > > First a look at the / context and then the /mnt/ : > > # ls -laT / > total 225 > drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 . > drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. > -rw-r--r-- 2 root wheel 1083 Jul 8 23:53:07 2020 .cshrc > drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs > -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile > -rw--- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd > drwxrwxr-x 2 root operator512 Aug 8 19:02:22 2020 .snap > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 2 root wheel 1024 Sep 21 01:56:39 2020 bin > drwxr-xr-x 24 root wheel 1536 Sep 21 01:58:43 2020 boot > dr-xr-xr-x 18 root wheel 512 Sep 21 02:20:24 2020 dev > -rw--- 1 root wheel 4096 Sep 21 02:20:37 2020 entropy > drwxr-xr-x 27 root wheel 2560 Sep 21 01:58:16 2020 etc > drwxr-xr-x 5 root wheel 2048 Sep 21 01:56:39 2020 lib > drwxr-xr-x 3 root wheel 512 Sep 21 01:56:38 2020 libexec > drwx-- 2 root wheel 98816 Jul 24 21:28:53 2020 lost+found > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media > drwxr-xr-x 6 root wheel 512 Sep 21 01:49:57 2020 microsd_ufs > drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 mnt > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net > dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc > drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 rescue > drwxr-xr-x 17 root wheel 2560 Mar 30 05:23:44 2020 root > drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 sbin > lrwxr-xr-x 1 root wheel11 May 1 19:22:54 2018 sys -> usr/src/sys > drwxrwxrwt 59 root wheel 3584 Sep 21 04:16:21 2020 tmp > drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 usb_efi > drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr > drwxr-xr-x 26 root wheel 512 Sep 21 02:20:36 2020 var > drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs > > # ls -laT /mnt > total 120 > drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 . > drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. > -rw-r--r-- 2 root wheel 1083 Jul 16 16:41:10 2020 .cshrc > drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs > -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile > -rw--- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd > drwxrwxr-x 2 root operator 512 Mar 14 19:02:19 2020 .snap > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 2 root wheel 1024 Sep 21 03:32:17 2020 bin > drwxr-xr-x 13 root wheel 1024 Sep 21 03:32:17 2020 boot > dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 dev > -rw--- 1 root wheel 4096 Sep 13 14:02:57 2020 entropy > drwxr-xr-x 27 root wheel 2560 Sep 21 03:36:49 2020 etc > drwxr-xr-x 5 root wheel 2048 Sep 21 03:32:16 2020 lib > drwxr-xr-x 3 root wheel 512 Sep 21 03:32:16 2020 libexec > drwx-- 2 root wheel 512 Mar 17 16:16:42 2020 lost+found > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media > drwxr-xr-x 2 root wheel 512 Mar 17 16:16:08 2020 microsd_ufs > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 mnt > drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net > dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc > drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:16 2020 rescue > drwxr-x--- 18 root wheel 2048 Mar 30 05:23:44 2020 root > drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:13 2020 sbin > lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> usr/src/sys > drwxrwxrwt 60 root wheel 5120 Mar 30 05:23:44 2020 tmp > drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr > drwxr-xr-x 26 root wheel 512 Mar 30 05:23:44 2020 var > drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs > > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/gpt/Rock64root 195378 105474 7427359%/ > devfs 0 0 0 100%/dev > /dev/label/Rock64root 109101362 100010 0%/microsd_ufs > /dev/msdosfs/RPI4EFIFS99 7 92 8%/usb_efi > /dev/gpt/PINE642Groot 195378 76731 10301643%/mnt > > > But when I do the "diff -qr / /mnt" I get the following "Only in " > notices: > > Only in /mnt: .cshrc > Only in /mnt: .libs > Only in /mnt: .profile > Only in /mnt: .rnd > Only in /mnt: .snap > Only in /mnt: COPYRIGHT > Only in /mnt: bin > Only in /mnt: boot > Only in /mnt: dev > Only in /mnt: entropy > Only in /mnt: etc > Only in /mnt: lib > Only in /mnt: libexec > Only in /mnt: lost+found > Only in /mnt: media > Only in /mnt: microsd_ufs > Only
Re: Odd diff -qr / /mnt "Only in " results
On 2020-Sep-21, at 16:16, Mark Millard wrote: > On 2020-Sep-21, at 13:38, Mark Millard wrote: > >> Context: head -r365932 (on a Rock64). But this could well not >> be new. >> >> First a look at the / context and then the /mnt/ : >> >> # ls -laT / >> total 225 >> drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 . >> drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. >> -rw-r--r-- 2 root wheel 1083 Jul 8 23:53:07 2020 .cshrc >> drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs >> -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile >> -rw--- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd >> drwxrwxr-x 2 root operator512 Aug 8 19:02:22 2020 .snap >> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >> drwxr-xr-x 2 root wheel 1024 Sep 21 01:56:39 2020 bin >> drwxr-xr-x 24 root wheel 1536 Sep 21 01:58:43 2020 boot >> dr-xr-xr-x 18 root wheel 512 Sep 21 02:20:24 2020 dev >> -rw--- 1 root wheel 4096 Sep 21 02:20:37 2020 entropy >> drwxr-xr-x 27 root wheel 2560 Sep 21 01:58:16 2020 etc >> drwxr-xr-x 5 root wheel 2048 Sep 21 01:56:39 2020 lib >> drwxr-xr-x 3 root wheel 512 Sep 21 01:56:38 2020 libexec >> drwx-- 2 root wheel 98816 Jul 24 21:28:53 2020 lost+found >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media >> drwxr-xr-x 6 root wheel 512 Sep 21 01:49:57 2020 microsd_ufs >> drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 mnt >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net >> dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc >> drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 rescue >> drwxr-xr-x 17 root wheel 2560 Mar 30 05:23:44 2020 root >> drwxr-xr-x 2 root wheel 2560 Sep 21 01:56:38 2020 sbin >> lrwxr-xr-x 1 root wheel11 May 1 19:22:54 2018 sys -> usr/src/sys >> drwxrwxrwt 59 root wheel 3584 Sep 21 04:16:21 2020 tmp >> drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 usb_efi >> drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr >> drwxr-xr-x 26 root wheel 512 Sep 21 02:20:36 2020 var >> drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs >> >> # ls -laT /mnt >> total 120 >> drwxr-xr-x 23 root wheel 512 Mar 30 05:23:44 2020 . >> drwxr-xr-x 24 root wheel 512 Sep 21 02:20:37 2020 .. >> -rw-r--r-- 2 root wheel 1083 Jul 16 16:41:10 2020 .cshrc >> drwxr-xr-x 2 root wheel 512 Jan 31 19:57:35 2017 .libs >> -rw-r--r-- 1 root wheel 1349 Sep 15 18:45:26 2019 .profile >> -rw--- 1 root wheel 1024 Dec 31 16:00:41 2009 .rnd >> drwxrwxr-x 2 root operator 512 Mar 14 19:02:19 2020 .snap >> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >> drwxr-xr-x 2 root wheel 1024 Sep 21 03:32:17 2020 bin >> drwxr-xr-x 13 root wheel 1024 Sep 21 03:32:17 2020 boot >> dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 dev >> -rw--- 1 root wheel 4096 Sep 13 14:02:57 2020 entropy >> drwxr-xr-x 27 root wheel 2560 Sep 21 03:36:49 2020 etc >> drwxr-xr-x 5 root wheel 2048 Sep 21 03:32:16 2020 lib >> drwxr-xr-x 3 root wheel 512 Sep 21 03:32:16 2020 libexec >> drwx-- 2 root wheel 512 Mar 17 16:16:42 2020 lost+found >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 media >> drwxr-xr-x 2 root wheel 512 Mar 17 16:16:08 2020 microsd_ufs >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 mnt >> drwxr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 net >> dr-xr-xr-x 2 root wheel 512 Mar 30 05:23:44 2020 proc >> drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:16 2020 rescue >> drwxr-x--- 18 root wheel 2048 Mar 30 05:23:44 2020 root >> drwxr-xr-x 2 root wheel 2560 Sep 21 03:32:13 2020 sbin >> lrwxr-xr-x 1 root wheel 11 May 1 19:22:54 2018 sys -> usr/src/sys >> drwxrwxrwt 60 root wheel 5120 Mar 30 05:23:44 2020 tmp >> drwxr-xr-x 16 root wheel 512 Mar 30 05:23:44 2020 usr >> drwxr-xr-x 26 root wheel 512 Mar 30 05:23:44 2020 var >> drwxr-xr-x 3 root wheel 512 Sep 18 13:04:15 2018 wrkdirs >> >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/gpt/Rock64root 195378 105474 7427359%/ >> devfs 0 0 0 100%/dev >> /dev/label/Rock64root 109101362 100010 0%/microsd_ufs >> /dev/msdosfs/RPI4EFIFS99 7 92 8%/usb_efi >> /dev/gpt/PINE642Groot 195378 76731 10301643%/mnt >> >> >> But when I do the "diff -qr / /mnt" I get the following "Only in " >> notices: >> >> Only in /mnt: .cshrc >> Only in /mnt: .libs >> Only in /mnt: .profile >> Only in /mnt: .rnd >> Only in /mnt: .snap >> Only in /mnt: COPYRIGHT >> Only in /mnt: bin >> Only in /mnt: boot >> Only in /mnt: dev >> Only in /mnt: entropy >> Onl
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
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. 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"
