date:20160529

[Bug 119211] amdgpu disables fan by default

2016-05-29 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=119211

--- Comment #2 from Stas Sergeev  ---
Even besides the fact that GPU was so hot I
couldn't even touch it?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 119211] amdgpu disables fan by default

2016-05-29 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=119211

--- Comment #1 from Vedran MiletiÄ  ---
You should produce some GPU load before the fan activates.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 119211] New: amdgpu disables fan by default

2016-05-29 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=119211

Bug ID: 119211
   Summary: amdgpu disables fan by default
   Product: Drivers
   Version: 2.5
Kernel Version: 4.5.5
  Hardware: All
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: stsp at list.ru
Regression: No

I have radeon R9 380.
After the KMS driver activates, the fans on
the GPU stops. They can be activated again by
properly setting up fancontrol, but this wasn't
configured on my PC. As the result, for the last
few years I have replaced many motherboards, all
starting to have bad capacitors around the video
card. But only now I have noticed that the fans
are not rotating... :(

The driver should activate fans by default, or
don't touch the initial settings (fans are rotating
before linux have started), but not stop them by default.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

2016-05-29 Thread Bhaktipriya Shridhar

Thanks Oded. Sending v3 right away :)

On Sun, May 29, 2016 at 8:31 PM, Oded Gabbay  wrote:
> On Thu, May 26, 2016 at 10:37 PM, Bhaktipriya Shridhar
>  wrote:
>> alloc_workqueue replaces deprecated create_workqueue().
>>
>> create_workqueue has been replaced with alloc_workqueue with max_active
>> as 0 since there is no need for throttling the number of active work items.
>>
>> WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be used in
>> memory reclaim path.
>>
>> kfd_process_wq is used for delay destruction. A work item embedded in
>> kfd_process gets queued to kfd_process_wq and when it executes it
>> destroys and frees the containing kfd_process and thus itself.
>>
>> This requires a dedicated workqueue because a work item once queued, may
>> get freed at any point of time and any external entity cannot
>> flush the work item. So, in order to wait for such a work item,
>> it needs to be put on a dedicated workqueue.
>>
>> kfd_module_exit() calls kfd_process_destroy_wq which ensures that all
>> pending work items are finished before the module is removed.
>>
>> flush_workqueue is unnecessary since destroy_workqueue() itself calls
>> drain_workqueue() which flushes repeatedly till the workqueue becomes empty.
>>
>> Hence flush_workqueue has been removed.
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>> ---
>>  Changes in v2:
>> - added explanation for setting concurrency value to
>>   WQ_DFL_ACTIVE
>> - added explanation for dropping WQ_MEM_RECLAIM
>>
>>  drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>> index ac00579..b21d3fc8 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>> @@ -63,13 +63,12 @@ static struct kfd_process *create_process(const struct 
>> task_struct *thread);
>>  void kfd_process_create_wq(void)
>>  {
>> if (!kfd_process_wq)
>> -   kfd_process_wq = create_workqueue("kfd_process_wq");
>> +   kfd_process_wq = alloc_workqueue("kfd_process_wq",0,0);
>
> You are missing a space between the arguments. Seem you forgot to run
> checkpatch.pl ;)
>
> Send a new patch and I'll add it to amdkfd's tree.
>
> Thanks,
>
>Oded
>
>>  }
>>
>>  void kfd_process_destroy_wq(void)
>>  {
>> if (kfd_process_wq) {
>> -   flush_workqueue(kfd_process_wq);
>> destroy_workqueue(kfd_process_wq);
>> kfd_process_wq = NULL;
>> }
>> --
>> 2.1.4
>>

[Bug 96271] TF2: GPU lockup on HD 7950

2016-05-29 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=96271

--- Comment #2 from Stephen Liang <hi+freedesktop at stephenliang.pw> ---
One more thing, I did run an apitrace and replayed the apitrace to see if that
reproduces the hang. The replay didn't hang my machine initially but after
running it a 2-3 times, it was able to hang the machine. I would attach the
apitrace but it is 2-3 GB and the hang is several hundreds of thousands of
frames in (and it's not reproducible every time during replay, just sometimes).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/3ea313f6/attachment.html>

[PATCH v3] gpu: drm: amd: amdkfd: Remove create_workqueue()

2016-05-29 Thread Bhaktipriya Shridhar

alloc_workqueue replaces deprecated create_workqueue().

create_workqueue has been replaced with alloc_workqueue with max_active
as 0 since there is no need for throttling the number of active work items.

WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be
used in memory reclaim path.

kfd_process_wq is used for delay destruction. A work item embedded in
kfd_process gets queued to kfd_process_wq and when it executes it
destroys and frees the containing kfd_process and thus itself.

This requires a dedicated workqueue because a work item once queued, may
get freed at any point of time and any external entity cannot
flush the work item. So, in order to wait for such a work item,
it needs to be put on a dedicated workqueue.

kfd_module_exit() calls kfd_process_destroy_wq which ensures that all
pending work items are finished before the module is removed.

flush_workqueue is unnecessary since destroy_workqueue() itself calls
drain_workqueue() which flushes repeatedly till the workqueue
becomes empty.

Hence flush_workqueue has been removed.

Signed-off-by: Bhaktipriya Shridhar 
---
 Changes in v3:
- Corrected space between arguments.

 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index ac00579..6482fee 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -63,13 +63,12 @@ static struct kfd_process *create_process(const struct 
task_struct *thread);
 void kfd_process_create_wq(void)
 {
if (!kfd_process_wq)
-   kfd_process_wq = create_workqueue("kfd_process_wq");
+   kfd_process_wq = alloc_workqueue("kfd_process_wq", 0, 0);
 }

 void kfd_process_destroy_wq(void)
 {
if (kfd_process_wq) {
-   flush_workqueue(kfd_process_wq);
destroy_workqueue(kfd_process_wq);
kfd_process_wq = NULL;
}
--
2.1.4

[Bug 96271] TF2: GPU lockup on HD 7950

2016-05-29 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=96271

--- Comment #1 from Stephen Liang <hi+freedesktop at stephenliang.pw> ---
Created attachment 124166
  --> https://bugs.freedesktop.org/attachment.cgi?id=124166=edit
output from GALLIUM_DDEBUG="800 noflush" steam steam://rungameid/440

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/6e116a2b/attachment.html>

[Bug 96271] TF2: GPU lockup on HD 7950

2016-05-29 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=96271

Bug ID: 96271
Summary: TF2: GPU lockup on HD 7950
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: hi+freedesktop at stephenliang.pw
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 124165
--> https://bugs.freedesktop.org/attachment.cgi?id=124165=edit
dmesg on kernel 4.7

I'm getting a GPU lockup on Team Fortress 2 which seems to be related to bug
#80419 since my dmesg is the same as comment #44 but this is occurring on Team
Fortress 2 rather than XCOM.

If I run native TF2 with GALLIUM_DDEBUG=800, I cannot reproduce the bug but the
frame rate drops significantly. With GALLIUM_DDEBUG="800 noflush", I was able
to reproduce the hang. This leads me to believe that the issue is related how
high the FPS is running.

My kernel is: Linux localhost.localdomain 4.4.9-300.fc23.x86_64
I've also tried 4.6 and 4.7, all of which hangs.

My ATI driver is: 7.7.99-3.20160524git040a7b8.fc23 (latest commit in git for
radeon)
I've also tried 7.6.1-3.20160215gitd41fccc.fc23 (the latest stable from fedora
23), all of which hangs.

My mesa version is: 11.3.0-0.37.git357495b.fc23
I've also tried 11.1.0-2.20151218.fc23 (the latest stable from fedora 23), all
of which hangs.

I've attached the GALLIUM_DDEBUG output and dmesg. One curious thing is that on
kernel 4.7, the kernel detects a hang and is able to reset the GPU resulting in
a temporary freeze that eventually resumes. However, the freeze will come again
after a short while (and resumes).

As a data point, I don't get any lockups while playing Skyrim on Wine.

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160529/9758336b/attachment.html>

64 matches

Mail list logo