Re: CURRENT, usr/src on git, howto "mergemaster"?
On 04.01.2021 19:59, Steve Kargl wrote: On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote: On Jan 4, 2021, at 10:19, Warner Losh wrote: mergemaster has been on its way out since well before the switch to git. It's been disfavored for at least a decade and basically unmaintained in the base for maybe last 5 years. Apart from major breakage, only doc changes have happened in that time. Adding to this: it has no maintainer, it’s less featureful, and it lacks tests. Once I switched to etcupdate a few years back I never looked back at mergemaster. I honestly think it should be deprecated in 13.x and removed in 14.x. It’s been several major releases since it’s been unofficially deprecated. -Enji For something that has been disfavored for a decade, unmaintained for at least 5 years, and now seemly unofficially deprecated, it seems strange that /usr/src/UPDATING does not mention etcupdate in the COMMON ITEMS section. % svn info UPDATING | grep -i vision Revision: 367909 % svn blame UPDATING ... 64477 imp To rebuild everything and install it on the current system. 64477 imp --- ... 262619 jmg mergemaster -Fp [5] 262619 jmg mergemaster -Fi [4] % svn log -r 262619 r262619 | jmg | 2014-02-28 11:51:47 -0800 (Fri, 28 Feb 2014) | 3 lines since -F is safe, and an update from 10-HEAD to 10-STABLE is sooo bloody anoying w/o it.. recommend people use -F too... etcupdate first appeared in the tree on 2012-07-13 (r238423) Moreover mergemaster is still officially documented and recommend as only right method in FreeBSD handbook. See https://www.freebsd.org/doc/handbook/makeworld.html. World is moving, we may have new tools but each deprecation should be, in this order: 1) well announced 2) adjusted in the handbook 3) implemeted Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem compiling git from ports
On 01.01.2021 21:19, Filippo Moretti wrote: It worked thank youFilippo On Friday, January 1, 2021, 5:25:10 PM GMT+1, Milan Obuch wrote: On Fri, 1 Jan 2021 16:11:52 + (UTC), Filippo Moretti wrote: I run again portmaster and I have the same error as previously reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo Moretti wrote: Ufs It exits with a different error: ===> Installing contributed scripts /bin/mkdir -p /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib ln: /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash: File exists *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 Stop. make: stopped in /usr/ports/devel/git I remember seeing this too. I worked around that using options: cat /var/db/ports/devel_git/options # This file is auto-generated by 'make config'. # Options for git-2.29.2 _OPTIONS_READ=git-2.29.2 _FILE_COMPLETE_OPTIONS_LIST=CONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NLS P4 PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=CONTRIB OPTIONS_FILE_SET+=CURL OPTIONS_FILE_SET+=CVS OPTIONS_FILE_UNSET+=GITWEB OPTIONS_FILE_UNSET+=GUI OPTIONS_FILE_UNSET+=HTMLDOCS OPTIONS_FILE_SET+=ICONV OPTIONS_FILE_UNSET+=NLS OPTIONS_FILE_SET+=P4 OPTIONS_FILE_SET+=PERL OPTIONS_FILE_SET+=SEND_EMAIL OPTIONS_FILE_UNSET+=SUBTREE OPTIONS_FILE_UNSET+=SVN OPTIONS_FILE_SET+=PCRE OPTIONS_FILE_UNSET+=PCRE2 Regards, Milan This is not related to cache fast lookup, but it is dependency bug of ruby ports. My portmaster -ad session failed with the same issue. I noticed that rubby has been update from 2.6 to 2.7 as part of this sesion. # pkg which /usr/local/bin/asciidoctor /usr/local/bin/asciidoctor was installed by package rubygem-asciidoctor-2.0.10 # ls -l /usr/local/bin/asciidoctor -rwxr-xr-x 1 root wheel 560 Jun 7 2020 /usr/local/bin/asciidoctor # /usr/local/bin/asciidoctor /usr/local/bin/asciidoctor: Command not found # ls -l /usr/local/bin/asciidoctor -rwxr-xr-x 1 root wheel 560 Jun 7 2020 /usr/local/bin/asciidoctor root@tegra210:/usr/ports # more /usr/local/bin/asciidoctor #!/usr/local/bin/ruby26 # # This file was generated by RubyGems. # # The application 'asciidoctor' is installed as part of a gem, and # this file is here to facilitate running it. # ... # ls -l /usr/local/bin/ruby26 ls: /usr/local/bin/ruby26: No such file or directory # portmaster -d rubygem-asciidoctor-2.0.10 ... Installing ruby27-gems-3.0.8... pkg-static: ruby27-gems-3.0.8 conflicts with ruby26-gems-3.0.8 (installs files into the same place). Problematic file: /usr/local/bin/gem ... # pkg info | grep ruby26 ruby26-gems-3.0.8 Package management framework for the Ruby language # pkg delete -f ruby26-gems # portmaster -d rubygem-asciidoctor-2.0.10 # /usr/local/bin/asciidoctor Usage: asciidoctor [OPTION]... FILE... Michal ... ___ 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 fails ( stopped in /usr/src/lib/libsysdecode )
On 30.11.2020 13:11, Johan Hendriks wrote: On 30/11/2020 12:29, Hans Petter Selasky wrote: On 11/30/20 11:43 AM, Johan Hendriks wrote: My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182 I did a make cleanworld && make cleanworld to make sure i use a fresh build but it errors out with the following message. This is a known issue and will be fixed. --HPS Thank you for the conformation. And thank you all for your work on FreeBSD. regards Johan Fixed in r368187. Sorry for troubles. Michal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On 19.10.2020 22:39, Mark Johnston wrote:
> On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote:
>>
>>
>> On 06.10.2020 15:37, Mark Johnston wrote:
>>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote:
>>>> Still seeing non-current pmap panics on the Pi3, this time a B+ running
>>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master)
>>>> during a -j4 buildworld. The backtrace reports
>>>>
>>>> panic: non-current pmap 0xa00020eab8f0
>>>
>>> Could you show the output of "show procvm" from the debugger?
>>
>> I see same panic too, in my case its very rare - typical scenario is
>> rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug
>> this?
>> Michal
>
> I suspect that there is some race involving the pmap switching in
> vmspace_exit(), but I can't see it. In the example below, presumably
> process 22604 on CPU 0 is also exiting? Could you show the backtrace?>
> It would also be useful to see the value of PCPU_GET(curpmap) at the
> time of the panic. I'm not sure if there's a way to get that from DDB,
> but I suspect it should be equal to >vm_pmap.
Mark,
I think that I found problem.
The PCPU_GET() is not (and is not supposed to be) an atomic operation,
it expects that thread is at least pinned.
This is not true for pmap_remove_pages() - so I think that the KASSERT
is racy and shoud be removed (or at least covered by
sched_pin()/sched_unpin() pair).
What do you think?
>
> I think vmspace_exit() should issue a release fence with the cmpset and
> an acquire fence when handling the refcnt == 1 case,
Yep, true, fully agree.
Michal
but I don't see why
> that would make a difference here. So, if you can test a debug patch,
> this one will yield a bit more debug info. If you can provide access to
> a vmcore and kernel debug symbols, that'd be even better.
>
> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
> index 284f00b3cc0d..3c53ae3b4c1e 100644
> --- a/sys/arm64/arm64/pmap.c
> +++ b/sys/arm64/arm64/pmap.c
> @@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap)
> int allfree, field, freed, idx, lvl;
> vm_paddr_t pa;
>
> - KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap));
> + KASSERT(pmap == PCPU_GET(curpmap),
> + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
>
> lock = NULL;
>
> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
> index c20005ae64cf..0ad415e3b88c 100644
> --- a/sys/vm/vm_map.c
> +++ b/sys/vm/vm_map.c
> @@ -358,7 +358,10 @@ vmspace_exit(struct thread *td)
> p = td->td_proc;
> vm = p->p_vmspace;
> atomic_add_int(_refcnt, 1);
> - refcnt = vm->vm_refcnt;
> + refcnt = atomic_load_int(>vm_refcnt);
> +
> + KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap),
> + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap)));
> do {
> if (refcnt > 1 && p->p_vmspace != ) {
> /* Switch now since other proc might free vmspace */
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On 06.10.2020 15:37, Mark Johnston wrote: > On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: >> Still seeing non-current pmap panics on the Pi3, this time a B+ running >> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) >> during a -j4 buildworld. The backtrace reports >> >> panic: non-current pmap 0xa00020eab8f0 > > Could you show the output of "show procvm" from the debugger? I see same panic too, in my case its very rare - typical scenario is rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug this? Michal panic: non-current pmap 0xa00012e92a80 cpuid = 2 time = 1602831265 KDB: stack backtrace: db_trace_self() at db_fetch_ksymtab+0x148 pc = 0x005f655c lr = 0x00148804 sp = 0x6dc41200 fp = 0x6dc41400 db_fetch_ksymtab() at kdb_backtrace+0x38 pc = 0x00148804 lr = 0x0036d3c0 sp = 0x6dc41410 fp = 0x6dc414d0 kdb_backtrace() at vpanic+0x19c pc = 0x0036d3c0 lr = 0x0032b320 sp = 0x6dc414e0 fp = 0x6dc41530 vpanic() at panic+0x44 pc = 0x0032b320 lr = 0x0032af3c sp = 0x6dc41540 fp = 0x6dc415f0 panic() at pmap_remove_pages+0x5c0 pc = 0x0032af3c lr = 0x0060bf0c sp = 0x6dc41600 fp = 0x6dc41660 pmap_remove_pages() at vmspace_exit+0xb0 pc = 0x0060bf0c lr = 0x005b988c sp = 0x6dc41670 fp = 0x6dc416d0 vmspace_exit() at exit1+0x4fc pc = 0x005b988c lr = 0x002e3fcc sp = 0x6dc416e0 fp = 0x6dc41740 exit1() at sys_sys_exit+0x10 pc = 0x002e3fcc lr = 0x002e3acc sp = 0x6dc41750 fp = 0x6dc417a0 sys_sys_exit() at unhandled_exception+0x57c pc = 0x002e3acc lr = 0x0061258c sp = 0x6dc417b0 fp = 0x6dc417c0 unhandled_exception() at do_el0_sync+0x324 pc = 0x0061258c lr = 0x00611f64 sp = 0x6dc417d0 fp = 0x6dc41800 do_el0_sync() at do_el0_sync+0x128 pc = 0x00611f64 lr = 0x00611d68 sp = 0x6dc41810 fp = 0x6dc41830 do_el0_sync() at handle_el0_sync+0x90 pc = 0x00611d68 lr = 0x005f8a24 sp = 0x6dc41840 fp = 0x6dc41980 handle_el0_sync() at 0x407a5ed0 pc = 0x005f8a24 lr = 0x407a5ed0 sp = 0x6dc41990 fp = 0xbcb0 KDB: enter: panic [ thread pid 22603 tid 100099 ] Stopped at 0x4077df30: undefined 5442 db> show all pcpu Current CPU: 2 cpuid= 0 dynamic pcpu = 0x66c880 curthread= 0xa000b39eb000: pid 22604 tid 100139 critnest 1 "msgfmt" curpcb = 0x6dd09aa0 fpcurthread = 0xa000b39eb000: pid 22604 "msgfmt" idlethread = 0xa12ad5a0: tid 13 "idle: cpu0" spin locks held: cpuid= 1 dynamic pcpu = 0x45bfc880 curthread= 0xa000da4185a0: pid 22605 tid 101155 critnest 1 "cmake" curpcb = 0x6e02caa0 fpcurthread = 0xa000da4185a0: pid 22605 "cmake" idlethread = 0xa12ad000: tid 14 "idle: cpu1" spin locks held: cpuid= 2 dynamic pcpu = 0x45c00880 curthread= 0xa00012c4c000: pid 22603 tid 100099 critnest 1 "msgfmt" curpcb = 0x6dc41aa0 fpcurthread = 0xa00012c4c5a0: pid 22307 "cmake" idlethread = 0xa12aa5a0: tid 15 "idle: cpu2" spin locks held: cpuid= 3 dynamic pcpu = 0x45c04880 curthread= 0xa788d5a0: pid 7 tid 100039 critnest 1 "doneq0" curpcb = 0x40372aa0 fpcurthread = 0xa00012c4c000: pid 22603 "msgfmt" idlethread = 0xa12aa000: tid 16 "idle: cpu3" spin locks held: db> show procvm p = 0xa00012e5d000, vmspace = 0xa00012e92960, map = 0xa00012e92960, pmap = 0xa00012e92a80 Task map 0xa00012e92960: pmap=0xa00012e92a80, nentries=88, version=170 map entry 0xa0002353b6c0: start=0x20, end=0x208000, eflags=0xc0c, prot=1/7/copy, object=0xa000ba1cec60, offset=0x0, copy (needed) Object 0xa000ba1cec60: type=2, size=0x13, res=19, ref=4, flags=0x1000 ruid -1 charge 0 sref=0, backing_object(0)=(0)+0x0 map entry 0xa000457c3180: start=0x217000, end=0x222000, eflags=0xc0c, prot=5/7/copy, object=0xa000ba1cec60, offset=0x7000, copy (needed) map entry 0xa000b3caa600: start=0x231000, end=0x232000, eflags=0, prot=1/7/copy, object=0xa0004b376c60, offset=0x0, obj ruid 0 charge 1000 Object 0xa0004b376c60: type=0, size=0x1, res=1, ref=1, flags=0x3010 ruid 0 charge 1000 sref=0, backing_object(0)=(0)+0x0 map entry 0xa000b3ce5720: start=0x241000, end=0x243000, eflags=0, prot=3/7/copy, object=0xa000b3a9a528, offset=0x0, obj ruid 0 charge 2000
Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect)
On 12.07.2020 8:37, Mark Millard via freebsd-arm wrote: > > >> On 2020-Jul-11, at 15:12, Mark Millard wrote: >> >> >>> >>> On 2020-Jul-11, at 14:45, Robert Crowston wrote: >>> >>> So what is the mistake I made here? >>> >>> Should I have given a globally unique name as the first argument to >>> DRIVER_MODULE()? I didn't see that in the man page, and other examples of >>> pcib drivers apparently get away with it. >>> >>> I did notice the weird message about "driver already loaded from kernel". I >>> wondered if that meant I was dragging in code to the core kernel, that >>> would otherwise live in an external module? >>> >>> Let me know how I can help fix it! >>> >>> -- RHC. >> >> It is not an area of expertise for me. I've spent hours just >> getting to the point of sending the notes that I have sent. >> > > Having found no evidence of any likely disaster from trying > the experiment, I've tried: > > # svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > === > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision 363021) > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) > @@ -739,5 +739,5 @@ > sizeof(struct bcm_pcib_softc), generic_pcie_fdt_driver); > > static devclass_t bcm_pcib_devclass; > -DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > +DRIVER_MODULE(bcm_pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > > > This was enough of a change for Ethernet and USB to become available > again on the OverDrive 1000. > > Apparently one must search all existing DRIVER_MODULE use and then > pick naming to have the new DRIVER_MODULE(NAME,BUSNAME,... end up > with the NAME,BUSNAME as a unique combination of names (or > combinations for when there is BUSNAME0, BUSNAME1, . . .). > > I also updated the USB3 SSD I use for booting either RPi4 > or Rock64. Be warned that the RPi4 boots are via > UEFI v1.16 use instead of by sysutils/u-boot-rpi4 use. > I do not have things set up for sysutils/u-boot-rpi4 as > stands. > > The SSD booted both contexts fine and the USB worked like > normal. On the Rock64, the built-in EtherNet also worked > fine. For the RPi4, a USB3 EtherNet adapter is used and > it worked fine. > > If someone checks sysutils/u-boot-rpi4 operation and finds > that it works, then I expect that such a patch as above is > all that is required. > > Note: If future bcmD's need similar code, care will > need to be taken naming in DRIVER_MODULE(,... > for them so that uniqueness is maintained. My use of > "bcm_" to match the context is not the only prefix that > would lead to unique naming currently. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Fixed in r363121. Thanks for the report. Michal Meloun ___ 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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 29.12.2018 18:47, Dennis Clarke wrote:
> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>
>> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>>
>>> On 2018-Dec-28, at 05:13, Michal Meloun
>>> wrote:
>>>
>>>> Mark,
>>>> this is known problem with qemu-user-static.
>>>> Emulation of every single interruptible syscall is broken by design (it
>>>> have signal related races). Theses races cannot be solved without major
>>>> rewrite of syscall emulation code.
>>>> Unfortunately, nobody actively works on this, I think.
>>>>
>
> Following along here quietly and I had to blink at this a few times.
> Is there a bug report somewhere within the qemu world related to this
> 'broken by design' qemu feature?
Firstly, I apologize for late answer. Writing a technically accurate but
still comprehensible report is extremely difficult for me.
Major design issue with qemu-user is the fact that guest (blocking /
interruptible) syscalls must be emulated atomically, including
delivering of asynchronous signals (including signals originated by
other thread).
This is something that cannot be emulated precisely by user mode
program, without specific kernel support. Let me explain this in a
little more details.
Assume that we have following trivial code:
void sig_alarm_handler(…)
{
if (!done) {
do some work;
alarm(10);
}
}
void foo(void)
{
install_signal_handler(SIGALARM, sig_alarm_handler);
alarm(10);
do some work;
while (true) {
rv = select(…, NULL);
if (rv == 0)
do some work;
else if (rv != EINTR)
Report error end exit;
}
}
In native environment, this code works well. It calls alarm signal
handler every 10s, irrespective if signal is fired in the program code
or in libc implementation of select() or if program is waiting in kernel
part of select() syscall.
In qemu-user environment, things get significantly harder. Qemu can
deliver signals to guest only on instruction boundary, the guest signal
handler should see emulated CPU context in consistent state. But kernel
can deliver signal to qemu in any time. Due to this, qemu must store
delivered signals into queue and emit these later, when emulator steps
over next instruction boundary.
Assume that qemu just emulates 'syscall' instruction from guest select()
call. Also assume that no other signals (but SIGALARM) are generated,
and socket used in select() never received or transmits any data.
The first version of qemu-user code emulating select() was:
abi_long do_freebsd_select(..)
{
convert input guest arguments to host;
rv = select(…);
convert output host arguments to guest;
return(rv);
}
But this is very racy. If alarm signal is fired before select(…) enters
kernel, qemu queues it (but does not deliver it to guest because it
isn't on instruction boundary) and continues in emulation. And because
(in our case) select() waits indefinitely, alarm signal is never
delivered to guest and whole program hangs.
Actual qemu code emulating select() looks like:
abi_long do_freebsd_select(..)
{
convert input guest arguments to host;
sigfillset();
sigprocmask(SIG_BLOCK, , );
if (ts->signal_pending) {
sigprocmask(SIG_SETMASK, , NULL);
/* We have a signal pending so just poll select() and return. */
tv2.tv_sec = tv2.tv_usec = 0;
ret = select(…, , ));
if (ret == 0)
ret = TARGET_EINTR;
} else {
ret = pselect(…, ));
sigprocmask(SIG_SETMASK, , NULL);
}
convert output host arguments to guest;
return(rv);
}
This look a much better. The code blocks all signals first, then checks
if any signal is pending. If yes, then does not-blocking select()
(because timeout is zero) and correctly returns EINTR immediately.
Otherwise, it uses other variant of select(), pselect() which adjusts
right signal mask itself.
That's mean that syscall is called with blocked signal delivery, but
kernel adjusts right sigmask before it waits for event. While this looks
like perfect solution and this code closes all races from first version,
then it doesn't. pselect() uses different semantic that select(), it
doesn't update timeout argument. So this solution is also inappropriate.
Moreover, I think, we don't have p equivalents for all blocking
syscalls.
Mark, I hope that this is also the answer to your question posted to
hackers@ and also the exploitation why you see hang.
Linux uses different approach to overcome this issue, safe_syscall ->
https://gitlab.collabora.com/tomeu/qemu/commit/4d330cee37a21aabfc619a1948953559e66951a4
It looks like workable workaround, but I'm not sure about ERESTART
versus EINTR return values. Imho, this can be problem.
I have list of other qemu-user problems (I mean mainly a bsd-user part
of qemu code here), not counting normal coding bugs:
- code is not thread safety but is used in threaded environment (rw
locks for example),
- em
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
>
> On 2018-Dec-22, at 12:55, Mark Millard wrote:
>
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head -r484783 under FreeBSD
>> head -r340287.]
>>
>> On 2018-Dec-22, at 00:10, Mark Millard wrote:
>>
>>> [I messed up the freebsd-emulation email address the first time I sent
>>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>>
>>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7}
>>> port cross
>>> builds in another message sequence. But it turns out that one thing I ran
>>> into
>>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a
>>> separate report
>>> with some updated notes.
>>>
>>> A little context: I had built from ports head -r484783 before under FreeBSD
>>> head
>>> -r340287 (as I remember the version). Back then it did not have this
>>> problem that it
>>> now has under FreeBSD head -r341836 . One ports-specific change was to
>>> force perl5.28
>>> as the default instead of perl5.26 originally. In fact this is what drives
>>> what is
>>> being rebuilt for my experiment that caught this. But I doubt the perl
>>> version is
>>> important to the problem. The context has a Ryzen Threadripper 1950X and
>>> has been
>>> tested both for FreeBSD under Hyper-V and for the same media native-booted.
>>> Both
>>> hang-up at the same point as seen via ps or top. The native tools for
>>> cross-build
>>> speedup were in use. Cross-builds targeting aarch64 did not get this
>>> problem but
>>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for
>>> the first
>>> armv7 try.
>>>
>>> ADDED: The qemu-user-static back with head -r340287 before installing the
>>> updated ports would likely be different than the -r484783 vintage. So both
>>> FreeBSD and qemu-user-static may have changed over the comparison.
>>
>> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
>> based on qemu-user-static from ports head -484783 --all built under FreeBSD
>> head -r340287 . So the use of the perl5.28 as the forced-default and the
>> newer FreeBSD head version -r341836 as the context are the differences here.
>>
>>> The hang-up:
>>>
>>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up
>>> and timed
>>> out. Looking during the wait in later tries shows something much like (from
>>> one of the
>>> examples):
>>>
>>> root 337190.0 0.0 12920 3528 0 I11:40 0:00.03 | |
>>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415510.0 0.0 12920 3520 0 I11:43 0:00.00 | |
>>>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415520.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | |
>>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt
>>> FLAVOR=qt5 build
>>> root 415660.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | |
>>>`-- /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELE
>>> root 415670.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | |
>>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> root 415850.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | |
>>>|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>> root 415860.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | |
>>>`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>>
>>> or as top showed it:
>>>
>>> 41552 root 1 52010M 1744K0 wait15 0:00 0.00%
>>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>>> 41566 root 1 52010M 1796K0 wait 1 0:00 0.00%
>>> /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>>> 41567 root 2 52088M13M0 select 4 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>>
>>> So:
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
>
> On 2018-Dec-22, at 12:55, Mark Millard wrote:
>
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head -r484783 under FreeBSD
>> head -r340287.]
>>
>> On 2018-Dec-22, at 00:10, Mark Millard wrote:
>>
>>> [I messed up the freebsd-emulation email address the first time I sent
>>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>>
>>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7}
>>> port cross
>>> builds in another message sequence. But it turns out that one thing I ran
>>> into
>>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a
>>> separate report
>>> with some updated notes.
>>>
>>> A little context: I had built from ports head -r484783 before under FreeBSD
>>> head
>>> -r340287 (as I remember the version). Back then it did not have this
>>> problem that it
>>> now has under FreeBSD head -r341836 . One ports-specific change was to
>>> force perl5.28
>>> as the default instead of perl5.26 originally. In fact this is what drives
>>> what is
>>> being rebuilt for my experiment that caught this. But I doubt the perl
>>> version is
>>> important to the problem. The context has a Ryzen Threadripper 1950X and
>>> has been
>>> tested both for FreeBSD under Hyper-V and for the same media native-booted.
>>> Both
>>> hang-up at the same point as seen via ps or top. The native tools for
>>> cross-build
>>> speedup were in use. Cross-builds targeting aarch64 did not get this
>>> problem but
>>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for
>>> the first
>>> armv7 try.
>>>
>>> ADDED: The qemu-user-static back with head -r340287 before installing the
>>> updated ports would likely be different than the -r484783 vintage. So both
>>> FreeBSD and qemu-user-static may have changed over the comparison.
>>
>> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
>> based on qemu-user-static from ports head -484783 --all built under FreeBSD
>> head -r340287 . So the use of the perl5.28 as the forced-default and the
>> newer FreeBSD head version -r341836 as the context are the differences here.
>>
>>> The hang-up:
>>>
>>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up
>>> and timed
>>> out. Looking during the wait in later tries shows something much like (from
>>> one of the
>>> examples):
>>>
>>> root 337190.0 0.0 12920 3528 0 I11:40 0:00.03 | |
>>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415510.0 0.0 12920 3520 0 I11:43 0:00.00 | |
>>>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415520.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | |
>>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt
>>> FLAVOR=qt5 build
>>> root 415660.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | |
>>>`-- /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELE
>>> root 415670.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | |
>>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> root 415850.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | |
>>>|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>> root 415860.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | |
>>>`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>>
>>> or as top showed it:
>>>
>>> 41552 root 1 52010M 1744K0 wait15 0:00 0.00%
>>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>>> 41566 root 1 52010M 1796K0 wait 1 0:00 0.00%
>>> /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>>> 41567 root 2 52088M13M0 select 4 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>>
>>> So:
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
On 27.12.2018 14:07, Gary Jennejohn wrote:
> On Thu, 27 Dec 2018 03:58:51 -0800
> Enji Cooper wrote:
>
>>> On Dec 27, 2018, at 2:17 AM, Trev wrote:
>>>
>>> Graham Perrin wrote on 26/12/2018 21:20:
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Wed Dec 26 10:18:52 GMT 2018
FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG
grahamperrin@momh167-gjp4-8570p:~ % iridium
ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser
www/iridium 2018.5.67_6 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %
Any ideas?
TIA
>>>
>>> Same problem with a freshly compiled (after 5 days, finished yesterday)
>>> www/chromium on RPi3.
>>>
>>> $ chrome
>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>
>>> $ uname -a
>>> FreeBSD rpi3.sentry.org 13.0-CURRENT FreeBSD 13.0-CURRENT r342189 RPI3
>>> arm64
>>
>> Hmm___ is something wonky with recent changes to rtld-elf that might be
>> impacting ARM64?
>>
>> CCing mmel@, because they might be interested in these bug reports.
>>
>
> No. I saw this with mplayer and also iridium when I installed them
> with pkg on AMD64.
>
>
> Strangely enough, mpv works, even though it shows a dependency on
> libglib-2.0.so.0 when I run ldd on it.
>
> glib-2 has "extern char **environ;" in one of its C-files.
>
I cannot talk about iridium (its i386/amd64 only and I don't want to
infect my headless build box with tons of X11 libraries).
But for multimedia/mplayer, I can say that this problem is caused by
mplayer itself.
The 'environ' is defined as global symbol in /usr/lib/crt1.o:
>readelf -s /usr/lib/crt1.o | grep environ
46: 0008 8 OBJECT GLOBAL DEFAULT COM environ
These startup objects (/usr/lib/crt*.o) are linked to each single
executable (but not to shared libraries). That means that any
dynamically linked executable exports 'environ' symbol (and many, many
others) with globally visibility.
>readelf -s /bin/ls | grep environ
78: 0024 8 OBJECT GLOBAL DEFAULT 22 environ
Because these symbols are globally visible, glib20 (and/or other
libraries) can use them.
Unfortunately, when mplayer binary gets linked, makefile uses symbol
version script '-Wl,--version-script,binary.ver' as part of link
command. And this script explicitly lowers visibility of *all* symbols
(but _IO_stdin_used) to local.
>more binary.ver
MPLAYER_1 {
# to support glibcs abhorrent backwards-compatibility hack
global: _IO_stdin_used;
local: *;
};
>readelf -s mplayer | grep environ
26: 0050 8 OBJECT LOCAL DEFAULT 24 environ
Of course, local symbols are visible only within originating object,
these are invisible for other objects.
I have no idea why mplayer authors uses this script, mainly why version
script is used for *main executable*.
>From my point of view, it's nothing but pure nonsense. This script hides
symbols provided by startup object files so resulting binary is (and
must be) invalid.
I hope that this short description is enough for maintainer to fix these.
Michal
___
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: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li wrote: >>>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>>> >>>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>>> wrote: >>>>>> >>>>>> amd64 and RPi3 do not have this issue. >>>>>> >>>>>> jsli@rpi2:/home/jsli 13:04 # uname -a >>>>>> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>>>> arm >>>>>> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >>>>>> jsli@rpi2:/home/jsli 13:05 # cd /mnt >>>>>> jsli@rpi2:/mnt 13:05 # tar xf >>>>>> /usr/ports/distfiles/sqlite-autoconf-326.tar.gz >>>>>> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ >>>>>> rm: sqlite-autoconf-326/tea: Operation not permitted >>>>>> rm: sqlite-autoconf-326/: Directory not empty >>>>>> jsli@rpi2:/mnt 13:05 # >>>>>> >>>>>> -Jia-Shiun >>>>> >>>>> Did you check for file flags? Do "ls -lod >>>>> sqlite-autoconf-326/tea". >>>>> >>>>> >>>> Unlikely caused by flags I think. >>>> >>>> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>>> jsli@rpi2:/home/jsli # cd /mnt >>>> jsli@rpi2:/mnt # ls -R >>>> jsli@rpi2:/mnt # mkdir dir >>>> jsli@rpi2:/mnt # ls -R >>>> dir/ >>>> ls: dir: directory causes a cycle >>>> jsli@rpi2:/mnt # >>>> >>>> >>>> looks inode no for directories are wrong >>>> >>>> jsli@rpi2:/mnt # ll -ia >>>> total 4 >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >>>> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >>>> jsli@rpi2:/mnt # ll -ia dir >>>> total 0 >>>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >>>> jsli@rpi2:/mnt # >>>> >>> >>> Ouch. >>> >>> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >>> >>> While they should be fixed, I have been meaning to commit the following >>> which will have a side effect of taking care of the bug you ran into: >>> >> >> Mateusz, >> where you see problem with 64-bit atomic on arm? I'm not aware of any >> problem in this area. > > inode allocation for tmpfs (and other places) was recently changed to use > 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 > failing to bump the number on 32-bit arm (at least for the variant used > by whatever is put on rpi2) looks like a decent explanation. The code > definitely works on amd64. > Fixed in r341679. Thanks for report. ___ 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: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li wrote: >>>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>>> >>>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>>> wrote: >>>>>> >>>>>> amd64 and RPi3 do not have this issue. >>>>>> >>>>>> jsli@rpi2:/home/jsli 13:04 # uname -a >>>>>> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>>>> arm >>>>>> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >>>>>> jsli@rpi2:/home/jsli 13:05 # cd /mnt >>>>>> jsli@rpi2:/mnt 13:05 # tar xf >>>>>> /usr/ports/distfiles/sqlite-autoconf-326.tar.gz >>>>>> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ >>>>>> rm: sqlite-autoconf-326/tea: Operation not permitted >>>>>> rm: sqlite-autoconf-326/: Directory not empty >>>>>> jsli@rpi2:/mnt 13:05 # >>>>>> >>>>>> -Jia-Shiun >>>>> >>>>> Did you check for file flags? Do "ls -lod >>>>> sqlite-autoconf-326/tea". >>>>> >>>>> >>>> Unlikely caused by flags I think. >>>> >>>> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>>> jsli@rpi2:/home/jsli # cd /mnt >>>> jsli@rpi2:/mnt # ls -R >>>> jsli@rpi2:/mnt # mkdir dir >>>> jsli@rpi2:/mnt # ls -R >>>> dir/ >>>> ls: dir: directory causes a cycle >>>> jsli@rpi2:/mnt # >>>> >>>> >>>> looks inode no for directories are wrong >>>> >>>> jsli@rpi2:/mnt # ll -ia >>>> total 4 >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >>>> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >>>> jsli@rpi2:/mnt # ll -ia dir >>>> total 0 >>>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >>>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >>>> jsli@rpi2:/mnt # >>>> >>> >>> Ouch. >>> >>> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >>> >>> While they should be fixed, I have been meaning to commit the following >>> which will have a side effect of taking care of the bug you ran into: >>> >> >> Mateusz, >> where you see problem with 64-bit atomic on arm? I'm not aware of any >> problem in this area. > > inode allocation for tmpfs (and other places) was recently changed to use > 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 > failing to bump the number on 32-bit arm (at least for the variant used > by whatever is put on rpi2) looks like a decent explanation. The code > definitely works on amd64. > Ahh, right. atomic_fetchadd_64() is clearly broken. Give me a few minutes for fix and test. -- diff --git a/sys/arm/include/atomic-v6.h b/sys/arm/include/atomic-v6.h index 8f63554c701..40d2b94f4cf 100644 --- a/sys/arm/include/atomic-v6.h +++ b/sys/arm/include/atomic-v6.h @@ -435,7 +435,7 @@ atomic_fetchadd_64(volatile uint64_t *p, uint64_t val) __asm __volatile( "1: \n" - " ldrexd %Q[tmp], %R[tmp], [%[ptr]] \n" + " ldrexd %Q[ret], %R[ret], [%[ptr]] \n" " adds%Q[tmp], %Q[ret], %Q[val] \n" " adc %R[tmp], %R[ret], %R[val] \n" " strexd %[exf], %Q[tmp], %R[tmp], [%[ptr]] \n" ___ 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: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 7:25, Mateusz Guzik wrote: > On 12/7/18, Jia-Shiun Li wrote: >> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >> >>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li wrote: amd64 and RPi3 do not have this issue. jsli@rpi2:/home/jsli 13:04 # uname -a FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>> arm jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli 13:05 # cd /mnt jsli@rpi2:/mnt 13:05 # tar xf /usr/ports/distfiles/sqlite-autoconf-326.tar.gz jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ rm: sqlite-autoconf-326/tea: Operation not permitted rm: sqlite-autoconf-326/: Directory not empty jsli@rpi2:/mnt 13:05 # -Jia-Shiun >>> >>> Did you check for file flags? Do "ls -lod sqlite-autoconf-326/tea". >>> >>> >> Unlikely caused by flags I think. >> >> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >> jsli@rpi2:/home/jsli # cd /mnt >> jsli@rpi2:/mnt # ls -R >> jsli@rpi2:/mnt # mkdir dir >> jsli@rpi2:/mnt # ls -R >> dir/ >> ls: dir: directory causes a cycle >> jsli@rpi2:/mnt # >> >> >> looks inode no for directories are wrong >> >> jsli@rpi2:/mnt # ll -ia >> total 4 >> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >> jsli@rpi2:/mnt # ll -ia dir >> total 0 >> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >> jsli@rpi2:/mnt # >> > > Ouch. > > Looks like 64-bit atomic on 32-bit arm don't work as advertised. > > While they should be fixed, I have been meaning to commit the following > which will have a side effect of taking care of the bug you ran into: > Mateusz, where you see problem with 64-bit atomic on arm? I'm not aware of any problem in this 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"
