On Thu, Feb 7, 2019 at 7:43 PM Saeed Mahameed <sae...@dev.mellanox.co.il> wrote: > > On Thu, Feb 7, 2019 at 2:17 AM Ian Kumlien <ian.kuml...@gmail.com> wrote: > > > > On Thu, Feb 7, 2019 at 2:01 AM Saeed Mahameed <sae...@dev.mellanox.co.il> > > wrote: > > > On Wed, Feb 6, 2019 at 3:00 PM Ian Kumlien <ian.kuml...@gmail.com> wrote: > > > > It changes directly after the first hw checksum failure, I don't know > > > > why =/ > > > > > > weird, Maybe a real check-summing issue/corruption on the PCI ?! > > > > Actually, it seems to have been introduced in 4.20.6 - 4.20.5 works just > > fine > > > > Great, the difference is only 120 patches. > that is bisect-able, it will only take 5 iterations to find the > offending commit.
I just wish it wasn't a server that takes, what feels like 5 minutes to boot... All of these seas of sensors 2d and 3d... =P But, yep, that's the plan > > Just FYI, my dmesg testcase: > > time ssh <server> "dmesg && exit > > real 3m5.845s > > user 0m0.035s > > sys 0m0.041s > > > > > can you try turning off checksum offloads > > > ethtool -K ethX rx off > > > > same test: > > real 0m3.408s > > user 0m0.022s > > sys 0m0.032s > > > > So yes, something in 4.20.6 goes wrong on the receiving part :/
