Kernels 5.0.0 and later networking does not work on i7-6850k on Asus X99A motherboard

[Robert Dinse]

On Asus x99A platform with an i7-6850k and 128GB RAM, 5.0.0 and later kernels neworking does not work. This is true whether I use the internal network card which is an Intel E1000 based chipset or a add on card that uses a Broadcomm chip. The same kernels work fine on X299 motherboards and i7-6700k CPUs. I have to run 4.18.0-x on this machine for networking to work. I have determined the problem is upstream as I built a 5.1.0 mainstream kernel and it behaves identically. I can't report from a machine that doesn't work since networking is what is broken that is why this machine is running 4.18.0 instead of 5.0.0 kernel under Ubuntu 19.04.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: linux-image-5.0.0-14-lowlatency (not installed)
ProcVersionSignature: Ubuntu 4.18.0-18.19-lowlatency 4.18.20
Uname: Linux 4.18.0-18-lowlatency x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/controlC1', '/dev/snd/hwC1D3', '/dev/snd/hwC1D2', '/dev/snd/hwC1D1', '/dev/snd/hwC1D0', '/dev/snd/pcmC1D9p', '/dev/snd/pcmC1D8p', '/dev/snd/pcmC1D7p', '/dev/snd/pcmC1D3p', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D2c', '/dev/snd/pcmC0D1p', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: MATE
Date: Sat May 11 03:20:29 2019
HibernationDevice: RESUME=UUID=963cb206-8962-4fc0-82a1-fc4f02a9b5c5
InstallationDate: Installed on 2017-05-05 (735 days ago)
InstallationMedia: Ubuntu-MATE 17.04 "Zesty Zapus" - Release amd64 (20170412)
MachineType: ASUS All Series
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-18-lowlatency root=UUID=28825f5b-a6fd-4e09-982c-0513ae4d2842 ro
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.18.0-18-lowlatency N/A
 linux-backports-modules-4.18.0-18-lowlatency N/A
 linux-firmware 1.178.1
RfKill:

SourcePackage: linux
UpgradeStatus: Upgraded to disco on 2019-05-05 (6 days ago)
dmi.bios.date: 08/11/2017
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1801
dmi.board.asset.tag: Default string
dmi.board.name: X99-E
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1801:bd08/11/2017:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnX99-E:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: ASUS MB
dmi.product.name: All Series
dmi.product.sku: All
dmi.product.version: System Version
dmi.sys.vendor: ASUS

[Robert Dinse (nanook)]

The i7-6700k has the same network interface cards as the i7-6850k so not an issue with the cards.

[Robert Dinse (nanook)]

Also, this machine is critical so I can not reboot frequently to test kernels and I have no other machines with this specific hardware to test with.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Robert Dinse (nanook)]

Was kind of hoping something severe enough to render the Operating System unusable on some platforms would get assigned someone and get a reasonable priority rather that sitting in limbo.

[Connor Kuehl (connork)]

Hi Robert,

Since the uptime of that machine is important, this might be kind of tricky, but we can still collect logs on the troublesome kernel with an extra step. Once you've booted into the kernel where networking doesn't work, the report can be generated and saved locally. Then you can boot back into the 4.18 kernel and submit the report to this bug [1].

My hope is that the logs might contain some clues which will help us zero in on the regression without too much kernel testing churn. If that's not the case, bisection to find the commit that introduced this regression looks like it could take around 15 steps to bisect and drill down on the regression.

[1] See step #2 here: https://help.ubuntu.com/community/ReportingBugs#Filing_bugs_when_offline_or_using_a_headless_setup

[Robert Dinse (nanook)]

      I can maybe do this but a 15 step bisection is not something I can do.
This machine needs to be in service 24x7 and it's 21 miles away, I have to
go there to reboot because when it comes up with no network then I'm stuck.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
  Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
    Knowledgeable human assistance, not telephone trees or script readers.
  See our web site: http://www.eskimo.com/ [phone] or [phone].

On Tue, 4 Jun 2019, Connor Kuehl wrote:

> Date: Tue, 04 Jun 2019 23:10:33 -0000
> From: Connor Kuehl <email address hidden>
> To: <email address hidden>
> Subject: [Bug 1828666] Re: Kernels 5.0.0 and later networking does not work on
> i7-6850k on Asus X99A motherboard
>
> Hi Robert,
>
> Since the uptime of that machine is important, this might be kind of
> tricky, but we can still collect logs on the troublesome kernel with an
> extra step. Once you've booted into the kernel where networking doesn't
> work, the report can be generated and saved locally. Then you can boot
> back into the 4.18 kernel and submit the report to this bug [1].
>
> My hope is that the logs might contain some clues which will help us
> zero in on the regression without too much kernel testing churn. If
> that's not the case, bisection to find the commit that introduced this
> regression looks like it could take around 15 steps to bisect and drill
> down on the regression.
>
> [1] See step #2 here:
> https://help.ubuntu.com/community/ReportingBugs#Filing_bugs_when_offline_or_using_a_headless_setup
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1828666
>
> Title:
> Kernels 5.0.0 and later networking does not work on i7-6850k on Asus
> X99A motherboard
>
> Status in linux package in Ubuntu:
> Confirmed
>
> Bug description:
> On Asus x99A platform with an i7-6850k and 128GB RAM, 5.0.0 and later
> kernels neworking does not work. This is true whether I use the
> internal network card which is an Intel E1000 based chipset or a add
> on card that uses a Broadcomm chip. The same kernels work fine on
> X299 motherboards and i7-6700k CPUs. I have to run 4.18.0-x on this
> machine for networking to work. I have determined the problem is
> upstream as I built a 5.1.0 mainstream kernel and it behaves
> identically. I can't report from a machine that doesn't work since
> networking is what is broken that is why this machine is running
> 4.18.0 instead of 5.0.0 kernel under Ubuntu 19.04.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 19.04
> Package: linux-image-5.0.0-14-lowlatency (not installed)
> ProcVersionSignature: Ubuntu 4.18.0-18.19-lowlatency 4.18.20
> Uname: Linux 4.18.0-18-lowlatency x86_64
> ApportVersion: 2.20.10-0ubuntu27
> Architecture: amd64
> AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/controlC1', '/dev/snd/hwC1D3', '/dev/snd/hwC1D2', '/dev/snd/hwC1D1', '/dev/snd/hwC1D0', '/dev/snd/pcmC1D9p', '/dev/snd/pcmC1D8p', '/dev/snd/pcmC1D7p', '/dev/snd/pcmC1D3p', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D...

[Robert Dinse (nanook)]

     This is old, but I found the issue was related to avahi autoip and
disabled it, problem solved.

On 7/31/21 10:06 AM, Norbert wrote:
> ** Tags removed: disco
>