Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

2016-11-28 Thread Linus Torvalds
On Mon, Nov 28, 2016 at 5:15 PM, Ben Hutchings  wrote:
>>
>> The modversions stuff may just be too painful to bother with. Very few
>> people probably use it, and the ones that do likely don't have any
>> overriding reason why.
> [...]
>
> Debian has some strong reasons:

Honestly, I'd just like to see actual real patches from people who
care about this.

The reason I disabled it entirely was simply that the discussions had
been going on forever, but nobody actually seemed to care enough to
just fix the damn thing. There was all the _noise_ about "look, here's
a patch", but nothing got sent to maintainers and actually actively
pushed as a "this fixes a regression".

At some point I just get fed up and say "this isn't worth the hot air
and endless pointless blathering".

What is the actual exact failure with MODVERSIONS today? IOW, if you
just remove the "broken", is it actually broken, and why? Because it
does work for me, I just got really tired of hearing about it, and
assuming it's just some broken toolchain or other case that I just
don't hit.

So somebody send me a minimal patch that is

 (a) tested
 (b) explains it
 (c) obvious

and I'll happily re-enable modversions.

Linus



Re: [PATCH] builddeb: add make fastdeb-pkg target

2016-11-28 Thread Andrew Donnellan

On 26/11/16 01:15, riku.voi...@linaro.org wrote:

From: Riku Voipio 

Currently, the deb-pkg and bindeb-pkg targets create multiple packages
for the kernel binaries, headers, userspace headers and firmware.

For developers who generate Debian packages as part of their development
workflows, it's often not necessary to generate all these packages.

Introduce new target, fastdeb-pkg, which only generates kernel packages.
Re-order package build order so that kernel binary package is created
first and we can exit cleanly unless generating rest packages with the
old bindeb-pkg and deb-pkg targets.

Cc: Jim Davis 
Cc: Andrew Donnellan 
Signed-off-by: Riku Voipio 


Some comments below. With those addressed:

Reviewed-by: Andrew Donnellan 


---
 scripts/package/Makefile |  7 ++-
 scripts/package/builddeb | 49 +---
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 71b4a8a..c858366 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -97,6 +97,10 @@ bindeb-pkg: FORCE
$(MAKE) KBUILD_SRC=
+$(call cmd,builddeb)

+fastdeb-pkg: FORCE
+   $(MAKE) KBUILD_SRC=
+   +$(call cmd,builddeb)
+
 clean-dirs += $(objtree)/debian/


@@ -142,7 +146,8 @@ help: FORCE
@echo '  rpm-pkg - Build both source and binary RPM kernel 
packages'
@echo '  binrpm-pkg  - Build only the binary kernel RPM package'
@echo '  deb-pkg - Build both source and binary deb kernel 
packages'
-   @echo '  bindeb-pkg  - Build only the binary kernel deb package'
+   @echo '  bindeb-pkg  - Build all binary kernel deb packages'
+   @echo '  fastdeb-pkg - Build only the binary kernel deb package'


Perhaps "kernel image deb package" to be more specific?


@echo '  tar-pkg - Build the kernel as an uncompressed 
tarball'
@echo '  targz-pkg   - Build the kernel as a gzip compressed 
tarball'
@echo '  tarbz2-pkg  - Build the kernel as a bzip2 compressed 
tarball'
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..5035f57 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -185,11 +185,6 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
fi
 fi

-if [ "$ARCH" != "um" ]; then
-   $MAKE headers_check KBUILD_SRC=
-   $MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
-fi
-
 # Install the maintainer scripts
 # Note: hook scripts under /etc/kernel are also executed by official Debian
 # kernel packages, as well as kernel packages built using make-kpkg.
@@ -323,6 +318,32 @@ EOF

 fi

+# Do we have firmware? Move it out of the way and build it into a package.


This comment is no longer accurate as we split the move and the build.


+if [ -e "$tmpdir/lib/firmware" ]; then
+   mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
+   rmdir "$tmpdir/lib/firmware"
+fi
+
+create_package "$packagename" "$tmpdir"
+[ "x$1" = "xfastdeb-pkg" ] && exit 0


How idiomatic is [ condition ] && command vs if [ condition ]; then 
command; fi? Perhaps it's just my lack of bash-fu but this took me a 
moment to parse.



+
+if [ -e "$fwdir/lib/firmware/$version" ]; then
+   cat <> debian/control
+
+Package: $fwpackagename
+Architecture: all
+Description: Linux kernel firmware, version $version
+ This package contains firmware from the Linux kernel, version $version.
+EOF
+
+   create_package "$fwpackagename" "$fwdir"
+fi
+
+if [ "$ARCH" != "um" ]; then
+   $MAKE headers_check KBUILD_SRC=
+   $MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
+fi
+
 # Build kernel header package
 (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > 
"$objtree/debian/hdrsrcfiles"
 (cd $srctree; find arch/*/include include scripts -type f) >> 
"$objtree/debian/hdrsrcfiles"
@@ -354,22 +375,6 @@ Description: Linux kernel headers for $KERNELRELEASE on 
\${kernel:debarch}
  This is useful for people who need to build external modules
 EOF

-# Do we have firmware? Move it out of the way and build it into a package.
-if [ -e "$tmpdir/lib/firmware" ]; then
-   mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
-   rmdir "$tmpdir/lib/firmware"
-
-   cat <> debian/control
-
-Package: $fwpackagename
-Architecture: all
-Description: Linux kernel firmware, version $version
- This package contains firmware from the Linux kernel, version $version.
-EOF
-
-   create_package "$fwpackagename" "$fwdir"
-fi
-
 cat <> debian/control

 Package: $libc_headers_packagename
@@ -386,8 +391,6 @@ if [ "$ARCH" != "um" ]; then
create_package "$libc_headers_packagename" "$libc_headers_dir"
 fi

-create_package 

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

2016-11-28 Thread Nicholas Piggin
On Tue, 29 Nov 2016 01:15:48 +
Ben Hutchings  wrote:

> [I've had to guess at the cc list for this, because we no longer have
> mail archives that preserve them.]

You got it about right.

> On Fri, 2016-11-25 at 10:01 -0800, Linus Torvalds wrote:
> > On Thu, Nov 24, 2016 at 4:40 PM, Nicholas Piggin  wrote: 
> >  
> > > > 
> > > > Yes, manual "marking" is never going to be a viable solution.  
> > > 
> > > I guess it really depends on how exactly you want to use it. For distros
> > > that do stable ABI but rarely may have to break something for security
> > > reasons, it should work and give exact control.  
> 
> This is roughly how Debian handles the kernel module ABI during a
> stable release.
> 
> > No. Because nobody else will care, so unless it's like a single symbol
> > or something, it will just be a maintenance nightmare.  
> 
> I agree with this.  We can explicitly "version" individual symbols
> anyway by doing something like:
> 
> -int foo(void);
> +#define foo foo_2
> +int foo_2(int);

Yeah... Benefit being it's very simple and everybody can see exactly
what it does and knows how it will work.

> 
> > > What else do people *actually* use it for? Preventing mismatched modules
> > > when .git version is not attached and release version of the kernel has
> > > not been bumped. Is that it?  
> > 
> > It used to be very useful for avoiding loading stale modules and then
> > wasting days on debugging something that wasn't the case when you had
> > forgotten to do "make modules_install". Change some subtle internal
> > ABI issue (add/remove a parameter, whatever) and it would really help.
> > 
> > These days, for me, LOCALVERSION_AUTO and module signing are what I
> > personally tend to use.
> >
> > The modversions stuff may just be too painful to bother with. Very few
> > people probably use it, and the ones that do likely don't have any
> > overriding reason why.  
> [...]
> 
> Debian has some strong reasons:
> 
> 1. Changing the release string requires any out-of-tree modules to be
> upgraded (at least rebuilt) on end-user systems.  So we try to avoid
> doing that during the lifetime of a stable release, i.e. we don't let
> the release string change.  Also, the release string is reflected in
> package names (e.g. linux-image-4.8.0-1-amd64), and introducing new
> package names requires manual approval by the Debian archive team.

This is something I've noticed. Would it be better if the module loader
ignores the kernel version and instead used some internal ABI version
string to check against? Otherwise (AFAICT) you always have 4.8.0 versions
despite being 4.8.7 kernel, and you can't upgrade a point release without
overwriting your old kernel and modules.

That is something we could potentially replace modversions with. It would
be a far more reasonable complexity to carry for downstream distros than
modversions. Though not something we can add for 4.9.

> 2. We want to allow ABI breaks for "internal" symbols used only by in-
> tree modules, as those breaks will be resolved by rebooting to complete
> the upgrade.  But we need a run-time check to prevent loading an
> incompatible module before the reboot.
> 
> 3. So far as I can see, module signing doesn't work for a distribution
> kernel with out-of-tree modules as there has to be a trust path from a
> built-in certificate to the module signing certificate.  So signature
> enforcement will have to be disabled on systems that use out-of-tree
> modules, thus it's not a substitute for modversions.
> 
> We expect Linux 4.9 to be the basis for a longterm stable branch and on
> that basis intend to include it in the next Debian stable release. 
> Even if the decision is to get rid of modversions, it would be very
> helpful if they could be revived for 4.9 so that we have some time to
> adapt our packaging practices to work without them in future.

It would be nice to get upstream to the point where 4.9 modversions
works if you just patch out depends BROKEN. That would require reverting
a few more of Al's arch patches.

Then in 4.10 we can re-add all those arch patches (which are less
controversial without the asm-prototypes.h workaround), and implement a
simple stable ABI version string check, and then in 4.11 we can remove
modversions.

Thanks,
Nick



Bug#846157: compile fails

2016-11-28 Thread Ben Hutchings
Control: reassign -1 src:linux 4.8.7-1
Control: forcemerge 841368 -1

On Mon, 2016-11-28 at 13:43 -0600, Brent S. Elmer wrote:
> Package: linux-source-4.8
> Version: 4.8.7-1
> Severity: normal
> 
> I am trying to compile a 4.8 kernel and it is failing.
[...]

This is a bug in Debian's package of gcc-6, but we will work around it
in the kernel source.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of
comp.compilers


signature.asc
Description: This is a digitally signed message part


Processed: Re: Bug#846157: compile fails

2016-11-28 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 src:linux 4.8.7-1
Bug #846157 [linux-source-4.8] compile fails
Bug reassigned from package 'linux-source-4.8' to 'src:linux'.
No longer marked as found in versions linux/4.8.7-1.
Ignoring request to alter fixed versions of bug #846157 to the same values 
previously set
Bug #846157 [src:linux] compile fails
Marked as found in versions linux/4.8.7-1.
> forcemerge 841368 -1
Bug #841368 {Done: Ben Hutchings } [src:linux] gcc-6 
6.2.0-7 breaks kernel build if stack protection is enabled
Bug #841420 {Done: Ben Hutchings } [src:linux] 
--enable-default-pie breaks kernel builds
Bug #841420 {Done: Ben Hutchings } [src:linux] 
--enable-default-pie breaks kernel builds
Marked as found in versions linux/4.8.7-1.
Marked as found in versions linux/4.8.7-1.
Bug #846157 [src:linux] compile fails
Severity set to 'serious' from 'normal'
Marked Bug as done
Marked as fixed in versions linux/4.9~rc3-1~exp1.
Marked as found in versions linux/4.7.6-1.
Merged 841368 841420 846157

-- 
841368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841368
841420: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841420
846157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846157
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: reassign 845927 to src:linux, reassign 845603 to src:linux, reassign 844124 to src:linux

2016-11-28 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 845927 src:linux
Bug #845927 [kernel] No sound Acer 2730 (Gnawty Atom 36x/37x series Atom
Warning: Unknown package 'kernel'
Bug reassigned from package 'kernel' to 'src:linux'.
No longer marked as found in versions 4.5.
Ignoring request to alter fixed versions of bug #845927 to the same values 
previously set
> reassign 845603 src:linux
Bug #845603 [realtek] realtek: not Found Firmware RTL8101E/RTL8102E
Warning: Unknown package 'realtek'
Bug reassigned from package 'realtek' to 'src:linux'.
Ignoring request to alter found versions of bug #845603 to the same values 
previously set
Ignoring request to alter fixed versions of bug #845603 to the same values 
previously set
> reassign 844124 src:linux
Bug #844124 [linux-vyatta-kbuild-4.9] linux-vyatta-kbuild-4.9: Lintian error: 
wrong-path-for-interpreter
Warning: Unknown package 'linux-vyatta-kbuild-4.9'
Bug reassigned from package 'linux-vyatta-kbuild-4.9' to 'src:linux'.
Ignoring request to alter found versions of bug #844124 to the same values 
previously set
Ignoring request to alter fixed versions of bug #844124 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
844124: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844124
845603: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845603
845927: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845927
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems




Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

2016-11-28 Thread Ben Hutchings
[I've had to guess at the cc list for this, because we no longer have
mail archives that preserve them.]

On Fri, 2016-11-25 at 10:01 -0800, Linus Torvalds wrote:
> On Thu, Nov 24, 2016 at 4:40 PM, Nicholas Piggin  wrote:
> > > 
> > > Yes, manual "marking" is never going to be a viable solution.
> > 
> > I guess it really depends on how exactly you want to use it. For distros
> > that do stable ABI but rarely may have to break something for security
> > reasons, it should work and give exact control.

This is roughly how Debian handles the kernel module ABI during a
stable release.

> No. Because nobody else will care, so unless it's like a single symbol
> or something, it will just be a maintenance nightmare.

I agree with this.  We can explicitly "version" individual symbols
anyway by doing something like:

-int foo(void);
+#define foo foo_2
+int foo_2(int);

> > What else do people *actually* use it for? Preventing mismatched modules
> > when .git version is not attached and release version of the kernel has
> > not been bumped. Is that it?
> 
> It used to be very useful for avoiding loading stale modules and then
> wasting days on debugging something that wasn't the case when you had
> forgotten to do "make modules_install". Change some subtle internal
> ABI issue (add/remove a parameter, whatever) and it would really help.
> 
> These days, for me, LOCALVERSION_AUTO and module signing are what I
> personally tend to use.
>
> The modversions stuff may just be too painful to bother with. Very few
> people probably use it, and the ones that do likely don't have any
> overriding reason why.
[...]

Debian has some strong reasons:

1. Changing the release string requires any out-of-tree modules to be
upgraded (at least rebuilt) on end-user systems.  So we try to avoid
doing that during the lifetime of a stable release, i.e. we don't let
the release string change.  Also, the release string is reflected in
package names (e.g. linux-image-4.8.0-1-amd64), and introducing new
package names requires manual approval by the Debian archive team.

2. We want to allow ABI breaks for "internal" symbols used only by in-
tree modules, as those breaks will be resolved by rebooting to complete
the upgrade.  But we need a run-time check to prevent loading an
incompatible module before the reboot.

3. So far as I can see, module signing doesn't work for a distribution
kernel with out-of-tree modules as there has to be a trust path from a
built-in certificate to the module signing certificate.  So signature
enforcement will have to be disabled on systems that use out-of-tree
modules, thus it's not a substitute for modversions.

We expect Linux 4.9 to be the basis for a longterm stable branch and on
that basis intend to include it in the next Debian stable release. 
Even if the decision is to get rid of modversions, it would be very
helpful if they could be revived for 4.9 so that we have some time to
adapt our packaging practices to work without them in future.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of
comp.compilers



signature.asc
Description: This is a digitally signed message part


Bug#846157: compile fails

2016-11-28 Thread Brent S. Elmer
Package: linux-source-4.8
Version: 4.8.7-1
Severity: normal

I am trying to compile a 4.8 kernel and it is failing.

exec make kpkg_version=13.018 -f /usr/share/kernel-package/ruleset/minimal.mk
debian APPEND_TO_VERSION=.161128  INITRD=YES
== making target debian/stamp/conf/minimal_debian [new prereqs: ]==
This is kernel package version 13.018.
test -d debian || mkdir debian
test ! -e stamp-building || rm -f stamp-building
install -p -m 755 /usr/share/kernel-package/rules debian/rules
for file in ChangeLog  Control  Control.bin86 config templates.in rules; do
\
cp -f  /usr/share/kernel-package/$file ./debian/;
\
done
cp: cannot stat '/usr/share/kernel-package/ChangeLog': No such file or
directory
for dir  in Config docs examples ruleset scripts pkg po;  do
\
  cp -af /usr/share/kernel-package/$dir  ./debian/;
\
done
test -f debian/control || sed -e 's/=V/4.8.7.161128/g'  \
-e 's/=D/4.8.7.161128-10.00.Custom/g' -e 's/=A/amd64/g'
\
-e 's/=SA//g'  \
-e 's/=I//g'\
-e 's/=CV/4.8/g'\
-e 's/=M/Unknown Kernel Package Maintainer /g' \
-e 's/=ST/linux/g'  -e 's/=B/x86_64/g'\
-e 's/=R/initramfs-tools | linux-initramfs-tool,/g'
/usr/share/kernel-package/Control > debian/control
test -f debian/changelog ||  sed -e 's/=V/4.8.7.161128/g'   \
-e 's/=D/4.8.7.161128-10.00.Custom/g'-e 's/=A/amd64/g'
\
-e 's/=ST/linux/g' -e 's/=B/x86_64/g' \
-e 's/=M/Unknown Kernel Package Maintainer
/g'\
 /usr/share/kernel-package/changelog > debian/changelog
chmod 0644 debian/control debian/changelog
test -d ./debian/stamp || mkdir debian/stamp
make -f debian/rules debian/stamp/conf/kernel-conf
make[1]: Entering directory '/usr/local/src/linux-source-4.8'
== making target debian/stamp/conf/kernel-conf [new prereqs: ]==
make EXTRAVERSION=.161128   ARCH=x86_64 \
oldconfig;
make[2]: Entering directory '/usr/local/src/linux-source-4.8'
  HOSTCC  scripts/basic/bin2c
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
make[2]: Leaving directory '/usr/local/src/linux-source-4.8'
make EXTRAVERSION=.161128   ARCH=x86_64 prepare
make[2]: Entering directory '/usr/local/src/linux-source-4.8'
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
  HYPERCALLS arch/x86/entry/syscalls/../../include/generated/asm/xen-
hypercalls.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:1052: recipe for target 'prepare-compiler-check' failed
make[2]: *** [prepare-compiler-check] Error 1
make[2]: Leaving directory '/usr/local/src/linux-source-4.8'
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/local/src/linux-source-4.8'
/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.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-source-4.8 depends on:
ii  binutils  2.27.51.20161108-1
ii  xz-utils  5.2.2-1.2

Versions of packages linux-source-4.8 recommends:
ii  bc1.06.95-9+b2
ii  gcc   4:6.1.1-1
ii  libc6-dev [libc-dev]  2.24-5
ii  make  4.1-9

Versions of packages linux-source-4.8 suggests:
ii  libncurses5-dev [ncurses-dev]  6.0+20160917-1
ii  libqt4-dev 

Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

2016-11-28 Thread Sven Joachim
On 2016-11-28 14:50 +0100, Matthias Klose wrote:

> please could you check again with
> https://people.debian.org/~doko/tmp/binutils_2.27.51.20161127-1.1_amd64.deb
> having the suggested fix proposed at
> https://sourceware.org/ml/binutils/2016-11/msg00348.html

Works for me, thanks. :-)

Cheers,
   Sven



Bug#766829: linux-image-3.16-3-amd64: Uncleared pch fifo underrun on pch transcoder A

2016-11-28 Thread Lorenzo Ancora
Package: src:linux
Version: 3.16.36-1+deb8u2
Followup-For: Bug #766829

I have the same issue (Windows/Debian dual boot with LVM2).
The boot continues unless the errors happen after an hibernation, and in the
last case I get a KERNEL PANIC and I must reboot, losing my work session.



-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/Sistema-Debian ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   13.776389] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d448
[   13.776399] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d400
[   13.776404] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d490
[   13.776408] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d4d8
[   13.776412] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d520
[   13.776416] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d568
[   13.776419] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d5b0
[   13.776962] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 
detected
[   13.793096] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0005 detected
[   13.793580] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   13.794273] usbcore: registered new interface driver rt2800usb
[   13.869830] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[   14.087377] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
usrquota,grpquota,user_xattr,journal_async_commit,auto_da_alloc,i_version
[   14.091088] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
usrquota,grpquota,user_xattr
[   14.289974] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[   14.322146] systemd-journald[209]: Received request to flush runtime journal 
from PID 1
[   14.345252] ip_tables: (C) 2000-2006 Netfilter Core Team
[   14.352884] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   14.371661] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   14.845552] RPC: Registered named UNIX socket transport module.
[   14.845559] RPC: Registered udp transport module.
[   14.845562] RPC: Registered tcp transport module.
[   14.845564] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   14.852650] FS-Cache: Loaded
[   14.866711] FS-Cache: Netfs 'nfs' registered for caching
[   14.889879] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[   15.588639] vboxdrv: Found 4 processor cores.
[   15.588833] vboxdrv: fAsync=0 offMin=0x1aa offMax=0xc92
[   15.588896] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 
'normal'.
[   15.588898] vboxdrv: Successfully loaded version 4.3.36_Debian (interface 
0x001a000b).
[   15.671544] vboxpci: IOMMU not found (not registered)
[   19.524010] e1000e :00:19.0: irq 42 for MSI/MSI-X
[   19.627858] e1000e :00:19.0: irq 42 for MSI/MSI-X
[   19.628171] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   19.719888] brcmsmac bcma0:0: firmware: direct-loading firmware 
brcm/bcm43xx-0.fw
[   19.739517] brcmsmac bcma0:0: firmware: direct-loading firmware 
brcm/bcm43xx_hdr-0.fw
[   19.914068] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false 
(implement)
[   19.914086] brcmsmac bcma0:0: brcms_ops_config: change power-save mode: 
false (implement)
[   19.914787] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   19.917629] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt2870.bin'
[   20.001134] rt2800usb 3-2:1.0: firmware: direct-loading firmware rt2870.bin
[   20.001155] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware 
detected - version: 0.29
[   20.234783] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   21.229571] wlan0: authenticate with e0:3f:49:96:04:a0
[   21.233420] wlan0: direct probe to e0:3f:49:96:04:a0 (try 1/3)
[   21.435193] wlan0: direct probe to e0:3f:49:96:04:a0 (try 2/3)
[   21.639116] wlan0: direct probe to e0:3f:49:96:04:a0 (try 3/3)
[   21.842962] wlan0: authentication with e0:3f:49:96:04:a0 timed out
[   28.646246] wlan0: authenticate with e0:3f:49:96:04:a0
[   28.648446] wlan0: send auth to e0:3f:49:96:04:a0 (try 1/3)
[   28.752763] wlan0: send auth to e0:3f:49:96:04:a0 (try 2/3)
[   28.754735] wlan0: authenticated
[   28.756742] wlan0: associate with e0:3f:49:96:04:a0 (try 1/3)
[   28.762557] wlan0: RX AssocResp from e0:3f:49:96:04:a0 (capab=0x411 status=0 
aid=2)
[   28.763114] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: 
associated
[   28.763121] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true 
(implement)
[   28.763134] wlan0: associated
[ 

Re: Bug#845690: gcc-6: gcc creates unbootable kernel on x86-64

2016-11-28 Thread Matthias Klose
On 27.11.2016 19:27, Sven Joachim wrote:
> On 2016-11-27 18:34 +0100, Matthias Klose wrote:
> 
>> On 27.11.2016 16:51, Sven Joachim wrote:
>>> On 2016-11-27 13:39 +0100, Matthias Klose wrote:
>>>
 Control: tags -1 + help moreinfo
 Control: severity -1 important

 On 27.11.2016 08:38, Sven Joachim wrote:
> Control: reassign -1 binutils 2.27.51.20161124-1
> Control: retitle -1 binutils: creates unbootable kernel on x86-64
> Control: severity -1 grave
>
> On 2016-11-26 15:13 +0100, Damien Wyart wrote:
>
>> After running further tests today, I think this is in fact *not*
>> related to gcc but to the kernel itself.
>>
>> I tested all 6.2.1-X versions as well as gcc-5 (5.4.1-3) and all the
>> kernels fail to boot (balck screen just after grub and nothing in the
>> logs).
>
> Same here, downgrading binutils to 2.27.51.20161118-2 helped.  I'm
> reassigning the bug and bumping the severity, since several people have
> observed the problem.

 The original report talks about a 4.4 problem on , which afaik is 
 superseded in
 unstable by newever versions released after the GCC 6 release.  This is 
 now made
 a binutils RC issue for building a kernel which is not in the archive 
 anymore.
 Please could you validate that the issue exists with the linux package in
 unstable as well?
>>>
>>> I have noticed the problem with vanilla Linux 4.8.11 from kernel.org, so
>>> I suspect the Debian kernel is affected as well.  There is no console
>>> output at all, the system freezes right when uncompressing the kernel.
>>>
>>> It should be noted that I haven't noticed the problem on my desktop
>>> (which has a 32-bit userland but a 64-bit kernel) where I have
>>> CONFIG_KERNEL_GZIP=y, but on my laptop which uses the default
>>> CONFIG_KERNEL_XZ=y it is reproducible.
>>
>> if it's really binutils, I prepared a package reverting the fix for PR 
>> ld/20815.
>> Would be nice if somebody could check that out:
>> https://people.debian.org/~doko/tmp/binutils_2.27.51.20161124-1.1_amd64.deb
> 
> Thanks, that binutils package produces a working kernel here.

please could you check again with
https://people.debian.org/~doko/tmp/binutils_2.27.51.20161127-1.1_amd64.deb
having the suggested fix proposed at
https://sourceware.org/ml/binutils/2016-11/msg00348.html



Bug#766829: linux-image-3.16-3-amd64: Uncleared pch fifo underrun on pch transcoder A

2016-11-28 Thread Lorenzo Ancora
Package: src:linux
Version: 3.16.36-1+deb8u2
Followup-For: Bug #766829

I have the same issue on a DELL LATITUDE 3330.
The boot continues unless the errors happen after an hibernation/suspension,
and in the last case I get a KERNEL PANIC. I must reboot (and lose the saved
session) to boot normally.



-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/Sistema-Debian ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   13.776389] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d448
[   13.776399] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d400
[   13.776404] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d490
[   13.776408] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d4d8
[   13.776412] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d520
[   13.776416] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d568
[   13.776419] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with 
disabled ep 8800d9a5d5b0
[   13.776962] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 
detected
[   13.793096] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0005 detected
[   13.793580] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   13.794273] usbcore: registered new interface driver rt2800usb
[   13.869830] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[   14.087377] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
usrquota,grpquota,user_xattr,journal_async_commit,auto_da_alloc,i_version
[   14.091088] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
usrquota,grpquota,user_xattr
[   14.289974] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: 
(null)
[   14.322146] systemd-journald[209]: Received request to flush runtime journal 
from PID 1
[   14.345252] ip_tables: (C) 2000-2006 Netfilter Core Team
[   14.352884] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   14.371661] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   14.845552] RPC: Registered named UNIX socket transport module.
[   14.845559] RPC: Registered udp transport module.
[   14.845562] RPC: Registered tcp transport module.
[   14.845564] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   14.852650] FS-Cache: Loaded
[   14.866711] FS-Cache: Netfs 'nfs' registered for caching
[   14.889879] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[   15.588639] vboxdrv: Found 4 processor cores.
[   15.588833] vboxdrv: fAsync=0 offMin=0x1aa offMax=0xc92
[   15.588896] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 
'normal'.
[   15.588898] vboxdrv: Successfully loaded version 4.3.36_Debian (interface 
0x001a000b).
[   15.671544] vboxpci: IOMMU not found (not registered)
[   19.524010] e1000e :00:19.0: irq 42 for MSI/MSI-X
[   19.627858] e1000e :00:19.0: irq 42 for MSI/MSI-X
[   19.628171] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   19.719888] brcmsmac bcma0:0: firmware: direct-loading firmware 
brcm/bcm43xx-0.fw
[   19.739517] brcmsmac bcma0:0: firmware: direct-loading firmware 
brcm/bcm43xx_hdr-0.fw
[   19.914068] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false 
(implement)
[   19.914086] brcmsmac bcma0:0: brcms_ops_config: change power-save mode: 
false (implement)
[   19.914787] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   19.917629] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt2870.bin'
[   20.001134] rt2800usb 3-2:1.0: firmware: direct-loading firmware rt2870.bin
[   20.001155] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware 
detected - version: 0.29
[   20.234783] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   21.229571] wlan0: authenticate with e0:3f:49:96:04:a0
[   21.233420] wlan0: direct probe to e0:3f:49:96:04:a0 (try 1/3)
[   21.435193] wlan0: direct probe to e0:3f:49:96:04:a0 (try 2/3)
[   21.639116] wlan0: direct probe to e0:3f:49:96:04:a0 (try 3/3)
[   21.842962] wlan0: authentication with e0:3f:49:96:04:a0 timed out
[   28.646246] wlan0: authenticate with e0:3f:49:96:04:a0
[   28.648446] wlan0: send auth to e0:3f:49:96:04:a0 (try 1/3)
[   28.752763] wlan0: send auth to e0:3f:49:96:04:a0 (try 2/3)
[   28.754735] wlan0: authenticated
[   28.756742] wlan0: associate with e0:3f:49:96:04:a0 (try 1/3)
[   28.762557] wlan0: RX AssocResp from e0:3f:49:96:04:a0 (capab=0x411 status=0 
aid=2)
[   28.763114] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: 
associated
[   28.763121] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true 
(implement)
[   28.763134]