linux_4.6.2-1_multi.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 15 Jun 2016 21:32:54 +0200
Source: linux
Binary: linux-source-4.6 linux-support-4.6.0-1 linux-doc-4.6 linux-manual-4.6 
linux-kbuild-4.6 linux-cpupower libcpupower0 libcpupower-dev linux-perf-4.6 
libusbip-dev usbip hyperv-daemons lockdep liblockdep4.6 liblockdep-dev 
linux-libc-dev linux-headers-4.6.0-1-all linux-headers-4.6.0-1-all-alpha 
kernel-image-4.6.0-1-alpha-generic-di nic-modules-4.6.0-1-alpha-generic-di 
nic-wireless-modules-4.6.0-1-alpha-generic-di 
nic-shared-modules-4.6.0-1-alpha-generic-di 
serial-modules-4.6.0-1-alpha-generic-di 
usb-serial-modules-4.6.0-1-alpha-generic-di 
ppp-modules-4.6.0-1-alpha-generic-di pata-modules-4.6.0-1-alpha-generic-di 
cdrom-core-modules-4.6.0-1-alpha-generic-di 
scsi-core-modules-4.6.0-1-alpha-generic-di 
scsi-modules-4.6.0-1-alpha-generic-di loop-modules-4.6.0-1-alpha-generic-di 
btrfs-modules-4.6.0-1-alpha-generic-di ext4-modules-4.6.0-1-alpha-generic-di 
isofs-modules-4.6.0-1-alpha-generic-di jfs-modules-4.6.0-1-alpha-generic-di 
xfs-modules-4.6.0-1-alpha-generic-di
 fat-modules-4.6.0-1-alpha-generic-di md-modules-4.6.0-1-alpha-generic-di 
multipath-modules-4.6.0-1-alpha-generic-di usb-modules-4.6.0-1-alpha-generic-di 
usb-storage-modules-4.6.0-1-alpha-generic-di 
fb-modules-4.6.0-1-alpha-generic-di input-modules-4.6.0-1-alpha-generic-di 
event-modules-4.6.0-1-alpha-generic-di mouse-modules-4.6.0-1-alpha-generic-di 
nic-pcmcia-modules-4.6.0-1-alpha-generic-di 
pcmcia-modules-4.6.0-1-alpha-generic-di 
nic-usb-modules-4.6.0-1-alpha-generic-di sata-modules-4.6.0-1-alpha-generic-di 
core-modules-4.6.0-1-alpha-generic-di crc-modules-4.6.0-1-alpha-generic-di 
crypto-modules-4.6.0-1-alpha-generic-di 
crypto-dm-modules-4.6.0-1-alpha-generic-di ata-modules-4.6.0-1-alpha-generic-di 
nbd-modules-4.6.0-1-alpha-generic-di squashfs-modules-4.6.0-1-alpha-generic-di 
virtio-modules-4.6.0-1-alpha-generic-di zlib-modules-4.6.0-1-alpha-generic-di 
fuse-modules-4.6.0-1-alpha-generic-di srm-modules-4.6.0-1-alpha-generic-di 
linux-headers-4.6.0-1-common
 linux-image-4.6.0-1-alpha-generic linux-headers-4.6.0-1-alpha-generic 
linux-image-4.6.0-1-alpha-smp linux-headers-4.6.0-1-alpha-smp 
linux-headers-4.6.0-1-all-amd64 kernel-image-4.6.0-1-amd64-di 
nic-modules-4.6.0-1-amd64-di nic-wireless-modules-4.6.0-1-amd64-di 
nic-shared-modules-4.6.0-1-amd64-di serial-modules-4.6.0-1-amd64-di 
usb-serial-modules-4.6.0-1-amd64-di ppp-modules-4.6.0-1-amd64-di 
pata-modules-4.6.0-1-amd64-di cdrom-core-modules-4.6.0-1-amd64-di 
firewire-core-modules-4.6.0-1-amd64-di scsi-core-modules-4.6.0-1-amd64-di 
scsi-modules-4.6.0-1-amd64-di loop-modules-4.6.0-1-amd64-di 
btrfs-modules-4.6.0-1-amd64-di ext4-modules-4.6.0-1-amd64-di 
isofs-modules-4.6.0-1-amd64-di jfs-modules-4.6.0-1-amd64-di 
ntfs-modules-4.6.0-1-amd64-di xfs-modules-4.6.0-1-amd64-di 
fat-modules-4.6.0-1-amd64-di md-modules-4.6.0-1-amd64-di 
multipath-modules-4.6.0-1-amd64-di usb-modules-4.6.0-1-amd64-di 
usb-storage-modules-4.6.0-1-amd64-di pcmcia-storage-modules-4.6.0-1-amd64-di
 fb-modules-4.6.0-1-amd64-di input-modules-4.6.0-1-amd64-di 
event-modules-4.6.0-1-amd64-di mouse-modules-4.6.0-1-amd64-di 
nic-pcmcia-modules-4.6.0-1-amd64-di pcmcia-modules-4.6.0-1-amd64-di 
nic-usb-modules-4.6.0-1-amd64-di sata-modules-4.6.0-1-amd64-di 
core-modules-4.6.0-1-amd64-di acpi-modules-4.6.0-1-amd64-di 
i2c-modules-4.6.0-1-amd64-di crc-modules-4.6.0-1-amd64-di 
crypto-modules-4.6.0-1-amd64-di crypto-dm-modules-4.6.0-1-amd64-di 
efi-modules-4.6.0-1-amd64-di ata-modules-4.6.0-1-amd64-di 
mmc-core-modules-4.6.0-1-amd64-di mmc-modules-4.6.0-1-amd64-di 
nbd-modules-4.6.0-1-amd64-di squashfs-modules-4.6.0-1-amd64-di 
speakup-modules-4.6.0-1-amd64-di virtio-modules-4.6.0-1-amd64-di 
uinput-modules-4.6.0-1-amd64-di sound-modules-4.6.0-1-amd64-di 
hyperv-modules-4.6.0-1-amd64-di udf-modules-4.6.0-1-amd64-di 
fuse-modules-4.6.0-1-amd64-di linux-image-4.6.0-1-amd64 
linux-headers-4.6.0-1-amd64 linux-image-4.6.0-1-amd64-dbg 
xen-linux-system-4.6.0-1-amd64
 linux-headers-4.6.0-1-common-rt linux-image-4.6.0-1-rt-amd64 
linux-headers-4.6.0-1-rt-amd64 linux-image-4.6.0-1-rt-amd64-dbg 
linux-headers-4.6.0-1-all-arm64 kernel-image-4.6.0-1-arm64-di 
nic-modules-4.6.0-1-arm64-di nic-wireless-modules-4.6.0-1-arm64-di 
nic-shared-modules-4.6.0-1-arm64-di ppp-modules-4.6.0-1-arm64-di 
cdrom-core-modules-4.6.0-1-arm64-di scsi-core-modules-4.6.0-1-arm64-di 
scsi-modules-4.6.0-1-arm64-di loop-modules-4.6.0-1-arm64-di 
btrfs-modules-4.6.0-1-arm64-di ext4-modules-4.6.0-1-arm64-di 
isofs-modules-4.6.0-1-arm64-di jfs-modules-4.6.0-1-arm64-di 
xfs-modules-4.6.0-1-arm64-di fat-modules-4.6.0-1-arm64-di 
md-modules-4.6.0-1-arm64-di multipath-modules-4.6.0-1-arm64-di 
usb-modules-4.6.0-1-arm64-di usb-storage-modules-4.6.0-1-arm64-di 
fb-modules-4.6.0-1-arm64-di input-modules-4.6.0-1-arm64-di 
event-modules-4.6.0-1-arm64-di nic-usb-modules-4.6.0-1-arm64-di 
sata-modules-4.6.0-1-arm64-di 

Bug#827342: linux-image-4.5.0-2-amd64: luks rootfs not recognized at boot after upgrade to linux-image 4.5.5

[Sander van Grieken]

On Wednesday 15 June 2016 12:21:56 Ben Hutchings wrote:
> > I have a LUKS rootfs on top of a mdadm managed raid0. Starting from 4.5.5 it
> > doesn't recognize the luks volume at boot. The same happens with 4.6.1
> 
> LUKS volumes are recognised and set uo by userland, so are you sure
> this is due to the kernel upgrade?
> 
> > The raid0 is not explicitly made with mdadm, it was previously handled by
> > dmraid I believe (fakeraid?)
> 
> I'm assuming that after a delay you see an '(initramfs)' shell prompt.
> Do you see any error messages before that?  If you then enter 'cat
> /proc/partitions', which devices does it show?

Downgrading to kernel 4.5.4 doesn't solve the issue, so it's probably not a 
kernel bug.

The only other upgrades in that timespan were e2fsprogs and e2fslibs, which 
I've also 
downgraded. That also didn't fix the problem, although I'm not sure if I 
correctly 
regenerated the initrd, since I'm not fluent with dracut..

I'll investigate further. This bug can be closed.

-Sander

Processing of linux_4.6.2-1_multi.changes

[Debian FTP Masters]

linux_4.6.2-1_multi.changes uploaded successfully to localhost
along with the files:
  linux_4.6.2-1.dsc
  linux_4.6.2.orig.tar.xz
  linux_4.6.2-1.debian.tar.xz

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

Re: VM crashes with linux-image-4.5.0-0.bpo.2-amd64:amd64/jessie-backports on KVM-Host

[Rolf Kutz]

Hi Nicholaѕ, 


thanks for your mail and sorry for my late answer.
I did some more examination and that fixed the
problem somehow. 


On 30/05/16 22:43 -0400, Nicholas D Steeves wrote:

"On 30 May 2016 at 03:32, Rolf Kutz  wrote:

Going back to linux-image-4.4.0-0.bpo.1-amd64 on the KVM-Server makes the
problem
disappear. Other VMs on that server run fine with both kernels. The VM in
question is an NFS4-Server running Debian
Jessie. The KVM-Images are on a BTRFS-Partition.


Just to clarify: 1. What kernel version is the VM host system?  2.
Have you installed mcelog and edac-utils on the host system?  3. Are
there any kernel, mce, or edac errors on the *host* system when you
encounter this crash?


1.) linux-image-4.5.0-0.bpo.2-amd64 when the problem was
happening, linux-image-4.4.0-0.bpo.1-amd64 when
not.

2.) I had those utilities installed and they
didn't report a problem. 


3.) No errors on the host system.


[1.794611] virtio: module verification failed: signature and/or required
key missing - tainting kernel


Tainted kernel.  How did this key verification failure of virtio module happen?


I don't know. But I don't see it any more with
virtio, but with scsi_mod on all my VMs like this:


[1.747969] scsi_mod: module verification failed: signature and/or
required key missing - tainting kernel


[...]


[3.162613]  [] ?


This makes me wonder if your ram is bad, of if your VM image is corrupt.




A bunch of pci-related errors.  Are you using virtio and/or pcie
passthrough?  I wonder if there are complementary errors in the dmesg
of the host kernel?


No, there are no messages in dmesg. I'm using
virtio, but no passthrough.


Well that's odd...again, I suspect VM image corruption.
My gut feeling is your VM images are corrupted, and/or that you have
bad ram.  I also wonder if it could be a virtio and/or pcie
passthrough issue if either are enabled...


RAM seems to be fine. Using ECC-RAM and no errors
where reported. I also would't suspect the same
outcome every time, with a RAM error. 


Could you please tell me a bit about your btrfs topology and which
features you've enabled?  


Some information about the btrfs topology:

# mount |grep btrfs
/dev/sdc1 on /srv/storage type btrfs 
(rw,noatime,compress=lzo,space_cache,autodefrag,subvolid=5,subvol=/)

# btrfs filesystem show 
Label: 'BTRFS_RAID'  uuid: 206a4530-6aff-4383-bb84-8cbf740eac1d

Total devices 2 FS bytes used 1.03TiB
devid1 size 3.64TiB used 1.07TiB path /dev/sdc1
devid2 size 3.64TiB used 1.07TiB path /dev/sdd1

# btrfs fi df /srv/storage/
Data, RAID1: total=1.06TiB, used=1.03TiB
Data, single: total=8.00MiB, used=0.00B
System, RAID1: total=8.00MiB, used=176.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, RAID1: total=3.00GiB, used=1.28GiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=448.00MiB, used=0.00B


Also, with what version of btrfs-progs did
you create the volume?  


ii  btrfs-tools3.17-1.1 amd64 Checksumming Copy on Write Files

I just noticed, that they where replaced by btrfs-progs, which I installed now.


Have you ever run a btrfs-scrub, btrfs-check,
or btrfs-balance on the host? (running which kernel, with which
version of btrfs-progs...)  If you haven't yet, please don't run
either until we discuss this some more.  Was your btrfs volume created
with btrfs-convert?  Are you running the host's btrfs volume on top of
LVM, MD, and/or in combination with a caching layer?


I did run a scrub whith the above tools. Don't
know the exact kernel version, but it was a kernel
from jessie-backports, probably 4.3.x. No errors
reported. Never did a balance or convert.

Do you think I should do it again with the newer
btrfs-progs?


In addition to answering all of these questions, could you please
trigger this again and send the host dmesg?


I did some testing and after installing some
different kernel versions on the VM, I couldn't
trigger the problem anymore. The system is stable
for weeks now. I suspect the VM-Image got
corrupted. I still can't explain, why it always
booted without problems the first time and crashed
on reboot.


Finally, because you're testing btrfs, you have recent backups, and
backups from before this error manifested, right?


Yes, I have backups of my data. :)

thanks and best regards
Rolf

--
People should not be afraid of their governments, governments should be
afraid of their people. - V

Re: Radeon driver not works on PPC with X800

[Ben Hutchings]

On Wed, 2016-06-15 at 20:39 +0200, TCH wrote:
> Hi!
> 
> I have an old G4 MDD, with an X800 card. I've just installed Debian Jessie
> and tried to breathe life into the 2d acceleration, but without success. If
> i install "firmware-linux-nonfree", then it loads the "r420_cp.bin", but
> then i only got a black screen after boot and the machine freezes
> completely.
> 
> My dmesg log:
> http://oscomp.hu/depot/dmesg.log
> 
> And xorg.log after a crash:
> http://oscomp.hu/depot/Xorg.0.log
> 
> I don't know if i am at the right place with this, but nobody could help me
> with this. Is this a known problem on PPC with X800 cards? I've read in
> this topic (http://ubuntuforums.org/showthread.php?t=1825309=2) that
> radeon not works with X800 on PPC.

So you read that it won't work, and indeed it doesn't work for you. 
Where's the surprise?

> Can anyone help me with this?

The Linux port to Power Macs is no longer actively developed and no-one 
on the Debian kernel team looks after them.
You might be able to get some help on the debian-powerpc list.  But if
you already asked there, you are out of luck.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.

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

Processed: Re: Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable

[Debian Bug Tracking System]

Processing control commands:

> tag -1 -moreinfo
Bug #827309 [src:linux] linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi 
unstable
Removed tag(s) moreinfo.

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

Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable

[Paul Gevers]

Control: tag -1 -moreinfo

On 14-06-16 23:16, Ben Hutchings wrote:
> What was the previous installed version?  (/var/log/dpkg.log should
> show this.)

2016-06-05 10:31:50 upgrade linux-image-3.16.0-4-kirkwood:armel
3.16.7-ckt25-1 3.16.7-ckt25-2

Paul




signature.asc
Description: OpenPGP digital signature

Radeon driver not works on PPC with X800

[TCH]

Hi!

I have an old G4 MDD, with an X800 card. I've just installed Debian Jessie
and tried to breathe life into the 2d acceleration, but without success. If
i install "firmware-linux-nonfree", then it loads the "r420_cp.bin", but
then i only got a black screen after boot and the machine freezes
completely.

My dmesg log:
http://oscomp.hu/depot/dmesg.log

And xorg.log after a crash:
http://oscomp.hu/depot/Xorg.0.log

I don't know if i am at the right place with this, but nobody could help me
with this. Is this a known problem on PPC with X800 cards? I've read in
this topic (http://ubuntuforums.org/showthread.php?t=1825309=2) that
radeon not works with X800 on PPC.

Can anyone help me with this?

- TCH

Processed: Re: Bug#827392: linux-image-4.6.0.-1-amd64: issues with intel xorg driver

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:linux
Bug #827392 [linux-image-4.6.0.-1-amd64] linux-image-4.6.0.-1-amd64: issues 
with intel xorg driver
Warning: Unknown package 'linux-image-4.6.0.-1-amd64'
Bug reassigned from package 'linux-image-4.6.0.-1-amd64' to 'src:linux'.
No longer marked as found in versions linux-image-4.6.0-1-amd64.
Ignoring request to alter fixed versions of bug #827392 to the same values 
previously set
> found -1 4.6.1-1
Bug #827392 [src:linux] linux-image-4.6.0.-1-amd64: issues with intel xorg 
driver
Marked as found in versions linux/4.6.1-1.

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

Re: Bug#827392: linux-image-4.6.0.-1-amd64: issues with intel xorg driver

[Mattia Rizzolo]

control: reassign -1 src:linux
control: found -1 4.6.1-1

[ please leave me out when discussing this bug ]

On Wed, Jun 15, 2016 at 06:54:56PM +0200, Vieno Foo wrote:
> Package: linux-image-4.6.0.-1-amd64

typo in the package name

> Version: linux-image-4.6.0-1-amd64

and this is not a valid version

reassignin accordingly.

> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>change from linux-image-4.5.0-2-amd64 to linux-image-4.6.0-1-amd64
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>running xorg
> 
>* What was the outcome of this action?
>when running linux 4.6.0-1-amd64 the xorg freezes for minutes or even
>crashes
> 
>* What outcome did you expect instead?
>having a graphical user interface without freezes or other issues
>linux 4.5.0-2-amd64 is running fine
> 
>* used hardware
>00:02.0 VGA compatible controller [0300]: Intel Corporation Braswell
>Integrated Graphics Controller [8086:22b1] (rev 21)
> 
> kind regards
> txt.file
> 
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.5.0-2-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCgAGBQJXYYhQAAoJEDm/gvVZCGXo5LoP/0cqstZIrzH8ejaweJaKcE+N
> vRAHQl95ELmO+QVA0eZOV36nUWzo7YdONwpWrAbzNQbOf+lFVELMhTrtX3yHySWP
> n8iMKsB6ryuO0rl+pBse+K5EOS61asHfDqpT32heWd5NR2W1MyheIsE3dJKnZ5MC
> 7dg57IqLWuvjnHMaaJJv25E4KSAfR899ffAaFwPLxwaqmnigbo1mbERxPMHvZh+7
> Kb8h0EV1NRZDqoTouIZSK6X0RxF0GEc4K5WYSiI8C6h3VbNeFt2NoHVGLEGDa445
> Ff5FuOw2tcj/5qdpDvtnPY9A4/DAFRK2KBrtjrPpkMxJQIsPbbuwgmhfCbhw+mZ6
> xY/uGqSOCU8nLoy1V1K67XrLMArMHYiF7/JjxGssYO3YiuJD+e696nxugR71Q4qP
> +hz5WkyN55ItOTpse8ywLlRHntV00XtqZvMEWod2iE0hU/fF8u1SqshVO+VGpJrK
> csds6V3YxXww33BfCXfizsNR1DL3vQr+dk6ClPITguaYXAzHpGIP+R4K/BTmIrTa
> VyxpT/AkCLY++yOubpwMBRCWWdZe1bKSvaO02zSH2Y8QxGI+0pkQd6rlHEH+l4ES
> Tqy8iwqC9Ha74Gu4OTwkhDbFjQiI4txqddKEdBjajx0wsULfTb43llmsJOt8E7cv
> AmFhE0QwqHwuIdYNKLpV
> =+jvl
> -END PGP SIGNATURE-

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog

[Usyskin, Alexander]

Hi

Also there is a third bug in systemd - it does not check if watchdog is alarm 
only, like iAMT.
In theory to achieve system reboot on timeout systemd should iterate over all 
available watchdogs and select one that is not alarm only.

Thanks
--
Sasha



-Original Message-
From: Sebastian Reichel [mailto:s...@debian.org] 
Sent: Wednesday, June 15, 2016 18:10
To: Usyskin, Alexander 
Cc: 827...@bugs.debian.org
Subject: Re: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after 
suspend/resume due to iAMT watchdog

Hi,

On Wed, Jun 15, 2016 at 01:25:53PM +, Usyskin, Alexander wrote:
> It may be that fdd9b8655933 uncovered the bug in iTCO_wdt because it 
> actually removes iAMT watchdog and new implementation does not creates 
> one for not provisioned ME.
>
> So before that patch there was two watchdog devices and systemd maybe 
> worked with iAMT one. After that patch only one watchdog exists in the 
> system - iTCO and system works with it.

Yes, looks like /dev/watchdog was iAMT watchdog on older kernels:

4.5:
Jun 15 01:26:36 earth systemd[1]: Hardware watchdog 'INTCAMT', version 0 Jun 15 
01:26:36 earth systemd[1]: Failed to set timeout to 30s: Invalid argument

4.6:
Jun 15 01:24:49 earth systemd[1]: Hardware watchdog 'iTCO_wdt', version 0 Jun 
15 01:24:49 earth systemd[1]: Set hardware watchdog to 30s.

Thanks for you help. So I guess there are two bugs, which are both unrelated to 
iAMT watchdog, but uncovered by this change:

1. systemd's watchdog logic seems to be broken after suspend/resume, so that 
the watchdog times out. It must be systemd's fault, since wd_keepalive does not 
trigger the bug. Previous kernels worked, since operations on INTCAMT were 
basically no-ops without provisioned ME.

2. iTCO_wdt hangs the system instead of restarting it.

-- Sebastian
-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog

[Sebastian Reichel]

Hi,

On Wed, Jun 15, 2016 at 01:25:53PM +, Usyskin, Alexander wrote:
> It may be that fdd9b8655933 uncovered the bug in iTCO_wdt because
> it actually removes iAMT watchdog and new implementation does not
> creates one for not provisioned ME.
>
> So before that patch there was two watchdog devices and systemd
> maybe worked with iAMT one. After that patch only one watchdog
> exists in the system - iTCO and system works with it.

Yes, looks like /dev/watchdog was iAMT watchdog on older kernels:

4.5:
Jun 15 01:26:36 earth systemd[1]: Hardware watchdog 'INTCAMT', version 0
Jun 15 01:26:36 earth systemd[1]: Failed to set timeout to 30s: Invalid argument

4.6:
Jun 15 01:24:49 earth systemd[1]: Hardware watchdog 'iTCO_wdt', version 0
Jun 15 01:24:49 earth systemd[1]: Set hardware watchdog to 30s.

Thanks for you help. So I guess there are two bugs, which are both
unrelated to iAMT watchdog, but uncovered by this change:

1. systemd's watchdog logic seems to be broken after suspend/resume,
so that the watchdog times out. It must be systemd's fault, since
wd_keepalive does not trigger the bug. Previous kernels worked,
since operations on INTCAMT were basically no-ops without
provisioned ME.

2. iTCO_wdt hangs the system instead of restarting it.

-- Sebastian


signature.asc
Description: PGP signature

Bug#827323: marked as done (linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog)

[Debian Bug Tracking System]

Your message dated Wed, 15 Jun 2016 17:10:13 +0200
with message-id <20160615151013.GB16860@earth>
and subject line Re: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze 
after suspend/resume due to iAMT watchdog
has caused the Debian Bug report #827323,
regarding linux: Regression v4.5 -> v4.6: system freeze after suspend/resume 
due to iAMT watchdog
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.)


-- 
827323: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827323
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: linux
Version: 4.5.5-1
Severity: normal

Hi,

My Lenovo Thinkpad X250 freezes a couple of seconds after
resuming from suspend. This happened with 4.5, but not
with v4.6. I bisected the problem using mainline kernel
with Debian config to the following commit:

sre@earth ~/src/linux (git)-[fdd9b86...|bisect] % git bisect bad
fdd9b8655933c3eb3154fe1ed351c17b654258bd is the first bad commit
commit fdd9b8655933c3eb3154fe1ed351c17b654258bd
Author: Alexander Usyskin 
Date:   Fri Jan 8 00:49:21 2016 +0200

mei: wd: drop the watchdog code from the core mei driver

Instead of integrating the iAMT watchdog in the mei core driver
we will create a watchdog device on the mei client bus and
create a driver for it.

This patch removes the watchdog code from the mei core driver.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

My system was configured to use the watchdog via "RuntimeWatchdogSec=30"
in "/etc/systemd/system.conf". After disabling the feature no system
freeze happens after suspend/resume cycle.

-- Sebastian

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Hi,

On Wed, Jun 15, 2016 at 01:25:53PM +, Usyskin, Alexander wrote:
> It may be that fdd9b8655933 uncovered the bug in iTCO_wdt because
> it actually removes iAMT watchdog and new implementation does not
> creates one for not provisioned ME.
>
> So before that patch there was two watchdog devices and systemd
> maybe worked with iAMT one. After that patch only one watchdog
> exists in the system - iTCO and system works with it.

Yes, looks like /dev/watchdog was iAMT watchdog on older kernels:

4.5:
Jun 15 01:26:36 earth systemd[1]: Hardware watchdog 'INTCAMT', version 0
Jun 15 01:26:36 earth systemd[1]: Failed to set timeout to 30s: Invalid argument

4.6:
Jun 15 01:24:49 earth systemd[1]: Hardware watchdog 'iTCO_wdt', version 0
Jun 15 01:24:49 earth systemd[1]: Set hardware watchdog to 30s.

Thanks for you help. So I guess there are two bugs, which are both
unrelated to iAMT watchdog, but uncovered by this change:

1. systemd's watchdog logic seems to be broken after suspend/resume,
so that the watchdog times out. It must be systemd's fault, since
wd_keepalive does not trigger the bug. Previous kernels worked,
since operations on INTCAMT were basically no-ops without
provisioned ME.

2. iTCO_wdt hangs the system instead of restarting it.

-- Sebastian


signature.asc
Description: PGP signature
--- End Message ---

Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog

[Usyskin, Alexander]

Hi

It may be that fdd9b8655933 uncovered the bug in iTCO_wdt because it actually 
removes iAMT watchdog and new
implementation does not creates one for not provisioned ME.
So before that patch there was two watchdog devices and systemd maybe worked 
with iAMT one.
After that patch only one watchdog exists in the system - iTCO and system works 
with it.


Thanks
--
Sasha



-Original Message-
From: Sebastian Reichel [mailto:s...@debian.org] 
Sent: Wednesday, June 15, 2016 14:30
To: Usyskin, Alexander 
Cc: 827...@bugs.debian.org
Subject: Re: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after 
suspend/resume due to iAMT watchdog

Hi,

On Wed, Jun 15, 2016 at 08:00:30AM +, Usyskin, Alexander wrote:
> I assume that "This happened with 4.6, but not with v4.5.", yes?

Yes, sorry.

> Do you have vPro system?

Yes, my CPU is i7-5600U.

> Have you provisioned your ME device?

No, I don't think so.

> If not, the iAMT watchdog should not be exposed to user-space and 
> should not affect systemd. Do you have /dev/watchdog* with identity 
> "iamt_wdt" at you system?

# ls /sys/class/watchdog
watchdog0
# wd_identify
iTCO_wdt

That's also, what was used by systemd:

Jun 15 01:24:49 earth kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 
Jun 15 01:24:49 earth kernel: iTCO_wdt: Found a Wildcat Point_LP TCO device 
(Version=2, TCOBASE=0x1860) Jun 15 01:24:49 earth kernel: iTCO_wdt: 
initialized. heartbeat=30 sec (nowayout=0) Jun 15 01:24:49 earth systemd[1]: 
Hardware watchdog 'iTCO_wdt', version 0 Jun 15 01:24:49 earth systemd[1]: Set 
hardware watchdog to 30s.

I have checked with wd_keepalive and I have a few more observations:

 * The freeze did not appear when wd_keepalive is used instead of systemd
 * The freeze appears, if I kill wd_keepalive, so the freeze itself seems
   to be a bug in the iTCO_wdt driver/hardware.

So looks like fdd9b8655933 somehow results in systemd being too slow to ping 
the watchdog in time.

-- Sebastian

> -Original Message-
> From: Sebastian Reichel [mailto:s...@debian.org]
> Sent: Wednesday, June 15, 2016 02:44
> To: Debian Bug Tracking System 
> Subject: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze 
> after suspend/resume due to iAMT watchdog
> 
> Source: linux
> Version: 4.5.5-1
> Severity: normal
> 
> Hi,
> 
> My Lenovo Thinkpad X250 freezes a couple of seconds after resuming 
> from suspend. This happened with 4.5, but not with v4.6. I bisected 
> the problem using mainline kernel with Debian config to the following 
> commit:
> 
> sre@earth ~/src/linux (git)-[fdd9b86...|bisect] % git bisect bad 
> fdd9b8655933c3eb3154fe1ed351c17b654258bd is the first bad commit 
> commit fdd9b8655933c3eb3154fe1ed351c17b654258bd
> Author: Alexander Usyskin 
> Date:   Fri Jan 8 00:49:21 2016 +0200
> 
> mei: wd: drop the watchdog code from the core mei driver
> 
> Instead of integrating the iAMT watchdog in the mei core driver
> we will create a watchdog device on the mei client bus and
> create a driver for it.
> 
> This patch removes the watchdog code from the mei core driver.
> 
> Signed-off-by: Alexander Usyskin 
> Signed-off-by: Tomas Winkler 
> Signed-off-by: Greg Kroah-Hartman 
> 
> My system was configured to use the watchdog via "RuntimeWatchdogSec=30"
> in "/etc/systemd/system.conf". After disabling the feature no system 
> freeze happens after suspend/resume cycle.
> 
> -- Sebastian
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (1000, 'testing'), (500, 'unstable'), (200, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> -
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). Any review or distribution 
> by others is strictly prohibited. If you are not the intended 
> recipient, please contact the sender and delete all copies.
> 
-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog

[Sebastian Reichel]

Hi,

On Wed, Jun 15, 2016 at 08:00:30AM +, Usyskin, Alexander wrote:
> I assume that "This happened with 4.6, but not with v4.5.", yes?

Yes, sorry.

> Do you have vPro system?

Yes, my CPU is i7-5600U.

> Have you provisioned your ME device?

No, I don't think so.

> If not, the iAMT watchdog should not be exposed to user-space and
> should not affect systemd. Do you have /dev/watchdog* with identity
> "iamt_wdt" at you system?

# ls /sys/class/watchdog 
watchdog0
# wd_identify
iTCO_wdt

That's also, what was used by systemd:

Jun 15 01:24:49 earth kernel: iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
Jun 15 01:24:49 earth kernel: iTCO_wdt: Found a Wildcat Point_LP TCO device 
(Version=2, TCOBASE=0x1860)
Jun 15 01:24:49 earth kernel: iTCO_wdt: initialized. heartbeat=30 sec 
(nowayout=0)
Jun 15 01:24:49 earth systemd[1]: Hardware watchdog 'iTCO_wdt', version 0
Jun 15 01:24:49 earth systemd[1]: Set hardware watchdog to 30s.

I have checked with wd_keepalive and I have a few more observations:

 * The freeze did not appear when wd_keepalive is used instead of systemd
 * The freeze appears, if I kill wd_keepalive, so the freeze itself seems
   to be a bug in the iTCO_wdt driver/hardware.

So looks like fdd9b8655933 somehow results in systemd being too slow to
ping the watchdog in time.

-- Sebastian

> -Original Message-
> From: Sebastian Reichel [mailto:s...@debian.org] 
> Sent: Wednesday, June 15, 2016 02:44
> To: Debian Bug Tracking System 
> Subject: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after 
> suspend/resume due to iAMT watchdog
> 
> Source: linux
> Version: 4.5.5-1
> Severity: normal
> 
> Hi,
> 
> My Lenovo Thinkpad X250 freezes a couple of seconds after resuming
> from suspend. This happened with 4.5, but not with v4.6. I
> bisected the problem using mainline kernel with Debian config to
> the following commit:
> 
> sre@earth ~/src/linux (git)-[fdd9b86...|bisect] % git bisect bad
> fdd9b8655933c3eb3154fe1ed351c17b654258bd is the first bad commit commit 
> fdd9b8655933c3eb3154fe1ed351c17b654258bd
> Author: Alexander Usyskin 
> Date:   Fri Jan 8 00:49:21 2016 +0200
> 
> mei: wd: drop the watchdog code from the core mei driver
> 
> Instead of integrating the iAMT watchdog in the mei core driver
> we will create a watchdog device on the mei client bus and
> create a driver for it.
> 
> This patch removes the watchdog code from the mei core driver.
> 
> Signed-off-by: Alexander Usyskin 
> Signed-off-by: Tomas Winkler 
> Signed-off-by: Greg Kroah-Hartman 
> 
> My system was configured to use the watchdog via "RuntimeWatchdogSec=30"
> in "/etc/systemd/system.conf". After disabling the feature no system freeze
> happens after suspend/resume cycle.
> 
> -- Sebastian
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (1000, 'testing'), (500, 'unstable'), (200, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> -
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 


signature.asc
Description: PGP signature

Processed: Re: Bug#827342: linux-image-4.5.0-2-amd64: luks rootfs not recognized at boot after upgrade to linux-image 4.5.5

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #827342 [src:linux] linux-image-4.5.0-2-amd64: luks rootfs not recognized 
at boot after upgrade to linux-image 4.5.5
Added tag(s) moreinfo.

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

Bug#827342: linux-image-4.5.0-2-amd64: luks rootfs not recognized at boot after upgrade to linux-image 4.5.5

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 2016-06-15 at 08:56 +0200, Sander van Grieken wrote:
> Package: src:linux
> Version: 4.5.5-1
> Severity: important
> 
> Upgrading linux kernel from 4.5.4 to 4.5.5 broke my boot.
> 
> I have a LUKS rootfs on top of a mdadm managed raid0. Starting from 4.5.5 it
> doesn't recognize the luks volume at boot. The same happens with 4.6.1

LUKS volumes are recognised and set uo by userland, so are you sure
this is due to the kernel upgrade?

> The raid0 is not explicitly made with mdadm, it was previously handled by
> dmraid I believe (fakeraid?)

I'm assuming that after a delay you see an '(initramfs)' shell prompt.
Do you see any error messages before that?  If you then enter 'cat
/proc/partitions', which devices does it show?

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Processed: tagging 827340

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 827340 + upstream
Bug #827340 [src:linux] linux: CVE-2010-5321 memory leak in videobuf on 
multiple calls to mmap()
Added tag(s) upstream.
> thanks
Stopping processing here.

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

Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after suspend/resume due to iAMT watchdog

[Usyskin, Alexander]

Hi

I assume that "This happened with 4.6, but not with v4.5.", yes?

Do you have vPro system? Have you provisioned your ME device?
If not, the iAMT watchdog should not be exposed to user-space and should not 
affect systemd.
Do you have /dev/watchdog* with identity "iamt_wdt" at you system?

Thanks
--
Sasha


-Original Message-
From: Sebastian Reichel [mailto:s...@debian.org] 
Sent: Wednesday, June 15, 2016 02:44
To: Debian Bug Tracking System 
Subject: Bug#827323: linux: Regression v4.5 -> v4.6: system freeze after 
suspend/resume due to iAMT watchdog

Source: linux
Version: 4.5.5-1
Severity: normal

Hi,

My Lenovo Thinkpad X250 freezes a couple of seconds after resuming from 
suspend. This happened with 4.5, but not with v4.6. I bisected the problem 
using mainline kernel with Debian config to the following commit:

sre@earth ~/src/linux (git)-[fdd9b86...|bisect] % git bisect bad 
fdd9b8655933c3eb3154fe1ed351c17b654258bd is the first bad commit commit 
fdd9b8655933c3eb3154fe1ed351c17b654258bd
Author: Alexander Usyskin 
Date:   Fri Jan 8 00:49:21 2016 +0200

mei: wd: drop the watchdog code from the core mei driver

Instead of integrating the iAMT watchdog in the mei core driver
we will create a watchdog device on the mei client bus and
create a driver for it.

This patch removes the watchdog code from the mei core driver.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

My system was configured to use the watchdog via "RuntimeWatchdogSec=30"
in "/etc/systemd/system.conf". After disabling the feature no system freeze 
happens after suspend/resume cycle.

-- Sebastian

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Bug#827342: linux-image-4.5.0-2-amd64: luks rootfs not recognized at boot after upgrade to linux-image 4.5.5

[Sander van Grieken]

Package: src:linux
Version: 4.5.5-1
Severity: important

Upgrading linux kernel from 4.5.4 to 4.5.5 broke my boot.

I have a LUKS rootfs on top of a mdadm managed raid0. Starting from 4.5.5 it
doesn't recognize the luks volume at boot. The same happens with 4.6.1

The raid0 is not explicitly made with mdadm, it was previously handled by
dmraid I believe (fakeraid?)




-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Sony Corporation
product_name: VPCZ21C5E
product_version: J004NLAK
chassis_vendor: Sony Corporation
chassis_version: N/A
bios_vendor: INSYDE
bios_version: R0170H5
board_vendor: Sony Corporation
board_name: VAIO
board_version: N/A

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0104] (rev 09)
Subsystem: Sony Corporation 2nd Generation Core Processor Family DRAM 
Controller [104d:9084]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 
00 [VGA controller])
Subsystem: Sony Corporation 2nd Generation Core Processor Family 
Integrated Graphics Controller [104d:9084]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: Sony Corporation 6 Series/C200 Series Chipset Family MEI 
Controller [104d:9084]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI])
Subsystem: Sony Corporation 6 Series/C200 Series Chipset Family USB 
Enhanced Host Controller [104d:9084]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset 
Family High Definition Audio Controller [8086:1c20] (rev 04)
Subsystem: Sony Corporation 6 Series/C200 Series Chipset Family High 
Definition Audio Controller [104d:9084]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 1 [8086:1c10] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 2 [8086:1c12] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.2 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 3 [8086:1c14] (rev b4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 4 [8086:1c16] (rev 

Bug#827340: linux: CVE-2010-5321 memory leak in videobuf on multiple calls to mmap()

[Petter Reinholdtsen]

Package: src:linux
Version: 3.2.78-1
Severity: minor
Tags: security

In 2010 an issue with the linux kernel implementation of v4l was
discovered and reported to RedHat as
https://bugzilla.redhat.com/show_bug.cgi?id=620629 >.  It was
assigned a CVE last year in
http://www.openwall.com/lists/oss-security/2015/02/08/4 > and is
still unsolved as far as I can tell.

If I understand the issue correctly, a user with access to /dev/video
can cause the kernel to leak memory and eventually run out of memory by
doing repeated calls to mmap().  In other words, users with video group
membership can bring down the machine.

According to
https://security-tracker.debian.org/tracker/CVE-2010-5321 > the
issue is present in Wheezy and onwards.  It is probably present in
earlier versions too.  I picked the kernel version number used in wheezy
for this report.

I noticed this issue, as it is the oldest non-fixed CVE number reported
by debsecan on my laptop, and decided it was time to track its progress
in a bug report.

-- 
Happy hacking
Petter Reinholdtsen