{"action":"created","issue":{"url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/issues/348","repository_url":"https://api.github.com/repos/RadeonOpenCompute/ROCm","labels_url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/issues/348/labels{/name}","comments_url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/issues/348/comments","events_url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/issues/348/events","html_url":"https://github.com/RadeonOpenCompute/ROCm/issues/348","id":301257926,"number":348,"title":"Core voltage settings not honored by amdgpu","user":{"login":"Angel996","id":25131903,"avatar_url":"https://avatars3.githubusercontent.com/u/25131903?v=4","gravatar_id":"","url":"https://api.github.com/users/Angel996","html_url":"https://github.com/Angel996","followers_url":"https://api.github.com/users/Angel996/followers","following_url":"https://api.github.com/users/Angel996/following{/other_user}","gists_url":"https://api.github.com/users/Angel996/gists{/gist_id}","starred_url":"https://api.github.com/users/Angel996/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Angel996/subscriptions","organizations_url":"https://api.github.com/users/Angel996/orgs","repos_url":"https://api.github.com/users/Angel996/repos","events_url":"https://api.github.com/users/Angel996/events{/privacy}","received_events_url":"https://api.github.com/users/Angel996/received_events","type":"User","site_admin":false},"labels":[{"id":682030524,"url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/labels/Base%20AMDGPU%20Driver%20-KGD%20issue","name":"Base AMDGPU Driver -KGD issue","color":"d93f0b","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2018-03-01T02:39:43Z","updated_at":"2018-03-21T11:37:16Z","closed_at":null,"author_association":"NONE","body":"Being able to downvolt GPUs in Linux is obviously crucial in mining. A simple hack of the polaris10_smc.c file found here achieves the task, it does work with latest versions of amdgpu (like 17.40):\r\n\r\nhttps://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/918649-underclocking-undervolting-the-rx-470-with-amdgpu-pro-success\r\n\r\nThe `polaris10_get_dependency_volt_by_clk` is responsible for setting core voltage. Strange though, the article is dated 2016, yet, up until now this has not been fixed. Core voltage table contained in GPU vbios works correctly in Windows, however in Linux it's ignored and core voltage is set at bootup at some fixed value (whose _value_ I was not even able to tell).\r\n\r\nI am not that much of a programmer to do it myself (I'm also kinda afraid to burn my GPUs $1800 worth), but this should really be an easy job for someone who wrote amdgpu. Just wonder why it's never been done? Or maybe it can be set somewhere in the OS itself, in config files? In `/sys/class/hwmon/hwmon$i/device/pp_table` ? Can you please hint it?\r\n\r\np.s. Neither ohgodatool or rocm-smi can actually downvolt GPU core. Power table values change, but actual core voltage does not. Ohgodatool can downvolt vddci, but that's only about 5% power savings.\r\n\r\nthanks )"},"comment":{"url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/issues/comments/374908792","html_url":"https://github.com/RadeonOpenCompute/ROCm/issues/348#issuecomment-374908792","issue_url":"https://api.github.com/repos/RadeonOpenCompute/ROCm/issues/348","id":374908792,"user":{"login":"todxx","id":36073783,"avatar_url":"https://avatars2.githubusercontent.com/u/36073783?v=4","gravatar_id":"","url":"https://api.github.com/users/todxx","html_url":"https://github.com/todxx","followers_url":"https://api.github.com/users/todxx/followers","following_url":"https://api.github.com/users/todxx/following{/other_user}","gists_url":"https://api.github.com/users/todxx/gists{/gist_id}","starred_url":"https://api.github.com/users/todxx/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/todxx/subscriptions","organizations_url":"https://api.github.com/users/todxx/orgs","repos_url":"https://api.github.com/users/todxx/repos","events_url":"https://api.github.com/users/todxx/events{/privacy}","received_events_url":"https://api.github.com/users/todxx/received_events","type":"User","site_admin":false},"created_at":"2018-03-21T11:37:16Z","updated_at":"2018-03-21T11:37:16Z","author_association":"NONE","body":"@rhlug The first error you're seeing is coming from vega10_register_thermal_interrupt in vega10_hwmgr.c.\r\nAfter some digging, I have some vague ideas of what might be happening.\r\n\r\nThis function is part of the hwmgr initialization sequence.  When pp tables are written, the hwmgr is re-initialized.  This re-initialization is when this error is hit.  The interesting part is that this initialization sequence is the same as was performed when the card was first loaded, and it seems to have worked the first time.  So digging through what vega10_register_thermal_interrupt does and looking for anything that could be different between the first initialization and a second, I ended up finding this in the irq registration routine amdgpu_irq_add_id:\r\n```\r\n\tif (adev->irq.client[client_id].sources[src_id] != NULL)\r\n\t\treturn -EINVAL;\r\n\r\n\tif (source->num_types && !source->enabled_types) {\r\n\t\tatomic_t *types;\r\n\r\n\t\ttypes = kcalloc(source->num_types, sizeof(atomic_t),\r\n\t\t\t\tGFP_KERNEL);\r\n\t\tif (!types)\r\n\t\t\treturn -ENOMEM;\r\n\r\n\t\tsource->enabled_types = types;\r\n\t}\r\n\r\n\tadev->irq.client[client_id].sources[src_id] = source;\r\n\treturn 0;\r\n```\r\n\r\nThe first two lines are a check to see if the irq was already registered, and if there was the routine exits with an error.  The registration happens in the 2nd to last line.  As can easily be seen, unless something unregisters the irq, running this routine twice would cause it to fail on the second call.\r\n\r\nAfter digging around some more, the only irq clean-up I found was during device shutdown, i.e. unloading all of amdgpu for the device.  So my best guess is that when the hwmgr is reinitialized, it is attempting to register an already registered irq, gets an error, and aborts.\r\n\r\nA quick and dirty hack to test this theory would be to replace the three occurances of `return -EINVAL` in vega10_register_thermal_interrupt with `return 0`.  Then a failure to register one of the thermal interrupts will cause the routine to return without causing hwmgr to abort initialization, though you will run the risk of potentially running without thermal threshold interrupts active.  Currently it looks like the interrupts only trigger an over-temp warning to be printed, so you wont be losing much.\r\n\r\n"}}
{"actor":{"display_login":"todxx"}}