[BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU - Page 2

**AaronP** · 03-22-12, 03:24 PM

Quote:

Originally Posted by Deanjo

Do the 295.33 (long-lived branch release) for Linux x86/x86_64 release address this issue?

No.

Deanjo · 03-30-12, 05:59 PM

OK this looks like a BIOS issue more then anything. I finally pestered Asus enough that they fixed their IOMMU in the BIOS and now it boots fine to the desktop with IOMMU enabled. The 11.02 Bios releases for the Sabertooth 990FX and the M5A97 EVO fixed this issue.

alan242 · 04-05-12, 01:11 PM

Quote:

Originally Posted by Deanjo

OK this looks like a BIOS issue more then anything. I finally pestered Asus enough that they fixed their IOMMU in the BIOS and now it boots fine to the desktop with IOMMU enabled. The 11.02 Bios releases for the Sabertooth 990FX and the M5A97 EVO fixed this issue.

Hrm... it appears they didn't fix it in 1102 for the M5A99X EVO board. I'm still getting XIDs and then the kernel detects CPU soft lockups.

Are you enabling the IOMMU option only or the IOMMU and the 64 MB window?

Can you provide any ASUS CaseIDs with the fix that I can reference?

CLC · 04-05-12, 05:53 PM

Unfortunately it doesn't seem to fix the issue on the Sabertooth 990FX, either.

I use Sabertooth 990FX (BIOS 1102), AMD FX 6100, GeForce GTX 550 Ti, GeForce 9800GT with 16GB RAM on Fedora 16 64bit (3.3.0-8 kernel) with the NVIDIA kernel module version 295.33. When IOMMU is activated in the BIOS - regardless of IOMMU reserved memory settings or memory remapping settings - I get the same errors in dmesg as Deanjo on page 1 and no X. When I use the nouveau module, I don't get these problems but 3D acceleration is painfully slow and makes the PC unsuitable for running as a Xen virtualized multi-OS, multi-user system (which is what I built it for). So that project's been on hiatus waiting for a patch or fix.

I've tried various xorg.conf settings, several distros and a horde of different kernel and BIOS configurations but nothing seems to help with this problem, aside from IOMMU - if IOMMU is on, the nvidia module doesn't work and if it's off, it does.

That said, here's some of the interesting topics on other forums from people who've had similar issues:

A Gentoo user provides very detailed information and seems to resolve his issue without disabling IOMMU
Kernel.org bug submission with a suggestion from an AMD IOMMU kernel developer to NVIDIA.
A user on this forum. 'Fix' is to disable IOMMU.
A user on the NVIDIA forums seems to solve a related issue on a 32bit kernel by disabling memory hole remapping.
Same issue as above with users on the Gentoo forums.
A user on TweakTown had similar problems with a 2.6.x kernel and a Gigabyte motherboard.
A Debian bug submission.
also
Nouveau had similar (?) problems in the past.
...which were fixed.

Hopefully these will help NVIDIA isolate and remedy the bug or advise us as to any configuration or hardware conflicts.

Deanjo · 04-06-12, 10:18 AM

Quote:

Originally Posted by alan242

Are you enabling the IOMMU option only or the IOMMU and the 64 MB window?

Yes, it works either way, IOMMU only and with the 64 MB window. As far as case ID goes, the typical useless Asus support was no help on the issue. I had to get the issue addressed using a contact that an associate had for asus engineering directly.

Deanjo · 04-06-12, 10:22 AM

Quote:

Originally Posted by CLC

Unfortunately it doesn't seem to fix the issue on the Sabertooth 990FX, either.

I use Sabertooth 990FX (BIOS 1102), AMD FX 6100, GeForce GTX 550 Ti, GeForce 9800GT with 16GB RAM on Fedora 16 64bit (3.3.0-8 kernel) with the NVIDIA kernel module version 295.33. When IOMMU is activated in the BIOS - regardless of IOMMU reserved memory settings or memory remapping settings - I get the same errors in dmesg as Deanjo on page 1 and no X. When I use the nouveau module, I don't get these problems but 3D acceleration is painfully slow and makes the PC unsuitable for running as a Xen virtualized multi-OS, multi-user system (which is what I built it for). So that project's been on hiatus waiting for a patch or fix.

It completely fixed the issue here. I setup another two Sabretooth systems here and they work fine with IOMMU (cards in use with the three systems GTX-580, GT520 and GTX-275). The M5A system is running fine as well with IOMMU and a 8800GT. All are running openSUSE Tumbleweed 64-bit. It is quite possible however that the choice of processor also plays a factor here. All the systems that have working IOMMU here are using Thuban processors so maybe the fix did not apply to BD processors.

CLC · 04-06-12, 11:50 AM

Deanjo,

Do you have another NVIDIA graphics card that you can add to the system and see if everything still works? It could be a multi-GPU issue - I'm not really able to test that until the end of the month as I'm currently using that machine in headless mode for several production-essential VMs.

alan242 · 04-06-12, 01:32 PM

Quote:

Originally Posted by Deanjo

Yes, it works either way, IOMMU only and with the 64 MB window. As far as case ID goes, the typical useless Asus support was no help on the issue. I had to get the issue addressed using a contact that an associate had for asus engineering directly.

I'm not surprised you had to go to ASUS engineering directly.

For the record, I'm running a Phenom II X6 1055T 95W, 16GB of RAM and PNY 9800GT with 1GB of RAM. I'm currently using a vanilla 3.3.0 kernel in 64 bit mode with no patches.

I have a feeling this is one of those where it's going to take a alignment of the memory bits into a sacred pattern followed by a sacrfice of a chicken... Which apparently Microsoft did as the IOMMU works fine for me in Win 7 64 bit with the old and new BIOS.

Can you tell me which openSUSE kernel you are using? Do you have any additional patches installed on it? Also, if the kernel config is not the openSUSE distributed one, can you attach yours to a post?

Can you attach a dmesg/boot log for comparison?

Thanks,
Alan

Deanjo · 04-06-12, 04:18 PM

Can you tell me which openSUSE kernel you are using?

kernel-desktop-3.3.1-18.1.x86_64

Do you have any additional patches installed on it?

Nope

Also, if the kernel config is not the openSUSE distributed one, can you attach yours to a post?

Stock opensuse config.

CLC · 04-07-12, 01:10 AM

Deanjo,

I'm curious about your memory configuration - how many RAM modules do you have installed in each of the systems? What memory configuration options in the BIOS have you changed?

I was using a 3.2 kernel, so I upgraded to 3.3.1 (vanilla) but to no avail. I'm trying the OpenSUSE kernel configuration, I'll report back with results tomorrow.

Deanjo · 04-07-12, 09:08 AM

Quote:

Originally Posted by CLC

Deanjo,

I'm curious about your memory configuration - how many RAM modules do you have installed in each of the systems? What memory configuration options in the BIOS have you changed?

I was using a 3.2 kernel, so I upgraded to 3.3.1 (vanilla) but to no avail. I'm trying the OpenSUSE kernel configuration, I'll report back with results tomorrow.

All the systems have 4 modules installed and I haven't changed any of the memory options in the BIOS other then module clock speed.

CLC · 04-07-12, 02:35 PM

I bit the bullet and did some thorough testing, removing each graphics card individually and trying different combinations of RAM modules. I tested using 4 kernels - 3.2-pf, 3.3.1-vanilla, 3.3.1-vanilla with opensuse config and the fedora kernel mentioned earlier. I reflashed 1102 again and reset everything to default apart from enabling IOMMU (both 64MB and without). I've tried the three most recent versions of the nvidia kernel module - 295.33, 295.20 and 290.10.

You seem to be correct about the bug being connected to the CPU - nothing else makes a difference. Can anybody else here confirm that their AMD FX processor and AMD 990FX/890FX chipset has this bug?

03-30-12, 05:59 PM	#14
Deanjo Registered User Join Date: Aug 2004 Posts: 301	Re: [BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU OK this looks like a BIOS issue more then anything. I finally pestered Asus enough that they fixed their IOMMU in the BIOS and now it boots fine to the desktop with IOMMU enabled. The 11.02 Bios releases for the Sabertooth 990FX and the M5A97 EVO fixed this issue.

04-05-12, 05:53 PM	#16
CLC Registered User Join Date: Apr 2012 Posts: 6	Re: [BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU Unfortunately it doesn't seem to fix the issue on the Sabertooth 990FX, either. I use Sabertooth 990FX (BIOS 1102), AMD FX 6100, GeForce GTX 550 Ti, GeForce 9800GT with 16GB RAM on Fedora 16 64bit (3.3.0-8 kernel) with the NVIDIA kernel module version 295.33. When IOMMU is activated in the BIOS - regardless of IOMMU reserved memory settings or memory remapping settings - I get the same errors in dmesg as Deanjo on page 1 and no X. When I use the nouveau module, I don't get these problems but 3D acceleration is painfully slow and makes the PC unsuitable for running as a Xen virtualized multi-OS, multi-user system (which is what I built it for). So that project's been on hiatus waiting for a patch or fix. I've tried various xorg.conf settings, several distros and a horde of different kernel and BIOS configurations but nothing seems to help with this problem, aside from IOMMU - if IOMMU is on, the nvidia module doesn't work and if it's off, it does. That said, here's some of the interesting topics on other forums from people who've had similar issues: A Gentoo user provides very detailed information and seems to resolve his issue without disabling IOMMU Kernel.org bug submission with a suggestion from an AMD IOMMU kernel developer to NVIDIA. A user on this forum. 'Fix' is to disable IOMMU. A user on the NVIDIA forums seems to solve a related issue on a 32bit kernel by disabling memory hole remapping. Same issue as above with users on the Gentoo forums. A user on TweakTown had similar problems with a 2.6.x kernel and a Gigabyte motherboard. A Debian bug submission. also Nouveau had similar (?) problems in the past. ...which were fixed. Hopefully these will help NVIDIA isolate and remedy the bug or advise us as to any configuration or hardware conflicts.

04-06-12, 11:50 AM	#19
CLC Registered User Join Date: Apr 2012 Posts: 6	Re: [BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU Deanjo, Do you have another NVIDIA graphics card that you can add to the system and see if everything still works? It could be a multi-GPU issue - I'm not really able to test that until the end of the month as I'm currently using that machine in headless mode for several production-essential VMs.

04-06-12, 04:18 PM	#21
Deanjo Registered User Join Date: Aug 2004 Posts: 301	Re: [BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU Can you tell me which openSUSE kernel you are using? kernel-desktop-3.3.1-18.1.x86_64 Do you have any additional patches installed on it? Nope Also, if the kernel config is not the openSUSE distributed one, can you attach yours to a post? Stock opensuse config.

04-07-12, 01:10 AM	#22
CLC Registered User Join Date: Apr 2012 Posts: 6	Re: [BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU Deanjo, I'm curious about your memory configuration - how many RAM modules do you have installed in each of the systems? What memory configuration options in the BIOS have you changed? I was using a 3.2 kernel, so I upgraded to 3.3.1 (vanilla) but to no avail. I'm trying the OpenSUSE kernel configuration, I'll report back with results tomorrow.

04-07-12, 02:35 PM	#24
CLC Registered User Join Date: Apr 2012 Posts: 6	Re: [BUG REPORT] 260.19.36 64-bit Linux driver conflicts with AMD 890FX IOMMU I bit the bullet and did some thorough testing, removing each graphics card individually and trying different combinations of RAM modules. I tested using 4 kernels - 3.2-pf, 3.3.1-vanilla, 3.3.1-vanilla with opensuse config and the fedora kernel mentioned earlier. I reflashed 1102 again and reset everything to default apart from enabling IOMMU (both 64MB and without). I've tried the three most recent versions of the nvidia kernel module - 295.33, 295.20 and 290.10. You seem to be correct about the bug being connected to the CPU - nothing else makes a difference. Can anybody else here confirm that their AMD FX processor and AMD 990FX/890FX chipset has this bug?