Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon

2020-04-27 Thread Izumi Tsutsui 
> Module Name:  src
> Committed By: tsutsui
> Date: Mon Apr 27 16:57:31 UTC 2020
> 
> Modified Files:
>   src/sys/external/bsd/drm2/dist/drm/radeon: radeon_ttm.c
> 
> Log Message:
> Fix possible bus_dmamap_load(9) leak.  PR/55127
> 
> "Looks good to me" from riastradh@.
> Note it was also commented "that code path is likely to be reached"

Mis-quoted, it should be "not likely".

> so maybe pullups are not necessary.

---
Izumi Tsutsui

re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon

2015-03-03 Thread matthew green 

Taylor R Campbell writes:
>Date: Wed, 04 Mar 2015 09:24:22 +1100
>from: matthew green 
> 
>"Taylor R Campbell" writes:
>> Module Name: src
>> Committed By:riastradh
>> Date:Tue Mar  3 13:57:20 UTC 2015
>> 
>> Modified Files:
>>  src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c
>> 
>> Log Message:
>> radeon_fence_wait returns 0, not positive, on success.
> 
>i haven't confirmed yet, but i suspect this change breaks
>radeondrmkms.
> 
> It does, and that breakage should be fixed by:
> 
> https://mail-index.netbsd.org/source-changes/2015/03/03/msg063651.html

indeed, this fixes it for me.  i thought i had tested it but
i only had rev 1.7.

thanks, and sorry for the noise!


.mrg.

re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon

2015-03-03 Thread matthew green 

"Taylor R Campbell" writes:
> Module Name:  src
> Committed By: riastradh
> Date: Mon Mar  2 17:53:00 UTC 2015
> 
> Modified Files:
>   src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c
> 
> Log Message:
> Return the error if there is one in radeon_fence_wait_seq.
> 
> Don't just always say we succeeded!
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 \
> src/sys/external/bsd/drm2/dist/drm/radeon/radeon_fence.c

this is infact the problem change -- reverting back to
radeon_fence.c 1.5 gives me (mostly) working drm again.


.mrg.

Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon

2015-03-03 Thread Taylor R Campbell 
   Date: Wed, 04 Mar 2015 09:24:22 +1100
   from: matthew green 

   "Taylor R Campbell" writes:
   > Module Name:   src
   > Committed By:  riastradh
   > Date:  Tue Mar  3 13:57:20 UTC 2015
   > 
   > Modified Files:
   >src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c
   > 
   > Log Message:
   > radeon_fence_wait returns 0, not positive, on success.

   i haven't confirmed yet, but i suspect this change breaks
   radeondrmkms.

It does, and that breakage should be fixed by:

https://mail-index.netbsd.org/source-changes/2015/03/03/msg063651.html

re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon

2015-03-03 Thread matthew green 

"Taylor R Campbell" writes:
> Module Name:  src
> Committed By: riastradh
> Date: Tue Mar  3 13:57:20 UTC 2015
> 
> Modified Files:
>   src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c
> 
> Log Message:
> radeon_fence_wait returns 0, not positive, on success.

i haven't confirmed yet, but i suspect this change breaks
radeondrmkms.

latest kernels are no longer enabling DRM in X for me, and we end
up with no KMS enabled, and really really slow access.. the console
seems fine, and the Xorg.0.log file is identical upto the point it
says direct rendering isn't working and gives up:

[75.407] drmOpenByBusid: drmGetBusid reports pci:0001:02:00.0
[75.408] (II) RADEON(0): GPU accel disabled or not working, using shadowfb 
for KMS
[75.408] (II) Loading sub module "shadow"

the next line is normally:

[68.095] (II) Loading sub module "dri2"

i'll test which exact change broke things this evening.


.mrg.