From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: Kernel Panic on high bandwidth transfer over wifi Date: Wed, 29 Aug 2018 08:29:23 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Nathaniel Munk , "netdev@vger.kernel.org" Return-path: Received: from mail-ed1-f66.google.com ([209.85.208.66]:43672 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727204AbeH2T0y (ORCPT ); Wed, 29 Aug 2018 15:26:54 -0400 Received: by mail-ed1-f66.google.com with SMTP id z27-v6so4230287edb.10 for ; Wed, 29 Aug 2018 08:29:26 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 08/29/2018 04:42 AM, Nathaniel Munk wrote: > Hi all, > I'm running Arch Linux on kernel 4.18.5 (same issue on both arch-provided kernel and mainline built-from-source). There is an issue whereby the kernel crashes when transferring at high bandwidths (approx 6mB/s) over a specific wifi connection. I can only reproduce the issue when using the Personal Hotspot on my iPhone 6S+, but can reproduce it very consistently on that connection. > > More often than not, any download reaching this speed will cause a panic, but if the download is immediately terminated at the first error the system can recover (and doing this I have obtained the attached logs). Unfortunately, I have not had access to a second machine to obtain the netconsole printout of the panic. > > As above, high-bandwidth transfers on other wifi networks do not cause the issue (nor on ethernet connections). > > As you can see from the attached log, the issue appears at tcp_recvmsg+0x579 and net_tx_action+0x1fe. At both these positions (net/ipv4/tcp.c:2000 and net/core/dev.c:4279 in mainline 4.18.5), a member of the skb struct is called. > > Thank you for your time (and I apologize if this is spurious or badly worded, this is my first bug report), and please don't hesitate to let me know if there's anything else I can do to help work this out. > > Regards, > ------------------- > Nathaniel Munk > nathaniel@munk.com.au > Unfortunately there is no attached log ;)