Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Mon, Nov 28, 2016 at 5:15 PM, Ben Hutchingswrote: >> >> 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
On 26/11/16 01:15, riku.voi...@linaro.org wrote: From: Riku VoipioCurrently, 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
On Tue, 29 Nov 2016 01:15:48 + Ben Hutchingswrote: > [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
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
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
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
[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 Pigginwrote: > > > > > > 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
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
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
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
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
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]