Bug#775519: System reboots instead of shutting down on HP EliteBook 840

2016-01-30 Thread Sander Verbrugge 
Package: src:linux
Version: 4.3.3-7
Followup-For: Bug #775519

Dear Maintainer,

Not a HP EliteBook at all, but:

Shutdown/poweroff does not work with linux-image-4.3.0-1-amd64. Instead it 
reboots.

Under linux-image-4.2.0-1-amd64, it works as intended.

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

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: GA-MA78GM-S2H
product_version:  
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version:  
bios_vendor: Award Software International, Inc.
bios_version: F4
board_vendor: Gigabyte Technology Co., Ltd.
board_name: GA-MA78GM-S2H
board_version: x.x

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] RS780 Host 
Bridge [1022:9600]
Subsystem: Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge 
[1022:9600]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR-  (64-bit, non-prefetchable)
Capabilities: 

00:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI 
to PCI bridge (int gfx) [1022:9602] (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=medium >TAbort- 
SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel modules: shpchp

00:0a.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI 
to PCI bridge (PCIE port 5) [1022:9609] (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:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (prog-if 01 [AHCI 1.0])
Subsystem: Gigabyte Technology Co., Ltd GA-MA770-DS3rev2.0 Motherboard 
[1458:b002]
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: ahci
Kernel modules: ahci

00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI])
Subsystem: Gigabyte Technology Co., Ltd SB7x0/SB8x0/SB9x0 USB OHCI0 
Controller [1458:5004]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI])
Subsystem: Gigabyte Technology Co., Ltd SB7x0/SB8x0/SB9x0 USB OHCI0 
Controller [1458:5004]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus 
Controller [1002:4385] (rev 3a)
Subsystem: Gigabyte Technology Co., Ltd GA-MA770-DS3rev2.0 Motherboard 
[1458:4385]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
TAbort- 
SERR- 
Kernel driver in use: pata_atiixp
Kernel modules: pata_atiixp, ata_generic

00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 
Azalia (Intel HDA) [1002:4383]
Subsystem: Gigabyte Technology Co., Ltd GA-MA770-DS3rev2.0 Motherboard 
[1458:a022]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF-

Re: Kernel version for stretch

2016-01-30 Thread maximilian attems 
On Sat, Jan 30, 2016 at 03:30:37PM +0100, Moritz Muehlenhoff wrote:
> On Thu, Jan 28, 2016 at 11:42:13PM +0100, maximilian attems wrote:
> > 
> > Well, those efforts have not a good track record, afais Ben is maintaining
> > their lts Linus.
> 
> I don't really understand the second half of your sentence,

one funny typo, here s/Linus/Linux/.

> but they certainly
> have a good track record: After all Jessie is based on their ckt 3.16 series
> and their 3.19 kernel is also working very well (we're using it at work 
> on top of jessie since 3.16 has some mm problems under high load). I've been 
> forwarding patches for merging to Luis and Kamal for quite a while now and 
> they've always been really responsive and helpful.

It is not an upstream sanctioned stable release and Jessie ended up squeezed.

Bug#813229: initramfs-tools: '/etc/initramfs-tools/initramfs.conf' is marked as obsolete conffile

2016-01-30 Thread Thilo Six 
Package: initramfs-tools
Version: 0.122
Severity: normal

Dear Maintainer,

since latest update of initramfs-tools 0.122
'/etc/initramfs-tools/initramfs.conf' is marked as
obsolete conffile:

% command dpkg-query -W -f='${Conffiles}\n' | command grep 
'initramfs.*obsolete$'
/etc/bash_completion.d/initramfs-tools 7eeb7184772f3658e7cf446945c096b1 obsolete
/etc/initramfs-tools/initramfs.conf 42161705437308c44abc6d46395889c1 obsolete

Usually the local admin can safely rm obsolete conffiles, thats not the case
with '/etc/initramfs-tools/initramfs.conf' as this breaks update-initramfs.



kind regards,

 Thilo

Re: Kernel version for stretch

2016-01-30 Thread Moritz Muehlenhoff 
On Thu, Jan 28, 2016 at 11:42:13PM +0100, maximilian attems wrote:
> On Thu, Jan 28, 2016 at 08:01:13PM +0100, Moritz Mühlenhoff wrote:
> > Ben Hutchings  wrote:
> > > For stretch, I would very much like to choose a kernel version for
> > > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > > lasts 2 years from release, after which someone else (maybe me) can
> > > take over.
> > 
> > Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> > for Ubuntu-non-LTS releases for two years.
> > 
> 
> Well, those efforts have not a good track record, afais Ben is maintaining
> their lts Linus.

I don't really understand the second half of your sentence, but they certainly
have a good track record: After all Jessie is based on their ckt 3.16 series
and their 3.19 kernel is also working very well (we're using it at work 
on top of jessie since 3.16 has some mm problems under high load). I've been 
forwarding patches for merging to Luis and Kamal for quite a while now and 
they've always been really responsive and helpful.

Cheers,
Moritz

Re: Kernel version for stretch

2016-01-30 Thread Moritz Mühlenhoff 
On Thu, Jan 28, 2016 at 08:15:30PM +, Ben Hutchings wrote:
> On Thu, 2016-01-28 at 20:01 +0100, Moritz Mühlenhoff wrote:
> > Ben Hutchings  wrote:
> > > For stretch, I would very much like to choose a kernel version for
> > > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > > lasts 2 years from release, after which someone else (maybe me) can
> > > take over.
> > 
> > Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> > for Ubuntu-non-LTS releases for two years.
> 
> Not in general; it can be as little as 12 months (e.g. 3.11-ckt).

I would need to confirm that, but AFAICS the non-LTS kernels after 3.11 are
all maintained for two years (since they are now made available at "hardware
enablement kernels" for the Ubuntu LTS releases.

> > We could base the stretch kernel on the underlying ckt kernel
> > series used for Ubuntu 16.04 or 16.10?
> 
> Given the politics involved, I would rather not do that twice in a row.

Ok.

Cheers,
Moritz

Bug#805252: linux-image-4.2.0-1-amd64: I/O errors when writing to iSCSI volumes

2016-01-30 Thread Christian Seiler 
Control: tags -1 + fixed-upstream patch jessie
Control: found -1 3.16.7-ckt20-1+deb8u3
Control: fixed -1 4.1.1-1~exp1

Hi,

so I've found out that this is actually a bug in LIO (the target) not
the initiator.

Problem is: LIO in Linux up to 4.0 uses vfs_writev to write out blocks
when using the fileio backend, so this has a limit of 1024 iovecs (as
per UIO_MAXIOV in include/uapi/linux/uio.h), each at most a page in
size, so that gives us a maximum of 4 MiB in data that can be processed
per request. (At 4 kiB page size.)

Older versions of the Linux software initiator had a hard limit of
512 kiB per request, which means that at most 128 iovec entries were
used, which fits perfectly. Newer versions of the Linux iSCSI initiator
don't have this hard-coded limit but rather use the value supplied by
the target. (This is correct behavior by the initiator, so there's no
bug there, against what I initially assumed.)

Problem now is that LIO with the fileio backend assumes that 8 MiB may
be transfered at the same time, because (according to comments in
drivers/target/target_core_file.h) they assume for some reason
unbeknownst to me that the maximum number of iovecs is 2048.

Note that this also means that any non-Linux initiator that properly
follows the target-supplied values for the maximum I/O size will run
into the same problem and cause I/O errors, even if it behaves
properly.

This problem doesn't affect upstream anymore, because they have
rewritten LIO to use vfs_iter_write, which doesn't have such
limitations, but was only introduced after 3.16. Backporting this would
be too much, and probably ABI-incompatible.

Fortunately, there's a much easier way to fix this, by just lowering
the limit in drivers/target/target_core_file.h to 4 MiB. I've tested
that and the limit will be properly set by LIO and newer initiators
won't choke on that, so that fixes the bug. See the attached patch.

CAVEAT: there is a slight problem with this change, and I don't know
what the best solution here is: the optimal_sectors setting for fileio
disks on people's existing setups is likely to be 16384, because that
corresponds to 8 MiB (the previous max value, which is the default for
optimal_sectors if no other value is set) - but that will cause the
kernel to refuse that setting, because it's now larger than the maximum
allowed value. If you use targetcli 3 (not part of Jessie, but you can
install e.g. the version from sid) then that will fail to set up the
target properly, because it will abort as soon as it notices that it
can't make the setting. (Leftover targetcli 2 from Wheezy upgrades
should not be affected as badly as far as I can tell, because the
startup scripts seem to ignore errors. But I haven't tested that.) So
that leaves the situation that without this fix, 3.16 kernels produce
I/O errors when used with initiators that respect the kernel's setting,
but with the fix the target configuration needs to be updated. (Of
course, one could also patch the kernel to ignore the specific value of
16384 for optimal_sectors if fileio is used as a backend and print a
warning.) Don't know what you'd prefer here.

Also note that this likely also affects the kernel in Wheezy, although
I haven't done any tests in that direction.

Regards,
Christian

PS, for reference, upstream discussion on the initiator mailing list
that resulted in me finding out that it's not the initiator but the
target that was the problem:
https://groups.google.com/forum/#!topic/open-iscsi/UE2JJfDmQ7w

From: Christian Seiler 
Date: Sat, 30 Jan 2016 13:48:54 CET
Subject: LIO: assume a maximum of 1024 iovecs

Previously the code assumed that vfs_[read|write}v supported 2048
iovecs, which is incorrect, as UIO_MAXIOV is 1024 instead. This caused
the target to advertise a maximum I/O size that was too large, which in
turn caused conforming initiators (most notably recent Linux kernels,
which started to respect the maximum I/O size of the target and not
have a hard-coded 512 kiB as previous kernel versions did) to send
write requests that were too large, resulting in LIO rejecting them
(kernel: fd_do_rw() write returned -22), resulting in data loss.

This patch adjusts the limit to 1024 iovecs, and also uses the
PAGE_SIZE macro instead of just assuming 4 kiB pages.

Signed-off-by: Christian Seiler 
---
 drivers/target/target_core_file.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/target/target_core_file.h
+++ b/drivers/target/target_core_file.h
@@ -1,6 +1,8 @@
 #ifndef TARGET_CORE_FILE_H
 #define TARGET_CORE_FILE_H
 
+#include 
+
 #define FD_VERSION		"4.0"
 
 #define FD_MAX_DEV_NAME		256
@@ -9,9 +11,9 @@
 #define FD_MAX_DEVICE_QUEUE_DEPTH 128
 #define FD_BLOCKSIZE		512
 /*
- * Limited by the number of iovecs (2048) per vfs_[writev,readv] call
+ * Limited by the number of iovecs (1024) per vfs_[writev,readv] call
  */
-#define FD_MAX_BYTES		8388608
+#define FD_MAX_BYTES		(1024*PAGE_SIZE)
 
 #define

Processed: Re: Bug#805252: linux-image-4.2.0-1-amd64: I/O errors when writing to iSCSI volumes

2016-01-30 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 + fixed-upstream patch jessie
Bug #805252 [src:linux] linux-image-4.2.0-1-amd64: I/O errors when writing to 
iSCSI volumes
Added tag(s) jessie, fixed-upstream, and patch.
> found -1 3.16.7-ckt20-1+deb8u3
Bug #805252 [src:linux] linux-image-4.2.0-1-amd64: I/O errors when writing to 
iSCSI volumes
Marked as found in versions linux/3.16.7-ckt20-1+deb8u3.
> fixed -1 4.1.1-1~exp1
Bug #805252 [src:linux] linux-image-4.2.0-1-amd64: I/O errors when writing to 
iSCSI volumes
Marked as fixed in versions linux/4.1.1-1~exp1.

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

Bug#813220: initramfs-tools-core: Needs to depend on busybox

2016-01-30 Thread Hilko Bengen 
Package: initramfs-tools-core
Version: 0.1222
Severity: grave

Dear Maintainer,

the busybox hook (/usr/share/initramfs-tools/hooks/busybox) requires
that busybox is installed.

Without busybox, it is currently not possible to generate an initrd
which breaks installation of kernel packages in the buildd chroots[1].

Cheers,
-Hilko

[1] See
https://buildd.debian.org/status/fetch.php?pkg=libguestfs=amd64=1%3A1.32.2-1=1454160613=log

Processed: fix bug metadata

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

> notfound 805252 4.2.6-1
Bug #805252 [src:linux] linux-image-4.2.0-1-amd64: I/O errors when writing to 
iSCSI volumes
No longer marked as found in versions linux/4.2.6-1.
>
End of message, stopping processing here.

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

Processed: Re: initramfs-tools-core: Needs to depend on busybox

2016-01-30 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 cryptsetup
Bug #813220 [initramfs-tools-core] initramfs-tools-core: Needs to depend on 
busybox
Bug reassigned from package 'initramfs-tools-core' to 'cryptsetup'.
No longer marked as found in versions 0.1222.
Ignoring request to alter fixed versions of bug #813220 to the same values 
previously set
> forcemerge 783297 -1
Bug #783297 [cryptsetup] split initramfs integration into a separate package
Bug #813220 [cryptsetup] initramfs-tools-core: Needs to depend on busybox
Severity set to 'wishlist' from 'grave'
Added indication that 813220 affects initramfs-tools
Marked as found in versions cryptsetup/2:1.6.6-5.
Merged 783297 813220

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

Bug#813220: initramfs-tools-core: Needs to depend on busybox

2016-01-30 Thread Ben Hutchings 
Control: reassign -1 cryptsetup
Control: forcemerge 783297 -1

On Sat, 30 Jan 2016 15:45:20 +0100 Hilko Bengen 
wrote:
> Package: initramfs-tools-core
> Version: 0.1222
> Severity: grave
> 
> Dear Maintainer,
> 
> the busybox hook (/usr/share/initramfs-tools/hooks/busybox) requires
> that busybox is installed.
[...]

No, it doesn't.  The busybox dependency is introduced by cryptsetup.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, reading IRC for the first time


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

Bug#809740: initramfs-tools: Completely ignores rootdelay

2016-01-30 Thread Martin Pitt 
Hello Ben and Christoph,

Ben Hutchings [2016-01-29 13:50 +]:
> # systemd maintainers do not want to handle ROOTDELAY

For the record, this isn't just a question of *where* to put a "sleep
$ROOTDELAY" -- my point is, the previous sleep was entirely
non-sensical, and moving it around would still be wrong:

 - Sleeping some extra seconds *before* the "wait for root fs" loop in
   local_device_setup() will either be a no-op (if $ROOTDELAY is
   shorter than the actual time that it takes for the root device to
   appear), or it's unnecessary waiting (if $ROOTDELAY is longer than
   necessary). This would have been the case in udev's i-t script, as
   that runs before "local" (IIRC the sleep used to be in init-top/).

 - Sleeping some extra seconds *after* the "wait for root fs" loop
   would be slightly less pointless, as that actually could make a
   difference (like waiting for more RAID mirror members to join
   before you boot the system). Still wrong, but at least not a no-op.
   But if booting a system without it fails, as "I always get a
   degraded array activated" just means that mdadm's initramfs-tools
   hook does not do a thorough enough job to assemble the root
   /dev/md?, or rather, does not wait until enough members are online.
   This should be done properly for every system with a dynamic
   waiting loop, we shouldn't expect users to figure out an
   appropriate $ROOTDELAY by themselves. Static sleeps are never the
   right answer.

So please don't put this into initramfs-tools either -- let's find out
what really goes wrong here and fix it properly?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#809740: initramfs-tools: Completely ignores rootdelay

2016-01-30 Thread Ben Hutchings 
On Sat, 2016-01-30 at 23:57 +0100, Martin Pitt wrote:
> Hello Ben and Christoph,
> 
> Ben Hutchings [2016-01-29 13:50 +]:
> > # systemd maintainers do not want to handle ROOTDELAY
> 
> For the record, this isn't just a question of *where* to put a "sleep
> $ROOTDELAY" -- my point is, the previous sleep was entirely
> non-sensical, and moving it around would still be wrong:
[...]

I know it's nonsensical, but it's a documented feature.  We just don't
have a proper fix for all the issues it is used to work around.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#813229: initramfs-tools: '/etc/initramfs-tools/initramfs.conf' is marked as obsolete conffile

2016-01-30 Thread Ben Hutchings 
On Sat, 2016-01-30 at 17:27 +0100, Thilo Six wrote:
> Package: initramfs-tools
> Version: 0.122
> Severity: normal
> 
> Dear Maintainer,
> 
> since latest update of initramfs-tools 0.122
> '/etc/initramfs-tools/initramfs.conf' is marked as
> obsolete conffile:
> 
> % command dpkg-query -W -f='${Conffiles}\n' | command grep 
> 'initramfs.*obsolete$'
> /etc/bash_completion.d/initramfs-tools 7eeb7184772f3658e7cf446945c096b1 
> obsolete

This is bug #811496.

> /etc/initramfs-tools/initramfs.conf 42161705437308c44abc6d46395889c1 obsolete

It has moved to initramfs-tools-core.  If you run:

    dpkg-query -W -f='${Conffiles}\n' | grep 'initramfs\.conf'

you should see:

 /etc/initramfs-tools/initramfs.conf 42161705437308c44abc6d46395889c1 obsolete
 /etc/initramfs-tools/initramfs.conf 7690949b00a8a2c0fad84fa4e965b00c

> Usually the local admin can safely rm obsolete conffiles, thats not the case
> with '/etc/initramfs-tools/initramfs.conf' as this breaks update-initramfs.

Indeed.  I'll investigate how to handle the package split in a way that
dpkg doesn't get confused like this.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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