-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ROCm on Bristol Ridge + ASUS prime X370-pro ? #121
Comments
The GPU seems to be detected:
and dmesg gives
|
X slows down/hangs very quickly but the machine allows remote ssh ! Fedora koji kernel version 4.11.1 has the same issue, so it seems not ROCK kernel specific. Booting with iommu=soft or deactivating IOMMU in BIOS seems to be the only solution but that also disables ROCm. Bummer. |
On May 16, 2017, at 9:14 AM, oheid <notifications@github.com<mailto:notifications@github.com>> wrote:
X slows down/hangs very quickly but the machine allows remote ssh ! Fedora koji kernel version 4.11.1 has the same issue, so it seems not ROCK kernel specific. Booting with iommu=soft or deactivating IOMMU in BIOS seems to be the only solution but that also disables ROCm. Bummer.
Both kernel versions (rebuilt on the respective target machines) work nicely on a Ryzen 1700x + R9 480 + Asus crosshair VI hero combo so I tend to believe that this is a BIOS issue (0604) rather than Ubuntu 16 (supported) vs. Fedora 25 (unsupported?).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#121 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD8DuV81Ah6HaQBc2C1o3Gt-9hY0qMtBks5r6a9EgaJpZM4NbFLV>.
We just received one of these motherboard, we try it with Bristolridge in the Lab.
Greg
|
Is there any update on this? I have a Bristol Ridge with similar symptoms: X starts up glacially slow and does not get faster. On the other hand, I can run the sample OpenCL vector_copy program from the terminal successfully. While X is being slow, 'top' reports near 100% idle, with near 0% values for us[er], sy[stem], and wa[iting for IO]. However the system load average never dips below 1.00 which seems weird. Something is doing a lot of waiting and it's counting toward the load average. I also can disable IOMMU and then X will run using the older ati/radeon driver. That would be a good workaround for many purposes, however I'm hoping to do OpenCL development on this system so I'm looking forward to using ROCm! Details:
Another workaround is to boot at runlevel 3 (no gui) and then ssh into the system, which is working. I'm getting interesting dmesg chatter, for example: [ 2786.497886] ------------[ cut here ]------------ |
Maybe I found the answer. It sounds like ROCm is intended for headless server development and maybe isn't expected to work with a display. I'm looking at the first response from gstoner here: Please let me know if I'm misinterpreting this, but for now I'll just run ROCm headless which is fine for what I'm doing. |
Is there any experience with runing ROCm-1.5.x on Bristol Ridge (A12-9800) + ASUS Prime X370-Pro? I use Fedora 25. The ROCK 4.9.0 kernel seems to have a problem with this hardware setup: Lightdm login manager or X launched from text console via startx hangs the machine after one or two seconds.
The ROCR example/test program crashes with
Is there any way to fix that?
I use kernel parameters "amd_iommu=on iommu=pt" - is this advisable?
The relevant kernel modules seem to be there
and IOMMUv2 is present:
The text was updated successfully, but these errors were encountered: