Bug#1045194: virtuabox-dkms module build fails with kernel 6.4.10

2023-08-13 Thread S R Wright

Package: virtualbox-dkms
Version: 7.0.10-dfsg-2

virtualbox-dkms module build fails when done with kernel 6.4.10

Output:

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 6.4.10 /boot/vmlinuz-6.4.10
Error! Bad return status for module build on kernel: 6.4.10 (x86_64)
Consult /var/lib/dkms/virtualbox/7.0.10/build/make.log for more information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/postinst.d at 
/var/lib/dpkg/info/linux-image-6.4.10.postinst line 391.
dpkg: error processing package linux-image-6.4.10 (--install):
 installed linux-image-6.4.10 package post-installation script subprocess 
returned error exit status 2
Errors were encountered while processing:
 linux-image-6.4.10





/var/lib/dkms/virtualbox/7.0.10/build/make.log is attached
DKMS make.log for virtualbox-7.0.10 for kernel 6.4.10 (x86_64)
Sun Aug 13 02:16:25 PM CDT 2023
make: Entering directory '/nvm/src/linux-6.4.10'
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPLibAll.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/common/string/strformatrt.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-agnostic1.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-agnostic2.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-os-specific.o
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvTracer.o: warning: objtool: SUPR0TracerFireProbe+0x7: indirect jump found in RETPOLINE build
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/SUPDrvTracer.o: warning: objtool: supdrvTracerProbeFireStub+0x0: 'naked' return found in RETHUNK build
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-os-specific.o: warning: objtool: rtThreadCtxHooksLnxSchedOut+0x1f: call to {dynamic}() with UACCESS enabled
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-os-specific.o: warning: objtool: rtThreadCtxHooksLnxSchedIn+0x29: call to {dynamic}() with UACCESS enabled
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-os-specific.o: warning: objtool: VBoxHost_RTR0MemKernelCopyTo+0x13: redundant CLD
/var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/combined-os-specific.o: warning: objtool: VBoxHost_RTR0MemKernelCopyFrom+0x13: redundant CLD
  LD [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxdrv/vboxdrv.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/VBoxNetFlt.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/SUPR0IdcClient.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/SUPR0IdcClientComponent.o
  CC [M]  /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/SUPR0IdcClient-linux.o
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.c: In function ‘vboxNetFltLinuxForwardToIntNetInner’:
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.c:1570:40: error: implicit declaration of function ‘skb_gso_segment’; did you mean ‘skb_gso_reset’? [-Werror=implicit-function-declaration]
 1570 | struct sk_buff *pSegment = skb_gso_segment(pBuf, 0 /*supported features*/);
  |^~~
  |skb_gso_reset
/var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.c:1570:40: warning: initialization of ‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:252: /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt/linux/VBoxNetFlt-linux.o] Error 1
make[1]: *** [scripts/Makefile.build:497: /var/lib/dkms/virtualbox/7.0.10/build/vboxnetflt] Error 2
make: *** [Makefile:2032: /var/lib/dkms/virtualbox/7.0.10/build] Error 2
make: Leaving directory '/nvm/src/linux-6.4.10'


Bug#996104: dkms: Fail to remove modules

2021-10-11 Thread S R Wright
I encountered this error as well,  however manual removal via 'dkms 
remove' is still operational.




Bug#995799: nvidia-legacy-340xx-driver startx failure on 5.14.9

2021-10-05 Thread S R Wright

Package: nvidia-legacy-340xx-driver
Version: 340.108-11
Severity: serious


The latest nvidia-legacy-340xx-driver succeeds in building the dkms 
module with kernel 5.14.9,  but startx fails to locate any valid 
screens.  This same driver works correctly with kernel 5.10.70.


It appears that drm may be what is having issues here as when it is 
working,  one can see both the nvidia and drm drivers loaded using 
lsmod;  with kernel 5.14.9 the nvidia driver is loaded,  the drm is not.


Comparing dmesg output --

5.10.70:
> sudo dmesg | egrep nvidia
[   17.228869] nvidia: loading out-of-tree module taints kernel.
[   17.228932] nvidia: module license 'NVIDIA' taints kernel.
[   17.247604] nvidia :04:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[   17.247929] [drm] Initialized nvidia-drm 0.0.0 20150116 for 
:04:00.0 on minor 0

[   32.923403] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs
[  109.283171] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

5.14.9:
> sudo dmesg | egrep nvidia
[   22.765964] nvidia: loading out-of-tree module taints kernel.
[   22.766040] nvidia: module license 'NVIDIA' taints kernel.
[   22.785231] nvidia :04:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem

[   53.226048] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

-- sRw



Bug#977698: Deluge 2.0.3-3 Move Download Folder functionality broken

2020-12-18 Thread S R Wright

Package: deluge
Version: 2.0.3-3
Severity:|important > dpkg -l deluge python3 python3-libtorrent 
libtorrent-rasterbar10 Desired=Unknown/Install/Remove/Purge/Hold | 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend 
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name 
Version Architecture Description 
+++-==---= 
ii deluge 2.0.3-3 all bittorrent client written in Python/PyGTK ii 
libtorrent-rasterbar10 1.2.9-0.2+b2 amd64 C++ bittorrent library by 
Rasterbar Software ii python3 3.9.0-4 amd64 interactive high-level 
object-oriented language (default python3 version) ii python3-libtorrent 
1.2.9-0.2+b2 amd64 Python bindings for libtorrent-rasterbar (Python 3) 
The functionality of Move Download Folder is broken in Deluge version 
2.0.3-3, although this may be a side effect of the move to python 3.9. 
The terminal shows this message when attempting to use move download 
folder: Temporarily disabling observer LegacyLogObserverWrapper(method TwistedLoggingObserver.emit of object at 0x7f048c5034f0>>) due to exception: [Failure instance: 
Traceback: : findCaller() takes from 1 to 2 
positional arguments but 3 were given 
/usr/lib/python3/dist-packages/deluge/ui/gtk3/menubar.py:368:on_dialog_response_event 
/usr/lib/python3/dist-packages/twisted/internet/defer.py:962:__del__ 
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:190:failure 
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:144:emit --- 
 --- 
/usr/lib/python3/dist-packages/twisted/logger/_observer.py:131:__call__ 
/usr/lib/python3/dist-packages/twisted/logger/_legacy.py:93:__call__ 
/usr/lib/python3/dist-packages/deluge/log.py:204:emit 
/usr/lib/python3.9/logging/__init__.py:1481:critical 
/usr/lib/python3.9/logging/__init__.py:1565:_log ] Traceback (most 
recent call last): File 
"/usr/lib/python3/dist-packages/deluge/ui/gtk3/menubar.py", line 368, in 
on_dialog_response_event client.core.move_storage( File 
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 962, in 
__del__ log.failure(format, File 
"/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 190, in 
failure self.emit(level, format, log_failure=failure, **kwargs) File 
"/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 144, in 
emit self.observer(event) ---  --- File 
"/usr/lib/python3/dist-packages/twisted/logger/_observer.py", line 131, 
in __call__ observer(event) File 
"/usr/lib/python3/dist-packages/twisted/logger/_legacy.py", line 93, in 
__call__ self.legacyObserver(event) File 
"/usr/lib/python3/dist-packages/deluge/log.py", line 204, in emit 
getattr(LoggingLoggerClass, event_dict['log_level'].name)( File 
"/usr/lib/python3.9/logging/__init__.py", line 1481, in critical 
self._log(CRITICAL, msg, args, **kwargs) File 
"/usr/lib/python3.9/logging/__init__.py", line 1565, in _log fn, lno, 
func, sinfo = self.findCaller(stack_info, stacklevel) 
builtins.TypeError: findCaller() takes from 1 to 2 positional arguments 
but 3 were given |




Bug#976339: Deluge standalone client broken with latest Python3

2020-12-03 Thread S R Wright

Package: deluge
Version: 2.0.3-3


dpkg -l deluge python3 python3-libtorrent libtorrent-rasterbar10

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  deluge 2.0.3-3  all  bittorrent client written 
in Python/PyGTK
ii  libtorrent-rasterbar10 1.2.9-0.1amd64C++ bittorrent library by 
Rasterbar Software
ii  python33.9.0-3  amd64interactive high-level 
object-oriented language (default python3 version)
ii  python3-libtorrent 1.2.9-0.1amd64Python bindings for 
libtorrent-rasterbar (Python 3)

With these packages installed, the deluge standalone client will not start.  
The dialog box shows this:



Attached is the screen output detailing a python error.

Unhandled error in Deferred:
Temporarily disabling observer LegacyLogObserverWrapper(>) due to exception: [Failure instance: Traceback: : _findCaller() takes from 1 to 2 positional arguments but 3 were 
given
/usr/lib/python3/dist-packages/twisted/internet/defer.py:88:succeed
/usr/lib/python3/dist-packages/twisted/internet/defer.py:953:__del__
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:270:critical
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:144:emit
---  ---
/usr/lib/python3/dist-packages/twisted/logger/_observer.py:131:__call__
/usr/lib/python3/dist-packages/twisted/logger/_legacy.py:93:__call__
/usr/lib/python3/dist-packages/deluge/log.py:208:emit
/usr/lib/python3/dist-packages/twisted/python/log.py:595:emit
/usr/lib/python3/dist-packages/twisted/logger/_legacy.py:154:publishToNewObserver
/usr/lib/python3/dist-packages/twisted/logger/_stdlib.py:115:__call__
/usr/lib/python3.9/logging/__init__.py:1500:log
/usr/lib/python3.9/logging/__init__.py:1565:_log
]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 88, in 
succeed
d = Deferred()
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 953, in 
__del__
log.critical("Unhandled error in Deferred:",
  File "/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 270, in 
critical
self.emit(LogLevel.critical, format, **kwargs)
  File "/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 144, in 
emit
self.observer(event)
---  ---
  File "/usr/lib/python3/dist-packages/twisted/logger/_observer.py", line 131, 
in __call__
observer(event)
  File "/usr/lib/python3/dist-packages/twisted/logger/_legacy.py", line 93, in 
__call__
self.legacyObserver(event)
  File "/usr/lib/python3/dist-packages/deluge/log.py", line 208, in emit
PythonLoggingObserver.emit(self, event_dict)
  File "/usr/lib/python3/dist-packages/twisted/python/log.py", line 595, in emit
_publishNew(self._newObserver, eventDict, textFromEventDict)
  File "/usr/lib/python3/dist-packages/twisted/logger/_legacy.py", line 154, in 
publishToNewObserver
observer(eventDict)
  File "/usr/lib/python3/dist-packages/twisted/logger/_stdlib.py", line 115, in 
__call__
self.logger.log(
  File "/usr/lib/python3.9/logging/__init__.py", line 1500, in log
self._log(level, msg, args, **kwargs)
  File "/usr/lib/python3.9/logging/__init__.py", line 1565, in _log
fn, lno, func, sinfo = self.findCaller(stack_info, stacklevel)
builtins.TypeError: _findCaller() takes from 1 to 2 positional arguments but 3 
were given



Bug#969470: virtualbox dkms build fails against kernel 5.8.x

2020-09-03 Thread S. R. Wright

Submitted the wrong make.log.  Attached is the correct one.

-- sRw


DKMS make.log for virtualbox-6.1.12 for kernel 5.8.6 (x86_64)
Thu 03 Sep 2020 11:12:18 AM CDT
make: Entering directory '/usr/src/linux-5.8.6'
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/alloc-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/initterm-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/memobj-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/mpnotification-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/powernotification-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o: warning: objtool: .text+0x7: indirect jump found in RETPOLINE build
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o: warning: objtool: supdrvTracerProbeFireStub() is missing an ELF size annotation
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/mpnotification-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/process-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/rtStrFormatKernelAddress-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semevent-r0drv-linux.o
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: VBoxHost_RTR0MemKernelCopyFrom()+0x13: redundant CLD
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: VBoxHost_RTR0MemKernelCopyTo()+0x13: redundant CLD
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semeventmulti-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semfastmutex-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/semmutex-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/spinlock-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/thread-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/thread2-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/threadctxhooks-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/time-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/timer-r0drv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/generic/semspinmutex-r0drv-generic.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/alloc/alloc.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/checksum/crc32.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/checksum/ipv4.o
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/threadctxhooks-r0drv-linux.o: warning: objtool: rtThreadCtxHooksLnxSchedOut()+0x1f: call to __x86_indirect_thunk_rax() with UACCESS enabled
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/linux/threadctxhooks-r0drv-linux.o: warning: objtool: rtThreadCtxHooksLnxSchedIn()+0x29: call to __x86_indirect_thunk_rax() with UACCESS enabled
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/checksum/ipv6.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/err/RTErrConvertFromErrno.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/err/RTErrConvertToErrno.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/err/errinfo.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/log.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logellipsis.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logrel.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logrelellipsis.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logcom.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/log/logformat.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/common/misc/RTAssertMsg1Weak.o
  CC [M] 

Bug#969470: virtualbox dkms build fails against kernel 5.8.x

2020-09-03 Thread S. R. Wright

Package: virtualbox-dkms
Version: 6.1.12-dfsg-9
Kernel: 5.8.6

The dkms build fails for the current version of virtualbox-dkms and kernel 
5.8.x sources:

Building module:
cleaning build area...
make -j8 KERNELRELEASE=5.8.6 -C /usr/src/linux-5.8.6 
M=/var/lib/dkms/virtualbox/6.1.12/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.8.6 (x86_64)
Consult /var/lib/dkms/virtualbox/6.1.12/build/make.log for more information.

make.log is attached.

-- sRw

DKMS make.log for virtualbox-6.1.12 for kernel 5.8.6 (x86_64)
Thu 03 Sep 2020 10:22:24 AM CDT
make: Entering directory '/usr/src/linux-5.8.6'
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.o
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/../SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.c:32:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvGip.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/linux/SUPDrv-linux.o] Error 1
compilation terminated.
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/alloc-r0drv.o
  CC [M]  /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/initterm-r0drv.o
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrv.o] Error 1
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvInternal.h:38,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.c:33:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvSem.o] Error 1
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPDrvTracer.o] Error 1
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/types.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/VBox/sup.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.c:31:
/var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/types.h:142:12: fatal error: linux/version.h: No such file or directory
  142 | #  include 
  |^
compilation terminated.
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/SUPLibAll.o] Error 1
In file included from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/include/iprt/initterm.h:33,
 from /var/lib/dkms/virtualbox/6.1.12/build/vboxdrv/r0drv/initterm-r0drv.c:31:

Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6

2020-04-30 Thread S R Wright

DKMS works for me using kernel 5.6.8  -- sRw

On 2020-04-30 06:09, Andreas Beckmann wrote:

On 30/04/2020 12.09, jim_p wrote:

And then the reference to #956458, which is for nvidia legacy 390xx.
So I would like to ask if the bug I mentioned here is indeed fixed in the -5
revision of the package. I can't test it right now, but I probably will
tomorrow or on Saturday.

I backported NVIDIA's changes from 440.82 to 418.126.02 (tesla-418),
then to 390.132 (legacy-390xx) then to 340.108 (copying the wrong bug
number). There were always some parts being patched not yet existing in
the older releases so the patches got smaller on the way. For 340.108 it
was more or less a complete redo, since nvidia significantly
restructured the driver source after that series. There were also some
ancient bits no longer existing in newer releases that needed to be
patched additionally for 5.6.

So yes, it is fixed for the 340 series, too. But as always, only
compile-tested.


Andreas





Bug#958446: nvidia-legacy-340xx-driver: Fails to build with kernel 5.6

2020-04-25 Thread S R Wright
Just my 2d,  but I am with Jim P on the whole "nouveau is something I 
hate even more" thing.  This driver is operational in 5.5.x as we know,  
but since that branch went EOL I have just reverted my machines to 5.4.x 
for the time being )OK for now since 5.4.x is long-term).  The native 
NVIDIA driver uses power very efficiently whereas my experience has been 
that nouveau does not.


On 2020-04-25 01:12, jim_p wrote:

Package: nvidia-legacy-340xx-driver
Version: 340.108-4
Followup-For: Bug #958446

I know the command I have to run, I just don't know the path to use there. And
last time I patched the file manually, because it was only one file, I wrote
that one line by hand :D
If you show me the way, e.e. the exact thing I have to write on the terminal to
do the patching, I will test it on 5.6. If it works, will you use it? I really
have no idea on how to find that offending line you mention.

Also, if it breaks the kernel on another branch, simply don't use it in that
branch. I have noticed that the package is not on the same (sub)version from
unstable to oldstable and I assume it is because of the different patches each
one can get.
I also hate to do all that for something that is eol, but being forced to use
nouveau is something I hate even more. In the very end, I will  consider
switching to another distro just to be able to use the driver, even if it means
that I will have to build it myself.



-- Package-specific info:
uname -a:
Linux mitsos 5.5.0-2-amd64 #1 SMP Debian 5.5.17-1 (2020-04-15) x86_64 GNU/Linux

/proc/version:
Linux version 5.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 9.3.0 (Debian 9.3.0-10)

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.309604] Console: colour VGA+ 80x25
[0.746332] pci :01:00.0: vgaarb: setting as boot VGA device
[0.746332] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.746332] pci :01:00.0: vgaarb: bridge control possible
[0.746332] vgaarb: loaded
[0.932293] Linux agpgart interface v0.103
[3.347163] nvidia: loading out-of-tree module taints kernel.
[3.347175] nvidia: module license 'NVIDIA' taints kernel.
[3.376308] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.396473] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.397701] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.397714] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[3.953374] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[5.213460] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22
[5.214117] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input23
[5.215241] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24
[5.215334] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25
[7.417788] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Apr 25 07:00 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Apr 25 07:00 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Apr 25 07:00 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Apr 25 07:00 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan  5 09:29 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jan  5 09:29 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jan  5 09:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan  5 09:29 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   54 Jan  5 09:29 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Jan  5 09:29 

Bug#946970: scp of large files breaks with kernel 5.4.x

2019-12-18 Thread S. R. Wright

Package: openssh-client
Version:  8.1p1-2

I am going to submit this as a bug in openssh-client for the moment, 
tho' it may actually be inside the kernel if it is driver related. The 
NIC is:


Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 02)


and uses the r8169 driver,  if that info is useful here.



When using scp to transfer a large file,  it errors out when running 
kernel 5.4.4;  with 5.3.17 it succeeds.  If I throttle the scp command 
using the -l option running kernel 5.4.4 it can succeed if it is slowed 
down enough.


> uname -a
Linux vex 5.4.4 #1 SMP PREEMPT Tue Dec 17 16:47:28 CST 2019 x86_64 
GNU/Linux


> scp -p /tmp/*.tgz elp:/tmp
XXX@elp's password:
linux-5.4.4.tgz 0%    0 0.0KB/s   --:-- ETAclient_loop: send 
disconnect: Broken pipe

lost connection


> uname -a
Linux vex 5.3.17 #1 SMP PREEMPT Wed Dec 18 09:19:36 CST 2019 x86_64 
GNU/Linux


> scp -p /tmp/*.tgz elp:/tmp
XXX@elp's password:
linux-5.4.4.tgz   100%  165MB 67.7MB/s   00:02



Bug#929229: systemd, udev -- keyboard freezes after exiting X in version 241-4

2019-05-19 Thread S R Wright
Is this confined to systemd 241-4?  Will back-revving to 241-3 be a 
sufficient workaround?




Bug#929229: systemd, udev -- keyboard freezes after exiting X in version 241-4

2019-05-19 Thread S R Wright

Package: systemd, udev
Version: 241-4
Kernel: seen in 5.1.3 and 4.19.44


dpkg -l | egrep "^ii" | egrep "241-4"

ii  libnss-systemd:amd64  241-4
amd64nss module providing dynamic user and group name resolution
ii  libpam-systemd:amd64  241-4
amd64system and service manager - PAM module
ii  libsystemd0:amd64 241-4
amd64systemd utility library
ii  libudev1:amd64241-4
amd64libudev shared library
ii  systemd   241-4
amd64system and service manager
ii  systemd-sysv  241-4
amd64system and service manager - SysV links
ii  udev  241-4
amd64/dev/ and hotplug management daemon


I am unsure whether the problem is with systemd or udev, but while operational 
with versions 241-3, upon upgrading to 241-4, the keyboard stops working after 
exiting X. I am using startx and fvwm.

-- sRw





Bug#923815: Info received (Bug#923815: nvidia-legacy-340xx-kernel-dkms does not build against kernel 5.0 source)

2019-03-27 Thread S. R. Wright

N.B. The nvidia-current dkms built and is operational against kernel v5.0.5

-- sRw



Bug#923815: Acknowledgement (nvidia-legacy-340xx-kernel-dkms does not build against kernel 5.0 source)

2019-03-27 Thread S. R. Wright

As 4.20.x is going EOL,  it may be prudent to investigate this bug WRT 5.0.x

-- sRw

On 3/5/19 11:51 AM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 923815: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923815.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian NVIDIA Maintainers 

If you wish to submit further information on this problem, please
send it to 923...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.





Bug#923815: nvidia-legacy-340xx-kernel-dkms does not build against kernel 5.0 source

2019-03-05 Thread S R Wright
Understood.  I noted today that even nvidia-current was not able to 
build the dkms module against 5.0,  so this is really not urgent.  -- sRw


On 3/5/19 7:25 PM, Andreas Beckmann wrote:

Control: tag -1 upstream

On 2019-03-05 18:49, S R Wright wrote:

The latest version of nvidia-legacy-340xx-kernel-dkms has build errors
when built against the latest 5.0 kernel source.

I will not investigate this before Linux 5.0 has reached experimental
and hope for a new ustream release inbetween :-)
The 340.xx changelog entries included with the latest 390.xx/410.xx
releases document Linux 5.0 related fixes, there is just no new release,
yet.


Andreas




Bug#922479: nvidia-legacy-340xx-kernel-dkms unknown symbols, kernel 4.20.x

2019-02-24 Thread S R Wright
This really needs to be fixed, at this point legacy NVIDIA graphics 
cards (such as my NVIDIA Corporation GT216M [NVS 5100M]) cannot use the 
legacy driver going past kernel 4.19.


The workaround of course is just to just use nouveau,  which at least 
*is* operational in 4.20.x but which also seems more like capitulation 
than a solution.


-- sRw



Bug#922479: nvidia-legacy-340xx-kernel-dkms unknown symbols, kernel 4.20.x

2019-02-16 Thread S R Wright

Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.107-3

This is completely functional in kernel 4.19.x and before,  but an attempt to 
use this in 4.20.x has failed.  While dkms can build the module to completion,  
at boot time in throws a large number of unknown symbols.

The list is attached.


[9.093073] nvidia: loading out-of-tree module taints kernel.
[9.093094] nvidia: module license 'NVIDIA' taints kernel.
[9.093322] nvidia: Unknown symbol rm_p2p_init_mapping (err -2)
[9.093341] nvidia: Unknown symbol rm_init_private_state (err -2)
[9.093392] nvidia: Unknown symbol rm_is_supported_device (err -2)
[9.093415] nvidia: Unknown symbol rm_gpu_ops_get_attached_uuids (err -2)
[9.093438] nvidia: Unknown symbol rm_gpu_ops_get_gpu_arch (err -2)
[9.093456] nvidia: Unknown symbol rm_gpu_ops_memory_alloc_sys (err -2)
[9.093477] nvidia: Unknown symbol rm_get_vbios_version (err -2)
[9.093500] nvidia: Unknown symbol nv_is_virtualized_system (err -2)
[9.093518] nvidia: Unknown symbol rm_resume_smu (err -2)
[9.093565] nvidia: Unknown symbol rm_power_management (err -2)
[9.093610] nvidia: Unknown symbol rm_gvi_free_private_state (err -2)
[9.093662] nvidia: Unknown symbol rm_gvi_isr (err -2)
[9.093702] nvidia: Unknown symbol rm_free_private_state (err -2)
[9.093719] nvidia: Unknown symbol rm_disable_gpu_state_persistence (err -2)
[9.093737] nvidia: Unknown symbol rm_init_adapter (err -2)
[9.093759] nvidia: Unknown symbol rm_ioctl (err -2)
[9.093781] nvidia: Unknown symbol rm_gpu_ops_memory_free (err -2)
[9.093820] nvidia: Unknown symbol rm_run_rc_callback (err -2)
[9.093841] nvidia: Unknown symbol rm_gvi_get_firmware_version (err -2)
[9.093859] nvidia: Unknown symbol rm_is_legacy_device (err -2)
[9.093876] nvidia: Unknown symbol rm_release_api_lock (err -2)
[9.093893] nvidia: Unknown symbol rm_gpu_ops_channel_destroy (err -2)
[9.093918] nvidia: Unknown symbol rm_validate_mmap_request (err -2)
[9.093951] nvidia: Unknown symbol rm_gpu_ops_memory_cpu_map (err -2)
[9.093989] nvidia: Unknown symbol rm_gpu_ops_get_uvm_priv_region (err -2)
[9.094007] nvidia: Unknown symbol rm_isr (err -2)
[9.094029] nvidia: Unknown symbol rm_shutdown_rm (err -2)
[9.094051] nvidia: Unknown symbol rm_acquire_api_lock (err -2)
[9.094068] nvidia: Unknown symbol rm_is_legacy_arch (err -2)
[9.094085] nvidia: Unknown symbol rm_gvi_bh (err -2)
[9.094103] nvidia: Unknown symbol rm_p2p_get_pages (err -2)
[9.094120] nvidia: Unknown symbol rm_i2c_remove_adapters (err -2)
[9.094142] nvidia: Unknown symbol rm_gpu_ops_kill_channel (err -2)
[9.094166] nvidia: Unknown symbol rm_gvi_resume (err -2)
[9.094203] nvidia: Unknown symbol rm_gpu_ops_address_space_create (err -2)
[9.094234] nvidia: Unknown symbol rm_gpu_ops_memory_alloc_fb (err -2)
[9.094255] nvidia: Unknown symbol rm_gvi_attach_device (err -2)
[9.094272] nvidia: Unknown symbol rm_suspend_smu (err -2)
[9.094313] nvidia: Unknown symbol rm_write_registry_dword (err -2)
[9.094333] nvidia: Unknown symbol rm_gvi_get_device_name (err -2)
[9.094351] nvidia: Unknown symbol rm_shutdown_adapter (err -2)
[9.094368] nvidia: Unknown symbol rm_get_gpu_uuid (err -2)
[9.094390] nvidia: Unknown symbol rm_i2c_transfer (err -2)
[9.094421] nvidia: Unknown symbol rm_write_registry_binary (err -2)
[9.094443] nvidia: Unknown symbol rm_get_gpu_uuid_raw (err -2)
[9.094467] nvidia: Unknown symbol rm_gpu_ops_copy_engine_allocate (err -2)
[9.094484] nvidia: Unknown symbol rm_p2p_put_pages (err -2)
[9.094505] nvidia: Unknown symbol rm_perform_version_check (err -2)
[9.094526] nvidia: Unknown symbol rm_isr_bh (err -2)
[9.094543] nvidia: Unknown symbol rm_gvi_suspend (err -2)
[9.094560] nvidia: Unknown symbol rm_gpu_ops_address_space_destroy (err -2)
[9.094618] nvidia: Unknown symbol rm_gvi_detach_device (err -2)
[9.094697] nvidia: Unknown symbol rm_gpu_ops_check_ecc_error_slowpath (err 
-2)
[9.094727] nvidia: Unknown symbol rm_gpu_ops_channel_translate_error (err 
-2)
[9.094744] nvidia: Unknown symbol rm_purge_mmap_contexts (err -2)
[9.094764] nvidia: Unknown symbol rm_p2p_destroy_mapping (err -2)
[9.094802] nvidia: Unknown symbol rm_get_device_name (err -2)
[9.094812] nvidia: Unknown symbol rm_shutdown_smu (err -2)
[9.094820] nvidia: Unknown symbol rm_init_smu (err -2)
[9.094828] nvidia: Unknown symbol rm_check_pci_config_space (err -2)
[9.094846] nvidia: Unknown symbol rm_execute_work_item (err -2)
[9.094855] nvidia: Unknown symbol rm_gpu_ops_destroy_session (err -2)
[9.094863] nvidia: Unknown symbol rm_shutdown_gvi_device (err -2)
[9.094881] nvidia: Unknown symbol rm_gpu_ops_channel_allocate (err -2)
[9.094891] nvidia: Unknown symbol rm_i2c_is_smbus_capable (err -2)
[9.094905] nvidia: Unknown symbol rm_gpu_ops_query_caps (err -2)
[9.094920] nvidia: 

Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)

2018-07-10 Thread S. R. Wright

Can verify,  this bug is kernel independent.

On Tue, 10 Jul 2018 12:15:51 +0200 Vincent Gatignol 
 wrote:

> hi there,
>
> running  4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64
> GNU/Linux and having this issue too
>
> not specifically related to the 4.16 versions
>
>
> Regards
>



Bug#841420: Rolling Back?

2016-10-31 Thread S. R. Wright

On 10/31/2016 06:42 AM, Hannu wrote:

How do I roll back to gcc-6.2.0-6?


If you haven't cleaned package cache recently you might try this:

cd /var/cache/apt/archives

ls -al *6.2.0-6*

and if gcc-6.2.0-6 seems to be present:

dpkg -i *6.2.0-6*

The packages still appear to be available at 
http://repo.kali.org/kali/pool/main/g/gcc-6/




Bug#841420: fix

2016-10-29 Thread S. R. Wright
As just a data point,  when -march=i686,  the kernel builds and seems to 
work well using 6.2.0-10 and with no patches to Makefile at all.


On 10/29/2016 10:24 AM, Oswald Buddenhagen wrote:

-no-pie is not a useful option here, because it's passed to the _linker_
only.

i got it to build with this minimal patch:

--- a/Makefile
+++ b/Makefile
@@ -400,5 +400,5 @@ KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes 
-Wno-trigraphs \
-Werror-implicit-function-declaration \
-Wno-format-security \
-  -std=gnu89
+  -std=gnu89 -fno-PIE

  KBUILD_AFLAGS_KERNEL :=





Bug#841420: --enable-default-pie breaks kernel builds

2016-10-21 Thread S. R. Wright
I agree with Eric;  while the workaround is to back rev the gcc and its 
associated packages,  I also build kernels straight from kernel.org, 
usually within hours of their availability and this has been working for 
me for many years,  and it is not sufficient to justify this change by 
saying doing so "isn't a good idea."  A change of functionality of this 
scope warrants a minor version number increase,  this change was not 
merely a bug fix.


As the kernel is the most important code gcc is ever likely to compile 
on debian or any other distro for that matter,  this change should be 
backed out,  and not reintroduced UNTIL the *official* kernel source is 
ready for it.


-- sRw

On 10/21/2016 06:43 AM, Wolfgang Walter wrote:

On Friday, 21 October 2016 14:45:25 CEST Ritesh Raj Sarraf wrote:

The Debian kernel packages still have a dependency on gcc-5, which may mean
that the kernels are currently only built/supported with gcc-5.

vanilla kernels (Linus' tree and the stable ones) could be compiled just fine
with gcc 6.2.0-6 and that now fails.

I still think this is a major regression and regard gcc 6.2.0-7 simply as
broken.


On Thu, 2016-10-20 at 11:22 -0500, S R Wright wrote:

Concurring with Wolfgang;  pulling the source straight from kernel.org
and using identical .config files will work with 6.2.0-6 but fail with
6.2.0-7.   I was able to build and install 4.8.3 with no issues after
back-revving gcc et. al. to 6.2.0-6

-- sRw

On 10/20/16 11:09, Wolfgang Walter wrote:

Hello,

with this version of gcc-6 I can't build vanilla kernels any more. It
fails
with even with CC_STACKPROTECTOR_STRONG disabled:

scripts/kconfig/mconf  Kconfig
configuration written to .config

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

ksrc@ei:~/build/kernels/linux-4.8.3$ make
scripts/kconfig/conf  --silentoldconfig Kconfig
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
CC  kernel/bounds.s
kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
   /*
   
Kbuild:45: recipe for target 'kernel/bounds.s' failed

make[1]: *** [kernel/bounds.s] Error 1
Makefile:1015: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2


I think this is a major regression if you can't build vanilla and stable
kernels any more.

Regards,

Regards,




Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

2016-10-20 Thread S. R. Wright
I agree.  When the version changes from 6.2.0-6 to 6.2.0-7,  only bug 
fixes should be included,  not changes in functionality.  In this case 
setting enable-default-pie essentially broke backwards compatibility.  
Kernel code that built in -6 failed to build in -7.  That, I agree,  
should be considered a bug,  and the change should be rolled back.


-- sRw

On 10/20/2016 05:49 PM, Ben Hutchings wrote:

On Fri, 2016-10-21 at 01:21 +0300, Konstantin Demin wrote:

It's not a GCC bug but kind of new feature.

It's a bug when a compiler fails to compile valid code.

Ben.


Take a look at this changelog entry:
  gcc-6 (6.2.0-7) unstable; urgency=medium

[ Matthias Klose ]
* Configure with --enable-default-pie and pass -z now when pie is enabled;
  on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x.
  Closes: #835148.

Starting at gcc 6.2.0-7 we must provide "-fno-PIE -fno-PIC" in
beginning of CFLAGS to build kernel successfully.

I'm currently looking for correct way to do this trick.






Bug#841420: --enable-default-pie breaks kernel builds

2016-10-20 Thread S R Wright
Concurring with Wolfgang;  pulling the source straight from kernel.org 
and using identical .config files will work with 6.2.0-6 but fail with 
6.2.0-7.   I was able to build and install 4.8.3 with no issues after 
back-revving gcc et. al. to 6.2.0-6


-- sRw


On 10/20/16 11:09, Wolfgang Walter wrote:

Hello,

with this version of gcc-6 I can't build vanilla kernels any more. It fails
with even with CC_STACKPROTECTOR_STRONG disabled:

scripts/kconfig/mconf  Kconfig
configuration written to .config

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

ksrc@ei:~/build/kernels/linux-4.8.3$ make
scripts/kconfig/conf  --silentoldconfig Kconfig
   CHK include/config/kernel.release
   CHK include/generated/uapi/linux/version.h
   CHK include/generated/utsrelease.h
   UPD include/generated/utsrelease.h
   CC  kernel/bounds.s
kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
  /*
  
Kbuild:45: recipe for target 'kernel/bounds.s' failed

make[1]: *** [kernel/bounds.s] Error 1
Makefile:1015: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2


I think this is a major regression if you can't build vanilla and stable
kernels any more.

Regards,




Bug#841368: gcc-6 6.2.0-7 breaks kernel build if stack protection is enabled

2016-10-19 Thread S R Wright

Package: gcc-6
Version: 6.2.0-7

Kernel building with stack protection enabled breaks with 6.2.0-7, whereas 
identical .config works using 6.2.0-6:

output:

make[2]: Leaving directory '/usr/src/linux-4.8.1'
makeARCH=x86_64 prepare
make[2]: Entering directory '/usr/src/linux-4.8.1'
scripts/kconfig/conf  --silentoldconfig Kconfig
  SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_32_ia32.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_64_x32.h
  SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_64.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  CHK include/config/kernel.release
  UPD include/config/kernel.release
Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by 
compiler
Makefile:1048: recipe for target 'prepare-compiler-check' failed
make[2]: *** [prepare-compiler-check] Error 1
make[2]: Leaving directory '/usr/src/linux-4.8.1'
debian/ruleset/targets/common.mk:194: recipe for target 
'debian/stamp/conf/kernel-conf' failed
make[1]: *** [debian/stamp/conf/kernel-conf] Error 2
make[1]: Leaving directory '/usr/src/linux-4.8.1'
/usr/share/kernel-package/ruleset/minimal.mk:93: recipe for target 
'debian/stamp/conf/minimal_debian' failed
make: *** [debian/stamp/conf/minimal_debian] Error 2
Failed to create a ./debian directory: No such file or directory at 
/usr/bin/make-kpkg line 970.

relevant .config section:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

-- sRw



Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found

2015-12-19 Thread S. R. Wright

Ian:

Attached is the info you suggested, pre- and post-upgrade.  Was never 
prompted to answer any questions or than to continue the upgrade.


 -- sRw
## v32:
root@mi6:# debconf-get-selections | grep grub
# /boot/grub/device.map has been regenerated
grub-efi-amd64  grub2/device_map_regeneratednote
grub-efi-amd64  grub2/kfreebsd_cmdline_default  string  quiet
grub-efi-amd64  grub2/force_efi_extra_removable boolean false
grub-efi-amd64  grub2/linux_cmdline_default string  video=LVDS-1:d
# What do you want to do about modified configuration file grub?
grub-efi-amd64  grub2/linux_cmdline string
grub-efi-amd64  grub2/kfreebsd_cmdline  string


root@mi6:# debconf-get-selections --installer | grep grub
grub-installer  grub-installer/grub_not_mature_on_this_platform boolean false
grub-installer  grub-installer/force-efi-extra-removableboolean false
grub-installer  grub-installer/apt-install-failed   error
grub-installer  grub-installer/grub-install-failed  error
grub-installer  grub-installer/skip boolean false
grub-installer  grub-installer/sataraid boolean true
grub-installer  grub-installer/choose_bootdev   select
grub-installer  grub-installer/only_debian  boolean true
grub-installer  grub-installer/make_active  boolean true
grub-installer  grub-installer/update-grub-failed   error
grub-installer  grub-installer/multipath-error  error
grub-installer  grub-installer/multipathboolean true
grub-installer  grub-installer/mounterr error
grub-installer  grub-installer/sataraid-error   error
grub-installer  grub-installer/bootdev  string
grub-installer  grub-installer/with_other_osboolean true
grub-installer  grub-installer/password-mismatcherror
grub-installer  grub-installer/grub2_instead_of_grub_legacy boolean true

root@mi6:# find /boot/efi -ls
 11 drwx--   3 root root 1024 Dec 31  1969 /boot/efi
   1811 drwx--   5 root root 1024 Dec 12 04:40 /boot/efi/EFI
   1881 drwx--   4 root root 1024 Dec 11 14:07 
/boot/efi/EFI/Microsoft
   1944 drwx--  29 root root 4096 Dec 11 14:07 
/boot/efi/EFI/Microsoft/Boot
   247   36 -rwx--   1 root root36864 Dec 18 21:33 
/boot/efi/EFI/Microsoft/Boot/BCD
   248   64 -rwx--   1 root root65536 Dec 11 14:07 
/boot/efi/EFI/Microsoft/Boot/BCD.LOG
   2495 -rwx--   1 root root 4391 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/boot.stl
   250 1132 -rwx--   1 root root  1159008 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
   251 1121 -rwx--   1 root root  1147744 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/bootmgr.efi
   1981 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/cs-CZ
   253   45 -rwx--   1 root root45408 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/cs-CZ/memtest.efi.mui
   1991 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/da-DK
   255   45 -rwx--   1 root root45408 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/da-DK/memtest.efi.mui
   2001 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/de-DE
   257   45 -rwx--   1 root root45920 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/de-DE/memtest.efi.mui
   2011 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/el-GR
   259   46 -rwx--   1 root root46432 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/el-GR/memtest.efi.mui
   2021 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/en-US
   263   73 -rwx--   1 root root74080 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/en-US/bootmgfw.efi.mui
   264   73 -rwx--   1 root root74080 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/en-US/bootmgr.efi.mui
   265   44 -rwx--   1 root root44896 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/en-US/memtest.efi.mui
   2031 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/es-ES
   267   45 -rwx--   1 root root45920 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/es-ES/memtest.efi.mui
   2041 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/fi-FI
   269   45 -rwx--   1 root root45408 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/fi-FI/memtest.efi.mui
   2051 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/fr-FR
   271   45 -rwx--   1 root root45920 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/fr-FR/memtest.efi.mui
   2061 drwx--   2 root root 1024 Dec 11 14:20 
/boot/efi/EFI/Microsoft/Boot/hu-HU
   273   45 -rwx--   1 root root45920 Oct 30 00:18 
/boot/efi/EFI/Microsoft/Boot/hu-HU/memtest.efi.mui
   2071 drwx--   2 root 

Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found

2015-12-19 Thread S. R. Wright

On 12/19/2015 10:04 AM, Ian Campbell wrote:

On Sat, 2015-12-19 at 09:52 -0600, S. R. Wright wrote:

Ian:

Attached is the info you suggested, pre- and post-upgrade.  Was never
prompted to answer any questions or than to continue the upgrade.
I can't explain how it got there, but I think that this 
Boot/bootx64.efi is what your system is booting from and it doesn't 
appear to be being updated. I expect that the reason this is present 
at all is that your BIOS is bug gy in the way the extra removable 
option is intended to workaround, if it wasn't you could likely 
convince your BIOS to boot thebconf-set-selections debian/grubx64.efi 
by playing with efibootmgr etc but I think you best bet would be to 
set grub2/force_efi_extra_removable=true, try (as root): echo 
"grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | de 
bconf-set-selections and then upgrade or reconfigure the package and 
it should be updated. Do you have any idea what might have happened at 
04:48 on Dec 12? Ian. 


Ian,  your suggestion appeared to have worked.  Ta!  As far as what 
happened @ 4.48a on the 12th,  I really cannot say as I was asleep.


Thanks again!
-- srw



Bug#808366: additional info

2015-12-19 Thread S. R. Wright
It's possible that Windows is not relevant here;  it could be that 
whatever selection is last on the list that the OS prober constructs may 
have this issue,  and in my case the last entry just happened to be 
Windows.  Just FYI.




Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found

2015-12-19 Thread S. R. Wright

On 12/19/2015 09:03 AM, Colin Watson wrote:

On Fri, Dec 18, 2015 at 09:26:55PM -0600, S. R. Wright wrote:

dpkg -l "grub*" | egrep "^ii"

ii  grub-common2.02~beta2-33 amd64GRand Unified Bootloader 
(common files)
ii  grub-efi   2.02~beta2-33 amd64GRand Unified Bootloader, 
version 2 (dummy package)
ii  grub-efi-amd64 2.02~beta2-33 amd64GRand Unified Bootloader, 
version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin 2.02~beta2-33 amd64GRand Unified Bootloader, 
version 2 (EFI-AMD64 binaries)
ii  grub2-common   2.02~beta2-33 amd64GRand Unified Bootloader 
(common files for version 2)

On a system that dual boots Linux and Windows 10, the latest grub-efi gives
this error:

error: symbol 'grub_efi_find_last_device_path' not found

when attempting to boot Windows 10 after an update-grub is performed.  Linux
will boot correctly;  however,  an attempt to boot Windows 10 will give this
error and say "press any key..." and bring one back to the OS menu.

There is a workaround, which is to downgrade back to 2.02~beta2-32, and
Windows will boot correctly.

This clearly indicates that GRUB is incorrectly installed in some way,
because you could only get a symbol mismatch such as this if the GRUB
image you're actually booting from doesn't match the modules it tries to
load from /boot/grub/ at run-time.  I would suggest digging around in
your EFI System Partition to see if there's a manually-copied version in
there somewhere.

I definitely did not copy anything manually into the EFI System 
Partition;  if a rogue file got into there -- or if something didn't get 
updated there that should have -- it happened via process.  A downgrade 
back to 32 worked fine,  an upgrade to 33 broke down, bothe of these 
performed using dpkg/apt-get.  About all I can say.




Bug#808366: grub-efi-amd64 -- error: symbol 'grub_efi_find_last_device_path' not found

2015-12-18 Thread S. R. Wright

Package: grub-efi-amd64
Version: 2.02~beta2-33
Severity: serious


dpkg -l "grub*" | egrep "^ii"

ii  grub-common2.02~beta2-33 amd64GRand Unified Bootloader 
(common files)
ii  grub-efi   2.02~beta2-33 amd64GRand Unified Bootloader, 
version 2 (dummy package)
ii  grub-efi-amd64 2.02~beta2-33 amd64GRand Unified Bootloader, 
version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin 2.02~beta2-33 amd64GRand Unified Bootloader, 
version 2 (EFI-AMD64 binaries)
ii  grub2-common   2.02~beta2-33 amd64GRand Unified Bootloader 
(common files for version 2)

On a system that dual boots Linux and Windows 10, the latest grub-efi 
gives this error:


error: symbol 'grub_efi_find_last_device_path' not found

when attempting to boot Windows 10 after an update-grub is performed.  
Linux will boot correctly;  however,  an attempt to boot Windows 10 will 
give this error and say "press any key..." and bring one back to the OS 
menu.


There is a workaround, which is to downgrade back to 2.02~beta2-32, and 
Windows will boot correctly.




Bug#798811: x11-xserver-utils xrandr: shows display in connected state after disconnecting it with --off option

2015-09-13 Thread S. R. Wright

Package: x11-xserver-utils
Version: 7.7+5


Kernel: 4.2.0
Arch: amd64


The xrandr query command shows a display that had been disconnected with:

xrandr --output LVDS-1  --off

as still being connected.  My host has an LCD display (LVDS-1) and an 
external monitor (VGA-1).  Starting with both connected:



> xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS-1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 
345mm x 194mm

   1600x900  59.98*+
   1152x864  59.96
   1024x768  59.92
   800x600   59.86
   640x480   59.38
   720x400   59.55
   640x400   59.95
   640x350   59.77
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
eDP-1 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
VGA-1 connected primary 1920x1080+0+0 (normal left inverted right x axis 
y axis) 510mm x 287mm

   1920x1080 60.00*+
   1680x1050 59.95
   1280x1024 60.02
   1440x900  59.89
   1280x720  60.00
   1024x768  60.00
   800x600   60.32
   640x480   60.00
   720x400   70.08

Both displays are active and mirroring.  After running "xrandr --output 
LVDS-1  --off"  the LCD goes dark and the output now is:


> xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS-1 connected (normal left inverted right x axis y axis)


   1600x900  59.98 +
   1152x864  59.96
   1024x768  59.92
   800x600   59.86
   640x480   59.38
   720x400   59.55
   640x400   59.95
   640x350   59.77
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
eDP-1 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
VGA-1 connected primary 1920x1080+0+0 (normal left inverted right x axis 
y axis) 510mm x 287mm

   1920x1080 60.00*+
   1680x1050 59.95
   1280x1024 60.02
   1440x900  59.89
   1280x720  60.00
   1024x768  60.00
   800x600   60.32
   640x480   60.00
   720x400   70.08

However it still indicates that LVDS-1 is "connected" and some apps I 
have tried (notably qiv, vlc and virtualbox guests) seem confused and 
believe fullscreen is still 1600x900 and NOT 1920x1080.


This may be pilot error,  but I would have suspected that LVDS-1 should 
be "disconnected" and that apps should be completely unaware of its 
existence and not use its res as fullscreen.




Bug#762876: re: bind 9 crash / assertion failure

2014-09-28 Thread S. R. Wright
On Sat, 27 Sep 2014 23:48:10 -0400 Michael Gilbert mgilb...@debian.org 
wrote:

 control: tag -1 moreinfo

 Could someone experiencing this please attach configuration files?
 I'm not able to reproduce it with a vanilla installation.

 Best wishes,
 Mike



It pretty reliably crashed for me with the simplest of caching-only name 
servers;  all I needed to do was start bind,  then start web browsing 
and it would trip the assertion failure very quickly.  -- sRw



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#762876: named assertion failure in bind9 1:9.9.5.dfsg-4.1 in mem.c

2014-09-26 Thread S. R. Wright
I can confirm that a rollback to version 1:9.9.5.dfsg-4 works 
correctly.  My name server is just caching-only.


-- sRw


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#762876: named assertion failure in bind9 1:9.9.5.dfsg-4.1 in mem.c

2014-09-25 Thread S. R. Wright

Package: bind9
Version: 1:9.9.5.dfsg-4.1

From syslog:
Sep 25 15:16:21 odeon named[12685]: mem.c:1321: REQUIRE(ptr != ((void *)0)) 
failed, back trace
Sep 25 15:16:21 odeon named[12685]: #0 0x7fd64356522d in ??
Sep 25 15:16:21 odeon named[12685]: #1 0x7fd6417527ba in ??
Sep 25 15:16:21 odeon named[12685]: #2 0x7fd64176302c in ??
Sep 25 15:16:21 odeon named[12685]: #3 0x7fd642e14694 in ??
Sep 25 15:16:21 odeon named[12685]: #4 0x7fd642dc016a in ??
Sep 25 15:16:21 odeon named[12685]: #5 0x7fd642da7c29 in ??
Sep 25 15:16:21 odeon named[12685]: #6 0x7fd642da7d99 in ??
Sep 25 15:16:21 odeon named[12685]: #7 0x7fd642e1b7fd in ??
Sep 25 15:16:21 odeon named[12685]: #8 0x7fd642e29bf0 in ??
Sep 25 15:16:21 odeon named[12685]: #9 0x7fd641773eeb in ??
Sep 25 15:16:21 odeon named[12685]: #10 0x7fd6411250a4 in ??
Sep 25 15:16:21 odeon named[12685]: #11 0x7fd640af5c2d in ??

Kernel:

uname -r

3.16.3

Essentially, after an upgrade of bind9, bind9-host, and bind9utils,  named 
restarted and crashed very soon
afterwards.  Doing a service restart on bind9 would get it working again,  but 
it would crash again relatively
quickly.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org