Bug#850464: nfs-blkmap.service fails to start at boot

[Daniel Pocock]

package: nfs-kernel-server
version: 1:1.3.4-2
severity: serious


The blkmapd process looks for /run/rpc_pipefs/nfs/blocklayout

It fails to find it and the system boot doesn't complete, it asks for an
emergency login on the text console.

I don't see anything under /run/rpc_pipefs/nfs

Other NFS services appear to be running fine.

The ArchLinux NFS wiki recommends masking the blkmapd service:

systemctl mask nfs-blkmap.service

https://wiki.archlinux.org/index.php/NFS

Perhaps blkmapd could be split into a separate package so it is only
installed for people who want it.



blkmapd[278]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No
such file or directory



blkmapd[278]: exit on signal(15)


systemd[1]: Failed to start pNFS block layout mapping daemon.
-- Subject: Unit nfs-blkmap.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit nfs-blkmap.service has failed.
-- 
-- The result is failed.

Bug#850425: linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is full" problem only under Xen

[Ben Hutchings]

Control: tag -1 upstream moreinfo

On Fri, 2017-01-06 at 11:37 +, Andy Smith wrote:
[...]
> In this response:
> 
> https://lists.xen.org/archives/html/xen-devel/2016-12/msg00294.html
> 
> Andrew Cooper suggested trying two patches:
> > Can you try these two patches from the XenServer Patch queue?
> > https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614
> > 
> > There are bugs with some device drivers in choosing the correct DMA
> > mask, which cause them incorrectly to believe that they need
> > bounce-buffering.  Once you hit bounce buffering, everything grinds
> > to a halt.
> 
> Using a kernel built with those patches the problem has gone away for
> me and has been stable for about a month of production load.
[...]

At a first glance these patches look reasonable, but they haven't been
applied upstream.  Why not?  We don't like to add patches that aren't
accepted upstream.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert
Coveyou



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

Processed: Re: Bug#850425: linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is full" problem only under Xen

[Debian Bug Tracking System]

Processing control commands:

> tag -1 upstream moreinfo
Bug #850425 [src:linux] linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is 
full" problem only under Xen
Added tag(s) upstream and moreinfo.

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

Processed: Attaching the patches

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch
Bug #850425 [src:linux] linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is 
full" problem only under Xen
Added tag(s) patch.

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

Bug#850425: Attaching the patches

[Ben Hutchings]

Control: tag -1 patch

For future reference, these are the patches reported to fix this,
although they don't actually apply to the current jessie branch.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert
Coveyou

From 7648f3da0d79feb1e9932c309f5e87ff7f100fc5 Mon Sep 17 00:00:00 2001
From: David Vrabel 
Date: Fri, 9 May 2014 11:30:31 +0100
Subject: [PATCH 1/2] dma: add dma_get_required_mask_from_max_pfn()

ia64 provides a duplicate of the generic dma_get_required_mask()
because it has ARCH_HAS_GET_REQUIRED_MASK.  Provide a common
dma_get_require_mask_max_pfn() instead.

Signed-off-by: David Vrabel 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-i...@vger.kernel.org
diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
index 2d1ad4b1..989e77f 100644
--- a/arch/ia64/include/asm/machvec.h
+++ b/arch/ia64/include/asm/machvec.h
@@ -289,7 +289,7 @@ extern struct dma_map_ops *dma_get_ops(struct device *);
 # define platform_dma_get_ops		dma_get_ops
 #endif
 #ifndef platform_dma_get_required_mask
-# define  platform_dma_get_required_mask	ia64_dma_get_required_mask
+# define  platform_dma_get_required_mask	dma_get_required_mask_from_max_pfn
 #endif
 #ifndef platform_irq_to_vector
 # define platform_irq_to_vector		__ia64_irq_to_vector
diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
index 37a4698..ef964b2 100644
--- a/arch/ia64/include/asm/machvec_init.h
+++ b/arch/ia64/include/asm/machvec_init.h
@@ -3,7 +3,6 @@
 
 extern ia64_mv_send_ipi_t ia64_send_ipi;
 extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
-extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
 extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
 extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
 extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index de1474f..e01f2c4 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -706,26 +706,6 @@ static void __init set_pci_dfl_cacheline_size(void)
 	pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
 }
 
-u64 ia64_dma_get_required_mask(struct device *dev)
-{
-	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
-	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
-	u64 mask;
-
-	if (!high_totalram) {
-		/* convert to mask just covering totalram */
-		low_totalram = (1 << (fls(low_totalram) - 1));
-		low_totalram += low_totalram - 1;
-		mask = low_totalram;
-	} else {
-		high_totalram = (1 << (fls(high_totalram) - 1));
-		high_totalram += high_totalram - 1;
-		mask = (((u64)high_totalram) << 32) + 0x;
-	}
-	return mask;
-}
-EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
-
 u64 dma_get_required_mask(struct device *dev)
 {
 	return platform_dma_get_required_mask(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9eda842..c978ee1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -916,8 +916,7 @@ int __init platform_bus_init(void)
 	return error;
 }
 
-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
-u64 dma_get_required_mask(struct device *dev)
+u64 dma_get_required_mask_from_max_pfn(struct device *dev)
 {
 	u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
 	u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
@@ -935,6 +934,13 @@ u64 dma_get_required_mask(struct device *dev)
 	}
 	return mask;
 }
+EXPORT_SYMBOL_GPL(dma_get_required_mask_from_max_pfn);
+
+#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
+u64 dma_get_required_mask(struct device *dev)
+{
+	return dma_get_required_mask_from_max_pfn(dev);
+}
 EXPORT_SYMBOL_GPL(dma_get_required_mask);
 #endif
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 94af418..b0bf514 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,7 @@ static inline int dma_set_coherent_mask(struct device *dev, u64 mask)
 }
 #endif
 
+extern u64 dma_get_required_mask_from_max_pfn(struct device *dev);
 extern u64 dma_get_required_mask(struct device *dev);
 
 static inline unsigned int dma_get_max_seg_size(struct device *dev)
From be2602ba7152b3e2557d192c2f2a5a91d4d29e3d Mon Sep 17 00:00:00 2001
From: David Vrabel 
Date: Fri, 9 May 2014 11:40:46 +0100
Subject: [PATCH 2/2] x86,xen: correct dma_get_required_mask() for Xen PV guests

On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set device DMA masks to allow them to use
only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance 

Bug#850380: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#850380: firmware-brcm80211 breaks wlan0 on Raspbian)

[Ben Hutchings]

On Fri, 2017-01-06 at 10:34 +0100, Frank Breitling wrote:
> > Then you need to report this to Raspbian, not to Debian.
> 
> I thought so as well. However, I reported it to Debian because the
> Raspbian packet states:
> 
> Maintainer: Debian Kernel Team 
> 
> Is this another bug or should I find the actual maintainer info
> somewhere else?

I don't think Raspbian has package maintainership, so you could ignore
the Maintainer fields.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert
Coveyou



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

Bug#848265: marked as done (Please enable atusb 802.15.4 support)

[Debian Bug Tracking System]

Your message dated Fri, 06 Jan 2017 16:19:50 +
with message-id <1483719590.3983.107.ca...@decadent.org.uk>
and subject line Re: Bug#848265: Please enable atusb 802.15.4 support
has caused the Debian Bug report #848265,
regarding Please enable atusb 802.15.4 support
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.)


-- 
848265: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848265
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-amd64
Version: 4.8+76
Severity: wishlist

Hi,
it would be great to have support for the atusb 802.15.4 device
enabled. These config options do the trick on top of 4.8+76:

  CONFIG_MAC802154=m
  CONFIG_IEEE802154_ATUSB=m

This make sense on all hardware with USB IMHO.

Additionally having the fakelb for experiments without actual hardware
would be nice:

  CONFIG_IEEE802154_FAKELB=m

Cheers,
 -- Guido

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.8.0-1-amd64  4.8.7-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 4.9~rc5-1~exp1

On Thu, 2016-12-15 at 20:50 +0100, Guido Günther wrote:
> Package: linux-image-amd64
> Version: 4.8+76
> Severity: wishlist
> 
> Hi,
> it would be great to have support for the atusb 802.15.4 device
> enabled. These config options do the trick on top of 4.8+76:
> 
>   CONFIG_MAC802154=m
>   CONFIG_IEEE802154_ATUSB=m
> 
> This make sense on all hardware with USB IMHO.

These have already been enabled in experimental.

> Additionally having the fakelb for experiments without actual hardware
> would be nice:
> 
>   CONFIG_IEEE802154_FAKELB=m

I can add that.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.


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

Bug#850425: linux-image-3.16.0-4-amd64: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andy Smith]

Package: src:linux
Version: 3.16.36-1+deb8u2
Severity: normal

Dear Maintainer,

This machine has an LSI SAS controller using the mpt3sas drive.

When running as a Xen dom0 and hitting the drives attached to the
SAS controller with significant IO (e.g.e the mdadm periodic scrub),
kernel errors happen within a few seconds, sometimes to the point of
panic and reboot. If not reboot then IO crawls to an unusably slow
speed.

As this only happens when running as a Xen dom0, I reported this to the
xen-devel list:

https://lists.xen.org/archives/html/xen-devel/2016-12/msg00287.html

In this response:

https://lists.xen.org/archives/html/xen-devel/2016-12/msg00294.html

Andrew Cooper suggested trying two patches:
> Can you try these two patches from the XenServer Patch queue?
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614
> 
> There are bugs with some device drivers in choosing the correct DMA
> mask, which cause them incorrectly to believe that they need
> bounce-buffering.  Once you hit bounce buffering, everything grinds
> to a halt.

Using a kernel built with those patches the problem has gone away for
me and has been stable for about a month of production load.

I tried a backports kernel and it still has the problem. I don't think
this is fixed in stretch or sid either from a quick look but I may be
mistaken.

I don't know the timescale at which the patches Andrew Cooper linked to
will make it into upstream but I thought it best to report this bug as
it seems likely that others will be affected.

Some logs of the problem happening are appended below.

Thanks,
Andy

Dec  4 07:06:00 elephant kernel: [22019.373653] mpt3sas :01:00.0: swiotlb 
buffer is full (sz: 57344 bytes)
Dec  4 07:06:00 elephant kernel: [22019.374707] mpt3sas :01:00.0: swiotlb 
buffer is full
Dec  4 07:06:00 elephant kernel: [22019.375754] BUG: unable to handle kernel 
NULL pointer dereference at 0010
Dec  4 07:06:00 elephant kernel: [22019.376430] IP: [] 
_base_build_sg_scmd_ieee+0x1f9/0x2d0 [mpt3sas]
Dec  4 07:06:00 elephant kernel: [22019.377122] PGD 0
Dec  4 07:06:00 elephant kernel: [22019.377825] Oops:  [#1] SMP
Dec  4 07:06:00 elephant kernel: [22019.378494] Modules linked in: binfmt_misc 
xen_gntdev xen_evtchn xenfs xen_privcmd nfsd auth_rpcgss oid_registry nfs_acl 
nfs lockd fscache sunrpc ipt_REJECT xt_LOG xt_limit xt_NFLOG nfnetlink_log 
nfnetlink xt_multiport xt_tcpudp iptable_filter ip_tables x_tables bonding 
joydev hid_generic usbhid hid x86_pkg_temp_thermal coretemp crc32_pclmul 
crc32c_intel iTCO_wdt iTCO_vendor_support evdev aesni_intel aes_x86_64 lrw 
gf128mul glue_helper ablk_helper cryptd pcspkr i2c_i801 ast ttm drm_kms_helper 
xhci_hcd ehci_pci ehci_hcd drm lpc_ich mfd_core mei_me usbcore mei usb_common 
igb ptp pps_core dca sg i2c_algo_bit i2c_core shpchp tpm_tis tpm button wmi 
ipmi_si ipmi_msghandler processor thermal_sys acpi_power_meter fuse autofs4 
ext4 crc16 mbcache jbd2 dm_mod raid10 raid1 md_mod sd_mod crc_t10dif 
crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci libata mpt3sas 
raid_class scsi_transport_sas scsi_mod
Dec  4 07:06:00 elephant kernel: [22019.384778] CPU: 0 PID: 29516 Comm: 
md5_resync Not tainted 3.16.0-4-amd64 #1 Debian 3.16.36-1+deb8u2
Dec  4 07:06:00 elephant kernel: [22019.385574] Hardware name: Supermicro Super 
Server/X10SRH-CLN4F, BIOS 2.0a 09/20/2016
Dec  4 07:06:00 elephant kernel: [22019.386400] task: 8800704ae2d0 ti: 
88005c41 task.ti: 88005c41
Dec  4 07:06:00 elephant kernel: [22019.387204] RIP: e030:[]  
[] _base_build_sg_scmd_ieee+0x1f9/0x2d0 [mpt3sas]
Dec  4 07:06:00 elephant kernel: [22019.388054] RSP: e02b:88005c413a00  
EFLAGS: 00010282
Dec  4 07:06:00 elephant kernel: [22019.388855] RAX: 0010 RBX: 
88006fb84070 RCX: 88006fb41be0
Dec  4 07:06:00 elephant kernel: [22019.389684] RDX:  RSI: 
ff30 RDI: 88005c507300
Dec  4 07:06:00 elephant kernel: [22019.390572] RBP:  R08: 
88006f90ae80 R09: 
Dec  4 07:06:00 elephant kernel: [22019.391395] R10: 880078eec000 R11: 
0001 R12: 880071230720
Dec  4 07:06:00 elephant kernel: [22019.392235] R13: ffeb R14: 
fff3 R15: 
Dec  4 07:06:00 elephant kernel: [22019.393031] FS:  () 
GS:88007840() knlGS:
Dec  4 07:06:00 elephant kernel: [22019.393850] CS:  e033 DS:  ES:  
CR0: 80050033
Dec  4 07:06:00 elephant kernel: [22019.394639] CR2: 0010 CR3: 
6ece5000 CR4: 00042660
Dec  4 07:06:00 elephant kernel: [22019.395434] Stack:
Dec  4 07:06:00 elephant kernel: [22019.396253]  88006f90ae70 
008068812a20 88005a1a1500 88007123
Dec  4 07:06:00 elephant kernel: [22019.397065]  88006f880800 
88006fcc2800 88006fb84000 000a
Dec  4 07:06:00 elephant kernel: [22019.397888]  

Re: LED on keyboard

[Bjørn Mork]

Jan Niggemann  writes:

> I'm building a 4.8.15 kernel (which is working great) for my Thinkpad
> T460s. What bothers me, is that I can't get the LEDs on the F1 and F4
> key working ((F1=mute, F4=mic on/off). I checked CONFIG_ directives
> that seem relevant to me, but - well, I'm missing something. I have
> enabled LED-related options as well as GPIO options.
>
> The relevant LEDs work fine using the backports 4.8 kernel
> (4.8.0-0.bpo.2-amd64 #1 SMP Debian 4.8.11-1~bpo8+1 (2016-12-14) x86_64
> GNU/Linux). I have diffed both configs, but didn't spot the relevant
> option.

These LEDs seem to be hardwired to the analog mixer on my X1 gen4.  So
they only work as expected when muting analog input and output. 


Bjørn

Bug#850380: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#850380: firmware-brcm80211 breaks wlan0 on Raspbian)

[Frank Breitling]

Then you need to report this to Raspbian, not to Debian.


I thought so as well. However, I reported it to Debian because the Raspbian 
packet states:

Maintainer: Debian Kernel Team 

Is this another bug or should I find the actual maintainer info somewhere else?


On 06.01.2017 05:21, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the firmware-brcm80211 package:

#850380: firmware-brcm80211 breaks wlan0 on Raspbian

It has been closed by Ben Hutchings .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Ben Hutchings 
 by
replying to this email.