Re: Linux 4.19 in Debian FTBFS with "undefined reference to `strcmp'"
On Thu, 20 Dec 2018, John Paul Adrian Glaubitz wrote: > Hi! > > On 12/20/18 12:16 AM, Finn Thain wrote: > > Andreas said the error happened when the new compiler expanded a > > __bultin_strcmp call to a strcmp call. > > https://lore.kernel.org/lkml/87in513wbt@igel.home/ > > > > The new compiler seems to assume that a strcmp symbol exists in the final > > link. I don't see how that kind of assumption is valid here. > > > > So I think the real bug is the lack of -ffreestanding. That omission > > allows the compiler to assume that libc is available in the final link. > > (At least, I imagine that's what the compiler authors had in mind.) > > Anyway, the use of -ffreestanding certainly avoids this optimization. > > Could someone whip up a patch so I can add it to the Debian package of > the kernel? > There are various patches to choose from. 1) As Andreas said, "strncmp doesn't make sense here." I agree, it's inefficient to use strncmp(a, b, strlen(a)) or strncmp([0], b, sizeof(a)) etc. We can find and fix these call sites as and when they break the build. I sent an incomplete patch to fix some of them -- https://lore.kernel.org/lkml/alpine.LNX.2.21.1807241423000.8@nippy.intranet/ 2) We can use -ffreestanding, to avoid risky optimizations involving libc. 3) As Arnd said, we can provide strcmp. That's what my #if 0 workaround did. I've not sent that upstream because a strcmp function (besides __builtin_strcmp) is not needed given either of the above solutions. Any or all of these approaches will avoid the link error. Option (1) seems to be approved by maintainers. So if you want a patch that can be sent upstream, that would be it. That solution might be a lot more maintainable if it took the form of a Coccinelle script that could be included in the kernel tree. Option (2) would involve a small Makefile patch, as below. diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 997c9f20ea0f..c318afd15e33 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -58,7 +58,7 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200) cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200) KBUILD_AFLAGS += $(cpuflags-y) -KBUILD_CFLAGS += $(cpuflags-y) -pipe +KBUILD_CFLAGS += $(cpuflags-y) ifdef CONFIG_MMU # without -fno-strength-reduce the 53c7xx.c driver fails ;-( KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2 @@ -69,6 +69,8 @@ KBUILD_CFLAGS += -D__uClinux__ KBUILD_AFLAGS += -D__uClinux__ endif +KBUILD_CFLAGS += -pipe -ffreestanding + KBUILD_LDFLAGS := -m m68kelf KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds This patch seems to work fine but may have implications for both 680x0 and Coldfire. It will make some optimizations unavailable but I haven't tried to measure that effect. It could be a hard sell if it harms performance. -- > Thanks, > Adrian > >
Re: [PATCH net-next] Amiga PCMCIA 100 MBit card support
From: ALeX Kazik Date: Wed, 19 Dec 2018 23:24:32 +0100 > + bool "PCMCIA NE2000 100MBit support" > + default n > + depends on ARM_ETHERH=n && AX88796=n && HYDRA=n && MAC8390=n > + depends on MCF8390=n && NE2000=n && NE2K_PCI=n && PCMCIA_AXNET=n > + depends on PCMCIA_PCNET=n && STNIC=n && ULTRA=n && WD80x3=n > + depends on XSURF100=n && ZORRO8390=n > + ---help--- Generally I'm not too happy with these changes, they are all very hackish. And in particular this huge complicated Kconfig construct is not maintainable at all. Sorry.
Re: ensure dma_alloc_coherent always returns zeroed memory
Btw, can you try wit the very latests dma-mapping-for-next tree which has a new fix from Thierry Reding that might be related.
Re: [git pull] m68k fixes for 4.20
The pull request you sent on Thu, 20 Dec 2018 16:16:47 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git > tags/m68k-for-v4.20-tag2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1d51b4b1d3f2db0d6d144175e31a84e472fbd99a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[git pull] m68k updates for 4.21
Hi Linus,
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
tags/m68k-for-v4.21-tag1
for you to fetch changes up to 005e13a96c0ed1437cb7f113d5d0f07ad9590962:
m68k: Generate uapi header and syscall table header files (2018-12-04
09:47:55 +0100)
m68k updates for v4.21
- Generate syscall headers,
- Small improvements and cleanups,
- Defconfig updates.
Thanks for pulling!
Bartlomiej Zolnierkiewicz (1):
m68k: Remove redundant 'default n' from Kconfig
Finn Thain (1):
m68k: Unroll raw_outsb() loop
Firoz Khan (3):
m68k: Add __NR_syscalls along with NR_syscalls
m68k: Add system call table generation support
m68k: Generate uapi header and syscall table header files
Geert Uytterhoeven (1):
m68k/defconfig: Update defconfigs for v4.20-rc1
arch/m68k/Kconfig.machine | 2 -
arch/m68k/Makefile | 3 +
arch/m68k/configs/amiga_defconfig | 103 +
arch/m68k/configs/apollo_defconfig | 93
arch/m68k/configs/atari_defconfig | 109 +
arch/m68k/configs/bvme6000_defconfig| 89
arch/m68k/configs/hp300_defconfig | 91
arch/m68k/configs/mac_defconfig | 93
arch/m68k/configs/multi_defconfig | 123 +-
arch/m68k/configs/mvme147_defconfig | 87 +++
arch/m68k/configs/mvme16x_defconfig | 89
arch/m68k/configs/q40_defconfig | 89
arch/m68k/configs/sun3_defconfig| 81 ---
arch/m68k/configs/sun3x_defconfig | 83 ---
arch/m68k/include/asm/Kbuild| 1 +
arch/m68k/include/asm/raw_io.h | 39 +++-
arch/m68k/include/asm/unistd.h | 3 +-
arch/m68k/include/uapi/asm/Kbuild | 1 +
arch/m68k/include/uapi/asm/unistd.h | 385 +--
arch/m68k/kernel/syscalls/Makefile | 38
arch/m68k/kernel/syscalls/syscall.tbl | 389
arch/m68k/kernel/syscalls/syscallhdr.sh | 36 +++
arch/m68k/kernel/syscalls/syscalltbl.sh | 32 +++
arch/m68k/kernel/syscalltable.S | 387 +--
24 files changed, 1161 insertions(+), 1285 deletions(-)
create mode 100644 arch/m68k/kernel/syscalls/Makefile
create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote: > > I would be really surprised if that is caused by the patch to add > > the zeroing. > Me too :) > > > Can you check which commit caused the issue by bisecting > > from a known good baseline? > > Yep. At least kernel build from v4.20-rc4 (which is base for your branch) > seems to work fine. Well, the branch has quite a few commits. Can you check the commit just before the zeroing to start, and if that is already broken (which I suspect) bisect the offending commit?
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, 2018-12-20 at 15:34 +0100, h...@lst.de wrote: > On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote: > > Hi Christoph, > > > > I test kernel from your 'dma-alloc-always-zero' branch, and as > > I can see we have DMA peripherals (like USB) broken. > > I would be really surprised if that is caused by the patch to add > the zeroing. Me too :) > Can you check which commit caused the issue by bisecting > from a known good baseline? Yep. At least kernel build from v4.20-rc4 (which is base for your branch) seems to work fine. -- Eugeniy Paltsev
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > I test kernel from your 'dma-alloc-always-zero' branch, and as > I can see we have DMA peripherals (like USB) broken. I would be really surprised if that is caused by the patch to add the zeroing. Can you check which commit caused the issue by bisecting from a known good baseline?
Re: ensure dma_alloc_coherent always returns zeroed memory
Hi Christoph, I test kernel from your 'dma-alloc-always-zero' branch, and as I can see we have DMA peripherals (like USB) broken. There are the errors example I got during USB initializing: -->8 usb 1-1: device descriptor read/64, error -110 usb usb1-port1: attempt power cycle usb 1-1: new high-speed USB device number 4 using ehci-platform usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -110 usb 1-1: new high-speed USB device number 5 using ehci-platform usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -110 usb usb1-port1: unable to enumerate USB device usb 2-1: new full-speed USB device number 2 using ohci-platform usb 2-1: device descriptor read/all, error -84 usb 2-1: new full-speed USB device number 3 using ohci-platform usb 2-1: device descriptor read/all, error -84 usb usb2-port1: attempt power cycle usb 2-1: new full-speed USB device number 4 using ohci-platform usb 2-1: device descriptor read/8, error -62 usb 2-1: device descriptor read/8, error -62 usb 2-1: new full-speed USB device number 5 using ohci-platform usb 2-1: device descriptor read/8, error -84 usb 2-1: device descriptor read/8, error -84 usb usb2-port1: unable to enumerate USB device [snip] --8< On Wed, 2018-12-19 at 17:59 +0100, Christoph Hellwig wrote: > FYI, I've picked this up for dma-mapping for-next now. > > ___ > linux-snps-arc mailing list > linux-snps-...@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=ZlJN > 1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=naBCT96A4RSQJLzBWzuCcmptFGiQDfFTOWJpprqDIVk=cHF84va89ofP6VlrV683ewENUXdaLW7opamLZSkZBgk= -- Eugeniy Paltsev
Re: Linux 4.19 in Debian FTBFS with "undefined reference to `strcmp'"
Hi! On 12/20/18 12:16 AM, Finn Thain wrote: > Andreas said the error happened when the new compiler expanded a > __bultin_strcmp call to a strcmp call. > https://lore.kernel.org/lkml/87in513wbt@igel.home/ > > The new compiler seems to assume that a strcmp symbol exists in the final > link. I don't see how that kind of assumption is valid here. > > So I think the real bug is the lack of -ffreestanding. That omission > allows the compiler to assume that libc is available in the final link. > (At least, I imagine that's what the compiler authors had in mind.) > Anyway, the use of -ffreestanding certainly avoids this optimization. Could someone whip up a patch so I can add it to the Debian package of the kernel? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
