Dear distributor:
Glad to get your contact info from market!
We are Giant & Merida supplier.
We supply
l Mountain bike suspension forks
l Snow bike forks
l Electric bike suspension forks
with good quality and very competitive price. Hope to be a partner of
your company!
E-catalog will be provided if needed.
Email me or add Whatsapp. Thank you!
Best regards
Jason Cheng
Tel:+86-18322397759;
WhatsApp:+86 183 2239 7759;
WeChat:18322397759;
Tianjin Shengtai Weiye Metalware Co., Ltd.
I am Barr Luis Fernandez,i have something important to discuss
with you which might interest you and I believe that it will be a
very good opportunity for both of us.
Kindly get back to me for more details.
Regards,
Barr. Luis Fernandez
Madrid Spain.
Hello Vlastimil, recently kbuild-all test bot reported compile error on
clang 10.0.1, with defconfig.
Nathan Chancellor wrote:
> I think this happens because arch_prepare_optimized_kprobe() calls kzalloc()
> with a size of MAX_OPTINSN_SIZE, which is
>
> #define MAX_OPTINSN_SIZE \
> (((unsigned long)optprobe_template_end - \
> (unsigned long)optprobe_template_entry) + \
> MAX_OPTIMIZED_LENGTH + JMP32_INSN_SIZE)
> and the optprobe_template_{end,entry} are not evaluated as constants.
>
> I am not sure what the solution is. There seem to be a growing list of issues
> with LLVM 10 that were fixed in LLVM 11, which might necessitate requiring
> LLVM 11 and newer to build the kernel, given this affects a defconfig.
> Cheers,
> Nathan
I think it's because kmalloc compiles successfully when size is constant,
and kmalloc_index isn't. so I think compiler seems to be confused.
currently if size is non-constant, kmalloc calls dummy function __kmalloc,
which always returns NULL.
so what about changing kmalloc to do compile-time assertion too, and track
all callers that are calling kmalloc with non-constant argument.
How do you think? If you think it is the solution, I'll do that work.
On Mon, 3 May 2021 at 20:09, Chukun Pan <amadeus(a)jmu.edu.cn> wrote:
>
> The NanoPi R1S H5 is a open source board made by FriendlyElec.
> It has the following features:
>
> - Allwinner H5, Quad-core Cortex-A53
> - 512MB DDR3 RAM
> - 10/100/1000M Ethernet x 2
> - RTL8189ETV WiFi 802.11b/g/n
> - USB 2.0 host port (A)
> - MicroSD Slot
> - Serial Debug Port
> - 5V 2A DC power-supply
>
> Signed-off-by: Chukun Pan <amadeus(a)jmu.edu.cn>
Linux next tag next-20210511 arm64 build failed due to this error.
Error: /builds/linux/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-r1s-h5.dts:35.15-16
syntax error
FATAL ERROR: Unable to parse input tree
make[3]: *** [/builds/linux/scripts/Makefile.lib:365:
arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-r1s-h5.dtb] Error 1
make[3]: Target '__build' not remade because of errors.
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
#regzb introduced: 7c9dbeda744f ("arm64: dts: allwinner: h5: Add
NanoPi R1S H5 support")
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h5-nanopi-r1s-h5.dts | 194 ++++++++++++++++++
> 2 files changed, 195 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-r1s-h5.dts
steps to reproduce:
--------------------------
# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of
# architectures, toolchains, kernel configurations, and make targets.
#
# TuxMake supports the concept of runtimes.
# See https://docs.tuxmake.org/runtimes/, for that to work it requires
# that you install podman or docker on your system.
#
# To install tuxmake on your system globally:
# sudo pip3 install -U tuxmake
#
# See https://docs.tuxmake.org/ for complete documentation.
tuxmake --runtime podman --target-arch arm64 --toolchain gcc-9
--kconfig defconfig --kconfig-add
https://builds.tuxbuild.com/1sNFFZazb6TLzCYLxNoyIcWs0eU/config
metadata:
git branch: master
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git commit: 4bf27b1f73303c33c5570b63f8ed734abcd1991f
git describe: next-20210511
--
Linaro LKFT
https://lkft.linaro.org
My two cents,
We know clang-10 support is stopped, but our build system is still running
these builds with clang-10. one of those observations is,
The LKFT build failures were noticed while building x86_64 and i386 with
clang-10 on linux next-20210514 tag.
- x86_64 (defconfig) with clang-10 - FAIL
- i386 (defconfig) with clang-10 - FAIL
- x86_64 (defconfig) with clang-11 - PASS
- i386 (defconfig) with clang-11 - PASS
- x86_64 (defconfig) with clang-12 - PASS
- i386 (defconfig) with clang-12 - PASS
Build log:
----------
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=x86_64
CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
clang'
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_relocate_parse_slow()+0x427: stack state mismatch: cfa1=4+120
cfa2=-1+0
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
eb_copy_relocations()+0x1d5: stack state mismatch: cfa1=4+104
cfa2=-1+0
x86_64-linux-gnu-ld: arch/x86/kernel/kprobes/opt.o: in function
`arch_prepare_optimized_kprobe':
opt.c:(.text+0x798): undefined reference to `__compiletime_assert_251'
make[1]: *** [/builds/linux/Makefile:1272: vmlinux] Error 1
ref:
https://builds.tuxbuild.com/1sW0ag5finSjVuErrrzeunjj1nx/
--
Linaro LKFT
https://lkft.linaro.org