diff for duplicates of <20190702180112.GB128603@google.com> diff --git a/a/1.txt b/N1/1.txt index 3b7e4cf..e8375d3 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -12,13 +12,13 @@ On Tue, Jul 02, 2019 at 04:25:59PM +0800, Kai Heng Feng wrote: > > > > at 5:09 PM, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote: > > > > > Hi Jeffrey, > > > > > -> > > > > We?ve encountered another issue, which causes multiple CRC -> > > > > errors and renders ethernet completely useless, here?s the +> > > > > We’ve encountered another issue, which causes multiple CRC +> > > > > errors and renders ethernet completely useless, here’s the > > > > > network stats: > > > > I also tried ignore_ltr for this issue, seems like it alleviates > > > > the symptom a bit for a while, then the network still becomes > > > > useless after some usage. -> > > > And yes, it?s also a Whiskey Lake platform. What?s the next step +> > > > And yes, it’s also a Whiskey Lake platform. What’s the next step > > > > to debug this problem? > > > > Kai-Heng > > > CRC errors not related to the LTR. Please, try to disable the ME on @@ -29,16 +29,16 @@ On Tue, Jul 02, 2019 at 04:25:59PM +0800, Kai Heng Feng wrote: > > According to ODM, the ME can be physically disabled by a jumper. > > But after disabling the ME the same issue can still be observed. > -> We?ve found that this issue doesn?t happen to SATA SSD, it only happens when +> We’ve found that this issue doesn’t happen to SATA SSD, it only happens when > NVMe SSD is in use. > > Here are the steps: > - Disable NVMe ASPM, issue persists -> - modprobe -r e1000e && modprobe e1000e, issue doesn?t happen -> - Enabling NVMe ASPM, issue doesn?t happen +> - modprobe -r e1000e && modprobe e1000e, issue doesn’t happen +> - Enabling NVMe ASPM, issue doesn’t happen > > As long as NVMe ASPM gets enabled after e1000e gets loaded, the issue -> doesn?t happen. +> doesn’t happen. IIUC the problem happens with the mainline and dev-queue e1000e driver, but not with the out-of-tree Intel driver. Since there is a @@ -79,7 +79,7 @@ maybe attach it to a kernel.org bugzilla? > > > > > > > > > > Same behavior can be observed on both mainline kernel and on > > > > > your dev-queue branch. -> > > > > OTOH, the same issue can?t be observed on out-of-tree e1000e. +> > > > > OTOH, the same issue can’t be observed on out-of-tree e1000e. > > > > > > > > > > Is there any plan to close the gap between upstream and > > > > > out-of-tree version? diff --git a/a/content_digest b/N1/content_digest index f05970c..f334d7a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,9 +4,16 @@ "ref\01804A45E-71B5-4C41-839C-AF0CFAD0D785@canonical.com\0" "ref\0E29A2CD2-1632-4575-9910-0808BD15F4D3@canonical.com\0" "From\0Bjorn Helgaas <helgaas@kernel.org>\0" - "Subject\0[Intel-wired-lan] RX CRC errors on I219-V (6) 8086:15be\0" + "Subject\0Re: RX CRC errors on I219-V (6) 8086:15be\0" "Date\0Tue, 2 Jul 2019 13:01:12 -0500\0" - "To\0intel-wired-lan@osuosl.org\0" + "To\0Kai Heng Feng <kai.heng.feng@canonical.com>\0" + "Cc\0Neftin" + Sasha <sasha.neftin@intel.com> + jeffrey.t.kirsher@intel.com + Anthony Wong <anthony.wong@canonical.com> + intel-wired-lan@lists.osuosl.org + linux-kernel <linux-kernel@vger.kernel.org> + " Linux PCI <linux-pci@vger.kernel.org>\0" "\00:1\0" "b\0" "On Tue, Jul 02, 2019 at 04:25:59PM +0800, Kai Heng Feng wrote:\n" @@ -23,13 +30,13 @@ "> > > > at 5:09 PM, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:\n" "> > > > > Hi Jeffrey,\n" "> > > > > \n" - "> > > > > We?ve encountered another issue, which causes multiple CRC\n" - "> > > > > errors and renders ethernet completely useless, here?s the\n" + "> > > > > We\342\200\231ve encountered another issue, which causes multiple CRC\n" + "> > > > > errors and renders ethernet completely useless, here\342\200\231s the\n" "> > > > > network stats:\n" "> > > > I also tried ignore_ltr for this issue, seems like it alleviates\n" "> > > > the symptom a bit for a while, then the network still becomes\n" "> > > > useless after some usage.\n" - "> > > > And yes, it?s also a Whiskey Lake platform. What?s the next step\n" + "> > > > And yes, it\342\200\231s also a Whiskey Lake platform. What\342\200\231s the next step\n" "> > > > to debug this problem?\n" "> > > > Kai-Heng\n" "> > > CRC errors not related to the LTR. Please, try to disable the ME on\n" @@ -40,16 +47,16 @@ "> > According to ODM, the ME can be physically disabled by a jumper.\n" "> > But after disabling the ME the same issue can still be observed.\n" "> \n" - "> We?ve found that this issue doesn?t happen to SATA SSD, it only happens when\n" + "> We\342\200\231ve found that this issue doesn\342\200\231t happen to SATA SSD, it only happens when\n" "> NVMe SSD is in use.\n" "> \n" "> Here are the steps:\n" "> - Disable NVMe ASPM, issue persists\n" - "> - modprobe -r e1000e && modprobe e1000e, issue doesn?t happen\n" - "> - Enabling NVMe ASPM, issue doesn?t happen\n" + "> - modprobe -r e1000e && modprobe e1000e, issue doesn\342\200\231t happen\n" + "> - Enabling NVMe ASPM, issue doesn\342\200\231t happen\n" "> \n" "> As long as NVMe ASPM gets enabled after e1000e gets loaded, the issue\n" - "> doesn?t happen.\n" + "> doesn\342\200\231t happen.\n" "\n" "IIUC the problem happens with the mainline and dev-queue e1000e\n" "driver, but not with the out-of-tree Intel driver. Since there is a\n" @@ -90,7 +97,7 @@ "> > > > > \n" "> > > > > Same behavior can be observed on both mainline kernel and on\n" "> > > > > your dev-queue branch.\n" - "> > > > > OTOH, the same issue can?t be observed on out-of-tree e1000e.\n" + "> > > > > OTOH, the same issue can\342\200\231t be observed on out-of-tree e1000e.\n" "> > > > > \n" "> > > > > Is there any plan to close the gap between upstream and\n" "> > > > > out-of-tree version?\n" @@ -99,4 +106,4 @@ "> \n" > -179fa6463ae968c92f7085afddd77dbc74f0061f06dd36df5a1d0c1618ee4010 +43ecd7371c18729e650d2fe6c566073826a1930458aab36c1d54b8c514bcf3c5
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.