Bug 1376455
| Summary: | AMD IOMMU blocks function of Via VL805 USB 3.0 chipset | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | bob <redzilla.coralnut> |
| Component: | kernel | Assignee: | Neil Horman <nhorman> |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | gansalmon, ichavero, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, nhorman, redhat, redzilla.coralnut |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-27 19:10:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
bob
2016-09-15 13:11:42 UTC
Created attachment 1201239 [details]
amd iommu enabled: dmesg.log
This is the output of dmesg when AMD IOMMU is enabled.
Created attachment 1201241 [details]
amd iommu enabled: lspci -vvnn
output of lspci -vvnn when AMD IOMMU is enabled.
Kernel is still blocking utilization of USB 3.0 drivers for the VIA VL805 chipset as of Linux version 4.8.15-200.fc24.x86_64. I've been reporting these bugs since F21, but nobody seems to respond to them. Does anyone in the Linux world even care about AMD IOMMU? The logs seem to indicate that, when the iommu is enabled the reset of the controller experiences a timeout when resetting the hardware. That immediately makes me think that this is a hardware issue that you are going to have to contact the motherboard manufacturer about. That said, there is one thing that I noticed that may help. The xhci reset routine honors a quirk for intel xhci controllers. Specifically it adds 1 millisecond of delay when resetting the controller for that vendor. Part of me wonders if AMD in their design has created a matching behavior when the iommu is enabled. This won't be the proper fix for the problem, but as a test, we can flag the amd controller with the same quirk to see if that circumvents the timeout error. I'll attach a patch in a moment Created attachment 1235893 [details]
test patch to see if intel timeout quirk applies to amd xhci controller
here you go. Note again, this is not a complete final fix, but it should tell us what needs to be fixed to make this controller works, assuming this isn't simply a hardware problem. Please build a kernel with this patch and report results.
Thank you for your time. Unfortunately, I have no clue what to do with the attachment you posted. To clarify -- I don't know how to implement your patch. If you could direct me to a page that offers a guide on how to do a kernel build while incorporating your patch, I would be happy to do the test. Additional information gained by additional testing: 1. AMD IOMMU and VL805 USB 3.0 chipset WORK FINE UNDER WINDOWS 7. It's only under Linux that the hardware fails to work. 2. VL805 USB 3.0 chipset works fine under Linux *IF AND ONLY IF* AMD IOMMU is DISABLED. 3. VL805 USB 3.0 chipset DOES NOT WORK work under linux IF AMD IOMMU is ENABLED. 4. Problem (3) has been confirmed by other users on other (Debian-based) linux distributions. These reports do not involve the same _motherboard_ that I am using, but they do involve the same _CHIPSETS_. 5. These observations suggest that it's a kernel problem, not a hardware problem. I don't understand how it can be otherwise, but I'm open to hearing an explanation. WRT implementing the patch referenced in Comment 5: Although I have extensive experience in linux, and have built my share of kernels under Gentoo, after spending 4 hours on this problem I was not able to build a kernel and implement the proposed patch for testing. I do not have the knowledge to do this under Fedora, for several reasons. Among them: There is no up to date set of instructions on how to build a kernel in Fedora. The best available page I've found is this one: https://fedoraproject.org/wiki/Building_a_custom_kernel Unfortunately, this page is quite old, it's information is out of date, it is unmaintained, and following those instructions results in failure. After spending hours attempting to follow the instructions, debugging them, and trying to figure out what part of the instructions needed to be updated, I still got nowhere. * Some of the packages that are referenced as being required are no longer in the source tree. * the instructions make are vague references to paths and file locations without actually listing them, which sends the user on a hunting expedition trying to find the right paths. * Once the proper paths are found, the files that are supposed to be there are not there. Presumably some configuration files and file names have changed since instructions were written. These factors result in the instructions failing to allow a user to be successful in building a kernel. Unfortunately, the end result is that the request to apply a patch cannot be implemented by someone who does not have the level of expertise of a kernel developer. Honestly speaking, I think my knowledge in Linux is far supreior to most people, but I'm just not able to complete the task suggested in Comment 5. Any help would be appreciated. that was alot of words to say "Help Please". :) Heres a brew build for you: https://koji.fedoraproject.org/koji/taskinfo?taskID=17139554 FWIW, these instructions: https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_a_Kernel_from_the_Fedora_source_tree Work just fine for me, presuming you are familiar with the use of the rpmbuild tool and the --rebuild option Anywho, the above brew build will have the rpms you need shortly Thanks for your help. I'm not sure what the "brew" build page is supposed to do for me. I am expecting to find a downloadable RPM but when I go to that page there is nothing there that is downloadable for me; none of the hyperlinks lead me to a downloadable file. I am using Firefox 50.1.0. If you could tell me exactly what I should be looking for that might help. Regarding the instructions provided in Comment 10 -- that's the same link that I cited as not working previously. I had thought that those instructions were out of date, but if they work for you then there is obviously a difference of state between your development environment and my fresh fedora install. Some part of those instructions is insufficient to get someone working with a fresh install to the state where they can perform the development tasks cited in the instructions. You click the buildArch link for the architecture you are interested in and then the link at the bottom of the page for the specific kernel variant that you want. Here is the direct link to the build kernel for x86_64: https://kojipkgs.fedoraproject.org//work/tasks/9556/17139556/kernel-4.8.11-200.fc24.x86_64.rpm I'm not sure how to make it any simpler than that. As for the instructions, I don't know what to tell you, I installed fedora 25 on this system on Jan 2 and its working fine for me. (In reply to Neil Horman from comment #12) > You click the buildArch link for the architecture you are interested in and > then the link at the bottom of the page for the specific kernel variant that > you want...I'm not sure how to make it any simpler than that. As a developer, I honestly don't think you have a good grasp of how foreign all of this "straightforward" advice appears to an end-user. It would be like a surgeon telling you to go perform an appendectomy on yourself with the expectation that you'll be able to get it right on your own. It's just not realistic to expect end users to have your level of familiarity and proficiency with Fedora's developer interfaces. Most of us don't know what a Koji is, though it's undoubtedly familiar to you. I used your direct link to the kernel RPM. Thanks. It would not install, citing failed dependencies. I downloaded the dependencies. Even with those dependencies in the same directory, the install fails. Obviously I'm missing something that you would consider trivial. # ls -lh *.rpm -rw-rw-r--. 1 bob bob 75K Jan 12 14:41 kernel-4.8.11-200.fc24.x86_64.rpm -rw-rw-r--. 1 bob bob 20M Jan 12 14:52 kernel-core-4.8.11-200.fc24.x86_64.rpm -rw-rw-r--. 1 bob bob 23M Jan 12 14:52 kernel-modules-4.8.11-200.fc24.x86_64.rpm # rpm --install kernel-4.8.11-200.fc24.x86_64.rpm error: Failed dependencies: kernel-core-uname-r = 4.8.11-200.fc24.x86_64 is needed by kernel-4.8.11-200.fc24.x86_64 kernel-modules-uname-r = 4.8.11-200.fc24.x86_64 is needed by kernel-4.8.11-200.fc24.x86_64 (In reply to bob from comment #13) > (In reply to Neil Horman from comment #12) > > You click the buildArch link for the architecture you are interested in and > > then the link at the bottom of the page for the specific kernel variant that > > you want...I'm not sure how to make it any simpler than that. > > # ls -lh *.rpm > -rw-rw-r--. 1 bob bob 75K Jan 12 14:41 kernel-4.8.11-200.fc24.x86_64.rpm > -rw-rw-r--. 1 bob bob 20M Jan 12 14:52 kernel-core-4.8.11-200.fc24.x86_64.rpm > -rw-rw-r--. 1 bob bob 23M Jan 12 14:52 > kernel-modules-4.8.11-200.fc24.x86_64.rpm > > # rpm --install kernel-4.8.11-200.fc24.x86_64.rpm > error: Failed dependencies: > kernel-core-uname-r = 4.8.11-200.fc24.x86_64 is needed by > kernel-4.8.11-200.fc24.x86_64 > kernel-modules-uname-r = 4.8.11-200.fc24.x86_64 is needed by > kernel-4.8.11-200.fc24.x86_64 Pass all rpms at the same command: rpm --install kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm Thanks. I apologize for needing so much help.
There seems to be an issue with the syntax I'm using to install the packages -- I'm getting messages that packages with those names are already installed, which I presume are the older, unpatched versions. Is there a way for me to force the install of these new "brew" packages over those that are already installed? I tried using --reinstall to force the install but it failed to work:
# rpm --install kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm
package kernel-core-4.8.14-200.fc24.x86_64 (which is newer than kernel-core-4.8.11-200.fc24.x86_64) is already installed
package kernel-core-4.8.15-200.fc24.x86_64 (which is newer than kernel-core-4.8.11-200.fc24.x86_64) is already installed
package kernel-modules-4.8.14-200.fc24.x86_64 (which is newer than kernel-modules-4.8.11-200.fc24.x86_64) is already installed
package kernel-modules-4.8.15-200.fc24.x86_64 (which is newer than kernel-modules-4.8.11-200.fc24.x86_64) is already installed
package kernel-4.8.14-200.fc24.x86_64 (which is newer than kernel-4.8.11-200.fc24.x86_64) is already installed
package kernel-4.8.15-200.fc24.x86_64 (which is newer than kernel-4.8.11-200.fc24.x86_64) is already installed
Similarly, the --reinstall option didn't fare any better:
# rpm --reinstall kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm package kernel-core-4.8.14-200.fc24.x86_64 (which is newer than kernel-core-4.8.11-200.fc24.x86_64) is already installed
package kernel-core-4.8.15-200.fc24.x86_64 (which is newer than kernel-core-4.8.11-200.fc24.x86_64) is already installed
package kernel-modules-4.8.14-200.fc24.x86_64 (which is newer than kernel-modules-4.8.11-200.fc24.x86_64) is already installed
package kernel-modules-4.8.15-200.fc24.x86_64 (which is newer than kernel-modules-4.8.11-200.fc24.x86_64) is already installed
package kernel-4.8.14-200.fc24.x86_64 (which is newer than kernel-4.8.11-200.fc24.x86_64) is already installed
package kernel-4.8.15-200.fc24.x86_64 (which is newer than kernel-4.8.11-200.fc24.x86_64) is already installed
Its not a package conflict problem you're having, its a version change issue you're having. rpm is telling you that you are trying to install a package that is older in version than the kernel you currently have installed already. Fedora released a new kernel in the time that we've been dealing with this. Its fine, just use the --force option to get around this. The --force option results in an error message that I don't have all of the necessary packages in place. Evidently the 3 packages that I was directed to install were necessary but not sufficient for the task:
# rpm --force --install kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm
Error! echo
Your kernel headers for kernel 4.8.11-200.fc24.x86_64 cannot be found at
/lib/modules/4.8.11-200.fc24.x86_64/build or /lib/modules/4.8.11-200.fc24.x86_64/source.
Downloading the kernel headers package and adding it to the command line yields a version error:
# rpm --force --install kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm kernel-headers-4.8.11-200.fc24.x86_64.rpm
error: Failed dependencies:
kernel-headers < 4.8.15-200.fc24 is obsoleted by (installed) kernel-headers-4.8.15-200.fc24.x86_64
Evidently the --force parameter isn't good enough to override the obsoleted kernel headers problem.
I could really use a complete set of instructions that will work.
then get the kernel headers package from the brew build page, in the same location that I described in comment 12. (In reply to Neil Horman from comment #18) > then get the kernel headers package from the brew build page, in the same > location that I described in comment 12. Please review the rpm --force command that was used in Comment 17. The appropriate kernel headers package from the brew build had already been downloaded and invoked on the command line. In Comment 18 it was suggested that I perform steps that I had already mentioned had failed in Comment 17. Perhaps you missed that. Unfortunately the instructions provided do not seem to work. Example: # ls -lha *.rpm -rw-rw-r--. 1 bob bob 75K Jan 12 14:41 kernel-4.8.11-200.fc24.x86_64.rpm -rw-rw-r--. 1 bob bob 20M Jan 12 14:52 kernel-core-4.8.11-200.fc24.x86_64.rpm -rw-rw-r--. 1 bob bob 1.1M Jan 13 12:21 kernel-headers-4.8.11-200.fc24.x86_64.rpm -rw-rw-r--. 1 bob bob 23M Jan 12 14:52 kernel-modules-4.8.11-200.fc24.x86_64.rpm # rpm --force --install kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm kernel-headers-4.8.11-200.fc24.x86_64.rpm error: Failed dependencies: kernel-headers < 4.8.15-200.fc24 is obsoleted by (installed) kernel-headers-4.8.15-200.fc24.x86_64 It seems that in Comment 18 you missed that I already had the package when you recommended that I get it. The problem is not that I don't have the package. The problem is that the instructions don't seem to work. What am I missing? include the --nodeps option Still got an error message -- not sure what to do about it. rpm --nodeps --force --install kernel-4.8.11-200.fc24.x86_64.rpm kernel-core-4.8.11-200.fc24.x86_64.rpm kernel-modules-4.8.11-200.fc24.x86_64.rpm kernel-headers-4.8.11-200.fc24.x86_64.rpm Error! echo Your kernel headers for kernel 4.8.11-200.fc24.x86_64 cannot be found at /lib/modules/4.8.11-200.fc24.x86_64/build or /lib/modules/4.8.11-200.fc24.x86_64/source. As noted in Comment 19 the kernel headers RPM was on disk and the package was explicitly included in the command line executed. For reasons that are not clear, I still got an error message. Oh, you know what, you probably have a package on your system that relies on having the kernel-devel package installed as well, which is never treated as a hard requires but can be a dependency via a trigger script (DKMS can do this as an example). If you install the kernel-devel pacakge from the brew build as well that should take care of it. I am an end user. I have no idea what you're talking about. I need an explicit set of directions to follow. I'm not asking you to do anything developer related, I'm asking you to fetch another rpm from the brew build page I gave you previously. To be explicit
1) Go here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17139554
2) Click the buildarch link for your systems architecture (should be x86_64)
3) download the kernel-devel pacakge....which has been scrubbed, because we've taken weeks to get this kernel installed.
I'm going to have to restart the build for you, which means I need to go dig out the patch from my old workstation. I'll post a new brew build for you on monday, along with instructions for what to do with it.
Oh, I see -- the instructions were incomplete and did not list a necessary package, and in the time it's taken to figure that out the packages have been purged. Not being a kernel developer, I don't know what packages are required to complete your test, so I have to rely on the integrity of the instructions provided. To make sure we're on the same page, I'm updating to the latest available stable kernel: x86_64 4.8.16-200.fc24 https://koji.fedoraproject.org/koji/taskinfo?taskID=17392954 Heres your new build. I'll remind you that: 1) I grabbed this bug because no one else was helping you with it. 2) No one actually has to help you with it. 3) While you don't have to be a developer, using the bugzilla interface to report and resolve bugs necessitates a certain level of expertise, and understanding packaging dependencies should fall under that expertise. I'm trying to help you here, but I have limited time to work on this bug, and while I understand its frustrating, you need to be able to sort through some of the problems you encounter while trying to diagnose this problem, or it will never get fixed, as I have neither the time nor desire to write a completely exhaustive set of directions to handle every contingency that you might come across. Thanks for the new build. I have downloaded all packages provided for my architecture:
ls -lh *.rpm
-rw-rw-r--. 1 bob bob 77K Jan 23 19:43 kernel-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 20M Jan 23 19:44 kernel-core-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 4.9M Jan 23 19:44 kernel-cross-headers-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 533M Jan 23 20:47 kernel-debug-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 12M Jan 23 19:48 kernel-debug-devel-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 521M Jan 23 20:44 kernel-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 58M Jan 23 19:58 kernel-debuginfo-common-x86_64-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 23M Jan 23 19:51 kernel-debug-modules-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 2.3M Jan 23 19:46 kernel-debug-modules-extra-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 12M Jan 23 19:52 kernel-devel-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 1.1M Jan 23 19:49 kernel-headers-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 23M Jan 23 19:48 kernel-modules-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 2.2M Jan 23 19:44 kernel-modules-extra-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 166K Jan 23 19:44 kernel-tools-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 153K Jan 23 19:44 kernel-tools-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 86K Jan 23 19:49 kernel-tools-libs-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 80K Jan 23 19:49 kernel-tools-libs-devel-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 1.5M Jan 23 19:50 perf-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 3.3M Jan 23 19:51 perf-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm
-rw-rw-r--. 1 bob bob 176K Jan 23 19:51 python-perf-4.9.5-100.test1.fc24.x86_64.rpm
Unfortunately, when I attempt to install all of the packages that you built, using the --install and --force parameters, the install fails with an error message regarding failed dependencies:
rpm --install --force kernel-4.9.5-100.test1.fc24.x86_64.rpm kernel-core-4.9.5-100.test1.fc24.x86_64.rpm kernel-cross-headers-4.9.5-100.test1.fc24.x86_64.rpm kernel-debug-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm kernel-debug-devel-4.9.5-100.test1.fc24.x86_64.rpm kernel-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm kernel-debuginfo-common-x86_64-4.9.5-100.test1.fc24.x86_64.rpm kernel-debug-modules-4.9.5-100.test1.fc24.x86_64.rpm kernel-debug-modules-extra-4.9.5-100.test1.fc24.x86_64.rpm kernel-devel-4.9.5-100.test1.fc24.x86_64.rpm kernel-headers-4.9.5-100.test1.fc24.x86_64.rpm kernel-modules-4.9.5-100.test1.fc24.x86_64.rpm kernel-modules-extra-4.9.5-100.test1.fc24.x86_64.rpm kernel-tools-4.9.5-100.test1.fc24.x86_64.rpm kernel-tools-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm kernel-tools-libs-4.9.5-100.test1.fc24.x86_64.rpm kernel-tools-libs-devel-4.9.5-100.test1.fc24.x86_64.rpm perf-4.9.5-100.test1.fc24.x86_64.rpm perf-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm python-perf-4.9.5-100.test1.fc24.x86_64.rpm python-perf-debuginfo-4.9.5-100.test1.fc24.x86_64.rpm
error: Failed dependencies:
kernel-uname-r = 4.9.5-100.test1.fc24.x86_64+debug is needed by kernel-debug-modules-4.9.5-100.test1.fc24.x86_64
kernel-uname-r = 4.9.5-100.test1.fc24.x86_64+debug is needed by kernel-debug-modules-extra-4.9.5-100.test1.fc24.x86_64
kernel-headers < 4.9.5-100.test1.fc24 is obsoleted by kernel-headers-4.9.5-100.test1.fc24.x86_64
Unfortunately, I'm at a loss as of what to do. This occurrs because I'm not a person who works with kernel builds every day at his job, and I just don't have your level of familiarity or expertise. Please help.
you've gone too far the other way now, start with the install command from comment 21 (replacing the package name-version-releases you used there with the ones from the new build) and only add int the kernel-devel package. Adding the -debug packages will introduce another set of dependencies that need resolving, and you have no need for those. Created attachment 1244785 [details]
dmesg output with test1 kernel build
ok, now were getting somewhere. Unfortunately it looks like opting your system into that same quirk didn't help, we get the same reset timeout as before (after several iommu errors). Just to confirm, I presume the usb port still doesn't work with the new kernel, correct? Correct. USB 3.0 port remains dead. Hmm, just stumbled on some information that might help. apparently AMD iommus have some problems in that they don't reset properly from power on which leads to problems, this among them. Can you please try the following: 1) Disable the iommu in BIOS 2) edit the kernel command line to include this: iommu=soft and boot the system. Please use the latest released kernel that you have installed, not my test kernel. This should enable the iommu during kernel boot, but not out of bios, and should enable the usb3 ports to be reset properly. Of course we know from Comment 1 that if IOMMU is disabled in BIOS then the USB 3.0 ports on the VIA chipset work fine. Following your recommendations to disable IOMMU in BIOS results in USB functionality as expected, irrespective of whether "iommu=soft" is used on the command line or not. This tells me that disabling IOMMU in BIOS works like it has always worked, just as you expected. From my seat, I can tell that turning off IOMMU in BIOS works as expected, and I have no way to tell if placing "iommu=soft" on the kernel command line actually accomplishes anything. The output of dmesg tells me nothing: $ dmesg | grep iommu [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.16-200.fc24.x86_64 root=/dev/mapper/fedora_colossus-root ro rd.lvm.lv=fedora_colossus/root rd.lvm.lv=fedora_colossus/swap rhgb rd.driver.blacklist=nouveau LANG=en_US.UTF-8 iommu=soft [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.8.16-200.fc24.x86_64 root=/dev/mapper/fedora_colossus-root ro rd.lvm.lv=fedora_colossus/root rd.lvm.lv=fedora_colossus/swap rhgb rd.driver.blacklist=nouveau LANG=en_US.UTF-8 iommu=soft I assume that you can recommend a test that will determine whether the kernel parameter actually accomplishes the desired effect, right? you'll see references to the SWIOTLB system initializing. If you post your dmesg log I can confirm for you. Created attachment 1245159 [details]
dmesg output with iommu=soft kernel parameter
Yup, SWIOTLB initalized. You should be good to go. Im going to officially close this as CANTFIX, since we didn't actually fix the bug, at least not without AMD intervening with an explanation of why the usb3.0 hardware wont reset properly with an iommu enabled in bios. Until then, people can find this bz as reference. (In reply to Neil Horman from comment #36) > Yup, SWIOTLB initalized. Can you tell me what you're looking at in the dmesg file to verify this? thx. |