Bug 1376455 - AMD IOMMU blocks function of Via VL805 USB 3.0 chipset
Summary: AMD IOMMU blocks function of Via VL805 USB 3.0 chipset
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-15 13:11 UTC by bob
Modified: 2017-01-28 06:33 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-27 19:10:28 UTC
Type: Bug


Attachments (Terms of Use)
amd iommu enabled: dmesg.log (129.18 KB, text/plain)
2016-09-15 13:22 UTC, bob
no flags Details
amd iommu enabled: lspci -vvnn (43.50 KB, text/plain)
2016-09-15 13:23 UTC, bob
no flags Details
test patch to see if intel timeout quirk applies to amd xhci controller (621 bytes, patch)
2016-12-29 15:30 UTC, Neil Horman
no flags Details | Diff
dmesg output with test1 kernel build (133.16 KB, text/plain)
2017-01-26 13:38 UTC, bob
no flags Details
dmesg output with iommu=soft kernel parameter (68.63 KB, text/plain)
2017-01-27 15:17 UTC, bob
no flags Details

Description bob 2016-09-15 13:11:42 UTC
Description of problem:

This is an AMD specific problem.

When IOMMU is enabled in BIOS and 4.7.2-201.fc24.x86_64 is booted on an AMD 970 chipset, the recognition of the VIA VL805 chipset for USB 3.0 is prevented.  The USB 3.0 ports on the motherboard provided by the VL 805 chipset are non-functional but the USB 2.0 ports provided by the AMD 970 southbridge work fine.

When IOMMU is disabled in BIOS the VL805 chipset is properly recognized and the USB 3.0 ports are functional.

Problem also reported on F22, Ubuntu and Mint, where users disable IOMMU to gain USB 3.0 functionality.

Version-Release number of selected component (if applicable):

4.7.2-201.fc24.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Toggle status of IOMMU between on/off in BIOS
2. Boot Kernel 4.7.2-201.fc24.x86_64
3. VIA VL803 chipset and USB 3.0 ports are dead if IOMMU enabled.


Additional info:

CPU = AMD FX-8350
Motherboard = Gigabyte GA-970A-UD3P
Chipset = AMD 970

This bug was never addressed when filed for F21.  1188654

Comment 1 bob 2016-09-15 13:22:01 UTC
Created attachment 1201239 [details]
amd iommu enabled: dmesg.log

This is the output of dmesg when AMD IOMMU is enabled.

Comment 2 bob 2016-09-15 13:23:04 UTC
Created attachment 1201241 [details]
amd iommu enabled: lspci -vvnn

output of lspci -vvnn when AMD IOMMU is enabled.

Comment 3 bob 2016-12-29 13:25:07 UTC
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?

Comment 4 Neil Horman 2016-12-29 15:28:36 UTC
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

Comment 5 Neil Horman 2016-12-29 15:30:11 UTC
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.

Comment 6 bob 2016-12-29 21:27:07 UTC
Thank you for your time.  Unfortunately, I have no clue what to do with the attachment you posted.

Comment 7 bob 2016-12-31 19:48:40 UTC
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.

Comment 8 bob 2017-01-01 18:11:02 UTC
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.

Comment 9 bob 2017-01-01 18:15:29 UTC
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.

Comment 10 Neil Horman 2017-01-01 21:58:19 UTC
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

Comment 11 bob 2017-01-12 19:01:27 UTC
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.

Comment 12 Neil Horman 2017-01-12 20:32:51 UTC
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.

Comment 13 bob 2017-01-12 21:00:18 UTC
(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

Comment 14 João Carlos Mendes Luís 2017-01-12 21:26:11 UTC
(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

Comment 15 bob 2017-01-13 01:23:28 UTC
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

Comment 16 Neil Horman 2017-01-13 11:55:15 UTC
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.

Comment 17 bob 2017-01-13 18:26:14 UTC
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.

Comment 18 Neil Horman 2017-01-16 12:47:46 UTC
then get the kernel headers package from the brew build page, in the same location that I described in comment 12.

Comment 19 bob 2017-01-17 01:14:40 UTC
(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?

Comment 20 Neil Horman 2017-01-17 14:37:54 UTC
include the --nodeps option

Comment 21 bob 2017-01-18 19:30:06 UTC
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.

Comment 22 Neil Horman 2017-01-19 14:18:16 UTC
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.

Comment 23 bob 2017-01-20 20:00:36 UTC
I am an end user.  I have no idea what you're talking about.  I need an explicit set of directions to follow.

Comment 24 Neil Horman 2017-01-20 20:29:43 UTC
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.

Comment 25 bob 2017-01-20 21:07:47 UTC
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

Comment 26 Neil Horman 2017-01-23 16:31:52 UTC
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.

Comment 27 bob 2017-01-24 05:44:35 UTC
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.

Comment 28 Neil Horman 2017-01-24 12:26:24 UTC
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.

Comment 29 bob 2017-01-26 13:38:22 UTC
Created attachment 1244785 [details]
dmesg output with test1 kernel build

Comment 30 Neil Horman 2017-01-26 15:18:48 UTC
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?

Comment 31 bob 2017-01-26 15:26:30 UTC
Correct.  USB 3.0 port remains dead.

Comment 32 Neil Horman 2017-01-26 19:26:52 UTC
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.

Comment 33 bob 2017-01-27 06:14:21 UTC
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?

Comment 34 Neil Horman 2017-01-27 12:49:46 UTC
you'll see references to the SWIOTLB system initializing.  If you post  your dmesg log I can confirm for you.

Comment 35 bob 2017-01-27 15:17:47 UTC
Created attachment 1245159 [details]
dmesg output with iommu=soft kernel parameter

Comment 36 Neil Horman 2017-01-27 19:10:28 UTC
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.

Comment 37 bob 2017-01-28 06:33:45 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.