Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Juho]

Most likely the kernel.  However, I can't see any obviously relevant
changes.  What does this command show:

    ls -l /sys/class/input/mouse*/device/device/driver


-- $ ls -l /sys/class/input/mouse*/device/device/driver
lrwxrwxrwx 1 root root 0 Apr  6 06:34 
/sys/class/input/mouse0/device/device/driver -> 
../../../../bus/serio/drivers/psmouse
lrwxrwxrwx 1 root root 0 Apr  6 06:34 
/sys/class/input/mouse1/device/device/driver -> 
../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx 1 root root 0 Apr  6 06:34 
/sys/class/input/mouse2/device/device/driver -> 
../../../../../../../../bus/hid/drivers/hid-multitouch



$ sudo modprobe -r psmouse
$ sudo modprobe psmouse

Makes it "work" again. ...


I also confirm that
sudo modprobe -r psmouse && sudo modprobe psmouse
works and after that command the touch-pad is working.


Magic key-codes, send a key code every 2s or some such to indicate
laptop unfold angle, such that when it's beyond 180 open the keycodes
spam stops and thus OS should turn off keyboard and touchpad because
it's now in "tablet" mode. It folds all the way out.


I also have magic codes:
[  386.645269] atkbd serio0: Unknown key released (translated set 2, 
code 0xbe on isa0060/serio0).
[  386.645281] atkbd serio0: Use 'setkeycodes e03e ' to make it 
known.


But these magic codes did appear also pre 8.4 time.

I also tried reverting back to linux-image-3.16.0-4-amd64 ckt20-1+deb8u4 
but that did not help.


I have Yoga 13 non-Pro model.

--
Juho

Processed: Re: Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits

[Debian Bug Tracking System]

Processing control commands:

> severity -1 wishlist
Bug #820156 [initramfs-tools-core] parse_numeric function cannot handle 
composite device numbers of more than 8 hex digits
Severity set to 'wishlist' from 'minor'

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

Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits

[Ben Hutchings]

Control: severity -1 wishlist

On Tue, 2016-04-05 at 19:13 -0400, Stephen Powell wrote:
> Package: initramfs-tools-core
> Version: 0.123
> Severity: minor
> Tags: patch
> 
> Congratulations on initramfs-tools version 0.123!  Many bugs in version 0.120
> have been fixed in this version.  However, it appears that the parse_numeric
> function, while improved over the 0.120 version, still doesn't handle the
> general case of a composite device number.  It seems it will only handle 8 hex
> digits or less correctly.
> 
> I have submitted a patch for your consideration.  The patch will accommodate 
> the
> general case of a composite device number of up to 16 hex digits (the limit).
> It also tightens up some other error checking corner cases.

I'm not applying this until the kernel actually supports device numbers
that large.  Currently it defines (in include/linux/kdev_t.h):

static inline u32 new_encode_dev(dev_t dev) { ... }
static inline dev_t new_decode_dev(u32 dev) { ... }

static inline u64 huge_encode_dev(dev_t dev)
{
return new_encode_dev(dev);
}

static inline dev_t huge_decode_dev(u64 dev)
{
return new_decode_dev(dev);
}

i.e. anything above bit 31 is zeroed.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.

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

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Dimitri John Ledkov]

On 6 April 2016 at 00:32, Ben Hutchings  wrote:
> On Wed, 2016-04-06 at 00:22 +0100, Ben Hutchings wrote:
> [...]
>> But I also found this commit in 3.17:
>>
>> commit f79a901331a823ae370584b15cd39dd110b95a0a
>> Author: Hans de Goede 
>> Date:   Fri Jul 18 12:21:47 2014 +0200
>>
>> ideapad-laptop: Disable touchpad interface on Yoga models
>>
>> Although it says 'disable touchpad interface', what it means is the
>> ideapad-laptop driver will ignore firmware events sayigng the touchpad
>> should be turned on or off (maybe based on rotation sensors in other
>> Ideapad models?).  It started handling those events in 3.6, which fits
>> the earlier report.
>>
>> Have either of you tried a kernel version newer than 3.16?
>
> Sorry, that won't help - this commit was reverted as the feature was
> previously working properly for some Yoga models.
>
> Dmitri, can you test whether that cherry-picking that commit fixes this
> for you?

I can try that yes.

So yoga 13 non-pro, has a few things
- normal touchpad which with up to date kernels doesn't come up on
boot, until psmouse is reloaded
- touchscreen which appears as a tablet input interface or some such
- and magic key-codes

Magic key-codes, send a key code every 2s or some such to indicate
laptop unfold angle, such that when it's beyond 180 open the keycodes
spam stops and thus OS should turn off keyboard and touchpad because
it's now in "tablet" mode. It folds all the way out.

Stuff has changed in yoga 13 pro models, cause things did stop working
on non-pro after pro-specific model/quick/modules things were merged.
But i believe pro revision did things differently.

-- 
Regards,

Dimitri.

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Ben Hutchings]

On Wed, 2016-04-06 at 00:22 +0100, Ben Hutchings wrote:
[...]
> But I also found this commit in 3.17:
> 
> commit f79a901331a823ae370584b15cd39dd110b95a0a
> Author: Hans de Goede 
> Date:   Fri Jul 18 12:21:47 2014 +0200
> 
> ideapad-laptop: Disable touchpad interface on Yoga models
> 
> Although it says 'disable touchpad interface', what it means is the
> ideapad-laptop driver will ignore firmware events sayigng the touchpad
> should be turned on or off (maybe based on rotation sensors in other
> Ideapad models?).  It started handling those events in 3.6, which fits
> the earlier report.
> 
> Have either of you tried a kernel version newer than 3.16?

Sorry, that won't help - this commit was reverted as the feature was
previously working properly for some Yoga models.

Dmitri, can you test whether that cherry-picking that commit fixes this
for you?

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.

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

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Ben Hutchings]

On Tue, 2016-04-05 at 23:18 +0100, Dimitri John Ledkov wrote:
> On 5 April 2016 at 22:49, Ben Hutchings  wrote:
> > 
> > Control: reassign -1 src:linux 3.16.7-ckt25-1
> > Control: tag -1 moreinfo
> > 
> > On Mon, 2016-04-04 at 22:11 +0300, Juho wrote:
> > > 
> > > Package: general
> > > Severity: important
> > > 
> > > After running "apt-get update && apt-get dist-upgrade" on 2016-04-03
> > > touchpad of IdeaPad Yoga 13 stopped working. Both touch plate and
> > > buttons are not working.
> > > This laptop also has a touch screen and it is still working without
> > > problems.
> > > I'm not sure which package included this 8.4 update might be the faulty
> > > one.
> > [...]
> > 
> > Most likely the kernel.  However, I can't see any obviously relevant
> > changes.  What does this command show:
> > 
> > ls -l /sys/class/input/mouse*/device/device/driver
> 
> I have such a Yoga, for me it's the older yoga-13, pre-highdpi pro version.
> 
> $ sudo modprobe -r psmouse
> $ sudo modprobe psmouse

Right, I suspected this was psmouse.  And there have been no changes
there.  So this probably isn't a regression, just an ongoing problem
that showed up on the first boot after the upgrade.

> Makes it "work" again. I have no idea what happens during the boot, or
> how come post-boot psmouse module loading results in working
> behaviour.
> Possibly something is racy in the kernel and initializes differently
> "post-boot".
> 
> It broke around 3.13 following upstream kernels for me or some such.
> And bisecting this using master/vanilla/.0 kernels ended up being
> fruitless, at least for me.
> So i'm reloading psmouse on my IdeaPad

According to this report it was earlier, between 3.4 and 3.8:
http://thread.gmane.org/gmane.linux.kernel.input/30222/

But I also found this commit in 3.17:

commit f79a901331a823ae370584b15cd39dd110b95a0a
Author: Hans de Goede 
Date:   Fri Jul 18 12:21:47 2014 +0200

ideapad-laptop: Disable touchpad interface on Yoga models

Although it says 'disable touchpad interface', what it means is the
ideapad-laptop driver will ignore firmware events sayigng the touchpad
should be turned on or off (maybe based on rotation sensors in other
Ideapad models?).  It started handling those events in 3.6, which fits
the earlier report.

Have either of you tried a kernel version newer than 3.16?

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

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

Bug#820156: parse_numeric function cannot handle composite device numbers of more than 8 hex digits

[Stephen Powell]

Package: initramfs-tools-core
Version: 0.123
Severity: minor
Tags: patch

Congratulations on initramfs-tools version 0.123!  Many bugs in version 0.120
have been fixed in this version.  However, it appears that the parse_numeric
function, while improved over the 0.120 version, still doesn't handle the
general case of a composite device number.  It seems it will only handle 8 hex
digits or less correctly.

I have submitted a patch for your consideration.  The patch will accommodate the
general case of a composite device number of up to 16 hex digits (the limit).
It also tightens up some other error checking corner cases.

Respectfully submitted,

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-
--- a/functions	2016-01-21 18:33:59.0 -0500
+++ b/functions	2016-03-24 08:09:11.0 -0400
@@ -128,14 +128,28 @@
 
 # lilo compatibility
 parse_numeric() {
-	case $1 in
+	case "$1" in
 	*:*)
 		# Does it match /[0-9]*:[0-9]*/?
-		minor=${1#*:}
-		major=${1%:*}
-		case $major$minor in
+		minor="${1#*:}"   # Everything after the first colon.
+		major="${1%%:*}"  # Everything before the first colon.
+		[ X"$major" = X ] && return   # major is null.
+		[ X"$minor" = X ] && return   # minor is null.
+		case "$major$minor" in
 		*[!0-9]*)
-			# No.
+			# major or minor contains a non-numeric character.
+			return
+			;;
+		esac
+		case "$major" in
+		0?*)
+			# major has a leading zero.
+			return
+			;;
+		esac
+		case "$minor" in
+		0?*)
+			# minor has a leading zero.
 			return
 			;;
 		esac
@@ -146,9 +160,56 @@
 		;;
 	*)
 		# [A-Fa-f0-9]*
-		value=$(( 0x${1} ))
-		minor=$(( (${value} & 0xff) | (${value} >> 12) & 0xfff00 ))
-		major=$(( (${value} >> 8) & 0xfff ))
+		case "$1" in
+		0?*)
+			# Composite device number has a leading zero.
+			return
+			;;
+		esac
+		[ ${#1} -gt 16 ] && return   # More than 16 hex digits.
+		#
+		# 16 hex digits, with leading zeros suppressed.
+		# Format is MmmMMMmm, where the "M"s are the hex
+		# digits of the major device number and the "m"s are the
+		# hex digits of the minor device number.
+		#
+		# Note: the shell uses 64-bit two's complement signed binary
+		# integer arithmetic internally when evaluating arithmetic
+		# expressions, even on 32-bit platforms such as i386.  Bitwise
+		# shift operations are arithmetic shifts, not logical shifts.
+		# Only the right-most 63 bits participate in a shift operation.
+		# The left-most bit, the sign bit, does not participate in
+		# the shift operation and remains unchanged.  For a shift
+		# left operation, bits shifted out of the left-most bit
+		# position which participates in the shift are lost; and zeros
+		# are shifted in on the right.  Arithmetic overflow occurs
+		# if any bits unlike the sign bit are shifted out of the
+		# left-most bit position which participates in the shift.
+		# (However, arithmetic overflow is ignored.)  For a shift
+		# right operation, bits shifted out of the right-most bit
+		# position are lost; and copies of the sign bit are shifted
+		# in on the left.  All 64 bit positions, including the sign
+		# bit, participate in bitwise "and" and bitwise "or"
+		# operations.
+		#
+		# Hexadecimal constants are treated as padded on the left
+		# with zeros, if needed, or truncated on the left, if needed,
+		# to make 16 digits.  If the left-most digit, after padding
+		# or truncating if needed, is in the range 8-f, inclusive,
+		# then the number is treated as negative, in two's complement
+		# form.  Otherwise, the number is treated as positive (or zero
+		# if all digits are zero).
+		#
+		# For the three operators used in the expressions below,
+		# the bitwise shift right operator (>>) has the highest
+		# priority, followed by the bitwise "and" operator (&),
+		# followed by the bitwise "or" operator (|).  Therefore, the
+		# default order of operations is correct; and no parentheses
+		# are needed in the expressions themselves.
+		#
+		devno=$(( 0x$1 ))
+		major=$(( devno >> 8 & 0xfff | devno >> 32 & 0xf000 ))
+		minor=$(( devno & 0xff | devno >> 12 & 0xff00 ))
 		;;
 	esac
 

Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Dimitri John Ledkov]

On 5 April 2016 at 22:49, Ben Hutchings  wrote:
> Control: reassign -1 src:linux 3.16.7-ckt25-1
> Control: tag -1 moreinfo
>
> On Mon, 2016-04-04 at 22:11 +0300, Juho wrote:
>> Package: general
>> Severity: important
>>
>> After running "apt-get update && apt-get dist-upgrade" on 2016-04-03
>> touchpad of IdeaPad Yoga 13 stopped working. Both touch plate and
>> buttons are not working.
>> This laptop also has a touch screen and it is still working without
>> problems.
>> I'm not sure which package included this 8.4 update might be the faulty
>> one.
> [...]
>
> Most likely the kernel.  However, I can't see any obviously relevant
> changes.  What does this command show:
>
> ls -l /sys/class/input/mouse*/device/device/driver


I have such a Yoga, for me it's the older yoga-13, pre-highdpi pro version.

$ sudo modprobe -r psmouse
$ sudo modprobe psmouse

Makes it "work" again. I have no idea what happens during the boot, or
how come post-boot psmouse module loading results in working
behaviour.
Possibly something is racy in the kernel and initializes differently
"post-boot".

It broke around 3.13 following upstream kernels for me or some such.
And bisecting this using master/vanilla/.0 kernels ended up being
fruitless, at least for me.
So i'm reloading psmouse on my IdeaPad

-- 
Regards,

Dimitri.

Processed: Re: Bug#820013: general: Touchpad not working on Lenovo IdeaPad Yoga 13 after updating from 8.3 to 8.4

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:linux 3.16.7-ckt25-1
Bug #820013 [general] general: Touchpad not working on Lenovo IdeaPad Yoga 13 
after  updating from 8.3 to 8.4
Bug reassigned from package 'general' to 'src:linux'.
Ignoring request to alter found versions of bug #820013 to the same values 
previously set
Ignoring request to alter fixed versions of bug #820013 to the same values 
previously set
Bug #820013 [src:linux] general: Touchpad not working on Lenovo IdeaPad Yoga 13 
after  updating from 8.3 to 8.4
Marked as found in versions linux/3.16.7-ckt25-1.
> tag -1 moreinfo
Bug #820013 [src:linux] general: Touchpad not working on Lenovo IdeaPad Yoga 13 
after  updating from 8.3 to 8.4
Added tag(s) moreinfo.

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

Processed: reassign 820061 to src:linux, forcibly merging 819881 820061

[Debian Bug Tracking System]

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

> reassign 820061 src:linux
Bug #820061 [linux-image-amd64] linux-image-amd64: kernel hangs since debian 8.4
Bug reassigned from package 'linux-image-amd64' to 'src:linux'.
No longer marked as found in versions 3.16.7-ckt25-1.
Ignoring request to alter fixed versions of bug #820061 to the same values 
previously set
> forcemerge 819881 820061
Bug #819881 [src:linux] radeon_fence_ref BUG: unable to handle kernel NULL 
pointer dereference
Bug #817874 [src:linux] linux-image-3.16.0-4-amd64: 3.16.7-ckt25-1 freeze with 
radeon driver
Bug #820061 [src:linux] linux-image-amd64: kernel hangs since debian 8.4
Severity set to 'serious' from 'normal'
Added indication that 820061 affects release.debian.org
Marked as found in versions linux/3.16.7-ckt25-1.
Added tag(s) patch, moreinfo, and upstream.
Bug #817874 [src:linux] linux-image-3.16.0-4-amd64: 3.16.7-ckt25-1 freeze with 
radeon driver
Merged 817874 819881 820061
> thanks
Stopping processing here.

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

linux_3.16.7-ckt25-1~bpo70+1_multi.changes ACCEPTED into wheezy-backports->backports-policy, wheezy-backports

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 02 Apr 2016 14:44:46 +0100
Source: linux
Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 
linux-support-3.16.0-0.bpo.4 linux-libc-dev linux-headers-3.16.0-0.bpo.4-all 
linux-headers-3.16.0-0.bpo.4-all-amd64 kernel-image-3.16.0-0.bpo.4-amd64-di 
nic-modules-3.16.0-0.bpo.4-amd64-di 
nic-wireless-modules-3.16.0-0.bpo.4-amd64-di 
nic-shared-modules-3.16.0-0.bpo.4-amd64-di 
serial-modules-3.16.0-0.bpo.4-amd64-di 
usb-serial-modules-3.16.0-0.bpo.4-amd64-di ppp-modules-3.16.0-0.bpo.4-amd64-di 
pata-modules-3.16.0-0.bpo.4-amd64-di cdrom-core-modules-3.16.0-0.bpo.4-amd64-di 
firewire-core-modules-3.16.0-0.bpo.4-amd64-di 
scsi-core-modules-3.16.0-0.bpo.4-amd64-di scsi-modules-3.16.0-0.bpo.4-amd64-di 
scsi-common-modules-3.16.0-0.bpo.4-amd64-di 
scsi-extra-modules-3.16.0-0.bpo.4-amd64-di loop-modules-3.16.0-0.bpo.4-amd64-di 
btrfs-modules-3.16.0-0.bpo.4-amd64-di ext4-modules-3.16.0-0.bpo.4-amd64-di 
isofs-modules-3.16.0-0.bpo.4-amd64-di jfs-modules-3.16.0-0.bpo.4-amd64-di 
ntfs-modules-3.16.0-0.bpo.4-amd64-di
 xfs-modules-3.16.0-0.bpo.4-amd64-di fat-modules-3.16.0-0.bpo.4-amd64-di 
md-modules-3.16.0-0.bpo.4-amd64-di multipath-modules-3.16.0-0.bpo.4-amd64-di 
usb-modules-3.16.0-0.bpo.4-amd64-di usb-storage-modules-3.16.0-0.bpo.4-amd64-di 
pcmcia-storage-modules-3.16.0-0.bpo.4-amd64-di 
fb-modules-3.16.0-0.bpo.4-amd64-di input-modules-3.16.0-0.bpo.4-amd64-di 
event-modules-3.16.0-0.bpo.4-amd64-di mouse-modules-3.16.0-0.bpo.4-amd64-di 
nic-pcmcia-modules-3.16.0-0.bpo.4-amd64-di 
pcmcia-modules-3.16.0-0.bpo.4-amd64-di nic-usb-modules-3.16.0-0.bpo.4-amd64-di 
sata-modules-3.16.0-0.bpo.4-amd64-di core-modules-3.16.0-0.bpo.4-amd64-di 
acpi-modules-3.16.0-0.bpo.4-amd64-di i2c-modules-3.16.0-0.bpo.4-amd64-di 
crc-modules-3.16.0-0.bpo.4-amd64-di crypto-modules-3.16.0-0.bpo.4-amd64-di 
crypto-dm-modules-3.16.0-0.bpo.4-amd64-di efi-modules-3.16.0-0.bpo.4-amd64-di 
ata-modules-3.16.0-0.bpo.4-amd64-di mmc-core-modules-3.16.0-0.bpo.4-amd64-di 
mmc-modules-3.16.0-0.bpo.4-amd64-di
 nbd-modules-3.16.0-0.bpo.4-amd64-di squashfs-modules-3.16.0-0.bpo.4-amd64-di 
speakup-modules-3.16.0-0.bpo.4-amd64-di virtio-modules-3.16.0-0.bpo.4-amd64-di 
uinput-modules-3.16.0-0.bpo.4-amd64-di sound-modules-3.16.0-0.bpo.4-amd64-di 
hyperv-modules-3.16.0-0.bpo.4-amd64-di udf-modules-3.16.0-0.bpo.4-amd64-di 
fuse-modules-3.16.0-0.bpo.4-amd64-di linux-headers-3.16.0-0.bpo.4-common 
linux-image-3.16.0-0.bpo.4-amd64 linux-headers-3.16.0-0.bpo.4-amd64 
linux-image-3.16.0-0.bpo.4-amd64-dbg xen-linux-system-3.16.0-0.bpo.4-amd64 
linux-headers-3.16.0-0.bpo.4-all-armel kernel-image-3.16.0-0.bpo.4-kirkwood-di 
nic-modules-3.16.0-0.bpo.4-kirkwood-di 
nic-shared-modules-3.16.0-0.bpo.4-kirkwood-di 
usb-serial-modules-3.16.0-0.bpo.4-kirkwood-di 
ppp-modules-3.16.0-0.bpo.4-kirkwood-di 
cdrom-core-modules-3.16.0-0.bpo.4-kirkwood-di 
scsi-core-modules-3.16.0-0.bpo.4-kirkwood-di 
loop-modules-3.16.0-0.bpo.4-kirkwood-di btrfs-modules-3.16.0-0.bpo.4-kirkwood-di
 ext4-modules-3.16.0-0.bpo.4-kirkwood-di 
isofs-modules-3.16.0-0.bpo.4-kirkwood-di jfs-modules-3.16.0-0.bpo.4-kirkwood-di 
fat-modules-3.16.0-0.bpo.4-kirkwood-di minix-modules-3.16.0-0.bpo.4-kirkwood-di 
md-modules-3.16.0-0.bpo.4-kirkwood-di 
multipath-modules-3.16.0-0.bpo.4-kirkwood-di 
usb-modules-3.16.0-0.bpo.4-kirkwood-di 
usb-storage-modules-3.16.0-0.bpo.4-kirkwood-di 
fb-modules-3.16.0-0.bpo.4-kirkwood-di input-modules-3.16.0-0.bpo.4-kirkwood-di 
event-modules-3.16.0-0.bpo.4-kirkwood-di 
mouse-modules-3.16.0-0.bpo.4-kirkwood-di 
nic-usb-modules-3.16.0-0.bpo.4-kirkwood-di 
sata-modules-3.16.0-0.bpo.4-kirkwood-di core-modules-3.16.0-0.bpo.4-kirkwood-di 
crc-modules-3.16.0-0.bpo.4-kirkwood-di 
crypto-modules-3.16.0-0.bpo.4-kirkwood-di 
crypto-dm-modules-3.16.0-0.bpo.4-kirkwood-di 
mmc-modules-3.16.0-0.bpo.4-kirkwood-di nbd-modules-3.16.0-0.bpo.4-kirkwood-di 
squashfs-modules-3.16.0-0.bpo.4-kirkwood-di 
uinput-modules-3.16.0-0.bpo.4-kirkwood-di
 leds-modules-3.16.0-0.bpo.4-kirkwood-di udf-modules-3.16.0-0.bpo.4-kirkwood-di 
fuse-modules-3.16.0-0.bpo.4-kirkwood-di kernel-image-3.16.0-0.bpo.4-orion5x-di 
nic-modules-3.16.0-0.bpo.4-orion5x-di 
nic-shared-modules-3.16.0-0.bpo.4-orion5x-di 
usb-serial-modules-3.16.0-0.bpo.4-orion5x-di 
ppp-modules-3.16.0-0.bpo.4-orion5x-di 
cdrom-core-modules-3.16.0-0.bpo.4-orion5x-di 
scsi-core-modules-3.16.0-0.bpo.4-orion5x-di 
loop-modules-3.16.0-0.bpo.4-orion5x-di ipv6-modules-3.16.0-0.bpo.4-orion5x-di 
btrfs-modules-3.16.0-0.bpo.4-orion5x-di ext4-modules-3.16.0-0.bpo.4-orion5x-di 
isofs-modules-3.16.0-0.bpo.4-orion5x-di jffs2-modules-3.16.0-0.bpo.4-orion5x-di 
jfs-modules-3.16.0-0.bpo.4-orion5x-di fat-modules-3.16.0-0.bpo.4-orion5x-di 
minix-modules-3.16.0-0.bpo.4-orion5x-di md-modules-3.16.0-0.bpo.4-orion5x-di 
multipath-modules-3.16.0-0.bpo.4-orion5x-di 
usb-modules-3.16.0-0.bpo.4-orion5x-di 
usb-storage-modules-3.16.0-0.bpo.4-orion5x-di 
event-modules-3.16.0-0.bpo.4-orion5x-di
 

Bug#820008: Support for securelevel and Secure Boot

[Ben Hutchings]

On Tue, 2016-04-05 at 09:34 +0200, Florian Weimer wrote:
> * Ben Hutchings:
> 
> > 
> > To ensure the integrity of the kernel, we should support a securelevel
> > where all modules must be signed by a trusted key and all APIs
> > allowing arbitrary memory writes are disabled.
> What is a trusted key?  I'm not convinced we can align this with
> Debian's principles.

The built-in trusted key will be created by the Debian FTP team - just
like the keys they use to sign releases..

(For initial testing, I'm using my own key pair so we can work in
parallel.)

[...]
> Maybe we should discuss this on debian-project?
[...]

This has been discussed many times over the past years.  A short
summary of what was agreed at DebConf 13:

https://lists.debian.org/<1376427261.11676.35.ca...@deadeye.wl.decadent.org.uk>

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

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

Processed (with 1 error): forcibly merging 819881 820061

[Debian Bug Tracking System]

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

> forcemerge 819881 820061
Bug #819881 [src:linux] radeon_fence_ref BUG: unable to handle kernel NULL 
pointer dereference
Bug #817874 [src:linux] linux-image-3.16.0-4-amd64: 3.16.7-ckt25-1 freeze with 
radeon driver
Unable to merge bugs because:
package of #820061 is 'linux-image-amd64' not 'src:linux'
Failed to forcibly merge 819881: Did not alter merged bugs.

> thanks
Stopping processing here.

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

Bug#783063: Xen domU freeze with "Guest Rx stalled"

[Wolodja Wentland]

Hello,

we have been observing this behaviour over the last couple of months and
can report that it still happens with recent kernels in
wheezy-backports.

In particular the following kernels where used:

Dom0: 3.16.7-ckt11-1+deb8u6~bpo70+1
DomU: 3.16.7-ckt20-1+deb8u3~bpo70+1

We still only see this with PV guests. How could we investigate this
further and/or solve the issue?
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC

Bug#820061: linux-image-amd64: kernel hangs since debian 8.4

[Bjørn Mork]

Benoît Tonnerre  writes:

> Apr  4 18:52:55 pci003-01 kernel: [   79.329223] RIP: 
> 0010:[]
> [] radeon_fence_ref+0xd/0x50 [radeon]
> Apr  4 18:52:55 pci003-01 kernel: [   79.330192] RSP: 0018:88003639fb18
> EFLAGS: 00010292
> Apr  4 18:52:55 pci003-01 kernel: [   79.331154] RAX:  RBX:
> 8802218f55f8 RCX: 8802218f4d08
> Apr  4 18:52:55 pci003-01 kernel: [   79.332125] RDX: 0001 RSI:
>  RDI: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.333110] RBP: 8802218f5550 R08:
> 8802218f4000 R09: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.334119] R10: 0002 R11:
> 88003639fe08 R12: 0020
> Apr  4 18:52:55 pci003-01 kernel: [   79.335117] R13: 88003639fbe0 R14:
> 88003639fbb0 R15: 8802218f55f8
> Apr  4 18:52:55 pci003-01 kernel: [   79.336120] FS:  7fd8f5323980()
> GS:88022dc6() knlGS:
> Apr  4 18:52:55 pci003-01 kernel: [   79.337143] CS:  0010 DS:  ES: 
> CR0: 80050033
> Apr  4 18:52:55 pci003-01 kernel: [   79.338142] CR2: 0008 CR3:
> 000223b3e000 CR4: 000407e0
> Apr  4 18:52:55 pci003-01 kernel: [   79.339125] Stack:
> Apr  4 18:52:55 pci003-01 kernel: [   79.340065]  a04900bc
> 0020 eea00100 88003639fcd0
> Apr  4 18:52:55 pci003-01 kernel: [   79.341006]  8802218f4000
> 8802216c0a20 8802216c0a20 0001
> Apr  4 18:52:55 pci003-01 kernel: [   79.341952]  
>   
> Apr  4 18:52:55 pci003-01 kernel: [   79.342899] Call Trace:
> Apr  4 18:52:55 pci003-01 kernel: [   79.343854]  [] ?
> radeon_sa_bo_new+0x25c/0x460 [radeon]

I believe this is fixed by commit f80be5a9b1cc ("Revert "drm/radeon:
hold reference to fences in radeon_sa_bo_new"") in v3.16.7-ckt26.


Bjørn

Bug#820008: Support for securelevel and Secure Boot

[Florian Weimer]

* Ben Hutchings:

> To ensure the integrity of the kernel, we should support a securelevel
> where all modules must be signed by a trusted key and all APIs
> allowing arbitrary memory writes are disabled.

What is a trusted key?  I'm not convinced we can align this with
Debian's principles.

> To meet Secure Boot requirements, we need to turn this on whenever
> booted with SB enabled.

I object to Microsoft Secure Boot support in Debian.  It has no clear
security objective, requires the use of Microsoft Windows and
Microsoft services to build boot loaders, and might harm our users in
the long term (e.g., users can only access the web from a Secure Boot
machine with a Firefox built by Mozilla, and Firefox promises web
sites not to enable the “Save as ...” context menu item).

Just support for UEFI signed boot loaders would be a different matter,
but then we don't need securelevel support in the kernel.

Maybe we should discuss this on debian-project?

Fedora has kernel patches for this, but they are not upstream, and are
unlikely to end up there ever.