Bug#884001: Severe graphics corruption on intel graphics since linux-image-4.9.0-4-amd64

2018-02-07 Thread Narcis Garcia 
Debian 9 (amd64) with Gnome in a notebook "HP TPN-C125"

$ lspci -k
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500
(rev 09)
Subsystem: Hewlett-Packard Company HD Graphics 5500
Kernel driver in use: i915
Kernel modules: i915
$ lspci -Q -k
00:02.0 Class 0300: Device 8086:1616 (rev 09)
Subsystem: Device 103c:81ef
Kernel driver in use: i915
Kernel modules: i915

Debian Live (amd64-Gnome) 9.0 -> all fine (Linux 4.9.0-3)
Debian Live (amd64-Gnome) 9.3 -> shifting, flick, black (Linux 4.9.0-4)
Debian installed updated -> shifting, flick, black (Linux 4.9.0-5)
Debian installed downgraded -> shifting, flick, black (Linux 4.9.0-4)
Debian installed downgraded -> all fine (Linux 4.9.0-3)

Current workaround for me:
$ sudo apt-get install linux-image-4.9.0-3-amd64
$ sudo apt-get remove linux-image-amd64 linux-image-4.9.0-5-amd64
$ sudo apt-get remove linux-image-4.9.0-4-amd64

-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Fwd: Re: Bug#889487: linux-image-4.14.0-2-amd64: please enable CONFIG_X86_MCELOG_LEGACY]

2018-02-07 Thread Roger Lynn 
Sorry, forwarding a reply I messed up.

- Forwarded message from Roger Lynn  -

Date: Tue, 6 Feb 2018 23:08:05 +
From: Roger Lynn 
To: Jon DeVree , 889...@bugs.debian.org
Newsgroups: linux.debian.kernel
Subject: Re: Bug#889487: linux-image-4.14.0-2-amd64: please enable 
CONFIG_X86_MCELOG_LEGACY
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 
SeaMonkey/2.49.1

On 04/02/18 02:00, Jon DeVree wrote:
> On Sun, Feb 04, 2018 at 01:03:59 +0100, Ben Hutchings wrote:
>> This was unintentional, but I think it's correct.  The Kconfig says to
>> use rasdaemon which is already packaged and in stable.
> 
> rasdaemon has a hard dependency on systemd, it isn't installable on
> machines still running sysvinit.

Yes it is installable. It depends on systemd, not systemd-sysv. systemd is
co-installable with sysvinit-core. I have it installed on a Stretch sysvinit
system (it then complains that it can't find a debugfs).

> Not sure if thats a hard dep or if it only just means rasdaemon is
> missing a sysvinit script.

Roger

- End forwarded message -

Bug#889831: linux-image-4.14.0-0.bpo.3-amd64: USB RNDIS ethernet gadget - slow download transfers, RX errors

2018-02-07 Thread Ben Hutchings 
On Wed, 2018-02-07 at 11:05 -0500, Tomasz Janowski wrote:
> Package: src:linux
> Version: 4.14.13-1~bpo9+1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> 
> The problems seems to appear with some newer smartphones, in my case I
> test Samsung Galaxy S8. I am trying to use USB tethering and everything
> seems to work as expected (modules are loaded, Ethernet devices are up
> and running, dhcp works fine). I can connect to the external world using
> both phone LTE and phone wireless network.
> 
> Now, the problem is that download speeds are terrible, arounf 64 KB/s
> while uploads are fast, the order of 15 MB/s. These speeds do not depend
> on the provider, as the results are similar when I tether wi-fi. The USB
> Ethernet interface on Linux host reports a lot of receive errors:
> 
> enp0s20u9: flags=4163  mtu 1500
> inet 192.168.42.166  netmask 255.255.255.0  broadcast 192.168.42.255
> inet6 fe80::890:3fff:fe0e:d2c6  prefixlen 64  scopeid 0x20
> ether 0a:90:3f:0e:d2:c6  txqueuelen 1000  (Ethernet)
> RX packets 716  bytes 859199 (839.0 KiB)
> RX errors 459  dropped 0  overruns 0  frame 459
> TX packets 731  bytes 86682 (84.6 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

So these are all frame errors.  There is a log message that would give
more information about them, but it's disabled by default.  You can
enable it by running:

echo 'format "bad rndis message" +p' > 
/sys/kernel/debug/dynamic_debug/control

[...]
> I tried the newest kernel from kernel.org git repositories, but the
> problem is still there. Should I contact upstream directly?
[...]

Yes, please mail linux-...@vger.kernel.org and net...@vger.kernel.org. 
You should include a sample of the "bad rndis message" log messages
that should appear after running the above command.  Please also cc
this bug address.

Ben.

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


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

Processed: Re: Bug#889827: linux-image-4.15.0-rc8-amd64: IP offloading does not work

2018-02-07 Thread Debian Bug Tracking System 
Processing control commands:

> tag -1 upstream patch moreinfo
Bug #889827 [src:linux] r8152: TCP/IP checksum offload gives false positives
Added tag(s) patch, upstream, and moreinfo.

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

Bug#889827: linux-image-4.15.0-rc8-amd64: IP offloading does not work

2018-02-07 Thread Ben Hutchings 
Control: tag -1 upstream patch moreinfo

Does the attached patch fix it?  Instructions for building a patched
kernel package can be found at:
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
From abc83f38abd2d62ce5a443e0b2a40a76d0b75cb8 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Wed, 7 Feb 2018 21:05:37 +
Subject: [PATCH] r8152: Fix conditions for setting ip_summed =
 CHECKSUM_UNNECESSARY

Currently r8152_rx_csum() returns CHECKSUM_UNNECESSARY for any packet
which the hardware reports as being IPv4 and not having a layer-4
checksum error, even if the layer-4 protocol was not recognised.
This will incorrectly include, for example, SCTP packets.  It also
appears that some TCP packets with valid headers and bad checksums
also trigger this bug.

Use the same logic for IPv4 as for IPv6.  We don't need to check the
hardware IP header checksum flag because that's always checked in
software.

Reported-by: Vincent Danjean 
Signed-off-by: Ben Hutchings 
---
 drivers/net/usb/r8152.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0657203ffb91..c3c8e2d74f8b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1845,16 +1845,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
 	opts2 = le32_to_cpu(rx_desc->opts2);
 	opts3 = le32_to_cpu(rx_desc->opts3);
 
-	if (opts2 & RD_IPV4_CS) {
-		if (opts3 & IPF)
-			checksum = CHECKSUM_NONE;
-		else if ((opts2 & RD_UDP_CS) && (opts3 & UDPF))
-			checksum = CHECKSUM_NONE;
-		else if ((opts2 & RD_TCP_CS) && (opts3 & TCPF))
-			checksum = CHECKSUM_NONE;
-		else
-			checksum = CHECKSUM_UNNECESSARY;
-	} else if (opts2 & RD_IPV6_CS) {
+	if (opts2 & (RD_IPV4_CS | RD_IPV6_CS)) {
 		if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
 			checksum = CHECKSUM_UNNECESSARY;
 		else if ((opts2 & RD_TCP_CS) && !(opts3 & TCPF))


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

Processed: retitle 889827 to r8152: TCP/IP checksum offload gives false positives

2018-02-07 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> retitle 889827 r8152: TCP/IP checksum offload gives false positives
Bug #889827 [src:linux] linux-image-4.15.0-rc8-amd64: IP offloading does not 
work
Changed Bug title to 'r8152: TCP/IP checksum offload gives false positives' 
from 'linux-image-4.15.0-rc8-amd64: IP offloading does not work'.
> thanks
Stopping processing here.

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

Processed: Re: Bug#889809: [linux] Fails to compile external modules

2018-02-07 Thread Debian Bug Tracking System 
Processing control commands:

> retitle -1 Some out-of-tree modules fail to build due to wrong include paths
Bug #889809 [src:linux] [linux] Fails to compile external modules
Changed Bug title to 'Some out-of-tree modules fail to build due to wrong 
include paths' from '[linux] Fails to compile external modules'.
> tag -1 wontfix
Bug #889809 [src:linux] Some out-of-tree modules fail to build due to wrong 
include paths
Added tag(s) wontfix.

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

Bug#889809: [linux] Fails to compile external modules

2018-02-07 Thread Ben Hutchings 
Control: retitle -1 Some out-of-tree modules fail to build due to wrong include 
paths
Control: tag -1 wontfix

On Wed, 2018-02-07 at 10:15 +0100, Charlemagne Lasse wrote:
> Source: linux
> Version: 4.14.13-1~bpo9+1
> Severity: normal
> X-Debbugs-CC: backpo...@vger.kernel.org
> 
> It seems like the current kernel in stretch backporst and in buster
> has problems when compiling external modules against it. This worked
> fine in the past.
[...]

It works fine for modules that use Kbuild in the normal way.  You have
found two projects that seem to do strange things with include paths. 
I think you should report this problem to those projects.

Ben.

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



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

Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

2018-02-07 Thread Yves-Alexis Perez 
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez 
> 
> Hi Yves-Alexis -
> 
> I apologize for the problem.  It seems to me that tunneling with an
> outer MTU that causes the inner MTU to be smaller than the min, is
> potentially problematic in other ways as well.

Maybe. I tried with removing the MTU setting, and I get (on ping again)

févr. 07 20:44:01 scapa kernel: mtu: 1266

which means I would get -EINVAL on standards kernels, which is not really good
either.

> But also it could seem unfortunate that the code with my fix does not
> look at actual packet size, but instead only looks at the MTU and then
> fails, even if no packet was going to be so large.  The intention of
> my patch was to prevent a negative number while calculating the
> maxfraglen in  __ip6_append_data().  An alternative fix maybe to
> instead return an error only if the mtu is less than or equal to the
> fragheaderlen.   Something like:
> 
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 3763dc01e374..5d912a289b95 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk,
> struct inet_cork_full *cork,
> if (np->frag_size)
> mtu = np->frag_size;
> }
> -   if (mtu < IPV6_MIN_MTU)
> -   return -EINVAL;
> cork->base.fragsize = mtu;
> if (dst_allfrag(rt->dst.path))
> cork->base.flags |= IPCORK_ALLFRAG;
> @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk,
> 
> fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len +
> (opt ? opt->opt_nflen : 0);
> +   if (mtu < fragheaderlen + 8)
> +   return -EINVAL;
> maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen -
>  sizeof(struct frag_hdr);
> (opt ? opt->opt_nflen : 0);
> 
> But then we also have to convince ourselves that maxfraglen can never
> be <= 0.  I'd have to think about that.
> 
> I am not sure if others have thoughts on supporting MTUs configured
> below the min in the spec.
> 
Here, the MTU is not below, so I'm not sure what happens.

Regards,
-- 
Yves-Alexis

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

Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

2018-02-07 Thread Mike Maloney 
On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez  wrote:
> On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
>> I'll try to printk the mtu before returning EINVAL to see why it's lower than
>> 1280, but maybe the IP encapsulation is not correctly handled?
>
> I did:
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 3763dc01e374..d3c651158d35 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1215,7 +1215,7 @@ static int ip6_setup_cork(struct sock *sk, struct 
> inet_cork_full *cork,
> mtu = np->frag_size;
> }
> if (mtu < IPV6_MIN_MTU)
> -   return -EINVAL;
> +   printk("mtu: %d\n", mtu);
> cork->base.fragsize = mtu;
> if (dst_allfrag(rt->dst.path))
> cork->base.flags |= IPCORK_ALLFRAG;
>
> and I get:
>
> févr. 07 18:19:50 scapa kernel: mtu: 1218
>
> and it doesn't depend on the original packet size (same thing happens with
> ping -s 100). It also happens with UDP (DNS) traffic, but apparently not with
> TCP.
>
> Regards,
> --
> Yves-Alexis

Hi Yves-Alexis -

I apologize for the problem.  It seems to me that tunneling with an
outer MTU that causes the inner MTU to be smaller than the min, is
potentially problematic in other ways as well.

But also it could seem unfortunate that the code with my fix does not
look at actual packet size, but instead only looks at the MTU and then
fails, even if no packet was going to be so large.  The intention of
my patch was to prevent a negative number while calculating the
maxfraglen in  __ip6_append_data().  An alternative fix maybe to
instead return an error only if the mtu is less than or equal to the
fragheaderlen.   Something like:

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 3763dc01e374..5d912a289b95 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk,
struct inet_cork_full *cork,
if (np->frag_size)
mtu = np->frag_size;
}
-   if (mtu < IPV6_MIN_MTU)
-   return -EINVAL;
cork->base.fragsize = mtu;
if (dst_allfrag(rt->dst.path))
cork->base.flags |= IPCORK_ALLFRAG;
@@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk,

fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len +
(opt ? opt->opt_nflen : 0);
+   if (mtu < fragheaderlen + 8)
+   return -EINVAL;
maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen -
 sizeof(struct frag_hdr);
(opt ? opt->opt_nflen : 0);

But then we also have to convince ourselves that maxfraglen can never
be <= 0.  I'd have to think about that.

I am not sure if others have thoughts on supporting MTUs configured
below the min in the spec.


Thanks.
--
Mike Maloney

Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

2018-02-07 Thread Ivan Zakharyaschev 

Hi Jason,

On Sun, 4 Feb 2018, Jason Duerstock wrote:


Does the kernel from here work for you?:

https://people.debian.org/~jrtc27/wheezy-backports-ia64/

Specifically 
https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb


(As I've already said, this kernel works for our machine.)

How to reproduce this build? Have you published the corresponding rules?

I tried:

$ apt-get source linux-image-3.16.0-0.bpo.4-mckinley
Reading package lists... Done
Building dependency tree
Reading state information... Done
Picking 'linux' as source package instead of 
'linux-image-3.16.0-0.bpo.4-mckinley'
NOTICE: 'linux' packaging is maintained in the 'Git' version control 
system at:

https://anonscm.debian.org/git/kernel/linux.git
Need to get 84.2 MB of source archives.
Get:1 http://ftp.ru.debian.org/debian/ wheezy-backports/main linux 
3.16.39-1+deb8u1~bpo70+1 (dsc) [97.4 kB]
Get:2 http://ftp.ru.debian.org/debian/ wheezy-backports/main linux 
3.16.39-1+deb8u1~bpo70+1 (tar) [81.8 MB]
Get:3 http://ftp.ru.debian.org/debian/ wheezy-backports/main linux 
3.16.39-1+deb8u1~bpo70+1 (diff) [2,316 kB]

Fetched 84.2 MB in 9s (9,087 kB/s)
dpkg-source: info: extracting linux in linux-3.16.39
dpkg-source: info: unpacking linux_3.16.39.orig.tar.xz
dpkg-source: info: unpacking linux_3.16.39-1+deb8u1~bpo70+1.debian.tar.xz
dpkg-source: info: applying debian/version.patch
...
$ cd linux-3.16.39/
$ sed -e 's/gcc-4.6/gcc-4.4/g' debian/config/ia64/defines -i
$ debuild -b -us -uc
$ debuild -j2 -b -us -uc
...
  LINKvmlinux
  LD  vmlinux.o
  MODPOST vmlinux.o
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
  KSYM.tmp_kallsyms1.o
  KSYM.tmp_kallsyms2.o
  LD  vmlinux
  SYSMAP  System.map
  Building modules, stage 2.
  OBJCOPY arch/ia64/hp/sim/boot/vmlinux.bin
  GZIParch/ia64/hp/sim/boot/vmlinux.gz
  MODPOST 2506 modules
  LN  vmlinux.gz
  Kernel: vmlinux.gz is ready
ERROR: "numa_slit" [drivers/block/nvme.ko] undefined!
make[6]: *** [__modpost] Error 1
make[5]: *** [modules] Error 2
make[4]: *** [sub-make] Error 2
make[3]: *** [__sub-make] Error 2
make[3]: Leaving directory 
`/home/imz/with-gcc-4.4.7_wheezy/linux-3.16.39/debian/build/build_ia64_none_itanium'

make[2]: *** [debian/stamps/build_ia64_none_itanium_plain] Error 2
make[2]: Leaving directory `/home/imz/with-gcc-4.4.7_wheezy/linux-3.16.39'
make[1]: *** [build-arch_ia64_none_itanium_real] Error 2
make[1]: Leaving directory `/home/imz/with-gcc-4.4.7_wheezy/linux-3.16.39'
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1357:
dpkg-buildpackage -rfakeroot -D -us -uc -j2 -b failed

$

(Parallellization, i.e., -j2, doesn't affect the result; I have checked 
that.)



On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev  wrote:



Yes, [this one] doesn't boot on our system. It might even be in our case a
strange/buggy behavior caused by old firmware for an otherwise correct
kernel binary code (or, of course, the code might be not correct). Perhaps,
there is a difference between yours and ours machines:

root@rx2620:~# cat /proc/cpuinfo
processor  : 0
vendor : GenuineIntel
arch   : IA-64
family : 31
model  : 2
model name : Madison up to 9M cache
revision   : 1
archrev: 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz: 1600.021
itc MHz: 1600.021752
BogoMIPS   : 2390.01
siblings   : 1
physical id: 0

processor  : 1
vendor : GenuineIntel
arch   : IA-64
family : 31
model  : 2
model name : Madison up to 9M cache
revision   : 1
archrev: 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz: 1600.021
itc MHz: 1600.021752
BogoMIPS   : 2390.01
siblings   : 1
physical id: 1

root@rx2620:~#

It looks like ours has 2 Madison CPUs (if we are to trust this cpuinfo),
which are older than your Montecito ones.




 [this one]:
 https://packages.debian.org/wheezy/linux-image-3.2.0-4-mckinley



So far, we've done a number of attempts to compile and boot a kernel (I'm
going to post the details and the kernels soon), and my conclusion so far is
that the only affecting factor is the version of gcc (even not -O1 vs
-Os/-O2).

gcc <= 4.5.3 produces a bootable kernel (as for
linux-image-3.2.0-4-mckinley, gcc 4.4.7 from wheezy and gcc 4.5.3 from
snapshots produced a bootable one in my experiments);
gcc > = 4.6.3 produces a non-bootable kernel.

So this already gives an initial hypothesis about the solution to 1):

To compile a bootable kernel for this machine, use gcc <= 4.5.3.

Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

2018-02-07 Thread Yves-Alexis Perez 
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
> I'll try to printk the mtu before returning EINVAL to see why it's lower than
> 1280, but maybe the IP encapsulation is not correctly handled?

I did:

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 3763dc01e374..d3c651158d35 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1215,7 +1215,7 @@ static int ip6_setup_cork(struct sock *sk, struct 
inet_cork_full *cork,
mtu = np->frag_size;
}
if (mtu < IPV6_MIN_MTU)
-   return -EINVAL;
+   printk("mtu: %d\n", mtu);
cork->base.fragsize = mtu;
if (dst_allfrag(rt->dst.path))
cork->base.flags |= IPCORK_ALLFRAG;

and I get:

févr. 07 18:19:50 scapa kernel: mtu: 1218

and it doesn't depend on the original packet size (same thing happens with
ping -s 100). It also happens with UDP (DNS) traffic, but apparently not with
TCP.

Regards,
-- 
Yves-Alexis

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

Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

2018-02-07 Thread Yves-Alexis Perez 
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote:
> Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
> to an IPv6 address I get:
> 
> ping: sendmsg: Invalid argument

I forgot an important bit of information: due to the way routers usually broke
path MTU discovery by filtering ICMP, I'm lowering the MTU to 1280 (so exactly
  IPV6_MIN_MTU) when using IPsec.

The MTU is configured by the IKE daemon (strongSwan, thus adding Tobias to
CC:) in routing table 220:

default via 192.168.28.254 dev eth0 proto static src 192.168.0.129 mtu 1280 
advmss 1320

I'll try to printk the mtu before returning EINVAL to see why it's lower than
1280, but maybe the IP encapsulation is not correctly handled?

Regards,
-- 
Yves-Alexis

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

Bug#889831: linux-image-4.14.0-0.bpo.3-amd64: USB RNDIS ethernet gadget - slow download transfers, RX errors

2018-02-07 Thread Tomasz Janowski 
Package: src:linux
Version: 4.14.13-1~bpo9+1
Severity: normal
Tags: upstream

Dear Maintainer,


The problems seems to appear with some newer smartphones, in my case I
test Samsung Galaxy S8. I am trying to use USB tethering and everything
seems to work as expected (modules are loaded, Ethernet devices are up
and running, dhcp works fine). I can connect to the external world using
both phone LTE and phone wireless network.

Now, the problem is that download speeds are terrible, arounf 64 KB/s
while uploads are fast, the order of 15 MB/s. These speeds do not depend
on the provider, as the results are similar when I tether wi-fi. The USB
Ethernet interface on Linux host reports a lot of receive errors:

enp0s20u9: flags=4163  mtu 1500
inet 192.168.42.166  netmask 255.255.255.0  broadcast 192.168.42.255
inet6 fe80::890:3fff:fe0e:d2c6  prefixlen 64  scopeid 0x20
ether 0a:90:3f:0e:d2:c6  txqueuelen 1000  (Ethernet)
RX packets 716  bytes 859199 (839.0 KiB)
RX errors 459  dropped 0  overruns 0  frame 459
TX packets 731  bytes 86682 (84.6 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and no transmission errors. This seems to be consistent with the
obtained data transfers.

There are no kernel error messages, only standard info about drivers
being loaded:

[  101.285339] usb 3-9: new high-speed USB device number 4 using xhci_hcd
[  101.438203] usb 3-9: New USB device found, idVendor=04e8, idProduct=6860
[  101.438207] usb 3-9: New USB device strings: Mfr=7, Product=8, SerialNumber=9
[  101.438209] usb 3-9: Product: SAMSUNG_Android
[  101.438211] usb 3-9: Manufacturer: SAMSUNG
[  101.438213] usb 3-9: SerialNumber: 98882945364a434f46
[  120.261092] usb 3-9: USB disconnect, device number 4
[  120.705638] usb 3-9: new high-speed USB device number 5 using xhci_hcd
[  120.857336] usb 3-9: New USB device found, idVendor=04e8, idProduct=6863
[  120.857341] usb 3-9: New USB device strings: Mfr=7, Product=8, SerialNumber=9
[  120.857344] usb 3-9: Product: SAMSUNG_Android
[  120.857346] usb 3-9: Manufacturer: SAMSUNG
[  120.857349] usb 3-9: SerialNumber: 98882945364a434f46
[  120.913643] usbcore: registered new interface driver cdc_ether
[  120.916880] rndis_host 3-9:1.0 usb0: register 'rndis_host' at 
usb-:00:14.0-9, RNDIS device, da:6c:2c:dc:42:53
[  120.916919] usbcore: registered new interface driver rndis_host
[  120.918709] rndis_host 3-9:1.0 enp0s20u9: renamed from usb0

It seems like a protocol compatibility issue, because the same phone
works superfast with Windows 10 machine (the same hardware running under
Windows 10). I also did not experience any problems with older phone,
like Galaxy J7 Pro. Both download and upload was fast.

I tried the newest kernel from kernel.org git repositories, but the
problem is still there. Should I contact upstream directly?


-- Package-specific info:
** Version:
Linux version 4.14.0-0.bpo.3-amd64 (debian-kernel@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.14.13-1~bpo9+1 
(2018-01-14)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-0.bpo.3-amd64 
root=UUID=8c76acc2-3a2a-470d-acac-0737925efafa ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: Z97-D3H
product_version: To be filled by O.E.M.
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: F7
board_vendor: Gigabyte Technology Co., Ltd.
board_name: Z97-D3H-CF
board_version: x.x

** Loaded modules:
rndis_host
cdc_ether
usbnet
ipt_REJECT
nf_reject_ipv4
xt_multiport
drbg
ansi_cprng
authenc
echainiv
xfrm6_mode_tunnel
xfrm4_mode_tunnel
iptable_mangle
xt_mark
xt_nat
nf_log_ipv4
nf_log_common
xfrm_user
xfrm4_tunnel
tunnel4
xt_LOG
ipcomp
xfrm_ipcomp
xt_conntrack
esp4
xt_tcpudp
ah4
af_key
xfrm_algo
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
pci_stub
vboxpci(O)
iptable_filter
vboxnetadp(O)
vboxnetflt(O)
vboxdrv(O)
algif_skcipher
af_alg
dummy
bridge
stp
llc
binfmt_misc
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
snd_hda_codec_hdmi
evdev
iTCO_wdt
iTCO_vendor_support
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
intel_cstate
intel_uncore
intel_rapl_perf
pcspkr
snd_soc_rt5640
snd_soc_sst_acpi
i915
snd_soc_ssm4567
snd_soc_rl6231
snd_hda_codec_realtek
dw_dmac
parport_serial
sg
snd_hda_codec_generic
dw_dmac_core
battery
snd_soc_sst_match
spi_pxa2xx_platform
snd_hda_intel
snd_hda_codec
snd_soc_core
video
elan_i2c
snd_hda_core
drm_kms_helper
snd_hwdep
snd_compress
tpm_infineon
snd_pcm
drm
snd_timer
acpi_pad
button
shpchp
snd
i2c_algo_bit
mei_me
mei
lpc_ich
soundcore
mfd_core
parport_pc
ppdev
lp
parport
sunrpc
loop
dm_crypt
dm_mod
ip_tables
x_tables
autofs4
ext4
crc16

Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

2018-02-07 Thread Yves-Alexis Perez 
Hi Mike,

I noticed a regression in 4.14.16 stable kernel (I assume it's also
present in mainline).

I'm using an IPsec setup where I tunnel all my IP trafic to a gateway.
The tunnel can use either IPv6 or IPv4 (depending on what's available
locally) and will route both IPv4 and IPv6 (my gateway will assign both
family addresses).

The tunnel doesn't use ESP directly but rather encapsulates in UDP.

Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
to an IPv6 address I get:

ping: sendmsg: Invalid argument

I bisected 4.14.15 to 4.14.16 and got the attached bisect log, which
ends with 8278804e05f6bcfe3fdfea4a404020752ead15a6 as the offending
commit. The -EINVAL is consistent with the “Invalid argument” return
from ping. I didn't try yet on a pure IPv6 setup (without IPsec
tunneling) but will followup when I have a chance to test it.

Reverting that commit on top of 4.14.17 fixes the problem.

If you need more info, please ask.

Regards,
-- 
Yves-Alexis# bad: [6c70076667f246dc200c7a3e9aeabd2f8f388416] Linux 4.14.16
# good: [a16134b082346b7e7c34f594a0763eafacdcea92] Linux 4.14.15
git bisect start 'v4.14.16' 'v4.14.15'
# bad: [72d4f3abd6d3521f5cd978b63f9301051f127812] r8169: fix memory corruption on retrieval of hardware statistics.
git bisect bad 72d4f3abd6d3521f5cd978b63f9301051f127812
# good: [295bcfbbcf5a741e9103605c3252276ed21433bb] ARM: net: bpf: correct stack layout documentation
git bisect good 295bcfbbcf5a741e9103605c3252276ed21433bb
# bad: [8278804e05f6bcfe3fdfea4a404020752ead15a6] ipv6: fix udpv6 sendmsg crash caused by too small MTU
git bisect bad 8278804e05f6bcfe3fdfea4a404020752ead15a6
# good: [9ad970c8a13595e38d3af98114bcbbec6d8a5be4] drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
git bisect good 9ad970c8a13595e38d3af98114bcbbec6d8a5be4
# good: [42d68bf2a42381642ea5ae460c6a5d86a56213f0] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
git bisect good 42d68bf2a42381642ea5ae460c6a5d86a56213f0
# good: [2295b3dd543f9a5a1834e4265d506a5bc0819983] ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL
git bisect good 2295b3dd543f9a5a1834e4265d506a5bc0819983
# first bad commit: [8278804e05f6bcfe3fdfea4a404020752ead15a6] ipv6: fix udpv6 sendmsg crash caused by too small MTU


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

Bug#889827: linux-image-4.15.0-rc8-amd64: IP offloading does not work

2018-02-07 Thread Vincent Danjean 
Package: src:linux
Version: 4.15~rc8-1~exp1
Severity: normal

  Hi,

  Since I got my laptop, I sometimes see some issues when transfering big
chunks of data ("dd if=big-partition ... | ssh ...", or just plain "apt 
upgrade").
With the ssh, I got error messages about wrong protocol (sorry, I did not
keep the error message). With apt, I got such kind of messages while downloading
the packages:
[...]
Réception de:82 http://ftp.fr.debian.org/debian unstable/main amd64 libgdal20 
amd64 2.2.3+dfsg-2 [5 327 kB]
Err:82 http://ftp.fr.debian.org/debian unstable/main amd64 libgdal20 amd64 
2.2.3+dfsg-2
  Somme de contrôle de hachage incohérente
  Hashes of expected file:
   - SHA256:832ddfc6014fd3be7f7cf61191e6eff2136e09d1636832bc09c63b4afb63e29e
   - MD5Sum:e9f3cd0628a30760a8fec012ba48a1fe [weak]
   - Filesize:5327124 [weak]
  Hashes of received file:
   - SHA256:e52c862d27a7fcb3cdadfd2d6afe4645f68940bae0cc238f0d0cc184081875ba
   - MD5Sum:21a29fff8d706b6a0233735ca2e78bcd [weak]
   - Filesize:5327124 [weak]
  Last modification reported: Tue, 06 Feb 2018 09:59:18 +
[...]

  In both cases, the error is transient (if I retry, it generally works or
it fails at another place) and occurs on high-speed network (ssh on a local
GB network, apt on a local GB network and then a high speed ISP network (the
French Renater network)). I did not observe issues on small transferts nor
on transfert on slower networks (no issues with apt on a ADSL link).
  Recently, I though about TCP offloading and experiment a bit. And, indeed,
I observe no more issues if I type:
$ sudo ethtool -K en-wired rx off tx off
before my "sudo apt upgrade -yd"
And I got issues again if I set offload on again:
$ sudo ethtool -K en-wired rx on tx on
$ sudo apt-get clean
$ sudo apt upgrade -yd

  So, it seems there is an issue with checksum offloading with this driver
and hardware.
  Note that I got this bug with previous kernels (such as 4.14*) but I did not
note the exact versions and I did not think to disable offloading at this time.

  Regards,
Vincent 


-- Package-specific info:
** Version:
Linux version 4.15.0-rc8-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.15~rc8-1~exp1 (2018-01-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc8-amd64 root=/dev/mapper/eyak-root ro 
apparmor=0 security= swapaccount=1 cgroup_enable=memory atkbd.softraw=0 
vsyscall=emulate quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[71838.653455] usb 3-1: Product: USB2807 Hub
[71838.653456] usb 3-1: Manufacturer: Microchip
[71838.672701] hub 3-1:1.0: USB hub found
[71838.672826] hub 3-1:1.0: 7 ports detected
[71838.746169] thunderbolt :07:00.0: 301: uid: 0x8086537e20a87610
[71838.746272] thunderbolt :07:00.0:  Port 0: 8086:1578 (Revision: 4, TB 
Version: 1, Type: Port (0x1))
[71838.746273] thunderbolt :07:00.0:   Max hop id (in/out): 7/7
[71838.746273] thunderbolt :07:00.0:   Max counters: 8
[71838.746274] thunderbolt :07:00.0:   NFC Credits: 0x80
[71838.746792] thunderbolt :07:00.0:  Port 1: 8086:1578 (Revision: 4, TB 
Version: 1, Type: Port (0x1))
[71838.746793] thunderbolt :07:00.0:   Max hop id (in/out): 15/15
[71838.746793] thunderbolt :07:00.0:   Max counters: 16
[71838.746794] thunderbolt :07:00.0:   NFC Credits: 0x780
[71838.747305] thunderbolt :07:00.0:  Port 2: 8086:1578 (Revision: 4, TB 
Version: 1, Type: Port (0x1))
[71838.747305] thunderbolt :07:00.0:   Max hop id (in/out): 15/15
[71838.747306] thunderbolt :07:00.0:   Max counters: 16
[71838.747306] thunderbolt :07:00.0:   NFC Credits: 0x0
[71838.747838] thunderbolt :07:00.0:  Port 3: 8086:1578 (Revision: 4, TB 
Version: 1, Type: Port (0x1))
[71838.747838] thunderbolt :07:00.0:   Max hop id (in/out): 15/15
[71838.747839] thunderbolt :07:00.0:   Max counters: 16
[71838.747839] thunderbolt :07:00.0:   NFC Credits: 0x3c0
[71838.748344] thunderbolt :07:00.0:  Port 4: 8086:1578 (Revision: 4, TB 
Version: 1, Type: Port (0x1))
[71838.748345] thunderbolt :07:00.0:   Max hop id (in/out): 15/15
[71838.748345] thunderbolt :07:00.0:   Max counters: 16
[71838.748346] thunderbolt :07:00.0:   NFC Credits: 0x3c0
[71838.748346] thunderbolt :07:00.0: 301:5: disabled by eeprom
[71838.748448] thunderbolt :07:00.0:  Port 6: 8086:1578 (Revision: 4, TB 
Version: 1, Type: PCIe (0x100102))
[71838.748448] thunderbolt :07:00.0:   Max hop id (in/out): 8/8
[71838.748449] thunderbolt :07:00.0:   Max counters: 2
[71838.748449] thunderbolt :07:00.0:   NFC Credits: 0x80
[71838.748587] thunderbolt :07:00.0:  Port 7: 8086:1578 (Revision: 4, TB 
Version: 1, Type: PCIe (0x100101))
[71838.748588] thunderbolt :07:00.0:   Max hop id (in/out): 8/8
[71838.748588] thunderbolt :07:00.0:   Max counters: 2
[71838.748589] thunderbolt :07:00.0:   NFC Credits: 0x80
[71838.748749] thunderbolt :07:00.0:  Port 8: 8086:1578 (Revision: 4, TB

Bug#889817: linux: kernel does not always provide a heap [alpha arm64 mips64el ppc64el ppc64 s390x sparc64]

2018-02-07 Thread Aurelien Jarno 
Source: linux
Version: 4.14.13-1
Severity: normal
Tags: upstream

When ASLR is enabled (which is the default), the Linux kernel on at
least alpha, arm64, mips64el, ppc64el, ppc64, s390x and sparc64 might
not provide a heap to the program. This is the case for example when
the program is run through the program interpreter ld.so. This happens
with different probability depending on the architecture. This causes
issues with GLIBC tunables support, which needs to be able to reserve
a few hundred bytes of memory through brk. This is reproducible with
at least kernel 4.9 and 4.15, and it's likely that the issue has always
been there.

The following script, based on one from James Cowgill, shows the issue:

#!/bin/bash
export LC_ALL=C

interp=$(readelf --headers /bin/cat | grep 'Requesting program interpreter' | 
sed -e 's/.*: //' -e 's/]//')

for i in {1..1}
do
OUT=$($interp /bin/cat /proc/self/maps)
if [[ $OUT != *heap* ]]
then
echo -n F
echo "$OUT"
else
echo -n .
fi
done

A workaround is to set /proc/sys/kernel/randomize_va_space to 1.

Bug#889809: [linux] Fails to compile external modules

2018-02-07 Thread Charlemagne Lasse 
Source: linux
Version: 4.14.13-1~bpo9+1
Severity: normal
X-Debbugs-CC: backpo...@vger.kernel.org

It seems like the current kernel in stretch backporst and in buster
has problems when compiling external modules against it. This worked
fine in the past. Also works fine when compiling against a manually
compiled 4.14 Linux kernel. So it seems to be a Debian specific
regression. Here are some examples

$ curl https://mirror2.openwrt.org/sources/backports-2017-11-01.tar.xz|tar xvJ
$ make -C backports-2017-11-01 defconfig-ath9k
$ make -C backports-2017-11-01
make: Entering directory '/usr/src/backports-2017-11-01'
make[5]: 'conf' is up to date.
#
# configuration written to .config
#
Building backport-include/backport/autoconf.h ... done.
In file included from :0:0:
/usr/src/backports-2017-11-01/backport-include/backport/backport.h:3:32:
fatal error: generated/autoconf.h: No such file or directory
 #include 
^
compilation terminated.
In file included from :0:0:
/usr/src/backports-2017-11-01/backport-include/backport/backport.h:3:32:
fatal error: generated/autoconf.h: No such file or directory
 #include 


$ curl 
https://downloads.open-mesh.org/batman/stable/sources/batman-adv/batman-adv-2017.4.tar.gz|tar
xvz
$ make -C batman-adv-2017.4
make: Entering directory '/usr/src/batman-adv-2017.4'
/usr/src/batman-adv-2017.4/gen-compat-autoconf.sh
/usr/src/batman-adv-2017.4/compat-autoconf.h
mkdir -p /usr/src/batman-adv-2017.4/build/net/batman-adv/
compat-patches/replacements.sh
touch /usr/src/batman-adv-2017.4/build/net/batman-adv/.compat-prepared
make -C /lib/modules/4.14.0-0.bpo.3-amd64/build
M=/usr/src/batman-adv-2017.4/build
PWD=/usr/src/batman-adv-2017.4/build REVISION= CONFIG_BATMAN_ADV=m
CONFIG_BATMAN_ADV_DEBUG=n CONFIG_BATMAN_ADV_DEBUGFS=y
CONFIG_BATMAN_ADV_BLA=y CONFIG_BATMAN_ADV_DAT=y CONFIG_BATMAN_ADV_NC=n
CONFIG_BATMAN_ADV_MCAST=y CONFIG_BATMAN_ADV_BATMAN_V=n
INSTALL_MOD_DIR=updates/  modules
make[1]: Entering directory '/usr/src/linux-headers-4.14.0-0.bpo.3-amd64'
In file included from :31:0:
/usr/src/batman-adv-2017.4/build/../compat.h:24:52: fatal error:
linux/version.h: No such file or directory
 #include  /* LINUX_VERSION_CODE */
^
compilation terminated.
In file included from :31:0:
/usr/src/batman-adv-2017.4/build/../compat.h:24:52: fatal error:
linux/version.h: No such file or directory
 #include  /* LINUX_VERSION_CODE */
^
compilation terminated.

--- System information. ---
Architecture:
Kernel:   Linux 4.14.0-0.bpo.3-amd64

Debian Release: 9.3
  500 stable  security.debian.org
  500 stable  httpredir.debian.org
  100 stretch-backports httpredir.debian.org