Bug#795151: Kernel panic on shutdown after "ip -6 neigh add proxy ..."

[Fredrik Roubert]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt11-1+deb8u3
Tags: ipv6

On a virtual machine running jessie (in a pretty default configuration,
using systemd, etc.), I have an OpenVPN server configured like this:

https://community.openvpn.net/openvpn/wiki/IPv6

I use "ip -6 neigh add proxy ..." statements to configure the IPv6
routed block used for assigning addresses to the VPN clients, with
these rules in /etc/network/interfaces:

iface eth0 inet6 static
address :::7::1
netmask 64
gateway fe80::1
up ip -6 neigh add proxy :::8::1000 dev $IFACE
up ip -6 neigh add proxy :::8::1001 dev $IFACE
up ip -6 neigh add proxy :::8::1002 dev $IFACE
down ip -6 neigh del proxy :::8::1000 dev $IFACE
down ip -6 neigh del proxy :::8::1001 dev $IFACE
down ip -6 neigh del proxy :::8::1002 dev $IFACE

(The "down ip ..." statements have no influence on the bug described
here, the kernel panic happens also if they are removed.)

This all works, until attempting a "shutdown -r" which causes the
systemd shutdown process to proceed as expected all the way until it's
supposed to execute "networking: Deconfiguring network interfaces..."
but instead gets a kernel panic, logging the following in journalctl:

Aug 11 03:55:31  kernel: INFO: rcu_sched self-detected stall on CPU { 3}  
(t=5250 jiffies g=555 c=554 q=243)
Aug 11 03:55:31  kernel: sending NMI to all CPUs:
Aug 11 03:55:31  kernel: NMI backtrace for cpu 3
Aug 11 03:55:31  kernel: CPU: 3 PID: 703 Comm: ip Not tainted 
3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u3
Aug 11 03:55:31  kernel: Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Aug 11 03:55:31  kernel: task: 880036ca15f0 ti: 8800b9bd8000 
task.ti: 8800b9bd8000
Aug 11 03:55:31  kernel: RIP: 0010:[]  
[] flat_send_IPI_mask+0x6e/0xa0
Aug 11 03:55:31  kernel: RSP: 0018:8800bfb83e30  EFLAGS: 00010046
Aug 11 03:55:31  kernel: RAX:  RBX: 0c00 RCX: 
0006
Aug 11 03:55:31  kernel: RDX: 0c00 RSI: 0002 RDI: 
0086
Aug 11 03:55:31  kernel: RBP: 000f R08: 000a R09: 

Aug 11 03:55:31  kernel: R10: 01a5 R11: 8800bfb83b96 R12: 
0003
Aug 11 03:55:31  kernel: R13: 818e2940 R14: 00f3 R15: 
81853680
Aug 11 03:55:31  kernel: FS:  7f37d3cc1700() 
GS:8800bfb8() knlGS:
Aug 11 03:55:31  kernel: CS:  0010 DS:  ES:  CR0: 8005003b
Aug 11 03:55:31  kernel: CR2: 7fffc1c7cfd0 CR3: b8ac CR4: 
06e0
Aug 11 03:55:31  kernel: Stack:
Aug 11 03:55:31  kernel:  00020008 0086 
8800bfb8d660 81853680
Aug 11 03:55:31  kernel:  81046ab3 8800bfb8d660 
810c53ca 8800bfb8dac0
Aug 11 03:55:31  kernel:  8109a04e 8800bfb92f00 
880036ca15f0 
Aug 11 03:55:31  kernel: Call Trace:
Aug 11 03:55:31  kernel:  
Aug 11 03:55:31  kernel:
Aug 11 03:55:31  kernel:  [] ? 
arch_trigger_all_cpu_backtrace+0xc3/0x140
Aug 11 03:55:31  kernel:  [] ? 
rcu_check_callbacks+0x3ea/0x630
Aug 11 03:55:31  kernel:  [] ? 
account_process_tick+0xde/0x180
Aug 11 03:55:31  kernel:  [] ? 
tick_sched_handle.isra.16+0x60/0x60
Aug 11 03:55:31  kernel:  [] ? 
update_process_times+0x40/0x70
Aug 11 03:55:31  kernel:  [] ? 
tick_sched_handle.isra.16+0x20/0x60
Aug 11 03:55:31  kernel:  [] ? tick_sched_timer+0x3c/0x60
Aug 11 03:55:31  kernel:  [] ? __run_hrtimer+0x67/0x1c0
Aug 11 03:55:31  kernel:  [] ? 
hrtimer_interrupt+0xe9/0x220
Aug 11 03:55:31  kernel:  [] ? 
smp_apic_timer_interrupt+0x3b/0x60
Aug 11 03:55:31  kernel:  [] ? 
apic_timer_interrupt+0x6d/0x80
Aug 11 03:55:31  kernel:  
Aug 11 03:55:31  kernel:
Aug 11 03:55:31  kernel:  [] ? 
queue_write_lock_slowpath+0x42/0x90
Aug 11 03:55:31  kernel:  [] ? __neigh_create+0x1e9/0x590
Aug 11 03:55:31  kernel:  [] ? 
ip6_finish_output2+0x17e/0x440
Aug 11 03:55:31  kernel:  [] ? igmp6_send+0x2c0/0x420
Aug 11 03:55:31  kernel:  [] ? 
rtnl_fill_ifinfo+0xa06/0xd10
Aug 11 03:55:31  kernel:  [] ? 
igmp6_group_dropped+0x126/0x230
Aug 11 03:55:31  kernel:  [] ? __alloc_skb+0x87/0x2a0
Aug 11 03:55:31  kernel:  [] ? 
__ipv6_dev_mc_dec+0xca/0x120
Aug 11 03:55:31  kernel:  [] ? ipv6_dev_mc_dec+0x16/0x30
Aug 11 03:55:31  kernel:  [] ? pndisc_destructor+0x5b/0x80
Aug 11 03:55:31  kernel:  [] ? neigh_ifdown+0xbd/0xe0
Aug 11 03:55:31  kernel:  [] ? 
ndisc_netdev_event+0x3f/0xd0
Aug 11 03:55:31  kernel:  [] ? 
notifier_call_chain+0x4e/0x70
Aug 11 03:55:31  kernel:  [] ? 
__dev_notify_flags+0x5a/0xb0
Aug 11 03:55:31  kernel:  [] ? dev_change_flags+0x4b/0x60
Aug 11 03:5

Bug#795060: Latest Wheezy backport kernel prefers Infiniband mlx4_en over mlx4_ib, breaks existing installs

[Christian Balzer]

Hello Ben,

thanks for the quick and detailed reply.

On Mon, 10 Aug 2015 15:53:57 +0200 Ben Hutchings wrote:

> Control: severity -1 important
> Control: tag -1 upstream
> 
> On Mon, 2015-08-10 at 13:52 +0900, Christian Balzer wrote:
> [...]
> > I'm also not seeing this on several other machines we use for Ceph
> > with the current Jessie kernel, but to be fair they use slightly
> > different (QDR, not FDR) ConnectX-3 HBAs.
> 
> If SR-IOV is enabled on the adapter then the ports will always operate
> in Ethernet mode as it's apparently not supported for IB.  Perhaps SR
> -IOV enabled on some adapters but not others?
>
I was wondering about that, but wasn't aware of the Ethernet only bit of
SR-IOV. 
Anyway, the previous cluster and one blade of this new one have Mellanox
firmware 2.30.8000, which doesn't offer the Flexboot Bios menu and thus
have no SR-IOV configuration option at boot time.

However the other blade (replacement mobo for a DoA one) in the new server
does have firmware 2.33.5100 and the Flexboot menu and had SR-IOV enabled.

Alas disabling it (and taking out the fake-install) did result in the same
behavior, mlx4_en was auto-loaded before mlx4_ib.

In all following tests I did reboot both nodes simultaneously, to avoid
having one port in Ethernet mode forcing things on the other side.

Also the newest QDR card for one of the Ceph cluster machines here does
have that firmware, but behaves properly (no mlx4_en auto-load) with the
latest Jessie kernel.
 
> If that's not the issue, it looks like you are supposed to set a module
> parameter in mlx4_core:
> port_type_array:Array of port types: HW_DEFAULT (0) is default 1 for
> IB, 2 for Ethernet (array of int) e.g.:
> options mlx4_core port_type_array=1,1
> 
I added that "options mlx4_core port_type_array=1" (since there is only
one port) to /etc/modprobe.d/local.conf, depmod -a, update-initramfs -u,
but no joy.
The mlx4_en module gets auto-loaded before the IB one as well with this
setting.

So ultimately only the fake-install of mlx4_en provides a workaround.

If you have anything else you would like to try let me know, this cluster
will probably not go into production for another 2 weeks.

> I don't know what determines the hardware default.
> 
> [...]
> > Given that the previous version works as expected and that Jessie is
> > doing the "right" thing as well, I'd consider this a critical bug.
> 
> No, it is important (since it is a regression) but it is not critical.
> 
Fair enough.

> > Had I rebooted the older production cluster with 500,000 users on it
> > into this kernel, the results would not have been pretty.
> 
> And that's why you tested on one machine first, right?
> 
Of course, but it would have still a) broken things (replication stopped)
and b) taken me even more time to figure out what was going on and how to
work around it as I can't reboot that cluster willy-nilly. 

There simply is a very high expectation that a kernel update like this
won't leave you dead in the water.

Regards,

Christian
-- 
Christian BalzerNetwork/Systems Engineer
ch...@gol.com   Global OnLine Japan/Fusion Communications
http://www.gol.com/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150811103816.3e943...@batzmaru.gol.ad.jp

Re: Converting kernel svn to git

[Ben Hutchings]

On Wed, 2015-08-05 at 12:46 +0100, Ben Hutchings wrote:
[...]
> Here's where I am with the conversion:
> https://anonscm.debian.org/cgit/kernel/temp/

I've made many fixes to the scripts today, and pushed them and the
results to there.  There's only one bug I'm aware of that I think is
necessary to fix (see below).

I haven't looked at the hook scripts yet, but I assume that replacing
them under git will be quite easy.

That leaves .gitignore.  How should we set up .gitignore for the root
directory when it's already shipped by upstream?  Should we strip it
from the orig tarball and replace it, or should we patch it (as we
already do)?

> Known bugs:
> 
> linux.git
> -
> 
> Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2,
> 2.6.26-{17,20} are detached.

Fixed.

> Several weird merges in early history.
> 
> Many merges in svn are not recorded in git, but this is presumably due
> to lack of mergeinfo in old svn versions.

Not fixed, but not that important.

> Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be
> possible in svn!  This might be due to svn mergeinfo accumulating
> branches.

Fixed - all but the first two parents are dropped.

> linux-latest.git
> 
> 
> Tip of wheezy branch is detached from its parent

Fixed.

> Many merges from sid to wheezy-backports are not recorded

Not fixed, but not that important.

> No squeeze branch

Fixed.

> linux-tools.git
> ---
> 
> Many merges from sid to trunk are not recorded

Not fixed, and I would like to do so as this makes the history rather
harder to understand.

> firmware-nonfree.git
> 
> 
> Tip of wheezy branch is detached from its parent

Fixed.

> What do we do with the sid branch?

I made it part of the wheezy branch.

> The 0.19 tag is in a firmware-nonfree subdirectory

Fixed.

> Merge before 0.4+etchnhalf.1 should not be recorded as a merge

Not fixed, but not that important.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers



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

Bug#765953: I had a similar problem, seems fixed on the upstream Kernel 4.1.4

[Ronoaldo José de Lana Pereira]

Hi!

I have a Lenovo G40-70 laptop that has this particular wifi card. I also
don't think this bug is related to the firmware, but I do think that this
issue is related to the driver, maybe this could get reassigned.

Since last year, I have followed a set of different tutorials, but none
fully fixed my problem. Here are some of my findings:

- Using Jessie stock kernel (3.16), the connection using my device is very
poor, and it disconnects very often (around every 10~30min). I attempted
the aproach of setting some kernel parameters, without much success. Some
of the parameters to set to avoid this due to powersave are not even
available in that kernel version.
- I found the rtlwifi_new Github repo, but was unable to test it. But I
also noted that Larry Finger merged some important paches into the
mainstream Kernel, and decided to try newer kernels.
- I did a custom build of the kernel 3.18 and 4.0.1, with better results,
but the issue was just attenuated. I was able to use the connection much
better than with the previous kernel, but was unable to keep it fully
working. Randomly, the connection dropped. The way I would describe
*dropped* is: you browse a site, then you click a link, and the new tab
open the link, get "loading" for a few seconds, and raises "error no
internet". When the connection was dropped, I had to manually disconnect
using Network Manager, then reconnect. This was happening randomly,
anything between a few minutes to, eventually, some hours of usage.

I was following the recent kernel changelogs for a while, and 4.1.4 has a
significant patch affecting this particular driver:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.1.y&id=33e1432c291b72339b03ea3450d7840cdba1dbe1

An infinity loop when running iperf was triggering the behavior of a
"blocked" wifi, which, from my analysis bellow, was the actual root cause
of my random disconnects: if those blocks were in the process of a wpa
rekey event or the like.

I was able to build 4.1.4 and could notice that the patch indeed fixed the
random disconnection issues for me.

I have also posted a reply to this open thread here:
http://forums.debian.net/viewtopic.php?f=5&t=118557&p=588289#p588289

For the reference about the bug, here are my wifi adapter information (from
lspci -v):
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe
Wireless Network Adapter
Subsystem: Lenovo Device b736
Flags: bus master, fast devsel, latency 0, IRQ 19
I/O ports at 3000 [size=256]
Memory at c040 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-23-b7-fe-ff-4c-e0-00
Capabilities: [150] Latency Tolerance Reporting
Capabilities: [158] L1 PM Substates
Kernel driver in use: rtl8723be

And my modproble setup: # cat /etc/modprobe.d/rtl_wifi.conf
options rtl8723be fwlps=0 swlps=0 ips=1 msi=1 debug=0

Hope this helps investigate the problem. Also, the same issues happen with
another wifi card I have, rtl8192cu; this one was not affected by the patch
and I'll test it as well on the newer kernel.

Please let me know if you want me to help doing any further tests in order
to help diagnose/debug/fix the problem.

-- 
Ronoaldo Pereira
ronoaldo.com 

Re: Converting kernel svn to git

[Ben Hutchings]

On Mon, 2015-08-10 at 13:01 -0700, maximilian attems wrote:
> On Thu, Aug 06, 2015 at 06:10:01PM +0100, Ben Hutchings wrote:
> > 
> > No, I want that history and a break in history will just make my life
> > harder.  If you only want some of the branches you can get those.
> 
> Ok, so let's go for history.
>  
> > > > Known bugs:
> > [...]
> > > On the other hand, none of the known bugs you mention is a show-stopper
> > > for the transition from my side.
> > 
> > Yes but they would be harder to fix later.  (git filter-branch is
> > powerful but it invalidates everyone else's clones.)
> 
> can you fix some of them in svn (preimport)? or does it need git-filter
> changes?
> 

Either git-filter-branch or changes to the svn2git rules.

I have most of these fixed now and am adding some more sanity checks.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.



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

Re: Converting kernel svn to git

[maximilian attems]

On Thu, Aug 06, 2015 at 06:10:01PM +0100, Ben Hutchings wrote:
> 
> No, I want that history and a break in history will just make my life
> harder.  If you only want some of the branches you can get those.

Ok, so let's go for history.
 
> > > Known bugs:
> [...]
> > On the other hand, none of the known bugs you mention is a show-stopper
> > for the transition from my side.
> 
> Yes but they would be harder to fix later.  (git filter-branch is
> powerful but it invalidates everyone else's clones.)

can you fix some of them in svn (preimport)? or does it need git-filter
changes?


-- 
maks


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150810200147.GA7913@gluino

linux_3.2.68-1+deb7u3_multi.changes ACCEPTED into oldstable-proposed-updates->oldstable-new, oldstable-proposed-updates

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 04 Aug 2015 02:41:28 +0100
Source: linux
Binary: linux-source-3.2 linux-doc-3.2 linux-manual-3.2 linux-support-3.2.0-4 
linux-libc-dev linux-headers-3.2.0-4-all linux-headers-3.2.0-4-all-alpha 
linux-headers-3.2.0-4-common linux-image-3.2.0-4-alpha-generic 
linux-headers-3.2.0-4-alpha-generic linux-image-3.2.0-4-alpha-smp 
linux-headers-3.2.0-4-alpha-smp linux-image-3.2.0-4-alpha-legacy 
linux-headers-3.2.0-4-alpha-legacy linux-headers-3.2.0-4-all-amd64 
kernel-image-3.2.0-4-amd64-di nic-modules-3.2.0-4-amd64-di 
nic-extra-modules-3.2.0-4-amd64-di nic-wireless-modules-3.2.0-4-amd64-di 
nic-shared-modules-3.2.0-4-amd64-di serial-modules-3.2.0-4-amd64-di 
usb-serial-modules-3.2.0-4-amd64-di ppp-modules-3.2.0-4-amd64-di 
pata-modules-3.2.0-4-amd64-di cdrom-core-modules-3.2.0-4-amd64-di 
firewire-core-modules-3.2.0-4-amd64-di scsi-core-modules-3.2.0-4-amd64-di 
scsi-modules-3.2.0-4-amd64-di scsi-common-modules-3.2.0-4-amd64-di 
scsi-extra-modules-3.2.0-4-amd64-di plip-modules-3.2.0-4-amd64-di 
floppy-modules-3.2.0-4-amd64-di
 loop-modules-3.2.0-4-amd64-di btrfs-modules-3.2.0-4-amd64-di 
ext2-modules-3.2.0-4-amd64-di ext3-modules-3.2.0-4-amd64-di 
ext4-modules-3.2.0-4-amd64-di isofs-modules-3.2.0-4-amd64-di 
jfs-modules-3.2.0-4-amd64-di ntfs-modules-3.2.0-4-amd64-di 
reiserfs-modules-3.2.0-4-amd64-di xfs-modules-3.2.0-4-amd64-di 
fat-modules-3.2.0-4-amd64-di ufs-modules-3.2.0-4-amd64-di 
qnx4-modules-3.2.0-4-amd64-di md-modules-3.2.0-4-amd64-di 
multipath-modules-3.2.0-4-amd64-di usb-modules-3.2.0-4-amd64-di 
usb-storage-modules-3.2.0-4-amd64-di pcmcia-storage-modules-3.2.0-4-amd64-di 
fb-modules-3.2.0-4-amd64-di input-modules-3.2.0-4-amd64-di 
event-modules-3.2.0-4-amd64-di mouse-modules-3.2.0-4-amd64-di 
irda-modules-3.2.0-4-amd64-di parport-modules-3.2.0-4-amd64-di 
nic-pcmcia-modules-3.2.0-4-amd64-di pcmcia-modules-3.2.0-4-amd64-di 
nic-usb-modules-3.2.0-4-amd64-di sata-modules-3.2.0-4-amd64-di 
core-modules-3.2.0-4-amd64-di acpi-modules-3.2.0-4-amd64-di 
i2c-modules-3.2.0-4-amd64-di
 crc-modules-3.2.0-4-amd64-di crypto-modules-3.2.0-4-amd64-di 
crypto-dm-modules-3.2.0-4-amd64-di efi-modules-3.2.0-4-amd64-di 
ata-modules-3.2.0-4-amd64-di mmc-core-modules-3.2.0-4-amd64-di 
mmc-modules-3.2.0-4-amd64-di nbd-modules-3.2.0-4-amd64-di 
squashfs-modules-3.2.0-4-amd64-di speakup-modules-3.2.0-4-amd64-di 
virtio-modules-3.2.0-4-amd64-di uinput-modules-3.2.0-4-amd64-di 
sound-modules-3.2.0-4-amd64-di zlib-modules-3.2.0-4-amd64-di 
hyperv-modules-3.2.0-4-amd64-di udf-modules-3.2.0-4-amd64-di 
fuse-modules-3.2.0-4-amd64-di linux-image-3.2.0-4-amd64 
linux-headers-3.2.0-4-amd64 linux-image-3.2.0-4-amd64-dbg 
xen-linux-system-3.2.0-4-amd64 linux-headers-3.2.0-4-common-rt 
linux-image-3.2.0-4-rt-amd64 linux-headers-3.2.0-4-rt-amd64 
linux-image-3.2.0-4-rt-amd64-dbg linux-headers-3.2.0-4-all-armel 
kernel-image-3.2.0-4-iop32x-di nic-modules-3.2.0-4-iop32x-di 
nic-shared-modules-3.2.0-4-iop32x-di usb-serial-modules-3.2.0-4-iop32x-di 
ppp-modules-3.2.0-4-iop32x-di
 pata-modules-3.2.0-4-iop32x-di cdrom-core-modules-3.2.0-4-iop32x-di 
scsi-core-modules-3.2.0-4-iop32x-di loop-modules-3.2.0-4-iop32x-di 
ipv6-modules-3.2.0-4-iop32x-di btrfs-modules-3.2.0-4-iop32x-di 
ext2-modules-3.2.0-4-iop32x-di ext3-modules-3.2.0-4-iop32x-di 
ext4-modules-3.2.0-4-iop32x-di isofs-modules-3.2.0-4-iop32x-di 
jffs2-modules-3.2.0-4-iop32x-di jfs-modules-3.2.0-4-iop32x-di 
reiserfs-modules-3.2.0-4-iop32x-di fat-modules-3.2.0-4-iop32x-di 
md-modules-3.2.0-4-iop32x-di multipath-modules-3.2.0-4-iop32x-di 
usb-modules-3.2.0-4-iop32x-di usb-storage-modules-3.2.0-4-iop32x-di 
event-modules-3.2.0-4-iop32x-di nic-usb-modules-3.2.0-4-iop32x-di 
sata-modules-3.2.0-4-iop32x-di core-modules-3.2.0-4-iop32x-di 
crc-modules-3.2.0-4-iop32x-di crypto-modules-3.2.0-4-iop32x-di 
crypto-dm-modules-3.2.0-4-iop32x-di ata-modules-3.2.0-4-iop32x-di 
nbd-modules-3.2.0-4-iop32x-di squashfs-modules-3.2.0-4-iop32x-di 
zlib-modules-3.2.0-4-iop32x-di udf-modules-3.2.0-4-iop32x-di
 fuse-modules-3.2.0-4-iop32x-di kernel-image-3.2.0-4-kirkwood-di 
nic-modules-3.2.0-4-kirkwood-di nic-shared-modules-3.2.0-4-kirkwood-di 
usb-serial-modules-3.2.0-4-kirkwood-di ppp-modules-3.2.0-4-kirkwood-di 
cdrom-core-modules-3.2.0-4-kirkwood-di scsi-core-modules-3.2.0-4-kirkwood-di 
loop-modules-3.2.0-4-kirkwood-di ipv6-modules-3.2.0-4-kirkwood-di 
btrfs-modules-3.2.0-4-kirkwood-di ext2-modules-3.2.0-4-kirkwood-di 
ext3-modules-3.2.0-4-kirkwood-di ext4-modules-3.2.0-4-kirkwood-di 
isofs-modules-3.2.0-4-kirkwood-di jfs-modules-3.2.0-4-kirkwood-di 
reiserfs-modules-3.2.0-4-kirkwood-di fat-modules-3.2.0-4-kirkwood-di 
minix-modules-3.2.0-4-kirkwood-di md-modules-3.2.0-4-kirkwood-di 
multipath-modules-3.2.0-4-kirkwood-di usb-modules-3.2.0-4-kirkwood-di 
usb-storage-modules-3.2.0-4-kirkwood-di fb-modules-3.2.0-4-kirkwood-di 
input-modules-3.2.0-4-kirkwood-di event-modules-3.2.0-4-kirkwood-di 
mouse-modules-3.2.0-4-kirkwo

linux_3.16.7-ckt11-1+deb8u3_multi.changes ACCEPTED into proposed-updates->stable-new, proposed-updates

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 04 Aug 2015 01:50:04 +0100
Source: linux
Binary: linux-source-3.16 linux-doc-3.16 linux-manual-3.16 
linux-support-3.16.0-4 linux-libc-dev linux-headers-3.16.0-4-all 
linux-headers-3.16.0-4-all-alpha kernel-image-3.16.0-4-alpha-generic-di 
nic-modules-3.16.0-4-alpha-generic-di 
nic-wireless-modules-3.16.0-4-alpha-generic-di 
nic-shared-modules-3.16.0-4-alpha-generic-di 
serial-modules-3.16.0-4-alpha-generic-di 
usb-serial-modules-3.16.0-4-alpha-generic-di 
ppp-modules-3.16.0-4-alpha-generic-di pata-modules-3.16.0-4-alpha-generic-di 
cdrom-core-modules-3.16.0-4-alpha-generic-di 
scsi-core-modules-3.16.0-4-alpha-generic-di 
scsi-modules-3.16.0-4-alpha-generic-di 
scsi-common-modules-3.16.0-4-alpha-generic-di 
scsi-extra-modules-3.16.0-4-alpha-generic-di 
loop-modules-3.16.0-4-alpha-generic-di btrfs-modules-3.16.0-4-alpha-generic-di 
ext4-modules-3.16.0-4-alpha-generic-di isofs-modules-3.16.0-4-alpha-generic-di 
jfs-modules-3.16.0-4-alpha-generic-di xfs-modules-3.16.0-4-alpha-generic-di 
fat-modules-3.16.0-4-alpha-generic-di
 md-modules-3.16.0-4-alpha-generic-di 
multipath-modules-3.16.0-4-alpha-generic-di 
usb-modules-3.16.0-4-alpha-generic-di 
usb-storage-modules-3.16.0-4-alpha-generic-di 
fb-modules-3.16.0-4-alpha-generic-di input-modules-3.16.0-4-alpha-generic-di 
event-modules-3.16.0-4-alpha-generic-di mouse-modules-3.16.0-4-alpha-generic-di 
nic-pcmcia-modules-3.16.0-4-alpha-generic-di 
pcmcia-modules-3.16.0-4-alpha-generic-di 
nic-usb-modules-3.16.0-4-alpha-generic-di 
sata-modules-3.16.0-4-alpha-generic-di core-modules-3.16.0-4-alpha-generic-di 
crc-modules-3.16.0-4-alpha-generic-di crypto-modules-3.16.0-4-alpha-generic-di 
crypto-dm-modules-3.16.0-4-alpha-generic-di 
ata-modules-3.16.0-4-alpha-generic-di nbd-modules-3.16.0-4-alpha-generic-di 
squashfs-modules-3.16.0-4-alpha-generic-di 
virtio-modules-3.16.0-4-alpha-generic-di zlib-modules-3.16.0-4-alpha-generic-di 
fuse-modules-3.16.0-4-alpha-generic-di srm-modules-3.16.0-4-alpha-generic-di 
linux-headers-3.16.0-4-common
 linux-image-3.16.0-4-alpha-generic linux-headers-3.16.0-4-alpha-generic 
linux-image-3.16.0-4-alpha-smp linux-headers-3.16.0-4-alpha-smp 
linux-headers-3.16.0-4-all-amd64 kernel-image-3.16.0-4-amd64-di 
nic-modules-3.16.0-4-amd64-di nic-wireless-modules-3.16.0-4-amd64-di 
nic-shared-modules-3.16.0-4-amd64-di serial-modules-3.16.0-4-amd64-di 
usb-serial-modules-3.16.0-4-amd64-di ppp-modules-3.16.0-4-amd64-di 
pata-modules-3.16.0-4-amd64-di cdrom-core-modules-3.16.0-4-amd64-di 
firewire-core-modules-3.16.0-4-amd64-di scsi-core-modules-3.16.0-4-amd64-di 
scsi-modules-3.16.0-4-amd64-di scsi-common-modules-3.16.0-4-amd64-di 
scsi-extra-modules-3.16.0-4-amd64-di loop-modules-3.16.0-4-amd64-di 
btrfs-modules-3.16.0-4-amd64-di ext4-modules-3.16.0-4-amd64-di 
isofs-modules-3.16.0-4-amd64-di jfs-modules-3.16.0-4-amd64-di 
ntfs-modules-3.16.0-4-amd64-di xfs-modules-3.16.0-4-amd64-di 
fat-modules-3.16.0-4-amd64-di md-modules-3.16.0-4-amd64-di 
multipath-modules-3.16.0-4-amd64-di
 usb-modules-3.16.0-4-amd64-di usb-storage-modules-3.16.0-4-amd64-di 
pcmcia-storage-modules-3.16.0-4-amd64-di fb-modules-3.16.0-4-amd64-di 
input-modules-3.16.0-4-amd64-di event-modules-3.16.0-4-amd64-di 
mouse-modules-3.16.0-4-amd64-di nic-pcmcia-modules-3.16.0-4-amd64-di 
pcmcia-modules-3.16.0-4-amd64-di nic-usb-modules-3.16.0-4-amd64-di 
sata-modules-3.16.0-4-amd64-di core-modules-3.16.0-4-amd64-di 
acpi-modules-3.16.0-4-amd64-di i2c-modules-3.16.0-4-amd64-di 
crc-modules-3.16.0-4-amd64-di crypto-modules-3.16.0-4-amd64-di 
crypto-dm-modules-3.16.0-4-amd64-di efi-modules-3.16.0-4-amd64-di 
ata-modules-3.16.0-4-amd64-di mmc-core-modules-3.16.0-4-amd64-di 
mmc-modules-3.16.0-4-amd64-di nbd-modules-3.16.0-4-amd64-di 
squashfs-modules-3.16.0-4-amd64-di speakup-modules-3.16.0-4-amd64-di 
virtio-modules-3.16.0-4-amd64-di uinput-modules-3.16.0-4-amd64-di 
sound-modules-3.16.0-4-amd64-di hyperv-modules-3.16.0-4-amd64-di 
udf-modules-3.16.0-4-amd64-di fuse-modules-3.16.0-4-amd64-di
 linux-image-3.16.0-4-amd64 linux-headers-3.16.0-4-amd64 
linux-image-3.16.0-4-amd64-dbg xen-linux-system-3.16.0-4-amd64 
linux-headers-3.16.0-4-all-arm64 kernel-image-3.16.0-4-arm64-di 
nic-modules-3.16.0-4-arm64-di nic-wireless-modules-3.16.0-4-arm64-di 
nic-shared-modules-3.16.0-4-arm64-di ppp-modules-3.16.0-4-arm64-di 
cdrom-core-modules-3.16.0-4-arm64-di scsi-core-modules-3.16.0-4-arm64-di 
scsi-modules-3.16.0-4-arm64-di loop-modules-3.16.0-4-arm64-di 
btrfs-modules-3.16.0-4-arm64-di ext4-modules-3.16.0-4-arm64-di 
isofs-modules-3.16.0-4-arm64-di jfs-modules-3.16.0-4-arm64-di 
xfs-modules-3.16.0-4-arm64-di fat-modules-3.16.0-4-arm64-di 
md-modules-3.16.0-4-arm64-di multipath-modules-3.16.0-4-arm64-di 
usb-modules-3.16.0-4-arm64-di usb-storage-modules-3.16.0-4-arm64-di 
input-modules-3.16.0-4-arm64-di event-modules-3.16.0-4-arm64-di 
nic-usb-modules-3.16.0-4-arm64-di sata-modules-3.16.0-4-arm64-di 
core-modules

Bug#795060: Latest Wheezy backport kernel prefers Infiniband mlx4_en over mlx4_ib, breaks existing installs

[Ben Hutchings]

Control: severity -1 important
Control: tag -1 upstream

On Mon, 2015-08-10 at 13:52 +0900, Christian Balzer wrote:
[...]
> I'm also not seeing this on several other machines we use for Ceph with the
> current Jessie kernel, but to be fair they use slightly different (QDR,
> not FDR) ConnectX-3 HBAs.

If SR-IOV is enabled on the adapter then the ports will always operate
in Ethernet mode as it's apparently not supported for IB.  Perhaps SR
-IOV enabled on some adapters but not others?

If that's not the issue, it looks like you are supposed to set a module
parameter in mlx4_core:
port_type_array:Array of port types: HW_DEFAULT (0) is default 1 for IB, 2 
for Ethernet (array of int)
e.g.:
options mlx4_core port_type_array=1,1

I don't know what determines the hardware default.

[...]
> Given that the previous version works as expected and that Jessie is
> doing the "right" thing as well, I'd consider this a critical bug.

No, it is important (since it is a regression) but it is not critical.

> Had I rebooted the older production cluster with 500,000 users on it into
> this kernel, the results would not have been pretty.

And that's why you tested on one machine first, right?

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.



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

Processed: Re: Bug#795060: Latest Wheezy backport kernel prefers Infiniband mlx4_en over mlx4_ib, breaks existing installs

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #795060 [linux-image-3.16.0-0.bpo.4-amd64] Latest Wheezy backport kernel 
prefers Infiniband mlx4_en over mlx4_ib, breaks existing installs
Severity set to 'important' from 'critical'
> tag -1 upstream
Bug #795060 [linux-image-3.16.0-0.bpo.4-amd64] Latest Wheezy backport kernel 
prefers Infiniband mlx4_en over mlx4_ib, breaks existing installs
Added tag(s) upstream.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b795060.14392148552201.transcr...@bugs.debian.org

Bug#794468: general: no watchdog support in installer kernel

[Ben Hutchings]

On Sun, 2015-08-09 at 13:39 +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
> 
> >Which watchdog device is this, that is enabled by the BIOS?  Normally I
> >expect them to be enabled only by the kernel driver.
> 
> It’s a 19″ server from Supermicro; Dominik would’ve to provide details.
> 
> >install time since the watchdog devices are not enabled by the system
> >firmware.
> 
> Oh well… apparently, the firmware setup screens don’t signal the
> watchdog either, so you can’t use that one for five minutes while
> the watchdog is enabled. This all points to buggy firmware. Again,
> details would have to come from Nik.

Then I think this should be fixed in the firmware.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.



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

Bug#795072: linux-image-3.16.0-4-amd64: freeze Oops BUG: unable to handle kernel paging request at

[igor80]

Package: src:linux
Version: 3.16.7-ckt11-1+deb8u3
Severity: normal

Dear Maintainer,

It is the default gnome desktop.
The whole system freezes after that Oops.
I do not have a clue of what could possibly be the cause.

Thanks.

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=aeff6d30-8391-4504-b422-04a6cb602ed2 ro quiet

** Not tainted

** Kernel log:
[ 1752.443287] BUG: unable to handle kernel paging request at 00040070
[ 1752.443302] IP: [] ksize+0x5c/0x80
[ 1752.443316] PGD 0 
[ 1752.443321] Oops:  [#1] SMP 
[ 1752.443328] Modules linked in: arc4 brcmsmac cordic brcmutil mac80211 
cfg80211 uvcvideo videobuf2_vmalloc bcma videobuf2_memops rtsx_pci_ms memstick 
videobuf2_core v4l2_common videodev joydev media acer_wmi sparse_keymap rfkill 
iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic 
coretemp pcspkr psmouse evdev shpchp wmi snd_hda_codec_hdmi serio_raw 
gma500_gfx snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep 
drm_kms_helper lpc_ich drm i2c_algo_bit i2c_i801 battery ac snd_pcm snd_timer 
snd i2c_core soundcore video button acpi_cpufreq processor fuse autofs4 ext4 
crc16 mbcache jbd2 hid_generic usbhid hid sg sd_mod crc_t10dif 
crct10dif_generic crct10dif_common rtsx_pci_sdmmc mmc_core ahci libahci libata 
ehci_pci scsi_mod uhci_hcd ehci_hcd usbcore usb_common rtsx_pci mfd_core r8169 
mii thermal thermal_sys
[ 1752.443431] CPU: 2 PID: 510 Comm: Xorg Tainted: GW 
3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u3
[ 1752.443436] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.09 09/04/2012
[ 1752.443441] task: 88003cb115b0 ti: 8800368b4000 task.ti: 
8800368b4000
[ 1752.443446] RIP: 0010:[]  [] 
ksize+0x5c/0x80
[ 1752.443453] RSP: 0018:8800368b7bc0  EFLAGS: 00010246
[ 1752.443458] RAX: 00040004 RBX: 880039ef5a00 RCX: 1000
[ 1752.443462] RDX: 8000 RSI: 88003daf1600 RDI: eabefc60
[ 1752.443467] RBP: 880036914000 R08: 8800368b7cd4 R09: 0003
[ 1752.443471] R10: 7000 R11: f000 R12: 
[ 1752.443475] R13: 88003d86b1c0 R14: 0ec0 R15: 
[ 1752.443481] FS:  7ff905eea980() GS:88003f30() 
knlGS:
[ 1752.443485] CS:  0010 DS:  ES:  CR0: 80050033
[ 1752.443489] CR2: 00040070 CR3: 3d3fa000 CR4: 07e0
[ 1752.443493] Stack:
[ 1752.443497]  8140cbd7  0008 
88003aac4c00
[ 1752.443504]  0008 0ec0 88003cb115b0 

[ 1752.443511]  81408927 88003cb115b0 8000 
00034140
[ 1752.443518] Call Trace:
[ 1752.443528]  [] ? __alloc_skb+0x87/0x2a0
[ 1752.443537]  [] ? sock_alloc_send_pskb+0x197/0x3b0
[ 1752.443546]  [] ? unix_stream_sendmsg+0x27c/0x410
[ 1752.443553]  [] ? sock_aio_write+0xf6/0x120
[ 1752.443562]  [] ? poll_select_copy_remaining+0x140/0x140
[ 1752.443569]  [] ? ___sys_recvmsg+0x107/0x2a0
[ 1752.443577]  [] ? do_sync_readv_writev+0x48/0x80
[ 1752.443584]  [] ? do_readv_writev+0x1bd/0x240
[ 1752.443593]  [] ? enqueue_hrtimer+0x21/0x80
[ 1752.443600]  [] ? SyS_writev+0x46/0xd0
[ 1752.443609]  [] ? system_call_fast_compare_end+0x10/0x15
[ 1752.443612] Code: 48 8d 04 fd 00 00 00 00 48 c1 e7 06 48 29 c7 48 b8 00 00 
00 00 00 ea ff ff 48 01 c7 48 8b 07 f6 c4 80 75 0e 48 89 f8 48 8b 40 30 <48> 63 
40 6c c3 0f 0b 48 8b 47 30 48 8b 17 80 e6 80 48 0f 44 c7 
[ 1752.443682] RIP  [] ksize+0x5c/0x80
[ 1752.443689]  RSP 
[ 1752.443692] CR2: 00040070
[ 1752.443699] ---[ end trace 42c6d479b8834dfa ]---

** Model information
sys_vendor: Packard Bell
product_name: dot s
product_version: V1.09
chassis_vendor: Chassis Manufacturer
chassis_version: Chassis Version
bios_vendor: Insyde Corp.
bios_version: V1.09
board_vendor: Packard Bell
board_name: SJE01_CT
board_version: Base Board Version

** Loaded modules:
arc4
brcmsmac
cordic
brcmutil
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_core
mac80211
v4l2_common
videodev
joydev
cfg80211
media
acer_wmi
rtsx_pci_ms
memstick
bcma
sparse_keymap
rfkill
iTCO_wdt
iTCO_vendor_support
pcspkr
evdev
coretemp
snd_hda_codec_realtek
snd_hda_codec_generic
snd_hda_codec_hdmi
gma500_gfx
drm_kms_helper
psmouse
drm
serio_raw
snd_hda_intel
i2c_algo_bit
i2c_i801
shpchp
wmi
lpc_ich
snd_hda_controller
i2c_core
snd_hda_codec
snd_hwdep
snd_pcm
snd_timer
ac
video
snd
soundcore
button
battery
acpi_cpufreq
processor
fuse
autofs4
ext4
crc16
mbcache
jbd2
hid_generic
usbhid
hid
sg
sd_mod
crc_t10dif
crct10dif_generic
crct10dif_common
rtsx_pci_sdmmc
mmc_core
ahci
libahci
libata
ehci_pci
uhci_hcd
scsi_mod
ehci_hcd
usbcore
rtsx_pci
usb_common
mfd_core
r8169
mii
thermal
thermal_sys

** PCI devices:
00:00.0 Host 

Bug#794680: drbd kernel module incompatible with drbd-utils -> kernel panics

[Matthew Vernon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tag -1 -moreinfo

Hi,

Sorry for the delay in getting back to you - I had to find a time when
I could crash our development Xen infrastructure without annoying my
colleagues ;-)

On 05/08/15 22:03, Ben Hutchings wrote:

> Can you reproduce this with Linux 4.1 (now in unstable)?

No - Linux 4.1 from unstable behaves itself.

> Can you reproduce this on bare hardware (without Xen)?

Yes - with the stock module it panics, with 8.4.6 (built by myself) it
behaves itself.

Regards,

Matthew
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBCgAGBQJVyHIKAAoJENoLBFPrThNN9t4H/iET55CohkVWIovlO/2/+Iju
HGpUJUI5cjMH7RZs24KPqPI3qAu+7+Rg8nQQ04H9coJwtiYUEbSeNSb9GP5yHP89
vFKpfQQylhE+DaEMQVO9MgkfXphEAoMVmeH7MO379h2dXgHmOICnmSkkwpJnISvW
9BOdqngWFU2n5Fn4R9AKv8O5VwpOZtSxjtTvA0VKs9Ky6JvAiom+8A+CsSzAcy+J
KzDT+G7HhYc7m9tvMjPjkmPCm60RfRMuok+eNjxTnVtf2qIB+7LY73XoGBlHg4Tt
OyYGnpFzFnKBngVTjVbTmGTuBiMBMjYCCnAsFngIUyHkd8lDBofAXmdYihK/Vjs=
=HD9C
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c8720a.1000...@cam.ac.uk

Processed: Re: Bug#794680: drbd kernel module incompatible with drbd-utils -> kernel panics

[Debian Bug Tracking System]

Processing control commands:

> tag -1 -moreinfo
Bug #794680 [linux] drbd kernel module incompatible with drbd-utils -> kernel 
panics
Removed tag(s) moreinfo.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b794680.143919976313718.transcr...@bugs.debian.org