Bug#868066: marked as done (linux-image-4.11.0-1-amd64: Error! Bad return status for module build on kernel (virtualbox 5.1.10 error: too few arguments))
Your message dated Wed, 12 Jul 2017 07:48:00 +0200 with message-idand subject line linux-image-4.11.0-1-amd64: Error! Bad return status for module build on kernel (virtualbox 5.1.10 error: too few arguments) has caused the Debian Bug report #868066, regarding linux-image-4.11.0-1-amd64: Error! Bad return status for module build on kernel (virtualbox 5.1.10 error: too few arguments) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 868066: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868066 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 4.11.6-1 Severity: normal Dear Maintainer, I upgraded my Buster system and I get the following error: ---8<-8<-8<-8<-8<-8<-8<-8<-8<-- Configurazione di linux-headers-4.11.0-1-amd64 (4.11.6-1)... /etc/kernel/header_postinst.d/dkms: Error! Bad return status for module build on kernel: 4.11.0-1-amd64 (x86_64) Consult /var/lib/dkms/virtualbox/5.1.10/build/make.log for more information. Error! Bad return status for module build on kernel: 4.11.0-1-amd64 (x86_64) Consult /var/lib/dkms/virtualbox-guest/5.1.10/build/make.log for more information. ---8<-8<-8<-8<-8<-8<-8<-8<-8<-- I have see that there is a patch: https://www.virtualbox.org/ticket/16576 $ cat /var/lib/dkms/virtualbox/5.1.10/build/make.log DKMS make.log for virtualbox-5.1.10 for kernel 4.11.0-1-amd64 (x86_64) mar 11 lug 2017, 20.00.13, CEST make: ingresso nella directory "/usr/src/linux-headers-4.11.0-1-amd64" LD /var/lib/dkms/virtualbox/5.1.10/build/built-in.o LD /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/built-in.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/linux/SUPDrv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrvGip.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrvSem.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrvTracer.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPLibAll.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/alloc-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/initterm-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/memobj-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/mpnotification-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/powernotification-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeLockUser’: /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1067:18: error: too few arguments to function ‘get_user_pages_remote’ rc = get_user_pages_remote( ^ In file included from /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/the-linux-kernel.h:98:0, from /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:31: /usr/src/linux-headers-4.11.0-1-common/include/linux/mm.h:1326:6: note: declared here long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm, ^ /usr/src/linux-headers-4.11.0-1-common/scripts/Makefile.build:299: set di istruzioni per l'obiettivo "/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o" non riuscito make[4]: *** [/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o] Errore 1 make[4]: *** Attesa per i processi non terminati /usr/src/linux-headers-4.11.0-1-common/scripts/Makefile.build:558: set di istruzioni per l'obiettivo "/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv" non riuscito make[3]: *** [/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv] Errore 2 /usr/src/linux-headers-4.11.0-1-common/Makefile:1509: set di istruzioni per l'obiettivo "_module_/var/lib/dkms/virtualbox/5.1.10/build" non riuscito
Bug#868082: linux-image-4.11.0-1-686: fails to boot on i386 (Soekris net5501)
Package: src:linux Version: 4.11.6-1 Severity: important Hello, after upgrading an i386 box (Soekris net5501) running testing (buster), I found out that the newly migrated Linux kernel fails to boot. Looking at the boot through the serial console reveals the following few messages: Booting 'Debian GNU/Linux, with Linux 4.11.0-1-686' Loading Linux 4.11.0-1-686 ... Loading initial ramdisk ... and then nothing else. The previous kernel image (4.9.0-3-686) works fine. I have currently altered GRUB_DEFAULT in /etc/default/grub, in order to force the machine to automatically boot that kernel version. I hope that this bug may be fixed soon. Thanks to the Debian Kernel Team for any help they may provide. -- Package-specific info: ** Model information ** PCI devices: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] (rev 33) Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: via-rhine Kernel modules: via_rhine 00:07.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: via-rhine Kernel modules: via_rhine 00:08.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: via-rhine Kernel modules: via_rhine 00:09.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) Subsystem: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:0106] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: via-rhine Kernel modules: via_rhine 00:14.0 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] ISA [1022:2090] (rev 03) Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] ISA [1022:2090] Control: I/O+ Mem- BusMaster- SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ii grub-pc 1.99-17 pn linux-doc-4.11 Versions of packages linux-image-4.11.0-1-686 is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#867677: initramfs-tools: [patch] feature request: provide hook to set host name in InitRAMFS config dynamically
And if you remove the extension .sh, then it is also backwards compatible with Debian 4.0 "Etch" :) # Define your network setup for the InitRAMFS via IP variable # # Still a kernel ip parameter will override any InitRAMFS config # setting (see script /usr/share/initramfs-tools/init). # # Additional information: # * https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt # In Debian as kernel command via /etc/default/grub # * The "variable" ${hostname} (case-sensitive) will be replaced on InitRAMFS creation # with the current host name through the hook `set_hostname_in_network_config` # This allows the machine to be registered with its name in DNS. IP=${hostname} #!/bin/sh # # This InitRAMFS hook provides: # Simple script to set IP parameter in InitRAMFS config with current # hostname, instead of manually maintaining InitRAMFS config. PREREQ="" prereqs() { echo "${PREREQ}" } case "${1}" in prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions # # Begin real processing # [ ! -f "${DESTDIR}/conf/initramfs.conf" ] || sed -i -e "s#\${hostname}#$(hostname)#" "${DESTDIR}/conf/initramfs.conf" [ ! -f "${DESTDIR}/conf/conf.d/network" ] || sed -i -e "s#\${hostname}#$(hostname)#" "${DESTDIR}/conf/conf.d/network"
Bug#868066: linux-image-4.11.0-1-amd64: Error! Bad return status for module build on kernel (virtualbox 5.1.10 error: too few arguments)
Package: src:linux Version: 4.11.6-1 Severity: normal Dear Maintainer, I upgraded my Buster system and I get the following error: ---8<-8<-8<-8<-8<-8<-8<-8<-8<-- Configurazione di linux-headers-4.11.0-1-amd64 (4.11.6-1)... /etc/kernel/header_postinst.d/dkms: Error! Bad return status for module build on kernel: 4.11.0-1-amd64 (x86_64) Consult /var/lib/dkms/virtualbox/5.1.10/build/make.log for more information. Error! Bad return status for module build on kernel: 4.11.0-1-amd64 (x86_64) Consult /var/lib/dkms/virtualbox-guest/5.1.10/build/make.log for more information. ---8<-8<-8<-8<-8<-8<-8<-8<-8<-- I have see that there is a patch: https://www.virtualbox.org/ticket/16576 $ cat /var/lib/dkms/virtualbox/5.1.10/build/make.log DKMS make.log for virtualbox-5.1.10 for kernel 4.11.0-1-amd64 (x86_64) mar 11 lug 2017, 20.00.13, CEST make: ingresso nella directory "/usr/src/linux-headers-4.11.0-1-amd64" LD /var/lib/dkms/virtualbox/5.1.10/build/built-in.o LD /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/built-in.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/linux/SUPDrv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrvGip.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrvSem.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPDrvTracer.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/SUPLibAll.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/alloc-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/initterm-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/memobj-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/mpnotification-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/powernotification-r0drv.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o CC [M] /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeLockUser’: /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1067:18: error: too few arguments to function ‘get_user_pages_remote’ rc = get_user_pages_remote( ^ In file included from /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/the-linux-kernel.h:98:0, from /var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:31: /usr/src/linux-headers-4.11.0-1-common/include/linux/mm.h:1326:6: note: declared here long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm, ^ /usr/src/linux-headers-4.11.0-1-common/scripts/Makefile.build:299: set di istruzioni per l'obiettivo "/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o" non riuscito make[4]: *** [/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o] Errore 1 make[4]: *** Attesa per i processi non terminati /usr/src/linux-headers-4.11.0-1-common/scripts/Makefile.build:558: set di istruzioni per l'obiettivo "/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv" non riuscito make[3]: *** [/var/lib/dkms/virtualbox/5.1.10/build/vboxdrv] Errore 2 /usr/src/linux-headers-4.11.0-1-common/Makefile:1509: set di istruzioni per l'obiettivo "_module_/var/lib/dkms/virtualbox/5.1.10/build" non riuscito make[2]: *** [_module_/var/lib/dkms/virtualbox/5.1.10/build] Errore 2 Makefile:152: set di istruzioni per l'obiettivo "sub-make" non riuscito make[1]: *** [sub-make] Errore 2 Makefile:8: set di istruzioni per l'obiettivo "all" non riuscito make: *** [all] Errore 2 make: uscita dalla directory "/usr/src/linux-headers-4.11.0-1-amd64" Ciao Davide -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc. bios_version: 2201 board_vendor: ASUSTeK Computer INC. board_name: P5Q DELUXE board_version: Rev 1.xx ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e20] (rev 03) Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard [1043:82d3] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
hi Ryan, On 07/11/2017 02:58 AM, Ryan Tandy wrote: > Today I built Linux 4.12 from upstream source and the test program still > crashes. I was looking at your fixes to initialize load_{fp,tm,vec} as well > as someone else fixing the CONFIG_ALIVEC typo but none of those have helped. Right, I tested it with the pending patches for HTM and the bug is still there, so, I doubt is has been fixed already. > I did confirm on this kernel that reverting 613036d9 still stops it from > crashing. Tomorrow I will try to narrow it down to a specific change. There > are only 4 hunks after all (the addition of msr_tm_active cannot be reverted > as there are more calls to it now). In fact I just did it and I found that the following patch fixes the problem. I am not able to understand why yet. Working on it right now. diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 9f3e2c932dcc..21bcb3b19758 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -231,7 +231,7 @@ void enable_kernel_fp(void) EXPORT_SYMBOL(enable_kernel_fp); static int restore_fp(struct task_struct *tsk) { - if (tsk->thread.load_fp || msr_tm_active(tsk->thread.regs->msr)) { + if (tsk->thread.load_fp) { load_fp_state(>thread.fp_state); current->thread.load_fp++; return 1; > It turns out it is _not_ compiler dependent. The test program compiled in a > jessie chroot succeeds in that chroot and then crashes if I run the same > binary in a stretch chroot. This also means I was wrong about the m{t,f}vsrd > instructions being related, as gcc-4.9 doesn't emit them (for this particular > program, at least). I understand that glibc might have VSX instructions, so, even if your application is not using VSX instructions, it might be required depending on the glibc version you are using, although the problem seems to be on the float point (FP) side. > objdump -d libpthread.so.0 output apparently lists some tbegin/tend > instructions, but I suppose those could be selected at runtime? Correct. I checked and Debian is enabling HTM[1] to do lock ellision. It is not a option that you can change on runtime, we would need to reconfigure/recompile glibc if we want to disable it. There is currently an effort to use glibc tunnables to enable/disable lock elision at runtime, but this is still under development. Out of curiosity, how did you bisect the kernel to find that commit-id? Did you do it automatically? [1] https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64el=2.24-12=1497900384=0 (Check for --enable-lock-elision)
Bug#864642: vmxnet3: Reports suspect GRO implementation on vSphere hosts / one VM crashes
found #864642 4.9.30-2+deb9u2 thanks And it still crashes.. Am 22.06.2017 um 14:58 schrieb Patrick Matthäi: > found #864642 4.9.30-2+deb9u1 > thanks > > > Am 12.06.2017 um 10:02 schrieb Patrick Matthäi: >> Package: src:linux >> Version: 4.9.30-1 >> Severity: important >> File: linux >> >> Dear Maintainer, >> >> *** Reporter, please consider answering these questions, where >> appropriate *** >> >> Since updating the kernel from linux-image-4.9.0-2-amd64 (4.9.18-1) to >> linux-image-4.9.0-3-amd64 (4.9.30-1) all VMs report - just for the >> "primary" interface this: >> >> TCP: ens192: Driver has suspect GRO implementation, TCP performance may >> be compromised. >> >> I can't see any performance impact. This happens on all our vSphere 6.0 >> and 6.5 hosts (running on HPE ProLiant DL 360 G8 - G9 HW / ProLiant ML >> 350 G9 and so on). >> >> Why is this bug important? Because on one VM this also produces a kernel >> panic after some time (minutes or hours). I just could get the panic >> attached as screenshot. The only "big" difference between the crashing >> host and the others may be, that it is also running PM2, NPM, NodeJS and >> a NFS kernel server. >> >> If I boot the VM with 4.9.30-1 and deactivate gro and lro with: >> ethtool -K ens192 gro off >> ethtool -K ens192 lro off >> .. it does not crash. >> >> Booting 4.9.18-1 and everything is completly fine ;) >> > The VM keeps on crashing after a few hours > -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Processed: Re: vmxnet3: Reports suspect GRO implementation on vSphere hosts / one VM crashes
Processing commands for cont...@bugs.debian.org: > found #864642 4.9.30-2+deb9u2 Bug #864642 [src:linux] vmxnet3: Reports suspect GRO implementation on vSphere hosts / one VM crashes Marked as found in versions linux/4.9.30-2+deb9u2. > thanks Stopping processing here. Please contact me if you need assistance. -- 864642: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
Control: tag -1 upstream Hi Breno, Today I built Linux 4.12 from upstream source and the test program still crashes. I was looking at your fixes to initialize load_{fp,tm,vec} as well as someone else fixing the CONFIG_ALIVEC typo but none of those have helped. I did confirm on this kernel that reverting 613036d9 still stops it from crashing. Tomorrow I will try to narrow it down to a specific change. There are only 4 hunks after all (the addition of msr_tm_active cannot be reverted as there are more calls to it now). It turns out it is _not_ compiler dependent. The test program compiled in a jessie chroot succeeds in that chroot and then crashes if I run the same binary in a stretch chroot. This also means I was wrong about the m{t,f}vsrd instructions being related, as gcc-4.9 doesn't emit them (for this particular program, at least). On Mon, Jul 10, 2017 at 10:23:40AM -0300, Breno Leitao wrote: Anyway, this is what I am going to investigate now: 1) If glibc's pthread method is using hardware transactional memory by default. I remember that upstream enabled it once and then disabled by default. objdump -d libpthread.so.0 output apparently lists some tbegin/tend instructions, but I suppose those could be selected at runtime? Thanks Ryan
Processed: Re: Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
Processing control commands: > tag -1 upstream Bug #866122 [src:linux] test060-mt-hot failing on ppc64el buildd Bug #866371 [src:linux] openldap FTBFS on ppc64{,el}: slapd-mtread failed (139) Added tag(s) upstream. Added tag(s) upstream. -- 866122: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 866371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems