Processed (with 1 error): Re: Bug#832359: linux-kbuild-4.6: Please include "scripts/headers_install.sh" and "scripts/unifdef", needed by "scripts/Makefile.headersinst"
Processing control commands: > retitle -1 linux-kbuild include useless Makefile.headersinst Bug #832359 [linux-kbuild-4.6] linux-kbuild-4.6: Please include "scripts/headers_install.sh" and "scripts/unifdef", needed by "scripts/Makefile.headersinst" Changed Bug title to 'linux-kbuild include useless Makefile.headersinst' from 'linux-kbuild-4.6: Please include "scripts/headers_install.sh" and "scripts/unifdef", needed by "scripts/Makefile.headersinst"'. > severity -1 minor Bug #832359 [linux-kbuild-4.6] linux-kbuild include useless Makefile.headersinst Severity set to 'minor' from 'normal' > severity -1 wontfix Severity level `wontfix' is not known. Recognized are: critical, grave, serious, important, normal, minor, wishlist, fixed. -- 832359: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832359 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#832359: linux-kbuild-4.6: Please include "scripts/headers_install.sh" and "scripts/unifdef", needed by "scripts/Makefile.headersinst"
Control: retitle -1 linux-kbuild include useless Makefile.headersinst Control: severity -1 minor Control: severity -1 wontfix On Sun, 2016-07-24 at 17:10 +0200, Jan Luca Naumann wrote: > Package: linux-kbuild-4.6 > Version: 4.6.4-1 > Severity: normal > > In linux-kbuild-* the Makefile "scripts/Makefile.headersinst" is included. > The Makefile needs the shell script "scripts/headers_install.sh" which is > not included in the current version of linux-kbuild-4.6. > > Can you please include this script "scripts/headers_install.sh" and the tool > "scripts/unifdef" (needed by scripts/headers_install.sh) in the package? linux-kbuild exists to support building out-of-tree modules, for which I believe this Makefile is never needed. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#832458: linux-image-4.6.0-0.bpo.1-amd64: Please enable SND_SOC_INTEL_BYT_MAX98090_MACH, needed for some Baytrail devices
Package: src:linux Version: 4.6.3-1~bpo8+1 Severity: normal Dear Maintainer, Please enable CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH=m - it is necessary for audio on certain Baytrail hardware. (I note that it is also necessary to set CONFIG_DW_DMAC=y (not m) for this, although I don't understand why.) Thank you, Ivan -- Package-specific info: ** Version: Linux version 4.6.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.6.3-1~bpo8+1 (2016-07-13) [ omitting irrelevant info, although I think the following line from dmesg is relevant: ] intel_sst_acpi 80860F28:00: No matching machine driver found
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Some additional Information which probably helps to find the root cause: The very same beheaviour (as in Jessie) is still shown in Stretch. I already tried to assign that bug to package "mount", but this was not accepted. The corresponding bug report demonstrates some more possibilities of "how you can workaroung" this faulty beheaviour. See here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788547#12
Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On Mon, Jul 25, 2016 at 01:41:41PM +0200, Ingo Jürgensmann wrote: > On 25.07.2016 12:23, Wei Liu wrote: > > First, thank you for replying! Very much appreciated! :) > > >I did skim your emails. But the oops was happening in memcpy+0x6 which > >indicated it came back to the origin question why would it got an > >exception there. > > > >Just by staring at the code doesn't get me anywhere. Without a concrete > >reproduction of the issue, I'm afraid I can't provide more input here. > > Well, from my point of view, it happens quite often when accessing the > server via SSH. For example today it crashed when I wanted to add something > and after I clicked into putty and typed the first char. In another putty, > where I have my netconsole log open, I instantly saw the oops. > > But what exactly causing these kinds of reboots, I'm clueless as you too. > Only that I do experience far more frequent crashes when accessing the > server from workplace via putty on Windows than via SSH on OSX or Debian > Linux. > > >There are several moving parts: > >0. Hardware > >1. Xen hypervisor > >2. Dom0 kernel > >Your report and the debian report suggested that Dom0 kernel is less > >likely to be the culprit because you've tried different Dom0 kernels. > > As just written in the other mail, I already tried kernel 4.5 from > backports. Still crashing. > > >As for Xen, not sure if you would be up for trying a debug build from > >source tree. That would help provide information on whether this is a > >bug in Xen or not. > > Will try to build from Debian source, but how to enable debug build? > I was thinking about building directly from xen.git. http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source Probably try the Xen 4.7 release. Wei. > -- > Ciao... //http://blog.windfluechter.net > Ingo \X/ XMPP: i...@jabber.windfluechter.net > > > gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On 25.07.2016 12:23, Wei Liu wrote: First, thank you for replying! Very much appreciated! :) I did skim your emails. But the oops was happening in memcpy+0x6 which indicated it came back to the origin question why would it got an exception there. Just by staring at the code doesn't get me anywhere. Without a concrete reproduction of the issue, I'm afraid I can't provide more input here. Well, from my point of view, it happens quite often when accessing the server via SSH. For example today it crashed when I wanted to add something and after I clicked into putty and typed the first char. In another putty, where I have my netconsole log open, I instantly saw the oops. But what exactly causing these kinds of reboots, I'm clueless as you too. Only that I do experience far more frequent crashes when accessing the server from workplace via putty on Windows than via SSH on OSX or Debian Linux. There are several moving parts: 0. Hardware 1. Xen hypervisor 2. Dom0 kernel Your report and the debian report suggested that Dom0 kernel is less likely to be the culprit because you've tried different Dom0 kernels. As just written in the other mail, I already tried kernel 4.5 from backports. Still crashing. As for Xen, not sure if you would be up for trying a debug build from source tree. That would help provide information on whether this is a bug in Xen or not. Will try to build from Debian source, but how to enable debug build? -- Ciao... //http://blog.windfluechter.net Ingo \X/ XMPP: i...@jabber.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
>
> Are you sure this is the correct syntax? I would expect that you
> should specify the mountpoint (target directory) rather than the
> source of the mount. eg. mount /home/ingo/leo.Bilder
> Do using that still give you the same problem?
Great, at least that works as expected if target directory is used.
But "man mount" explicitely states:
"When mounting a filesystem mentioned in fstab or mtab, it suffices to
give only the device, or only the mount point."
Moreover my syntax (using the device/source has worked flawlewssly since
I am using Linux. In Debian I use it since Lenny! And it works if the
command is issued as 'root'.
>
> Might also be useful to have a log of what strace tells you about
> running the command.
For completenes here the stace output:
~$ strace -Ff -tt mount leo:/Bilder 2>&1 | tee strace-mount.log
09:54:06.486801 execve("/bin/mount", ["mount", "leo:/Bilder"], [/* 36
vars */]) = 0
09:54:06.487198 brk(0) = 0x1295000
09:54:06.487350 fcntl(0, F_GETFD) = 0
09:54:06.487410 fcntl(1, F_GETFD) = 0
09:54:06.487438 fcntl(2, F_GETFD) = 0
09:54:06.487465 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487533 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487571 mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315787000
09:54:06.487629 access("/etc/ld.so.preload", R_OK) = 0
09:54:06.487704 open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487742 fstat(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
09:54:06.48 mmap(NULL, 28, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0)
= 0x7f4315786000
09:54:06.487810 close(3)= 0
09:54:06.487846 open("/opt/lib/libmediaclient.so", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487880 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\35\0\0\0\0\0\0"...,
832) = 832
09:54:06.487914 fstat(3, {st_mode=S_IFREG|0755, st_size=64168, ...}) = 0
09:54:06.487948 mmap(NULL, 2161808, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315359000
09:54:06.487981 mprotect(0x7f4315368000, 2093056, PROT_NONE) = 0
09:54:06.488017 mmap(0x7f4315567000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f4315567000
09:54:06.488061 close(3)= 0
09:54:06.488094 munmap(0x7f4315786000, 28) = 0
09:54:06.488130 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
09:54:06.488163 fstat(3, {st_mode=S_IFREG|0644, st_size=144332, ...}) = 0
09:54:06.488195 mmap(NULL, 144332, PROT_READ, MAP_PRIVATE, 3, 0) =
0x7f4315763000
09:54:06.488227 close(3)= 0
09:54:06.488259 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488297 open("/lib/x86_64-linux-gnu/libmount.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488333 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\254\0\0\0\0\0\0"...,
832) = 832
09:54:06.488366 fstat(3, {st_mode=S_IFREG|0644, st_size=284096, ...}) = 0
09:54:06.488400 mmap(NULL, 2383648, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315113000
09:54:06.488432 mprotect(0x7f4315156000, 2097152, PROT_NONE) = 0
09:54:06.488465 mmap(0x7f4315356000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x43000) = 0x7f4315356000
09:54:06.488504 mmap(0x7f4315358000, 3872, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315358000
09:54:06.488542 close(3)= 0
09:54:06.488577 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488611 open("/lib/x86_64-linux-gnu/libselinux.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488644 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20c\0\0\0\0\0\0"...,
832) = 832
09:54:06.488677 fstat(3, {st_mode=S_IFREG|0644, st_size=142728, ...}) = 0
09:54:06.488709 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315762000
09:54:06.488745 mmap(NULL, 2246896, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314eee000
09:54:06.488777 mprotect(0x7f4314f0f000, 2097152, PROT_NONE) = 0
09:54:06.488814 mmap(0x7f431510f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f431510f000
09:54:06.488852 mmap(0x7f4315111000, 6384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315111000
09:54:06.488890 close(3)= 0
09:54:06.488924 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488960 open("/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488995 read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"...,
832) = 832
09:54:06.489028 fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
09:54:06.489061 mmap(NULL, 3844640, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314b43000
09:54:06.489094 mprotect(0x7f4314ce5000, 2093056, PROT_NONE) = 0
09:54:06.489128
