On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun <melounmichal_at_gmail.com> wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li <jiashiun_at_gmail.com> wrote: >>>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers <asomers_at_freebsd.org> wrote: >>>> >>>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li <jiashiun_at_gmail.com> >>>>> wrote: >>>>>> >>>>>> amd64 and RPi3 do not have this issue. >>>>>> >>>>>> jsli_at_rpi2:/home/jsli 13:04 # uname -a >>>>>> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>>>> arm >>>>>> jsli_at_rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >>>>>> jsli_at_rpi2:/home/jsli 13:05 # cd /mnt >>>>>> jsli_at_rpi2:/mnt 13:05 # tar xf >>>>>> /usr/ports/distfiles/sqlite-autoconf-3260000.tar.gz >>>>>> jsli_at_rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-3260000/ >>>>>> rm: sqlite-autoconf-3260000/tea: Operation not permitted >>>>>> rm: sqlite-autoconf-3260000/: Directory not empty >>>>>> jsli_at_rpi2:/mnt 13:05 # >>>>>> >>>>>> -Jia-Shiun >>>>> >>>>> Did you check for file flags? Do "ls -lod >>>>> sqlite-autoconf-3260000/tea". >>>>> >>>>> >>>> Unlikely caused by flags I think. >>>> >>>> jsli_at_rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>>> jsli_at_rpi2:/home/jsli # cd /mnt >>>> jsli_at_rpi2:/mnt # ls -R >>>> jsli_at_rpi2:/mnt # mkdir dir >>>> jsli_at_rpi2:/mnt # ls -R >>>> dir/ >>>> ls: dir: directory causes a cycle >>>> jsli_at_rpi2:/mnt # >>>> >>>> >>>> looks inode no for directories are wrong >>>> >>>> jsli_at_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 wheel 0 Dec 7 09:55 dir/ >>>> jsli_at_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_at_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 _at__at_ -435,7 +435,7 _at__at_ 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"Received on Fri Dec 07 2018 - 09:21:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC