Bug#849051: linux-image-4.8.0-2-amd64: Random segfaults with Radeon HD 4250

[Styopa Semenukha]

Package: src:linux
Version: 4.8.11-1
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,

The recent kernel update causes segfaults and system hanging when using
graphical mode. Segfaults randomly occur to graphical apps, always occur
to apps using hardware acceleration (e.g. chromium), occur under various
DE (tried KDE, Fluxbox). Segfaults never occur in text terminal mode.

However, when I boot into 4.8.0-1 or earlier versions, the system works
flawlessly, including hardware acceleration.

I'll be glad to provide any additional information. Thanks.

-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 5.4.1 
20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 (2016-12-02)

** Command line:
BOOT_IMAGE=/vmlinuz-4.8.0-2-amd64 
root=UUID=7d081ac6-a56b-49a4-8afc-658cb48fc974 ro single 
resume=/dev/mapper/wd-swap

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[6.865521] it87: Beeping is supported
[6.871580] Loading iSCSI transport class v2.0-870.
[6.880628] iscsi: registered transport (tcp)
[6.912687] iscsi: registered transport (iser)
[7.010766] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input4
[7.012362] ACPI: Power Button [PWRB]
[7.014189] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
[7.016262] ACPI: Power Button [PWRF]
[7.020242] acpi_cpufreq: overriding BIOS provided _PSD data
[7.027987] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[7.039831] wmi: Mapper loaded
[7.063462] sd 0:0:0:0: Attached scsi generic sg0 type 0
[7.065638] sd 2:0:0:0: Attached scsi generic sg1 type 0
[7.067853] sr 3:0:0:0: Attached scsi generic sg2 type 5
[7.070203] sd 6:0:0:0: Attached scsi generic sg3 type 0
[7.072827] sd 6:0:0:1: Attached scsi generic sg4 type 0
[7.075388] sd 6:0:0:2: Attached scsi generic sg5 type 0
[7.080628] sd 6:0:0:3: Attached scsi generic sg6 type 0
[7.083422] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
[7.085055] sp5100_tco: PCI Vendor ID: 0x1002, Device ID: 0x4385, Revision 
ID: 0x42
[7.085488] sd 7:0:0:0: Attached scsi generic sg7 type 0
[7.085571] sd 7:0:0:1: Attached scsi generic sg8 type 0
[7.085696] sd 7:0:0:2: Attached scsi generic sg9 type 0
[7.085946] sd 7:0:0:3: Attached scsi generic sg10 type 0
[7.094338] sp5100_tco: Using 0xfed80b00 for watchdog MMIO address
[7.095738] sp5100_tco: Last reboot was not triggered by watchdog.
[7.098515] sp5100_tco: initialized (0xa90f80e6cb00). heartbeat=60 sec 
(nowayout=0)
[7.124534] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:05.1/sound/card1/input6
[7.128612] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC889: 
line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[7.130123] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.131644] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[7.133145] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[7.134637] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x11/0x1e
[7.136125] snd_hda_codec_realtek hdaudioC0D0:inputs:
[7.141568] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
[7.143094] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
[7.144545] snd_hda_codec_realtek hdaudioC0D0:  Line=0x1a
[7.158656] random: crng init done
[7.168801] input: HDA ATI SB Front Mic as 
/devices/pci:00/:00:14.2/sound/card0/input7
[7.170315] input: HDA ATI SB Rear Mic as 
/devices/pci:00/:00:14.2/sound/card0/input8
[7.171784] input: HDA ATI SB Line as 
/devices/pci:00/:00:14.2/sound/card0/input9
[7.173249] input: HDA ATI SB Line Out Front as 
/devices/pci:00/:00:14.2/sound/card0/input10
[7.174874] input: HDA ATI SB Line Out Surround as 
/devices/pci:00/:00:14.2/sound/card0/input11
[7.176365] input: HDA ATI SB Line Out CLFE as 
/devices/pci:00/:00:14.2/sound/card0/input12
[7.177856] input: HDA ATI SB Line Out Side as 
/devices/pci:00/:00:14.2/sound/card0/input13
[7.179407] input: HDA ATI SB Front Headphone as 
/devices/pci:00/:00:14.2/sound/card0/input14
[7.199100] kvm: Nested Virtualization enabled
[7.200849] kvm: Nested Paging enabled
[7.340670] media: Linux media interface: v0.10
[7.349591] Linux video capture interface: v2.00
[7.364772] uvcvideo: Found UVC 1.00 device  (046d:081a)
[7.384328] uvcvideo 3-1:1.0: Entity type for entity Extension 4 was not 
initialized!
[7.386372] uvcvideo 3-1:1.0: Entity type for entity Extension 6 was not 
initialized!
[7.388353] uvcvideo 3-1:1.0: Entity type for entity Extension 7 was not 
initialized!
[7.390327] uvcvideo 3-1:1.0: Entity type for entity Processing 2 was not 

Re: Trying to build both linux kernel + kernel/debian from .git

[Ben Hutchings]

On Thu, 2016-12-22 at 15:02 +1100, Andrew Worsley wrote:
> Help appreciated on how these two .git repositories are expected to
> work together. Or just if they are not meant to.
> 
> I am trying to do a git bisect to see when the hibernation bug#844788 (
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844788 )
> 
> I have checked out the mainline kernel into linux and then checked out
> https://anonscm.debian.org/git/kernel/linux.git  into
>    /build/linux/debian-linux
> 
> - which apprently gives a debian directory for the kernel .
> 
> I then do a symbolic link from with the mainline linux checkout to the
> debian directory check out:
> 
> debian -> /build/linux/debian-linux/debian
> 
> Using git tag -l to find a suitable tag and then select the kernel a
> similar tag and build the release and install it and see if it works.
>
> But this doesn't seem to work at all  so I guess is completely wrong
> 
> I get errors like:
> 
> fakeroot make -f debian/rules -n binarymacbook: 2:51PM
> dh_testdir
> make -f debian/rules.gen binary-indep
> make[1]: Entering directory '/build/deb-linux'
> make[1]: debian/rules.gen: No such file or directory
> make[1]: *** No rule to make target 'debian/rules.gen'.  Stop.
> make[1]: Leaving directory '/build/deb-linux'
> debian/rules:46: recipe for target 'binary-indep' failed
> make: *** [binary-indep] Error 2

Various files (debian/control, debian/rules.gen, etc.) are generated by
debian/bin/gencontrol.py and are not committed.

Also one of the first things in the build rules is a check that all
patches were applied - which they aren't.

> I was trying to just compile mainline kernels (no debian patches) via
> 
> make deb-pkg
> 
> 
> Kinda of getting stuck -Hitting problems where ever I turn to. Recent
> 4.9 kernels compile and run - but hibernate doesn't restore
> 
> My mainline 3.18 kernel + initrd just crash without any output after
> booting from grub when building with a stretch based system (needs a
> few patches to compile them).
> 
> I am suspecting the stretch based system might be causing the older
> kernels problems.

It's possible that they don't build as expected with the current
compiler and linker.

> Perhaps using containers to build them under older releases might
> fix things?

Yes, it might do.

> I am thinking I need a working serial port (not a laptop) to debug the
> restore crashes or perhaps try and reproduce things via kvm?

KVM is unlikely to reproduce the issue as it will be emulatng different
devices.

netconsole *might* help:
https://www.kernel.org/doc/Documentation/networking/netconsole.txt

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin


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

Re: Backport facebook IPv6 routing table PMTU exception patch

[Ben Hutchings]

On Wed, 2016-12-21 at 13:14 -0800, Rumen Telbizov wrote:
[...]
> Due to the severity of this, I was wondering if you could consider
> backporting that patch for the 3.16 kernel as well?
>
> Additional details regarding the patch are available at:
> https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/

Having read that page, this sounds much too risky to try backporting.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Trying to build both linux kernel + kernel/debian from .git

[Andrew Worsley]

Help appreciated on how these two .git repositories are expected to
work together. Or just if they are not meant to.

I am trying to do a git bisect to see when the hibernation bug#844788 (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844788 )

I have checked out the mainline kernel into linux and then checked out
https://anonscm.debian.org/git/kernel/linux.git  into
   /build/linux/debian-linux

- which apprently gives a debian directory for the kernel .

I then do a symbolic link from with the mainline linux checkout to the
debian directory check out:

debian -> /build/linux/debian-linux/debian

Using git tag -l to find a suitable tag and then select the kernel a
similar tag and build the release and install it and see if it works.

But this doesn't seem to work at all  so I guess is completely wrong

I get errors like:

fakeroot make -f debian/rules -n binarymacbook: 2:51PM
dh_testdir
make -f debian/rules.gen binary-indep
make[1]: Entering directory '/build/deb-linux'
make[1]: debian/rules.gen: No such file or directory
make[1]: *** No rule to make target 'debian/rules.gen'.  Stop.
make[1]: Leaving directory '/build/deb-linux'
debian/rules:46: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2

I was trying to just compile mainline kernels (no debian patches) via

make deb-pkg


Kinda of getting stuck -Hitting problems where ever I turn to. Recent
4.9 kernels compile and run - but hibernate doesn't restore

My mainline 3.18 kernel + initrd just crash without any output after
booting from grub when building with a stretch based system (needs a
few patches to compile them).

I am suspecting the stretch based system might be causing the older
kernels problems. Perhaps using containers to build them under older
releases might fix things?

I am thinking I need a working serial port (not a laptop) to debug the
restore crashes or perhaps try and reproduce things via kvm?

No easy paths...

Andrew

Bug#839157: marked as done (xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, depends on kernel-VERSION, not provided by unsigned-kernel-Package)

[Debian Bug Tracking System]

Your message dated Thu, 22 Dec 2016 00:04:30 +
with message-id <1482365070.2677.6.ca...@decadent.org.uk>
and subject line Re: xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, 
depends on kernel-VERSION, not provided by unsigned-kernel-Package
has caused the Debian Bug report #839157,
regarding xen-linux-system-4.7.0-0.bpo.1-amd64: jessie-backports, depends on 
kernel-VERSION, not provided by unsigned-kernel-Package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
839157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839157
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xen-linux-system-4.7.0-0.bpo.1-amd64
Version: 4.7.2-1~bpo8+1
Severity: normal
Tags: patch

Dear Maintainer,

Package depends on "linux-image-4.7 (= VERSION)
-
Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1), xen-system-amd64
-

In jessie-backports in the moment there is just
linux-image-4.7.0-0.bpo.1-amd64-unsigned which
-
Provides: linux-image-4.7.0-0.bpo.1-amd64
-
This can not satisfy the Depends:.

So Depends:-Line could be
-
Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1) | 
linux-image-4.7.0-0.bpo.1-amd64-unsigned (= 4.7.2-1~bpo8+1), xen-system-amd64
-




-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (101, 'testing'), (100, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xen-linux-system-4.7.0-0.bpo.1-amd64 depends on:
ii  linux-image-4.7.0-0.bpo.1-amd64-unsigned [linux-image-4.7.0  4.7.2-1~bpo8+1
ii  xen-system-amd64 4.4.1-9+deb8u7

xen-linux-system-4.7.0-0.bpo.1-amd64 recommends no packages.

xen-linux-system-4.7.0-0.bpo.1-amd64 suggests no packages.

-- no debconf information
--- control	2016-09-07 22:41:42.0 +0200
+++ control_20160929	2016-09-29 16:49:20.899532199 +0200
@@ -4,7 +4,7 @@
 Architecture: amd64
 Maintainer: Debian Kernel Team 
 Installed-Size: 404
-Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1), xen-system-amd64
+Depends: linux-image-4.7.0-0.bpo.1-amd64 (= 4.7.2-1~bpo8+1) | linux-image-4.7.0-0.bpo.1-amd64-unsigned (= 4.7.2-1~bpo8+1), xen-system-amd64
 Section: metapackages
 Priority: optional
 Homepage: https://www.kernel.org/
--- End Message ---
--- Begin Message ---
This is not a bug.  The 'unsigned' packages shouldn't get installed
automatically.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Bug#838607: marked as done (linux-image-4.7.0-0.bpo.1-amd64-unsigned: new file date writing issue)

[Debian Bug Tracking System]

Your message dated Thu, 22 Dec 2016 00:05:24 +
with message-id <1482365124.2677.7.ca...@decadent.org.uk>
and subject line Re: Bug#838607: linux-image-4.7.0-0.bpo.1-amd64-unsigned: new 
file date writing issue
has caused the Debian Bug report #838607,
regarding linux-image-4.7.0-0.bpo.1-amd64-unsigned: new file date writing issue
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838607
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: linux-image-4.7.0-0.bpo.1-amd64-unsigned
Version: 4.7.2-1~bpo8+1
Severity: normal

There's a bug with ext4 on the new 4.7 kernel -- rare but it happened 
here on an ext4 mountpoint (/home /dev/md1   ext4  rw,relatime,data=ordered)


when a new file is created, the "create time" is not properly set.(2014 
was written as the create year instead of 2016)


it occured today after I updated to 4.7 so I can only assume it has 
something to do with it..


my system here has "mdadm" containers, and perhaps it's possible a set 
of conditions allowed this rarity to occur.
--- End Message ---
--- Begin Message ---
Closing due to lack of response.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily
Tomlin



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

Re: Backport facebook IPv6 routing table PMTU exception patch

[Ozgur Karatas]

21.12.2016, 23:59, "Rumen Telbizov" :Hello, The original patch has been put together against 4.1/4.2 kernel and as such will probably need to be modified to work on 3.16. While I could try adapt it and patch my kernel, this would mean that going forward I'll need to maintain this and keep patching and rebuilding after every change from Debian. Not ideal. Moreover, no other Debian jessie 3.16 user would benefit from the fix. Again, even today users could run the 4.7 from backports and benefit from the patch but how many do that? I would assume that most users will run the default 3.16 which leaves them exposed to this DoS scenario. In short, if Debian maintains the patch all jessie IPv6 users running default kernel will benefit from this going forward. Thank you for your feedback and consideration. Regards,Rumen Telbizov Dear Telbizov; you are very right and please don't understand me wrong, I'm not a Debian maintainer :) but I just explain my idea. I think, maintainer's will be taken into your consideration. Thanks for information, Regards ~Ozgur

Re: Backport facebook IPv6 routing table PMTU exception patch

[Rumen Telbizov]

Hello,

The original patch has been put together against 4.1/4.2 kernel and as such
will probably need to be modified to work on 3.16. While I could try adapt
it and patch my kernel, this would mean that going forward I'll need to
maintain this and keep patching and rebuilding after every change from
Debian. Not ideal. Moreover, no other Debian jessie 3.16 user would benefit
from the fix.

Again, even today users could run the 4.7 from backports and benefit from
the patch but how many do that? I would assume that most users will run the
default 3.16 which leaves them exposed to this DoS scenario.

In short, if Debian maintains the patch all jessie IPv6 users running
default kernel will benefit from this going forward.

Thank you for your feedback and consideration.

Regards,
Rumen Telbizov

On Wed, Dec 21, 2016 at 1:22 PM, Ozgur Karatas 
wrote:

> Hello,
>
> As you have mentioned this patchset has already been reported for the
> linux-kernel.
> For now, you can patch to kernel and run udpflood and test to systems.
>
> The bug only module -not kernel-, I think, you can use the kernel module
> and fix it.
>
> http://www.spinics.net/lists/netdev/msg301225.html
>
> Thanks for report.
>
> Regards,
>
> ~Ozgur
>
> 21.12.2016, 23:14, "Rumen Telbizov" :
>
> Dear Debian kernel maintainers,
>
> This might be a long shot but I decided to ask here anyway. If nothing
> else I hope to bring more awareness.
>
> The current kernel in Debian Jessie (3.16) is prone to a
> resource-exhaustion attack against its IPv6 routing table. In short, every
> time a packet from a new IPv6 peer is received an entry is created in the
> IPv6 routing table. This serves as a cache (although it's in the same
> table) so that MTU and other parameters are stored on a per-peer basis.
> This creates the potential for an attacker to quickly fill up the table by
> sending packets from different source addresses. The effect is that as the
> table gets full the garbage collector starts running back-to-back using
> 100% system CPU causing the system to degrade rapidly.
>
> The above is my understanding anyway and might be partially incorrect.
>
> Facebook has contributed a patch which skips the creation of a new entry
> if the MTU is the same as the default route (which is almost always the
> case), thus keeping the table small. Unfortunately that patch has been
> introduced sometime after 4.1-4.2 kernels and is not present in the default
> Debian Jessie kernel. It does seem to be fixed in the 4.7 from backports.
>
> Due to the severity of this, I was wondering if you could consider
> backporting that patch for the 3.16 kernel as well?
>
> Additional details regarding the patch are available at:
> https://code.facebook.com/posts/1123882380960538/linux-
> ipv6-improvement-routing-cache-on-demand/
>
> ​Regards,​
> --
> Rumen Telbizov
> Unix Systems Administrator 
>
>


-- 
Rumen Telbizov
Unix Systems Administrator 

Re: Backport facebook IPv6 routing table PMTU exception patch

[Ozgur Karatas]

Hello, As you have mentioned this patchset has already been reported for the linux-kernel.For now, you can patch to kernel and run udpflood and test to systems. The bug only module -not kernel-, I think, you can use the kernel module and fix it. http://www.spinics.net/lists/netdev/msg301225.html Thanks for report. Regards, ~Ozgur 21.12.2016, 23:14, "Rumen Telbizov" :Dear Debian kernel maintainers,This might be a long shot but I decided to ask here anyway. If nothing else I hope to bring more awareness.The current kernel in Debian Jessie (3.16) is prone to a resource-exhaustion attack against its IPv6 routing table. In short, every time a packet from a new IPv6 peer is received an entry is created in the IPv6 routing table. This serves as a cache (although it's in the same table) so that MTU and other parameters are stored on a per-peer basis. This creates the potential for an attacker to quickly fill up the table by sending packets from different source addresses. The effect is that as the table gets full the garbage collector starts running back-to-back using 100% system CPU causing the system to degrade rapidly.The above is my understanding anyway and might be partially incorrect.Facebook has contributed a patch which skips the creation of a new entry if the MTU is the same as the default route (which is almost always the case), thus keeping the table small. Unfortunately that patch has been introduced sometime after 4.1-4.2 kernels and is not present in the default Debian Jessie kernel. It does seem to be fixed in the 4.7 from backports. Due to the severity of this, I was wondering if you could consider backporting that patch for the 3.16 kernel as well?Additional details regarding the patch are available at: https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/ ​Regards,​--Rumen TelbizovUnix Systems Administrator

Backport facebook IPv6 routing table PMTU exception patch

[Rumen Telbizov]

Dear Debian kernel maintainers,

This might be a long shot but I decided to ask here anyway. If nothing else
I hope to bring more awareness.

The current kernel in Debian Jessie (3.16) is prone to a
resource-exhaustion attack against its IPv6 routing table. In short, every
time a packet from a new IPv6 peer is received an entry is created in the
IPv6 routing table. This serves as a cache (although it's in the same
table) so that MTU and other parameters are stored on a per-peer basis.
This creates the potential for an attacker to quickly fill up the table by
sending packets from different source addresses. The effect is that as the
table gets full the garbage collector starts running back-to-back using
100% system CPU causing the system to degrade rapidly.

The above is my understanding anyway and might be partially incorrect.

Facebook has contributed a patch which skips the creation of a new entry if
the MTU is the same as the default route (which is almost always the case),
thus keeping the table small. Unfortunately that patch has been introduced
sometime after 4.1-4.2 kernels and is not present in the default Debian
Jessie kernel. It does seem to be fixed in the 4.7 from backports.

Due to the severity of this, I was wondering if you could consider
backporting that patch for the 3.16 kernel as well?

Additional details regarding the patch are available at:
https://code.facebook.com/posts/1123882380960538/linux-ipv6-improvement-routing-cache-on-demand/

​Regards,​
-- 
Rumen Telbizov
Unix Systems Administrator 

Bug#848967: linux-image: Power button of Dell XPS13 does not send any events

[Paul Menzel]

Package: src:linux
Version: 4.8.11-1
Severity: normal

Dear Debian folk,


pressing the power button on the Dell XPS13 no event is sent.

Neither `xev` nor `acpi_listen` shows something.

If I remember correctly, it worked on the shipped Ubuntu 16.04 from Dell.


Kind regards,

Paul Menzel

-- Package-specific info:
** Version:
Linux version 4.8.0-2-amd64 (debian-kernel@lists.debian.org) (gcc 
version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1 
(2016-12-02)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-amd64 
root=UUID=2809c0c6-7152-4e35-a6da-a26e7400e556 ro quiet


** Not tainted

** Kernel log:
[2.356558] Bluetooth: HCI UART protocol Intel registered
[2.356568] Bluetooth: HCI UART protocol BCM registered
[2.356568] Bluetooth: HCI UART protocol QCA registered
[2.362373] ACPI: Battery Slot [BAT0] (battery present)
[2.362520] wmi: Mapper loaded
[2.363711] idma64 idma64.0: Found Intel integrated DMA 64-bit
[2.364301] intel-lpss :00:15.1: enabling device ( -> 0002)
[2.364519] idma64 idma64.1: Found Intel integrated DMA 64-bit
[2.364872] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[2.366919] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:04F3:2234.0001/input/input8

[2.368091] mei_me :00:16.0: enabling device ( -> 0002)
[2.368133] hid-multitouch 0003:04F3:2234.0001: 
input,hiddev0,hidraw0: USB HID v1.10 Device [ELAN Touchscreen] on 
usb-:00:14.0-4/input0

[2.369771] input: PC Speaker as /devices/platform/pcspkr/input/input10
[2.381350] usbcore: registered new interface driver btusb
[2.382577] bluetooth hci0: firmware: failed to load 
qca/rampatch_usb_0302.bin (-2)
[2.382751] bluetooth hci0: Direct firmware load for 
qca/rampatch_usb_0302.bin failed with error -2
[2.382753] Bluetooth: hci0: failed to request rampatch file: 
qca/rampatch_usb_0302.bin (-2)

[2.383359] i801_smbus :00:1f.4: SMBus using PCI interrupt
[2.471578] dcdbas dcdbas: Dell Systems Management Base Driver 
(version 5.6.0-3.2)

[2.480502] [drm] Memory usable by graphics device = 4096M
[2.480504] [drm] Replacing VGA console driver
[2.483581] ath10k_pci :3a:00.0: pci irq msi oper_irq_mode 2 
irq_mode 0 reset_mode 0

[2.484252] Console: switching to colour dummy device 80x25
[2.487901] intel_rapl: Found RAPL domain package
[2.487903] intel_rapl: Found RAPL domain core
[2.487903] intel_rapl: Found RAPL domain uncore
[2.487904] intel_rapl: Found RAPL domain dram
[2.490884] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.490885] [drm] Driver supports precise vblank timestamp query.
[2.492445] iTCO_vendor_support: vendor-support=0
[2.493325] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[2.493484] iTCO_wdt: Found a Intel PCH TCO device (Version=4, 
TCOBASE=0x0400)

[2.493628] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[2.496855] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[2.497712] i915 :00:02.0: firmware: direct-loading firmware 
i915/kbl_dmc_ver1_01.bin

[2.498292] [drm] Finished loading i915/kbl_dmc_ver1_01.bin (v1.1)
[2.504002] [drm] GuC firmware load skipped
[2.542973] ACPI: Video Device [GFX0] (multi-head: yes  rom: no 
post: no)
[2.543853] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input11
[2.544275] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[2.544279] [drm] Initialized i915 1.6.0 20160711 for :00:02.0 on 
minor 0

[2.553300] fbcon: inteldrmfb (fb0) is primary device
[2.608135] snd_hda_codec_realtek hdaudioC0D0: autoconfig for 
ALC3246: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[2.608136] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[2.608137] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)

[2.608137] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[2.608138] snd_hda_codec_realtek hdaudioC0D0:inputs:
[2.608139] snd_hda_codec_realtek hdaudioC0D0:  Headset Mic=0x19
[2.608139] snd_hda_codec_realtek hdaudioC0D0:  Headphone Mic=0x1a
[2.608140] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[2.622922] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[2.624693] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[2.624748] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[2.624791] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[2.624866] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input16

[2.720318] random: crng init done
[2.734006] input: DLL075B:01