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))

2017-07-11 Thread Debian Bug Tracking System
Your message dated Wed, 12 Jul 2017 07:48:00 +0200
with message-id 
and 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)

2017-07-11 Thread Francesco Poli (wintermute)
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

2017-07-11 Thread M. Buecher
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)

2017-07-11 Thread Davide Prina

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

2017-07-11 Thread Breno Leitao
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

2017-07-11 Thread Patrick Matthäi
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

2017-07-11 Thread Debian Bug Tracking System
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

2017-07-11 Thread Ryan Tandy

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

2017-07-11 Thread Debian Bug Tracking System
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