[OS-BUILD PATCH 0/46] PCI: tegra: Revert raw_violation_fixup for tegra124

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: jmflinuxtx on gitlab.com

As reported in https://bugzilla.kernel.org/206217 , raw_violation_fixup
is causing more harm than good in some common use-cases.

This patch as RFC is a partial revert of the 191cd6fb5 commit:
 "PCI: tegra: Add SW fixup for RAW violations"
that was first introduced in 5.3 kernel.
This fix the following regression since then.


When using both the network NIC and I/O on MMC this can lead to the
following message on jetson-tk1:

 NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out

and

 pcieport 0000:00:02.0: AER: Uncorrected (Non-Fatal) error received:
0000:01:00.0
 r8169 0000:01:00.0: AER: PCIe Bus Error: severity=Uncorrected (Non-
Fatal), type=Transaction Layer, (Requester ID)
 r8169 0000:01:00.0: AER:   device [10ec:8168] error
status/mask=00004000/00400000
 r8169 0000:01:00.0: AER:    [14] CmpltTO                (First)
 r8169 0000:01:00.0: AER: can't recover (no error_detected callback)
 pcieport 0000:00:02.0: AER: device recovery failed


After that, the ethernet NIC isn't functional anymore even after
reloading
the module.
After a reboot, this is reproducible by copying a large file over the
ethernet NIC to the MMC.
For some reasons this cannot be reproduced when the same file is copied
to a tmpfs.


This patch is RFC because it requires more understanding from Nvidia.
 - Is the fixup (available in l4t downstrem) still needed for upstream ?
 - Is there a need to update the fixup values for upstream ?
 - If the fixup is reverted, does the hw bug can still be seen with
   upstream ?

Others can also provides more understanding:
 - Conditions to reproduce the bug (or not)...


Signed-off-by: Nicolas Chauvet <kwizart@xxxxxxxxx>


Upstream Status: https://patchwork.ozlabs.org/project/linux-
tegra/patch/20200420164304.28810-1-kwizart@xxxxxxxxx/

Note:

The patch series is too large to sent by email.

To review the series locally, set up your repository to fetch from the GitLab
remote:

  $ git remote add gitlab https://gitlab.com/cki-project/kernel-ark.git
  $ git config remote.gitlab.fetch '+refs/merge-requests/*/head:refs/remotes/gitlab/merge-requests/*'
  $ git fetch gitlab

Finally, check out the merge request:

  $ git checkout gitlab/merge-requests/427

It is also possible to review the merge request on GitLab at:
    https://gitlab.com/cki-project/kernel-ark/-/merge_requests/427
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux