Re: [PATCH 2/3] Enabled LRA for ia64.

[Frank Scheiner]

Hi Jonathan, Richard,

On 12.06.24 20:54, Jonathan Wakely wrote:

On 12/06/24 16:09 +0200, Frank Scheiner wrote:

Dear Richard,

On 12.06.24 13:01, Richard Biener wrote:

[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without?  Both from May:

https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html

somehow for example libstdc++ summaries were not merged, it might
be you do not have recent python installed on the system?  Or you
didn't use contrib/test_summary to create those mails.


No, I did not use contrib/test_summary. But I still have tarballs of
both testsuite runs, so could still produce these summaries - I hope?


It looks like the results at
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are
just what's printed on standard out, including output from 'make -j4'
so not combined into one set of results.


That's what it is, yes.


It would certainly be better to either get the results from the .sum
files, or just use the contrib/test_summary script to do that for you.


Ok, I posted the results as created by contrib/test_summary now:

1. non-LRA version on [1]

2. LRA version on [2]

[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html

[2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html

The difference 2 compared to 1 is attached.


Do I need to run this on the host that did the testing or can I run it
on my NFS server where the tarballs are actually located, too?


I don't think the script cares where it's run, it just looks at text
files which should work on any host.


It looks like it worked fine. :-)

Cheers,
Frank
 
diff --git a/gcc-15-testsuite-summary.log b/gcc-15-lra-testsuite-summary.log
index b7acc04..558079a 100644
--- a/gcc-15-testsuite-summary.log
+++ b/gcc-15-lra-testsuite-summary.log
@@ -306,13 +306,12 @@ FAIL: gcc.dg/guality/csttest.c  -Og -DPREVENT_OPTIMIZATION  line 55 q == -(0x1ef
 FAIL: gcc.dg/guality/csttest.c  -Og -DPREVENT_OPTIMIZATION  line 55 r == -(0x1efULL << 50)
 XPASS: gcc.dg/guality/example.c   -O0  execution test
 XPASS: gcc.dg/guality/guality.c   -O0  execution test
-XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c   -O1  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c   -O2  -DPREVENT_OPTIMIZATION  execution test
+FAIL: gcc.dg/guality/inline-params-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c   -Os  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params.c   -O1  -DPREVENT_OPTIMIZATION  execution test
-XPASS: gcc.dg/guality/inline-params.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 19 k == 3
 FAIL: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 31 k == 3
@@ -434,6 +433,7 @@ FAIL: gcc.dg/guality/pr41447-1.c   -Os  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41447-1.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41616-1.c   -O1  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41616-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
+FAIL: gcc.dg/guality/pr41616-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41616-1.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 34 c == [0]
 FAIL: gcc.dg/guality/pr43077-1.c   -O0  line 19 vara == 1
@@ -798,10 +798,10 @@ FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-genera
 UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
 UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,-fprofile-generate -D_PROFILE_GENERATE
 UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,-fprofile-use -D_PROFILE_USE
-FAIL: gcc.dg/tree-prof/pr77698.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
-UNRESOLVED: gcc.dg/tree-prof/pr77698.c compilation,  -fprofile-use -D_PROFILE_USE
-UNRESOLVED: gcc.dg/tree-prof/pr77698.c execution,-fprofile-generate -D_PROFILE_GENERATE
-UNRESOLVED: gcc.dg/tree-prof/pr77698.c execution,-fprofile-use -D_PROFILE_USE
+FAIL: gcc.dg/tree-prof/pr47187.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
+UNRESOLVED: gcc.dg/tree-prof/pr47187.c compilation,  -fprofile-use -D_PROFILE_USE
+UNRESOLVED: gcc.dg/tree-prof/pr47187.c execution,-fprofile-generate -D_PROFILE_GENERATE
+UNRESOLVED: gcc.dg/tree-prof/pr47187.c execution,-fprofile-use -D_PROFILE_USE
 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= -" 3
 FAIL: gcc.dg/tree-

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

Native configuration is ia64-t2-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata2,"aR"
WARNING: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess 
errors) program timed out.
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O1  execution test

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

Native configuration is ia64-t2-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata2,"aR"
WARNING: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess 
errors) program timed out.
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O1  execution test

Re: Nächstes Treffen ?! Fuckup

[Dennis Frank]

Ich habe Di. 25.6. notiert

Florian Lohoff  schrieb am Mi., 12. Juni 2024, 18:33:

>
> Hi,
> ich glaube ich habe mich da vertan und nur Mist gemacht.
>
> Das nächste Treffen soll Dienstag 15.6 sein - Der 15.6 ist kein
> Dienstag.
>
> Weiss jemand noch was wir machen wollten ? Helmut?
>
> Jemand müsste dann das Wiki noch ändern und auch im OSMCal eintragen.
>
> Ich bin leider nächste Woche auch Beruflich unterwegs deshalb wollte ich
> das gerade mal nachpflegen.
>
> Flo
> --
> Florian Lohoff f...@zz.de
>   Any sufficiently advanced technology is indistinguishable from magic.
> ___
> OSM mailing list
> OSM@gt.owl.de
> https://gt.owl.de/mailman/listinfo/osm
___
OSM mailing list
OSM@gt.owl.de
https://gt.owl.de/mailman/listinfo/osm

[ceph-users] Re: CephFS metadata pool size

[Frank Schilder]

Hi, there seem to be replies missing to this list. For example, I can't find 
any messages that contain information that could lead to this conclusion:

> * pg_num too low (defaults are too low)
> * pg_num not a power of 2
> * pg_num != number of OSDs in the pool
> * balancer not enabled

It is horrible for other users to follow threads or learn from them if part of 
the communication is private. This thread is not the first occurrence, it seems 
to become more frequent recently. Could posters please reply to the list 
instead of individual users?

Thanks for your consideration.
=====
Frank Schilder
AIT Risø Campus
Bygning 109, rum S14


From: Anthony D'Atri 
Sent: Wednesday, June 12, 2024 2:53 PM
To: Eugen Block
Cc: Lars Köppel; ceph-users@ceph.io
Subject: [ceph-users] Re: CephFS metadata pool size

If you have:

* pg_num too low (defaults are too low)
* pg_num not a power of 2
* pg_num != number of OSDs in the pool
* balancer not enabled

any of those might result in imbalance.

> On Jun 12, 2024, at 07:33, Eugen Block  wrote:
>
> I don't have any good explanation at this point. Can you share some more 
> information like:
>
> ceph pg ls-by-pool 
> ceph osd df (for the relevant OSDs)
> ceph df
>
> Thanks,
> Eugen
>
> Zitat von Lars Köppel :
>
>> Since my last update the size of the largest OSD increased by 0.4 TiB while
>> the smallest one only increased by 0.1 TiB. How is this possible?
>>
>> Because the metadata pool reported to have only 900MB space left, I stopped
>> the hot-standby MDS. This gave me 8GB back but these filled up in the last
>> 2h.
>> I think I have to zap the next OSD because the filesystem is getting read
>> only...
>>
>> How is it possible that an OSD has over 1 TiB less data on it after a
>> rebuild? And how is it possible to have so different sizes of OSDs?
>>
>>
>> [image: ariadne.ai Logo] Lars Köppel
>> Developer
>> Email: lars.koep...@ariadne.ai
>> Phone: +49 6221 5993580 <+4962215993580>
>> ariadne.ai (Germany) GmbH
>> Häusserstraße 3, 69115 Heidelberg
>> Amtsgericht Mannheim, HRB 744040
>> Geschäftsführer: Dr. Fabian Svara
>> https://ariadne.ai
>>
>>
>> On Tue, Jun 11, 2024 at 3:47 PM Lars Köppel  wrote:
>>
>>> Only in warning mode. And there were no PG splits or merges in the last 2
>>> month.
>>>
>>>
>>> [image: ariadne.ai Logo] Lars Köppel
>>> Developer
>>> Email: lars.koep...@ariadne.ai
>>> Phone: +49 6221 5993580 <+4962215993580>
>>> ariadne.ai (Germany) GmbH
>>> Häusserstraße 3, 69115 Heidelberg
>>> Amtsgericht Mannheim, HRB 744040
>>> Geschäftsführer: Dr. Fabian Svara
>>> https://ariadne.ai
>>>
>>>
>>> On Tue, Jun 11, 2024 at 3:32 PM Eugen Block  wrote:
>>>
>>>> I don't think scrubs can cause this. Do you have autoscaler enabled?
>>>>
>>>> Zitat von Lars Köppel :
>>>>
>>>> > Hi,
>>>> >
>>>> > thank you for your response.
>>>> >
>>>> > I don't think this thread covers my problem, because the OSDs for the
>>>> > metadata pool fill up at different rates. So I would think this is no
>>>> > direct problem with the journal.
>>>> > Because we had earlier problems with the journal I changed some
>>>> > settings(see below). I already restarted all MDS multiple times but no
>>>> > change here.
>>>> >
>>>> > The health warnings regarding cache pressure resolve normally after a
>>>> > short period of time, when the heavy load on the client ends. Sometimes
>>>> it
>>>> > stays a bit longer because an rsync is running and copying data on the
>>>> > cluster(rsync is not good at releasing the caps).
>>>> >
>>>> > Could it be a problem if scrubs run most of the time in the background?
>>>> Can
>>>> > this block any other tasks or generate new data itself?
>>>> >
>>>> > Best regards,
>>>> > Lars
>>>> >
>>>> >
>>>> > global  basic mds_cache_memory_limit
>>>> > 17179869184
>>>> > global  advanced  mds_max_caps_per_client
>>>> >16384
>>>> > global  advanced
>>>> mds_recall_global_max_decay_threshold
>>>> >262144
>>>> > global  advanced  mds_

Re: [PATCH 2/3] Enabled LRA for ia64.

[Frank Scheiner]

Dear Richard,

On 12.06.24 13:01, Richard Biener wrote:

[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without?  Both from May:

https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html

somehow for example libstdc++ summaries were not merged, it might
be you do not have recent python installed on the system?  Or you
didn't use contrib/test_summary to create those mails.


No, I did not use contrib/test_summary. But I still have tarballs of
both testsuite runs, so could still produce these summaries - I hope?

Do I need to run this on the host that did the testing or can I run it
on my NFS server where the tarballs are actually located, too?

Architectures are different though, the NFS server is 32-bit ARM.

Cheers,
Frank

Re: [PATCH 2/3] Enabled LRA for ia64.

[Frank Scheiner]

Hi all,

On 12.06.24 15:19, René Rebe wrote:

On Jun 12, 2024, at 15:00, Richard Biener  wrote:

On Wed, 12 Jun 2024, René Rebe wrote:

On Jun 12, 2024, at 13:01, Richard Biener  wrote:
On Wed, 12 Jun 2024, Rene Rebe wrote:

not sure how you exactly did this though?  I've never tried
testing of a canadian-cross tree - did you copy the whole build
tree over from the x86 to the ia64 machine?


IIRC the testsuite did not just work copying the canadian-cross.
I did run the testsuite from the cross-compiled gcc using a ssh
based dejagnu board config, but Frank also did fully bootstrap and
ran the testsuite natively.


Exactly, the results I posted are both based on natively bootstrapped 
GCC binaries (took ca. 5 hours each on my rx2800 i2). The post titles 
include the exact commit hash they are based on:


1. [ia64] Results for 15.0.0 20240528 (experimental) [master revision 
236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on 
ia64-t2-linux-gnu ([1])


2. [ia64] Results for 15.0.0 20240528 (experimental) [master revision 
236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on 
ia64-t2-linux-gnu ([2])


[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816346.html

[2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html

I tried to save time during the testsuite runs (it still took more than 
7 hours on my rx2800 i2 running in tmpfs) by manually running multiple 
testsuites in parallel in the following fashion:


```
gcc   | libstdc++
  |
  |
--|
g++   |
  |
  |
--|
gfortran  |
  |
  |
--|
libgomp   |---
  | libatomic
  |---
  | objc
```
... and also using multiple jobs per testsuite where it saved time (e.g. 
it does not for the libgomp testsuite). This is the reason that the 
output is somewhat split up.


[1] and [2] each also list the commands used to run the testsuites and 
timing data. For reference these were produced on a:


rx2800 i2 w/1 x Itanium 2 9320 running @1.33 GHz w/SMT enabled

Cheers,
Frank

[FFmpeg-cvslog] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

ffmpeg | branch: master | Frank Plowman  | Sun Jun  9 
12:17:26 2024 +0100| [d72a5fe719c01da07af30e4402a7c3cd994b4cfc] | committer: 
Nuo Mi

lavc/vvc: Prevent overflow in chroma QP derivation

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Additionally, don't discard the return code from sps_chroma_qp_table.

Signed-off-by: Frank Plowman 

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d72a5fe719c01da07af30e4402a7c3cd994b4cfc
---

 libavcodec/vvc/ps.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..92368eafc2 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+// Note: we cannot check qp_{in,out}[j+1] here as qp_*[j] + 
delta_qp_*
+//   may not fit in an 8-bit signed integer.
+if (qp_in[j] + delta_qp_in[j] > 63 || qp_out[j] + delta_qp_out > 
63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
@@ -186,8 +191,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }

___
ffmpeg-cvslog mailing list
ffmpeg-cvslog@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog

To unsubscribe, visit link above, or email
ffmpeg-cvslog-requ...@ffmpeg.org with subject "unsubscribe".

[Bug 2069035] Re: [24.10] Please test secure-boot and lockdown on the 6.10 kernel (s390x) for Oracular

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069035

Title:
  [24.10] Please test secure-boot and lockdown on the 6.10 kernel
  (s390x) for Oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2069035/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069129] Re: [UBUNTU 24.04] Cannot find or install the 'crypto-policies' package

[Frank Heimes]

Thanks Adrien, I was just also digging into this and found that jammy was the 
last release where the package existed:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2069129/+subscriptions

(interesting to see what you are working on instead)

Meanwhile I've updated the status of this ticket to Invalid.

** Package changed: linux (Ubuntu) => crypto-policies (Ubuntu)

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Changed in: crypto-policies (Ubuntu)
 Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)

** Changed in: ubuntu-z-systems
   Status: New => Invalid

** Changed in: crypto-policies (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069129

Title:
  [UBUNTU 24.04] Cannot find or install the 'crypto-policies' package

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2069129/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069129] Re: [UBUNTU 24.04] Cannot find or install the 'crypto-policies' package

[Frank Heimes]

... and I just found that it got deleted starting with kinetic/22.10
incl. rationale provided by vorlon:
https://launchpad.net/ubuntu/+source/crypto-policies/20190816git-1/+publishinghistory

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069129

Title:
  [UBUNTU 24.04] Cannot find or install the 'crypto-policies' package

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2069129/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: shutdown/reboot taking a long time

[Frank Kardel]

Hi Thomas !

I believe PR kern/56309 (~ 3 years ago) already documents this.

https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=56309

I disabled removing swap for the time being.

Best regards

  Frank

On 2024-06-09 22:46, Thomas Klausner wrote:

Hi!

Recently I noticed that after a longer uptime, shutdown takes a while.

I think it's in the step where it tears down the swap.

The last time I rebooted, there was no memory pressure (no big
processes running), but the reboot took over 5 hours.

The swap setup is:


swapctl -lh

Device  Size UsedAvail Capacity  Priority
/dev/dk2127G 269M 127G 0%0
/dev/dk7192G 271M 192G 0%0
/dev/dk4128G 270M 128G 0%0
Total   447G 810M 446G 0%

Has anyone else seen this?
  Thomas

[Bug 2069035] Re: [24.10] Please test secure-boot and lockdown on the 6.10 kernel (s390x) for Oracular

[Frank Heimes]

Many thanks Grgo for the test, and the blazing fast turnaround !

** Changed in: linux (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069035

Title:
  [24.10] Please test secure-boot and lockdown on the 6.10 kernel
  (s390x) for Oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2069035/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH RESEND 2/6] target/riscv: Introduce extension implied rule helpers

[Frank Chang]

On Wed, Jun 5, 2024 at 2:32 PM  wrote:

> From: Frank Chang 
>
> Introduce helpers to enable the extensions based on the implied rules.
> The implied extensions are enabled recursively, so we don't have to
> expand all of them manually. This also eliminates the old-fashioned
> ordering requirement. For example, Zvksg implies Zvks, Zvks implies
> Zvksed, etc., removing the need to check the implied rules of Zvksg
> before Zvks.
>
> Signed-off-by: Frank Chang 
> ---
>  target/riscv/tcg/tcg-cpu.c | 89 ++
>  1 file changed, 89 insertions(+)
>
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 683f604d9f..899d605d36 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -36,6 +36,9 @@
>  static GHashTable *multi_ext_user_opts;
>  static GHashTable *misa_ext_user_opts;
>
> +static GHashTable *misa_implied_rules;
> +static GHashTable *ext_implied_rules;
> +
>  static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
>  {
>  return g_hash_table_contains(multi_ext_user_opts,
> @@ -833,11 +836,95 @@ static void riscv_cpu_validate_profiles(RISCVCPU
> *cpu)
>  }
>  }
>
> +static void riscv_cpu_init_implied_exts_rules(void)
> +{
> +RISCVCPUImpliedExtsRule *rule;
> +int i;
> +
> +for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
> +g_hash_table_insert(misa_implied_rules,
> GUINT_TO_POINTER(rule->ext),
> +(gpointer)rule);
> +}
> +
> +for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
> +g_hash_table_insert(ext_implied_rules,
> GUINT_TO_POINTER(rule->ext),
> +(gpointer)rule);
> +}
> +}
> +
> +static void cpu_enable_implied_rule(RISCVCPU *cpu,
> +RISCVCPUImpliedExtsRule *rule)
> +{
> +CPURISCVState *env = >env;
> +RISCVCPUImpliedExtsRule *ir;
> +target_ulong hartid = 0;
> +int i;
> +
> +#if !defined(CONFIG_USER_ONLY)
> +hartid = env->mhartid;
> +#endif
> +
> +if (!(rule->enabled & BIT_ULL(hartid))) {
> +/* Enable the implied MISAs. */
> +if (rule->implied_misas) {
> +riscv_cpu_set_misa_ext(env, env->misa_ext |
> rule->implied_misas);
> +
> +for (i = 0; misa_bits[i] != 0; i++) {
> +if (rule->implied_misas & misa_bits[i]) {
> +ir = g_hash_table_lookup(misa_implied_rules,
> +
>  GUINT_TO_POINTER(misa_bits[i]));
> +
> +if (ir) {
> +cpu_enable_implied_rule(cpu, ir);
> +}
> +}
> +}
> +}
> +
> +/* Enable the implied extensions. */
> +for (i = 0; rule->implied_exts[i] != RISCV_IMPLIED_EXTS_RULE_END;
> i++) {
> +cpu_cfg_ext_auto_update(cpu, rule->implied_exts[i], true);
> +
> +ir = g_hash_table_lookup(ext_implied_rules,
> +
>  GUINT_TO_POINTER(rule->implied_exts[i]));
> +
> +if (ir) {
> +cpu_enable_implied_rule(cpu, ir);
> +}
> +}
> +
> +rule->enabled |= BIT_ULL(hartid);
>

Should I use the qatomic API here to set the enabled bitmask?

This wouldn't impact the results but it may cause the implied rules
to be traversed and re-enabled (which has no harm) if the enabled bit
of a hart is accidentally cleared by another harts.


> +}
> +}
> +
> +static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
> +{
> +RISCVCPUImpliedExtsRule *rule;
> +int i;
> +
> +/* Enable the implied MISAs. */
> +for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
> +if (riscv_has_ext(>env, rule->ext)) {
> +cpu_enable_implied_rule(cpu, rule);
> +}
> +}
> +
> +/* Enable the implied extensions. */
> +for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
> +if (isa_ext_is_enabled(cpu, rule->ext)) {
> +cpu_enable_implied_rule(cpu, rule);
> +}
> +}
> +}
> +
>  void riscv_tcg_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
>  {
>  CPURISCVState *env = >env;
>  Error *local_err = NULL;
>
> +riscv_cpu_init_implied_exts_rules();
> +riscv_cpu_enable_implied_rules(cpu);
> +
>  riscv_cpu_validate_misa_priv(env, _err);
>  if (local_err != NULL) {
>  error_propagate(errp, local_err);
> @@ -1343,6 +1430,8 @@ static void riscv_tcg_cpu_instance_init(CPUState *cs)
>
>  misa_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
>  multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
> +misa_implied_rules = g_hash_table_new(NULL, g_direct_equal);
> +ext_implied_rules = g_hash_table_new(NULL, g_direct_equal);
>  riscv_cpu_add_user_properties(obj);
>
>  if (riscv_cpu_has_max_extensions(obj)) {
> --
> 2.43.2
>
>

Re: make dist considered harmful: odd gotcha with building elfutils rpms

[Frank Ch. Eigler]

Hi -

> That is certainly a bug, dist targets shouldn't be conditional.

Thanks!

> [...]
> >   But I think the root cause is more the continued reliance
> > on "make dist", made necessary by the exclusion of generated autoconf*
> > materiel in the source tree.
> 
> I really don't think putting generated file into git is a good idea.
> You get all those issues that gcc, binutils and gdb have where you need
> all this extra CI just to make sure people use the "correct" tools to
> regenerate the files.

That need always seemed overstated.  The tools are "correct" if they
work (to configure/build elfutils on the platforms & configurations of
interest), even if they are not the freshest upstream or a particular
distro version.  If some developer manages to push in an
unsatisfactory version, any other developer (or a bot) can regen and
fix it.  It seems to me a non-problem.

- FChE

make dist considered harmful: odd gotcha with building elfutils rpms

[Frank Ch. Eigler]

Hi -

While trying to get a reliable fedora-copr build of the git/master
snapshot of elfutils, I ran into a problem that took me too long to
figure out.  I was running "make rpm" from an elfutils build tree,
which involves running a "make dist" substep to produce a complete
buildable source tarball (with all the autoconf* stuff included).  Or
rather, "complete"  since the behaviour of "make dist" is itself
dependent on the previous configure and thus the characteristics of
the host.

On this particular host, I was testing json-c-devel-less debuginfod
configuration recently, and didn't reinstall some library or other.
When "make rpm" ran "make dist" on elfutils, the resulting tarball was
NOT COMPLETE, because the doc/Makefile.am only conditionally adds some
of the man pages.

That might have been fine, if the machine on which the tarball/srpm
would finally build were of the same configuration, but that's not the
case.  That one was a fully (json-c-devel) equipped box.  So when the
configure ran there, the make configury expected the doc/debuginfod.8
file in the sources, but it wasn't there.  Build failed.

A workaround this could be to unconditionalize all those "notrans"
"dist" bits in doc/Makefile.am (and hope that the rest of the tree
behaves).  But I think the root cause is more the continued reliance
on "make dist", made necessary by the exclusion of generated autoconf*
materiel in the source tree.  (In these SBOM days, a source tarball
that crypto traceable to a git tag would also be welcome, but the
current auto* exclusion policy does not enable that either.)

Perhaps it's time to reconsider this policy.

- FChE

Re: [klee-dev] Reducing the Number of .ktest Files Generated for Longest Execution Paths

[Frank Busse]

Hi,


On Tue, 11 Jun 2024 11:41:34 +
Sun  wrote:

> When running Klee on various programs, I notice that it generates a
> `.ktest` file for each explored execution path. For my current
> project's scope, this behavior results in excessive data, most of
> which is not relevant to my needs. Specifically, I am interested in
> only retaining the `.ktest` files for the ten longest execution
> paths, which are most relevant to my analysis.

typically one would use, e.g.:

--only-output-states-covering-new

to reduce the number of generated ktest files.

> Could you please advise:
> 1. Is there an existing command-line option or configuration setting
> in Klee that allows for limiting the generation of `.ktest` files to
> only the longest paths?
> 2. If no such setting exists, could you point
> me towards the parts of Klee's source code where modifications might
> be implemented to achieve this functionality?

How would you now the lengths of the longest paths in advance?

You could modify shouldWriteTest in the Executor:
https://github.com/klee/klee/blob/ad557cb0f8e20a0e4a86ea5fcd11ed95f5c3b637/lib/Core/Executor.cpp#L3788

The depth is in the ExecutionState:
https://github.com/klee/klee/blob/ad557cb0f8e20a0e4a86ea5fcd11ed95f5c3b637/lib/Core/ExecutionState.h#L180


Kind regards,

Frank

___
klee-dev mailing list
klee-dev@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev

[ceph-users] Re: Documentation for meaning of "tag cephfs" in OSD caps

[Frank Schilder]

There is a tiny bit more to it. The idea is that, when adding a data pool, any 
cephfs client can access the new pool without changing and updating the caps. 
To this end, the fs-caps must include 2 pieces of information, the application 
name "cephfs" and the file system name (ceph can have multiple file systems). 
Any cephfs enabled pool with the correct file system name will be accessible to 
a properly authorized client of that file system without having to add that 
pool to the client caps explicitly, as was necessary in older versions.

The 2 pieces of information are provided like:

application name cephfs: "tag cephfs"
file system name: "data=con-fs2"

One can check what is encoded for each pool using

ceph osd pool ls detail --format=json | jq '.[] | .pool_name, 
.application_metadata'

For a ceph-fs pool, it will look something like

"con-fs2-data2"
{
  "cephfs": {
"data": "con-fs2"
  }
}

As of today, it seems indeed undocumented black magic and you need to search 
very carefully to find ceph-user cases that discuss (issues with) these tags, 
thereby explaining it as a side effect.

Best regards,
=
Frank Schilder
AIT Risø Campus
Bygning 109, rum S14


From: Eugen Block 
Sent: Tuesday, June 11, 2024 2:14 PM
To: ceph-users@ceph.io
Subject: [ceph-users] Re: Documentation for meaning of "tag cephfs" in OSD caps

I assume it means that pools with an enabled application "cephfs" can
be targeted by specifying this tag instead of listing each pool
separately. Browsing through the code [1] seems to confirm that
(somehow, I'm not a dev):

> if (g.match.pool_tag.application == ng.match.pool_tag.application

But I agree, it's worth adding that to the docs.

[1]
https://github.com/ceph/ceph/blob/09e81319648dd504cfd94edfdd321c7163cefa98/src/osd/OSDCap.cc#L549

Zitat von Petr Bena :

> Hello
>
> In https://docs.ceph.com/en/latest/cephfs/client-auth/ we can find that
>
> ceph fs authorize cephfs_a client.foo / r /bar rw Results in
>
> client.foo
>   key: *key*
>   caps:  [mds]  allow  r,  allow  rw  path=/bar
>   caps:  [mon]  allow  r
>   caps:  [osd]  allow  rw  tag  cephfs  data=cephfs_a
>
>
> What is this "tag cephfs" thing? It seems like some undocumented
> black magic to me, since I can't find anything that documents it.
> Can someone explain how it works under the hood? What does it expand
> to? What does it limit and how?
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io


___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[Bug 2052707] Re: [24.04 FEAT] bump powerpc-utils to version 1.3.12

[Frank Heimes]

** Changed in: ubuntu-power-systems
 Assignee: Skipper Bug Screeners (skipper-screen-team) => Ubuntu on IBM 
Power Systems Bug Triage (ubuntu-power-triage)

** Changed in: ubuntu-power-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2052707

Title:
  [24.04 FEAT] bump powerpc-utils to version 1.3.12

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2052707/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069040] [NEW] Compile glibc for Power9

[Frank Heimes]

Public bug reported:

The architectural level set for ppc64el is generally Power 9.
But it turned out that glibc is still compiled for Power 8.
This should be changed to Power 9.

** Affects: ubuntu-power-systems
 Importance: Undecided
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
 Status: New

** Affects: glibc (Ubuntu)
 Importance: Undecided
 Assignee: Simon Chopin (schopin)
 Status: New


** Tags: ppc64el

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069040

Title:
  Compile glibc for Power9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2069040/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2069035] Re: [24.10] Please test secure-boot and lockdown on the 6.10 kernel (s390x) for Oracular

[Frank Heimes]

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => bugproxy (bugproxy)

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

** Tags added: reverse-proxy-bugzilla s390x

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2069035

Title:
  [24.10] Please test secure-boot and lockdown on the 6.10 kernel
  (s390x) for Oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2069035/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[QGIS-Developer] Is it allowed to sell data in a QGIS plugin?

[Christopher Frank via QGIS-Developer]

Hi,

 

We have developed a QGIS plugin that requires various geospatial data. Our company offers the relevant geospatial data in a packed way and charges a few euros for it.



 

We would like to implement in the plugin the whole order process, open source of course. The user will feel like shoping the data in a geoshop. To provide the necessary information we communicate with an api of a real geoshop. Before we start to implement this idea, we would like to be sure that this is allowed.

 

Kind regards an thx in advance. 

Chris Steimann


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[ccp4bb] Antiviral Open Science Forum: 19 June 4pm BST

[Frank von Delft]

Hello, for those of you interested in line-of-sight to clinic, the next 
Antiviral Open Science Forum should be particularly interesting:


https://asapdiscovery.org/forum/#2024-jun

Weds 19 June @ 4pm BST (11am EST).

Sign up to get the link.

 * *John Pottage, Jr.
   <https://www.intrepidalliance.org/leadership/john-pottage-jr/> and
   Jim Demarest
   <https://www.intrepidalliance.org/leadership/jim-demarest/>
   (Intrepid Alliance <https://www.intrepidalliance.org/>)*: /Antiviral
   Target Compound Profile (TCP) for Pandemic Preparedness/
 * *Ed J. Griffen
   <https://scholar.google.co.uk/citations?user=i5FIoI8J=en>
   (MedChemica <https://www.medchemica.com/>) (ASAP
   <http://asapdiscovery.org>)* : /The Open Science Discovery of
   DNDi-6510: An orally bioavailable SARS-CoV-2 antiviral/

Ed's talk is a key output of the COVID Moonshot, which a whole lot of 
you helped with.


Cheers

Frank





To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [PATCH RESEND 1/6] target/riscv: Introduce extension implied rules definition

[Frank Chang]

Hi Alistair,

On Tue, Jun 11, 2024 at 9:35 AM Alistair Francis 
wrote:

> On Wed, Jun 5, 2024 at 4:35 PM  wrote:
> >
> > From: Frank Chang 
> >
> > RISCVCPUImpliedExtsRule is created to store the implied rules.
> > 'is_misa' flag is used to distinguish whether the rule is derived
> > from the MISA or other extensions.
> > 'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores
> > the offset of the extension defined in RISCVCPUConfig. 'ext' will also
> > serve as the key of the hash tables to look up the rule in the following
> > commit.
> >
> > Signed-off-by: Frank Chang 
> > ---
> >  target/riscv/cpu.c |  8 
> >  target/riscv/cpu.h | 18 ++
> >  2 files changed, 26 insertions(+)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index cee6fc4a9a..c7e5cec7ef 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -2242,6 +2242,14 @@ RISCVCPUProfile *riscv_profiles[] = {
> >  NULL,
> >  };
> >
> > +RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
> > +NULL
> > +};
> > +
> > +RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
> > +NULL
> > +};
> > +
> >  static Property riscv_cpu_properties[] = {
> >  DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
> >
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index 1501868008..b5a036cf27 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -122,6 +122,24 @@ typedef enum {
> >  EXT_STATUS_DIRTY,
> >  } RISCVExtStatus;
> >
> > +typedef struct riscv_cpu_implied_exts_rule RISCVCPUImpliedExtsRule;
> > +
> > +struct riscv_cpu_implied_exts_rule {
> > +/* Bitmask indicates the rule enabled status for the harts. */
> > +uint64_t enabled;
>
> I'm not clear why we need this
>

This is because a rule may be implied more than once.
e.g. Zcf implies RVF, Zfa also implies RVF.
There's no need to check RVF's implied rule again for Zfa after Zcf's
implied rules are enabled.

The implied rules are checked recursively, so once the rule has been
enabled (per-CPU basis),
the rule (and all its implied rules) will not be rechecked.

Regards,
Frank Chang


> Alistair
>
> > +/* True if this is a MISA implied rule. */
> > +bool is_misa;
> > +/* ext is MISA bit if is_misa flag is true, else extension offset.
> */
> > +const uint32_t ext;
> > +const uint32_t implied_misas;
> > +const uint32_t implied_exts[];
> > +};
> > +
> > +extern RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[];
> > +extern RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[];
> > +
> > +#define RISCV_IMPLIED_EXTS_RULE_END -1
> > +
> >  #define MMU_USER_IDX 3
> >
> >  #define MAX_RISCV_PMPS (16)
> > --
> > 2.43.2
> >
> >
>

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Sun, Jun 09, 2024 at 05:13:46PM -0500 schrieb Dale:

> Frank Steinmetzger wrote:
> > Am Samstag, 8. Juni 2024, 19:46:05 MESZ schrieb Dale:
> >
> >>>> Sadly, the CPU I got is for processing only, no video support it says.
> >>> So you got an F model?
> >> I got the X model.  It's supposed to be a wttle bit faster.  o_O
> > Well as we have been mentioning several times by now: starting with AM5 
> > CPUs, 
> > the X models all have integrated graphics. Where does what say “no video 
> > support” and in which context?
> >
> 
> 
> I found it on the AMD website.  The CPU I got is a AM4.  Linky.
> 
> https://www.amd.com/en/products/processors/desktops/ryzen/5000-series/amd-ryzen-7-5800x.html
> 
> From that:
> 
> Graphics Model        Discrete Graphics Card Required
> 
> I think the G model has graphics, but gives up a little speed.  Or as I
> put it above, a wiiile bit.  LOL 

Oky, are you sure? The 5800 is an AM4 CPU. Up until now in this thread, 
you were talking of AM5 (i.e. 7000-series CPU with a 600-series Mobo 
chipset and DDR5). The 5800X does not fit into this at all. Just sayin’.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Sugar is what gives coffee a sour taste, if you forget to put it in.


signature.asc
Description: PGP signature

[Github-comments] Re: [geany/www.geany.org] Try to more explicit state SEPA only for bank transfers (PR #50)

[Frank Lanitz via Github-comments]

@frlan commented on this pull request.



> @@ -16,7 +16,7 @@ More than financial support, the Geany project needs help 
> with:
 If you want to donate money to the Geany project, it will be used to support 
further development of Geany, to pay running costs for hosting and domains and 
support presenting Geany on various [Open Source Conferences][5].
 
 There are different options to donate, including bank transfer and Liberapay.
-Bank transfer to the [Geany e.V.][8] account is the preferred way for donating 
money as the money is transferred directly without a third party involved and 
additional fees can be avoided.
+Bank transfer to the [Geany e.V.][8] account (only SEPA / Europe) is the 
preferred way for donating money as the money is transferred directly without a 
third party involved and additional fees can be avoided.

Just saw the comment -- github is just way to noisy by default. Will update it 
next chance. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/www.geany.org/pull/50#discussion_r1633851484
You are receiving this because you are subscribed to this thread.

Message ID: 

[Github-comments] Re: [geany/geany-plugins] Spellcheck: remove obsolete gtk check version (PR #1360)

[Frank Lanitz via Github-comments]

Merged #1360 into master.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1360#event-13107632663
You are receiving this because you are subscribed to this thread.

Message ID: 

Re: [FFmpeg-devel] [PATCH] fate/vvc: add vvc-conformance-RPR_A_Alibaba_4

[Frank Plowman]

On 10/06/2024 18:31, James Almer wrote:
> On 6/10/2024 2:23 PM, Frank Plowman wrote:
>> On 10/06/2024 14:26, Nuo Mi wrote:
>>> Hi Frank,
>>> Thank you for the patch.
>>> Could we follow the naming conventions used for other clips?
>>>
>> Hi,
>>
>> I did it this way because I do not have access to the FATE server, so
>> somebody had to upload the clip for me and I felt it was easier if they
>> did not have to rename the clip.  Also there is already a mixture of VVC
>> clip titles with and without the vendor's name.
>>
>> If someone renames the clip on the FATE server it is easy to send a v2.
> 
> I just renamed it to RPR_A_4.bit

Thank you James.  v2 sent.

-- 
Frank
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] fate/vvc: add vvc-conformance-RPR_A_4

[Frank Plowman]

  BeforeAfter
-
make fate-vvc CPU Time (No ASM)  131.52s  134.83s
libavcodec/vvc/* Line Coverage 95.3%96.9%
inter_template.c Line Coverage 74.3%88.2%
inter.c Line Coverage  85.3%99.2%

Signed-off-by: Frank Plowman 
---
 tests/fate/vvc.mak | 1 +
 tests/ref/fate/vvc-conformance-RPR_A_4 | 9 +
 2 files changed, 10 insertions(+)
 create mode 100644 tests/ref/fate/vvc-conformance-RPR_A_4

diff --git a/tests/fate/vvc.mak b/tests/fate/vvc.mak
index 0ff287eea6..3e762ec65e 100644
--- a/tests/fate/vvc.mak
+++ b/tests/fate/vvc.mak
@@ -14,6 +14,7 @@ VVC_SAMPLES_10BIT =   \
 POC_A_1   \
 PPS_B_1   \
 RAP_A_1   \
+RPR_A_4   \
 SAO_A_3   \
 SCALING_A_1   \
 SLICES_A_3\
diff --git a/tests/ref/fate/vvc-conformance-RPR_A_4 
b/tests/ref/fate/vvc-conformance-RPR_A_4
new file mode 100644
index 00..58ae0f3861
--- /dev/null
+++ b/tests/ref/fate/vvc-conformance-RPR_A_4
@@ -0,0 +1,9 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 832x480
+#sar 0: 0/1
+0,  0,  0,1,  1198080, 0x2c12c2be
+0,  1,  1,1,  1198080, 0x47275378
+0,  2,  2,1,  1198080, 0x5d7b0327
+0,  3,  3,1,  1198080, 0x0b15318a
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] fate/vvc: add vvc-conformance-RPR_A_Alibaba_4

[Frank Plowman]

On 10/06/2024 14:26, Nuo Mi wrote:
> Hi Frank,
> Thank you for the patch.
> Could we follow the naming conventions used for other clips?
> 
Hi,

I did it this way because I do not have access to the FATE server, so
somebody had to upload the clip for me and I felt it was easier if they
did not have to rename the clip.  Also there is already a mixture of VVC
clip titles with and without the vendor's name.

If someone renames the clip on the FATE server it is easy to send a v2.

Cheers,
--
Frank
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[PATCH v3 1/1] dt-bindings: remoteproc: imx_rproc: add minItems for power-domain

[Frank Li]

"fsl,imx8qxp-cm4" and "fsl,imx8qm-cm4" need minimum 2 power domains. Other
platform doesn't require 'power-domain'.

Signed-off-by: Frank Li 
---

Notes:
Change from v2 to v3
- only imx8qxp and imx8qm need power-domain, other platform don't need it.
- update commit message.

Change from v1 to v2
- set minitem to 2 at top
- Add imx8qm compatible string also
- use not logic to handle difference compatible string restriction
- update commit message.

pass dt_binding_check.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check 
DT_SCHEMA_FILES=fsl,imx-rproc.yaml
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  CHKDT   Documentation/devicetree/bindings
  LINTDocumentation/devicetree/bindings
  DTEX
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dts
  DTC_CHK 
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dtb

 .../bindings/remoteproc/fsl,imx-rproc.yaml| 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index df36e29d974ca..57d75acb0b5e5 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -59,6 +59,7 @@ properties:
 maxItems: 32
 
   power-domains:
+minItems: 2
 maxItems: 8
 
   fsl,auto-boot:
@@ -99,6 +100,20 @@ allOf:
   properties:
 fsl,iomuxc-gpr: false
 
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - fsl,imx8qxp-cm4
+  - fsl,imx8qm-cm4
+then:
+  required:
+- power-domains
+else:
+  properties:
+power-domains: false
+
 additionalProperties: false
 
 examples:
-- 
2.34.1

[kmail2] [Bug 483779] KMail hangs when invoking "Configure KMail..."

[Peer Frank]

https://bugs.kde.org/show_bug.cgi?id=483779

--- Comment #6 from Peer Frank  ---
meanwhile the problem seems resolved on my system
(kmail Version 6.1.0 (24.05.0) framework 6.2.0)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 483779] KMail hangs when invoking "Configure KMail..."

[Peer Frank]

https://bugs.kde.org/show_bug.cgi?id=483779

--- Comment #6 from Peer Frank  ---
meanwhile the problem seems resolved on my system
(kmail Version 6.1.0 (24.05.0) framework 6.2.0)

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

[Bug 2067355] Re: Update s390-tools to (currently latest) v2.33.1 in oracular

[Frank Heimes]

I've worked on some more lintian warning, polishing the package a bit more and 
have now an updated debdiff (just for s390-tools; s390-tools-signed didn't 
change):
https://launchpadlibrarian.net/734514167/s390-tools_2.31.0-0ubuntu5_2.33.1-0ubuntu1.diff.gz
and also did a new test build in PPA that is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp2067355/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067355

Title:
  Update s390-tools to (currently latest) v2.33.1 in oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2067355/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Samstag, 8. Juni 2024, 15:40:48 MESZ schrieb Meowie Gamer:

> vim has a WHAT?! You gotta tell me how to use that.

Digraphs are graphs (i.e. characters) that are entered using two other 
characters. Basically it’s the same principle as the X11 compose key, but 
specific to vim. If you enter :dig[raph], you get a list of all defined such 
digraphs. The output of the ga command (print ascii info) includes the digraph 
combo, if one exists for the highlighted character. The unicode plugin behaves 
similarly. You can also define your own.

The feature is used in insert mode and triggered with , after which you 
press the two characters.

For example, there are predefined digraphs for Cyrillic, Greek and Japanese 
Hiragana and Katakana. And you can paint boxes easily thanks to the mnemonics 
involved. A lowercase character denotes a thin line, an uppercase a thick 
line. The characters themselves signify the “direction” of the line; u=up, 
r=right, l=left, d=down, v=vertical, h=horizontal. So to paint a thin vertical 
light with a thick line branching to the right, you press vR: ┝.

See :help dig for more.
-- 
“Privacy laws are our biggest impediment to us obtaining our
objectives.” — Michael Eisner, CEO of Disney, 2001

[FFmpeg-devel] [PATCH] fate/vvc: add vvc-conformance-RPR_A_Alibaba_4

[Frank Plowman]

  BeforeAfter
-
make fate-vvc CPU Time (No ASM)  131.52s  134.83s
libavcodec/vvc/* Line Coverage 95.3%96.9%
inter_template.c Line Coverage 74.3%88.2%
inter.c Line Coverage  85.3%99.2%

Signed-off-by: Frank Plowman 
---
 tests/fate/vvc.mak | 1 +
 tests/ref/fate/vvc-conformance-RPR_A_Alibaba_4 | 9 +
 2 files changed, 10 insertions(+)
 create mode 100644 tests/ref/fate/vvc-conformance-RPR_A_Alibaba_4

diff --git a/tests/fate/vvc.mak b/tests/fate/vvc.mak
index 0ff287eea6..93b86f15f0 100644
--- a/tests/fate/vvc.mak
+++ b/tests/fate/vvc.mak
@@ -14,6 +14,7 @@ VVC_SAMPLES_10BIT =   \
 POC_A_1   \
 PPS_B_1   \
 RAP_A_1   \
+RPR_A_Alibaba_4   \
 SAO_A_3   \
 SCALING_A_1   \
 SLICES_A_3\
diff --git a/tests/ref/fate/vvc-conformance-RPR_A_Alibaba_4 
b/tests/ref/fate/vvc-conformance-RPR_A_Alibaba_4
new file mode 100644
index 00..58ae0f3861
--- /dev/null
+++ b/tests/ref/fate/vvc-conformance-RPR_A_Alibaba_4
@@ -0,0 +1,9 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 832x480
+#sar 0: 0/1
+0,  0,  0,1,  1198080, 0x2c12c2be
+0,  1,  1,1,  1198080, 0x47275378
+0,  2,  2,1,  1198080, 0x5d7b0327
+0,  3,  3,1,  1198080, 0x0b15318a
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Samstag, 8. Juni 2024, 19:46:05 MESZ schrieb Dale:

> >> Sadly, the CPU I got is for processing only, no video support it says.
> > 
> > So you got an F model?
> 
> I got the X model.  It's supposed to be a wttle bit faster.  o_O

Well as we have been mentioning several times by now: starting with AM5 CPUs, 
the X models all have integrated graphics. Where does what say “no video 
support” and in which context?

-- 
An empty head is easier to nod with.

[FFmpeg-devel] [PATCH v4] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Additionally, don't discard the return code from sps_chroma_qp_table.

Signed-off-by: Frank Plowman 
---
Changes since v3:
* Add comment noting why qp_{in,out} are not tested themselves.

 libavcodec/vvc/ps.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..92368eafc2 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+// Note: we cannot check qp_{in,out}[j+1] here as qp_*[j] + 
delta_qp_*
+//   may not fit in an 8-bit signed integer.
+if (qp_in[j] + delta_qp_in[j] > 63 || qp_out[j] + delta_qp_out > 
63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
@@ -186,8 +191,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [PATCH v3 11/13] hw/riscv/riscv-iommu: add DBG support

[Frank Chang]

Reviewed-by: Frank Chang 

Daniel Henrique Barboza  於 2024年5月24日 週五 上午1:42寫道：
>
> From: Tomasz Jeznach 
>
> DBG support adds three additional registers: tr_req_iova, tr_req_ctl and
> tr_response.
>
> The DBG cap is always enabled. No on/off toggle is provided for it.
>
> Signed-off-by: Tomasz Jeznach 
> Signed-off-by: Daniel Henrique Barboza 
> ---
>  hw/riscv/riscv-iommu-bits.h | 17 +++
>  hw/riscv/riscv-iommu.c  | 59 +
>  2 files changed, 76 insertions(+)
>
> diff --git a/hw/riscv/riscv-iommu-bits.h b/hw/riscv/riscv-iommu-bits.h
> index e253b29b16..f143c4a926 100644
> --- a/hw/riscv/riscv-iommu-bits.h
> +++ b/hw/riscv/riscv-iommu-bits.h
> @@ -84,6 +84,7 @@ struct riscv_iommu_pq_record {
>  #define RISCV_IOMMU_CAP_ATS BIT_ULL(25)
>  #define RISCV_IOMMU_CAP_T2GPA   BIT_ULL(26)
>  #define RISCV_IOMMU_CAP_IGS GENMASK_ULL(29, 28)
> +#define RISCV_IOMMU_CAP_DBG BIT_ULL(31)
>  #define RISCV_IOMMU_CAP_PAS GENMASK_ULL(37, 32)
>  #define RISCV_IOMMU_CAP_PD8 BIT_ULL(38)
>  #define RISCV_IOMMU_CAP_PD17BIT_ULL(39)
> @@ -185,6 +186,22 @@ enum {
>  RISCV_IOMMU_INTR_COUNT
>  };
>
> +/* 5.24 Translation request IOVA (64bits) */
> +#define RISCV_IOMMU_REG_TR_REQ_IOVA 0x0258
> +
> +/* 5.25 Translation request control (64bits) */
> +#define RISCV_IOMMU_REG_TR_REQ_CTL  0x0260
> +#define RISCV_IOMMU_TR_REQ_CTL_GO_BUSY  BIT_ULL(0)
> +#define RISCV_IOMMU_TR_REQ_CTL_NW   BIT_ULL(3)
> +#define RISCV_IOMMU_TR_REQ_CTL_PID  GENMASK_ULL(31, 12)
> +#define RISCV_IOMMU_TR_REQ_CTL_DID  GENMASK_ULL(63, 40)
> +
> +/* 5.26 Translation request response (64bits) */
> +#define RISCV_IOMMU_REG_TR_RESPONSE 0x0268
> +#define RISCV_IOMMU_TR_RESPONSE_FAULT   BIT_ULL(0)
> +#define RISCV_IOMMU_TR_RESPONSE_S   BIT_ULL(9)
> +#define RISCV_IOMMU_TR_RESPONSE_PPN RISCV_IOMMU_PPN_FIELD
> +
>  /* 5.27 Interrupt cause to vector (64bits) */
>  #define RISCV_IOMMU_REG_IVEC0x02F8
>
> diff --git a/hw/riscv/riscv-iommu.c b/hw/riscv/riscv-iommu.c
> index 3516b82081..52f0851895 100644
> --- a/hw/riscv/riscv-iommu.c
> +++ b/hw/riscv/riscv-iommu.c
> @@ -1655,6 +1655,50 @@ static void 
> riscv_iommu_process_pq_control(RISCVIOMMUState *s)
>  riscv_iommu_reg_mod32(s, RISCV_IOMMU_REG_PQCSR, ctrl_set, ctrl_clr);
>  }
>
> +static void riscv_iommu_process_dbg(RISCVIOMMUState *s)
> +{
> +uint64_t iova = riscv_iommu_reg_get64(s, RISCV_IOMMU_REG_TR_REQ_IOVA);
> +uint64_t ctrl = riscv_iommu_reg_get64(s, RISCV_IOMMU_REG_TR_REQ_CTL);
> +unsigned devid = get_field(ctrl, RISCV_IOMMU_TR_REQ_CTL_DID);
> +unsigned pid = get_field(ctrl, RISCV_IOMMU_TR_REQ_CTL_PID);
> +RISCVIOMMUContext *ctx;
> +void *ref;
> +
> +if (!(ctrl & RISCV_IOMMU_TR_REQ_CTL_GO_BUSY)) {
> +return;
> +}
> +
> +ctx = riscv_iommu_ctx(s, devid, pid, );
> +if (ctx == NULL) {
> +riscv_iommu_reg_set64(s, RISCV_IOMMU_REG_TR_RESPONSE,
> + RISCV_IOMMU_TR_RESPONSE_FAULT |
> + (RISCV_IOMMU_FQ_CAUSE_DMA_DISABLED << 10));
> +} else {
> +IOMMUTLBEntry iotlb = {
> +.iova = iova,
> +.perm = ctrl & RISCV_IOMMU_TR_REQ_CTL_NW ? IOMMU_RO : IOMMU_RW,
> +.addr_mask = ~0,
> +.target_as = NULL,
> +};
> +int fault = riscv_iommu_translate(s, ctx, , false);
> +if (fault) {
> +iova = RISCV_IOMMU_TR_RESPONSE_FAULT | (((uint64_t) fault) << 
> 10);
> +} else {
> +iova = iotlb.translated_addr & ~iotlb.addr_mask;
> +iova >>= TARGET_PAGE_BITS;
> +iova &= RISCV_IOMMU_TR_RESPONSE_PPN;
> +
> +/* We do not support superpages (> 4kbs) for now */
> +iova &= ~RISCV_IOMMU_TR_RESPONSE_S;
> +}
> +riscv_iommu_reg_set64(s, RISCV_IOMMU_REG_TR_RESPONSE, iova);
> +}
> +
> +riscv_iommu_reg_mod64(s, RISCV_IOMMU_REG_TR_REQ_CTL, 0,
> +RISCV_IOMMU_TR_REQ_CTL_GO_BUSY);
> +riscv_iommu_ctx_put(s, ref);
> +}
> +
>  typedef void riscv_iommu_process_fn(RISCVIOMMUState *s);
>
>  static void riscv_iommu_update_ipsr(RISCVIOMMUState *s, uint64_t data)
> @@ -1778,6 +1822,12 @@ static MemTxResult riscv_iommu_mmio_write(void 
> *opaque, hwaddr addr,
>
>  return MEMTX_OK;
>
> +case RISCV_IOMMU_REG_TR_REQ_CTL:
> +process_fn = riscv_iommu_process_dbg;
> +regb = RISCV_IOMMU_REG_TR_REQ_CTL;
> +busy = RISCV_IOMMU_TR_REQ_CTL_GO_BUSY;
> +break;
> +
>  defaul

Re: [PATCH v3 10/13] hw/riscv/riscv-iommu: add ATS support

[Frank Chang]

Reviewed-by: Frank Chang 

Daniel Henrique Barboza  於 2024年5月24日 週五 上午1:41寫道：
>
> From: Tomasz Jeznach 
>
> Add PCIe Address Translation Services (ATS) capabilities to the IOMMU.
> This will add support for ATS translation requests in Fault/Event
> queues, Page-request queue and IOATC invalidations.
>
> Signed-off-by: Tomasz Jeznach 
> Signed-off-by: Daniel Henrique Barboza 
> ---
>  hw/riscv/riscv-iommu-bits.h |  43 +++-
>  hw/riscv/riscv-iommu.c  | 129 +++-
>  hw/riscv/riscv-iommu.h  |   1 +
>  hw/riscv/trace-events   |   3 +
>  4 files changed, 173 insertions(+), 3 deletions(-)
>
> diff --git a/hw/riscv/riscv-iommu-bits.h b/hw/riscv/riscv-iommu-bits.h
> index a4def7b8ec..e253b29b16 100644
> --- a/hw/riscv/riscv-iommu-bits.h
> +++ b/hw/riscv/riscv-iommu-bits.h
> @@ -81,6 +81,7 @@ struct riscv_iommu_pq_record {
>  #define RISCV_IOMMU_CAP_SV57X4  BIT_ULL(19)
>  #define RISCV_IOMMU_CAP_MSI_FLATBIT_ULL(22)
>  #define RISCV_IOMMU_CAP_MSI_MRIFBIT_ULL(23)
> +#define RISCV_IOMMU_CAP_ATS BIT_ULL(25)
>  #define RISCV_IOMMU_CAP_T2GPA   BIT_ULL(26)
>  #define RISCV_IOMMU_CAP_IGS GENMASK_ULL(29, 28)
>  #define RISCV_IOMMU_CAP_PAS GENMASK_ULL(37, 32)
> @@ -209,6 +210,7 @@ struct riscv_iommu_dc {
>
>  /* Translation control fields */
>  #define RISCV_IOMMU_DC_TC_V BIT_ULL(0)
> +#define RISCV_IOMMU_DC_TC_EN_ATSBIT_ULL(1)
>  #define RISCV_IOMMU_DC_TC_EN_PRIBIT_ULL(2)
>  #define RISCV_IOMMU_DC_TC_T2GPA BIT_ULL(3)
>  #define RISCV_IOMMU_DC_TC_DTF   BIT_ULL(4)
> @@ -270,6 +272,20 @@ struct riscv_iommu_command {
>  #define RISCV_IOMMU_CMD_IODIR_DVBIT_ULL(33)
>  #define RISCV_IOMMU_CMD_IODIR_DID   GENMASK_ULL(63, 40)
>
> +/* 3.1.4 I/O MMU PCIe ATS */
> +#define RISCV_IOMMU_CMD_ATS_OPCODE  4
> +#define RISCV_IOMMU_CMD_ATS_FUNC_INVAL  0
> +#define RISCV_IOMMU_CMD_ATS_FUNC_PRGR   1
> +#define RISCV_IOMMU_CMD_ATS_PID GENMASK_ULL(31, 12)
> +#define RISCV_IOMMU_CMD_ATS_PV  BIT_ULL(32)
> +#define RISCV_IOMMU_CMD_ATS_DSV BIT_ULL(33)
> +#define RISCV_IOMMU_CMD_ATS_RID GENMASK_ULL(55, 40)
> +#define RISCV_IOMMU_CMD_ATS_DSEGGENMASK_ULL(63, 56)
> +/* dword1 is the ATS payload, two different payload types for INVAL and PRGR 
> */
> +
> +/* ATS.PRGR payload */
> +#define RISCV_IOMMU_CMD_ATS_PRGR_RESP_CODE  GENMASK_ULL(47, 44)
> +
>  enum riscv_iommu_dc_fsc_atp_modes {
>  RISCV_IOMMU_DC_FSC_MODE_BARE = 0,
>  RISCV_IOMMU_DC_FSC_IOSATP_MODE_SV32 = 8,
> @@ -334,7 +350,32 @@ enum riscv_iommu_fq_ttypes {
>  RISCV_IOMMU_FQ_TTYPE_TADDR_INST_FETCH = 5,
>  RISCV_IOMMU_FQ_TTYPE_TADDR_RD = 6,
>  RISCV_IOMMU_FQ_TTYPE_TADDR_WR = 7,
> -RISCV_IOMMU_FW_TTYPE_PCIE_MSG_REQ = 8,
> +RISCV_IOMMU_FQ_TTYPE_PCIE_ATS_REQ = 8,
> +RISCV_IOMMU_FW_TTYPE_PCIE_MSG_REQ = 9,
> +};
> +
> +/* Header fields */
> +#define RISCV_IOMMU_PREQ_HDR_PIDGENMASK_ULL(31, 12)
> +#define RISCV_IOMMU_PREQ_HDR_PV BIT_ULL(32)
> +#define RISCV_IOMMU_PREQ_HDR_PRIV   BIT_ULL(33)
> +#define RISCV_IOMMU_PREQ_HDR_EXEC   BIT_ULL(34)
> +#define RISCV_IOMMU_PREQ_HDR_DIDGENMASK_ULL(63, 40)
> +
> +/* Payload fields */
> +#define RISCV_IOMMU_PREQ_PAYLOAD_R  BIT_ULL(0)
> +#define RISCV_IOMMU_PREQ_PAYLOAD_W  BIT_ULL(1)
> +#define RISCV_IOMMU_PREQ_PAYLOAD_L  BIT_ULL(2)
> +#define RISCV_IOMMU_PREQ_PAYLOAD_M  GENMASK_ULL(2, 0)
> +#define RISCV_IOMMU_PREQ_PRG_INDEX  GENMASK_ULL(11, 3)
> +#define RISCV_IOMMU_PREQ_UADDR  GENMASK_ULL(63, 12)
> +
> +
> +/*
> + * struct riscv_iommu_msi_pte - MSI Page Table Entry
> + */
> +struct riscv_iommu_msi_pte {
> +  uint64_t pte;
> +  uint64_t mrif_info;
>  };
>
>  /* Fields on pte */
> diff --git a/hw/riscv/riscv-iommu.c b/hw/riscv/riscv-iommu.c
> index 11c418b548..3516b82081 100644
> --- a/hw/riscv/riscv-iommu.c
> +++ b/hw/riscv/riscv-iommu.c
> @@ -641,6 +641,20 @@ static bool 
> riscv_iommu_validate_device_ctx(RISCVIOMMUState *s,
>  RISCVIOMMUContext *ctx)
>  {
>  uint32_t fsc_mode, msi_mode;
> +uint64_t gatp;
> +
> +if (!(s->cap & RISCV_IOMMU_CAP_ATS) &&
> +(ctx->tc & RISCV_IOMMU_DC_TC_EN_ATS ||
> + ctx->tc & RISCV_IOMMU_DC_TC_EN_PRI ||
> + ctx->tc & RISCV_IOMMU_DC_TC_PRPR)) {
> +return false;
> +}
> +
> +if (!(ctx->tc & RISCV_IOMMU_DC_TC_EN_ATS) &&
> +(ctx->tc & RISCV_IOMMU_DC_TC_T2GPA ||
> + ctx->tc & R

Re: [PATCH v3 05/13] hw/riscv: add riscv-iommu-pci reference device

[Frank Chang]

gt; +pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY |
> + PCI_BASE_ADDRESS_MEM_TYPE_64, >bar0);
> +
> +int ret = msix_init(dev, RISCV_IOMMU_INTR_COUNT,
> +>bar0, 0, RISCV_IOMMU_REG_MSI_CONFIG,
> +>bar0, 0, RISCV_IOMMU_REG_MSI_CONFIG + 256, 0, 
> );
> +
> +if (ret == -ENOTSUP) {
> +/*
> + * MSI-x is not supported by the platform.
> + * Driver should use timer/polling based notification handlers.
> + */
> +warn_report_err(err);
> +} else if (ret < 0) {
> +error_propagate(errp, err);
> +return;
> +} else {
> +/* mark all allocated MSIx vectors as used. */
> +msix_vector_use(dev, RISCV_IOMMU_INTR_CQ);
> +msix_vector_use(dev, RISCV_IOMMU_INTR_FQ);
> +msix_vector_use(dev, RISCV_IOMMU_INTR_PM);
> +msix_vector_use(dev, RISCV_IOMMU_INTR_PQ);
> +iommu->notify = riscv_iommu_pci_notify;
> +}
> +
> +PCIBus *bus = pci_device_root_bus(dev);
> +if (!bus) {
> +error_setg(errp, "can't find PCIe root port for %02x:%02x.%x",
> +pci_bus_num(pci_get_bus(dev)), PCI_SLOT(dev->devfn),
> +PCI_FUNC(dev->devfn));
> +return;
> +}
> +
> +riscv_iommu_pci_setup_iommu(iommu, bus, errp);
> +}
> +
> +static void riscv_iommu_pci_exit(PCIDevice *pci_dev)
> +{
> +pci_setup_iommu(pci_device_root_bus(pci_dev), NULL, NULL);
> +}
> +
> +static const VMStateDescription riscv_iommu_vmstate = {
> +.name = "riscv-iommu",
> +.unmigratable = 1
> +};
> +
> +static void riscv_iommu_pci_init(Object *obj)
> +{
> +RISCVIOMMUStatePci *s = RISCV_IOMMU_PCI(obj);
> +RISCVIOMMUState *iommu = >iommu;
> +
> +object_initialize_child(obj, "iommu", iommu, TYPE_RISCV_IOMMU);
> +qdev_alias_all_properties(DEVICE(iommu), obj);
> +}
> +
> +static Property riscv_iommu_pci_properties[] = {
> +DEFINE_PROP_UINT16("vendor-id", RISCVIOMMUStatePci, vendor_id,
> +   PCI_VENDOR_ID_REDHAT),
> +DEFINE_PROP_UINT16("device-id", RISCVIOMMUStatePci, device_id,
> +   PCI_DEVICE_ID_REDHAT_RISCV_IOMMU),
> +DEFINE_PROP_UINT8("revision", RISCVIOMMUStatePci, revision, 0x01),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void riscv_iommu_pci_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> +k->realize = riscv_iommu_pci_realize;
> +k->exit = riscv_iommu_pci_exit;
> +k->class_id = 0x0806;

Replace 0x0806 with PCI_CLASS_SYSTEM_IOMMU.

Otherwise,
Reviewed-by: Frank Chang 

> +dc->desc = "RISCV-IOMMU DMA Remapping device";
> +dc->vmsd = _iommu_vmstate;
> +dc->hotpluggable = false;
> +dc->user_creatable = true;
> +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> +device_class_set_props(dc, riscv_iommu_pci_properties);
> +}
> +
> +static const TypeInfo riscv_iommu_pci = {
> +.name = TYPE_RISCV_IOMMU_PCI,
> +.parent = TYPE_PCI_DEVICE,
> +.class_init = riscv_iommu_pci_class_init,
> +.instance_init = riscv_iommu_pci_init,
> +.instance_size = sizeof(RISCVIOMMUStatePci),
> +.interfaces = (InterfaceInfo[]) {
> +{ INTERFACE_PCIE_DEVICE },
> +{ },
> +},
> +};
> +
> +static void riscv_iommu_register_pci_types(void)
> +{
> +type_register_static(_iommu_pci);
> +}
> +
> +type_init(riscv_iommu_register_pci_types);
> --
> 2.44.0
>
>

[Bug 2068820] [NEW] package thunderbird 2:1snap1-0ubuntu3 failed to install/upgrade: new thunderbird package pre-installation script subprocess returned error exit status 1

[Frank Prince]

Public bug reported:

Upgrade to 24.04 hung on updating thunderbird to snap.
Was unable to boot after upgrade was interrupted.
Booted to command line, enabled networking, initiated repair. Upgrade completed.
Was able to boot normally.
On first run of thunderbird got an error. Reported said I had two versions 
installed, snap and normal.
Reported this error against the snap.

ProblemType: Package
DistroRelease: Ubuntu 24.04
ProcVersionSignature: Ubuntu 6.8.0-35.35-generic 6.8.4
Uname: Linux 6.8.0-35-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.28.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Sat Jun  8 19:13:28 2024
ErrorMessage: new thunderbird package pre-installation script subprocess 
returned error exit status 1
InstallationDate: Installed on 2023-05-26 (380 days ago)
InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316)
Python3Details: /usr/bin/python3.12, Python 3.12.3, python3-minimal, 
3.12.3-0ubuntu1
PythonDetails: N/A
RelatedPackageVersions:
 dpkg 1.22.6ubuntu6
 apt  2.7.14build2
Snap: thunderbird 115.11.1-1 (stable)
SnapChanges:
 ID   Status  Spawn  Ready  Summary
 425  Done2024-06-09T00:47:49-04:00  2024-06-09T00:48:12-04:00  Install 
"thunderbird" snap
SnapSource: ubuntu/+source/thunderbird
Title: package thunderbird 2:1snap1-0ubuntu3 failed to install/upgrade: new 
thunderbird package pre-installation script subprocess returned error exit 
status 1
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: thunderbird (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package noble

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068820

Title:
  package thunderbird 2:1snap1-0ubuntu3 failed to install/upgrade: new
  thunderbird package pre-installation script subprocess returned error
  exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/2068820/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Samstag, 8. Juni 2024, 04:05:17 MESZ schrieb Dale:


> > DisplayPort supports daisy-chaining. So if you do get another monitor some
> > day, look for one that has this feature and you can drive two monitors
> > with
> > one port on the PC.
> 
> That's something I didn't know.  I wondered why they had that when a
> HDMI port is about the same size and can handle about the same
> resolution.  It has abilities HDMI doesn't.  Neat.  :-D

Polemically speaking, HDMI is designed for the concerns of the MAFIA (Music 
and Film Industry of America) with stuff like DRM. DisplayPort is technically 
the better protocol, for example with more bandwidth and it is open. There was 
news recently that the HDMI forum would not allow AMD to implement HDMI 2.1 in 
its open source driver, which means no 4K 120 Hz for Linux users.

> Sadly, the CPU I got is for processing only, no video support it says.

So you got an F model?

> > But what I also just remembered: only the ×16 GPU slot and the primary M.2
> > slots (which are often one gen faster than the other M.2 slots) are
> > connected to the CPU via dedicated links. All other PCIe slots are behind
> > the chipset. And that in turn is connected to the CPU via a PCIe 4.0×4
> > link. This is probably the technical reason why there are so few boards
> > with slots wider than ×4 – there is just no way to make use of them,
> > because they all most go through that ×4 bottleneck to the CPU.
> > 
> > ┌───┐ 5.0×4 ┌───┐ 4.0×4 ┌─┐   ┌───┐
> > │M.2┝===┥CPU┝━━━┥ Chipset ┝━━━┥M.2│
> > └───┘   └─┰─┘   └─┰─┰─┘   └───┘
> > 
> > 5.0×16┃   ┃ ┃
> > 
> > ┌─┸─┐┌┸─┐ ┌─┸┐
> > │GPU││PCIe 1│ │PCIe 2│
> > └───┘└──┘ └──┘
> > […]
> 
> Nice block diagram.  You use software to make that?

Yes, vim’s builtin digraph feature. O:-)

-- 
Team work:
Everyone does what he wants, nobody does what he should, and all play along.

[exim] Re: [exim-announce] Exim 4.98-RC0 released

[Frank Elsner via Exim-users]

On Fri, 7 Jun 2024 23:41:11 +0100 Jeremy Harris via Exim-users wrote:
> On 07/06/2024 22:51, Frank Elsner via Exim-users wrote:
> > dns.c: In function ‘dns_lookup’:
> > dns.c:1143:9: error: ‘event_action’ undeclared (first use in this 
> > function); did you mean ‘queue_action’?
> >   1143 | s = event_action;
> 
> OK, that's a bug.  You're building with DISABLE_EVENTS defined.  Thanks
> for finding this.  You could leave the events facility included, or
> wait for the next RC, or comment out lines 1138-1169 of dns.c
> (retain the "return rc;" only.

Ok, thanks so far. I will curb my impatience and wait for the next RC.


--Frank

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Re: [exim-announce] Exim 4.98-RC0 released

[Frank Elsner via Exim-users]

On Fri, 7 Jun 2024 22:27:06 +0100 Jeremy Harris via Exim-users wrote:
  [ ... ]

> The default set for these hints-databases is in the OS/Makefile-
> (Linux, for your case).  Look for USE_ and DBMLIB.
> Those defaults can be overidden by settings in your Local/Makefile.
> 
> The USE_* and the DBMLIB need to be consistent.

The problem disappeared. dont't ask what I did.

A new comes up:

cc dns.c
dns.c: In function ‘dns_lookup’:
dns.c:1143:9: error: ‘event_action’ undeclared (first use in this function); 
did you mean ‘queue_action’?
 1143 | s = event_action;
  | ^~~~
  | queue_action
dns.c:1143:9: note: each undeclared identifier is reported only once for each 
function it appears in
dns.c:1147:17: error: ‘transport_instance’ has no member named ‘event_action’
 1147 | { s = tp->event_action; break; }
  | ^~
dns.c:1161:5: error: implicit declaration of function ‘event_raise’ 
[-Wimplicit-function-declaration]
 1161 | event_raise(s, US"dns:fail",
  | ^~~
make[1]: *** [Makefile:857: dns.o] Error 1
make[1]: Leaving directory 
'/usr/local/exim/src/exim-4.98-RC0/build-Linux-x86_64'
make: *** [Makefile:37: all] Error 2


--Frank

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[exim] Re: [exim-announce] Exim 4.98-RC0 released

[Frank Elsner via Exim-users]

On Fri, 7 Jun 2024 17:52:36 +0100 Jeremy Harris via Exim-users wrote:
> On 07/06/2024 17:33, Frank Elsner via Exim-users wrote:
> > Did it, same result. Btw, tar file unpacked into new directory, no old 
> > files in.
> 
> What release of Exim did you last build with?

This Makefile was successfully used with exim-4.97.1

> db_env_create is called when compiled for Berkeley DB 4.1 or later.
> What version do you have?

My Fedora has libdb-5.3.28-61, according to "ldd exim"

> What is the full link line for exim_dbmbuild ("make FULLECHO='') ?

cc -O -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/include/libdb -o 
exim_dbmbuild  exim_dbmbuild.o \
  -lcrypt -lm  -lgdbm -lgdbm_compat

--Frank

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

git/master snapshot debuginfod deployed to fedora.stg server

[Frank Ch. Eigler]

Hi -

Open for your experimentation needs, on a recent fedora client and a
fresh build of elfutils,

env DEBUGINFOD_URLS='ima:enforcing https://debuginfod.stg.fedoraproject.org' \
DEBUGINFOD_IMA_CERT_PATH=/etc/keys/ima \
DEBUGINFOD_VERBOSE=1 \
debuginfod-find debuginfo /bin/ls

should result in content similar to:

Loaded pem pubkey /etc/keys/ima/fedora-39-ima.pem, keyid 388b603e
Loaded der certificate /etc/keys/ima/fedora-39-ima.der, keyid = 388b603e
Loaded pem certificate /etc/keys/ima/fedora-39-ima.cert, keyid = 388b603e
Loaded der certificate /etc/keys/ima/fedora-38-ima.der, keyid = e7b0c859
Loaded pem certificate /etc/keys/ima/fedora-38-ima.cert, keyid = e7b0c859
Loaded pem pubkey /etc/keys/ima/fedora-38-ima.pem, keyid e7b0c859
debuginfod_find_debuginfo e79defd2793644d11e45a043e6c1e6559e7c149f
server urls "ima:enforcing https://debuginfod.stg.fedoraproject.org/;
[...]
init server 0 https://debuginfod.stg.fedoraproject.org/buildid [IMA 
verification policy: enforcing]
url 0 
https://debuginfod.stg.fedoraproject.org/buildid/e79defd2793644d11e45a043e6c1e6559e7c149f/debuginfo
query 1 urls in parallel
header HTTP/2 200
[...]
header x-debuginfod-size: 453232
header x-debuginfod-archive: 
/mnt/fedora_koji_prod/koji/packages/coreutils/9.3/5.fc39/x86_64/coreutils-debuginfo-9.3-5.fc39.x86_64.rpm
header x-debuginfod-file: /usr/lib/debug/usr/bin/ls-9.3-5.fc39.x86_64.debug
header x-debuginfod-imasignature: 
030204388b603e00483046022100dd67332b59c2f9431958d0cc80ed332955c89f765dbf8aeeb4262159e457511d022100a2513d0807be86be7bda1802fe6f22b04e9e753891f106120498ca16fa28a20a
header last-modified: Thu, 18 Jan 2024 00:00:00 GMT
[...]
got file from server
Searching for ima keyid 388b603e
Computed ima signature verification res=0
valid signature


Metadata searches should start working a little bit later on:
https://pagure.io/fedora-infra/ansible/pull-request/2057


- FChE

[exim] Re: [exim-announce] Exim 4.98-RC0 released

[Frank Elsner via Exim-users]

On Fri, 7 Jun 2024 17:03:19 +0100 Jeremy Harris via Exim-users wrote:
> On 07/06/2024 16:52, Frank Elsner via Exim-users wrote:
> > /usr/bin/ld: exim_dbmbuild.o: in function `main':
> > exim_dbmbuild.c:(.text+0x386): undefined reference to `db_env_create'
> > /usr/bin/ld: exim_dbmbuild.c:(.text+0x3da): undefined reference to 
> > `db_create'
> 
> Best immediate guess: you need to do a "make distclean" or "make clean" first.

Did it, same result. Btw, tar file unpacked into new directory, no old files in.


--Frank

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Bug 2063456] Re: package cephadm: dependency "cephadmlib" missing

[Frank Barton]

on a related note - ceph 19 hasn't been formally released - why is 19
the version that is included in 24.04 LTS, instead of version 18 "reef"?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063456

Title:
  package cephadm: dependency "cephadmlib" missing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/2063456/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[exim] Re: [exim-announce] Exim 4.98-RC0 released

[Frank Elsner via Exim-users]

On Fri, 7 Jun 2024 15:54:17 +0100 Bernard Quatermass via Exim-announce wrote:
> Hi all,
> 
> Time has come to start the process towards a new release incorporating 
> the improvements and fixes since 4.97.
> 
> This first release candidate v4.98-RC0 is available

When trying to compile this version with my old Makefile I get

cc -o exim_dbmbuild
/usr/bin/ld: exim_dbmbuild.o: in function `main':
exim_dbmbuild.c:(.text+0x386): undefined reference to `db_env_create'
/usr/bin/ld: exim_dbmbuild.c:(.text+0x3da): undefined reference to `db_create'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:737: exim_dbmbuild] Error 1
make[1]: Leaving directory 
'/usr/local/exim/src/exim-4.98-RC0/build-Linux-x86_64'
make: *** [Makefile:37: all] Error 2

Just to inform you,
Frank

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [PATCH v2 1/1] dt-bindings: remoteproc: imx_rproc: add minItems for power-domain

[Frank Li]

On Fri, Jun 07, 2024 at 09:32:26AM +0200, Krzysztof Kozlowski wrote:
> On 06/06/2024 17:00, Frank Li wrote:
> > "fsl,imx8qxp-cm4" and "fsl,imx8qm-cm4" need minimum 2 power domains. Keep
> > the same restriction for other compatible string.
> > 
> > Signed-off-by: Frank Li 
> > ---
> > 
> > Notes:
> > Change from v1 to v2
> > - set minitem to 2 at top
> > - Add imx8qm compatible string also
> > - use not logic to handle difference compatible string restriction
> > - update commit message.
> > 
> > pass dt_binding_check.
> > 
> > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check 
> > DT_SCHEMA_FILES=fsl,imx-rproc.yaml
> >   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
> >   CHKDT   Documentation/devicetree/bindings
> >   LINTDocumentation/devicetree/bindings
> >   DTEX
> > Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dts
> >   DTC_CHK 
> > Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dtb
> > 
> >  .../bindings/remoteproc/fsl,imx-rproc.yaml | 14 ++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
> > b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > index df36e29d974ca..da108a39df435 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > @@ -59,6 +59,7 @@ properties:
> >  maxItems: 32
> >  
> >power-domains:
> > +minItems: 2
> >  maxItems: 8
> >  
> >fsl,auto-boot:
> > @@ -99,6 +100,19 @@ allOf:
> >properties:
> >  fsl,iomuxc-gpr: false
> >  
> > +  - if:
> > +  properties:
> > +compatible:
> > +  not:
> > +contains:
> > +  enum:
> > +- fsl,imx8qxp-cm4
> > +- fsl,imx8qm-cm4
> > +then:
> > +  properties:
> > +power-domains:
> > +  minItems: 8
> 
> What happened with the "else:"? How many power domains is needed for
> other devices?

So far, only fsl,imx8qxp-cm4 ind fsl,imx8qm-cm4 need power domain (2-8). 
Power-domains is option property. 

Can I just remove whole "if"?

Frank 


> 
> Best regards,
> Krzysztof
> 

[Bug 2063456] Re: package cephadm: dependency "cephadmlib" missing

[Frank Barton]

Is there any movement on this for 24.04 LTS? still having the same issue on a 
fresh install
installed:
cephadm/noble,now 19.2.0~git20240301.4c76c50-0ubuntu6 amd64 [installed]

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063456

Title:
  package cephadm: dependency "cephadmlib" missing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/2063456/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2068577] Re: [UBUNTU 24.04] Running sosreport causes the system to crash and produce a dump

[Frank Heimes]

On top I've noticed that there are probably nfs shares active in your system 
(saw that in fstab).
There is an open issue with nfs.
Would you mind tearing down (and removing nfs) temporarily and for test reasons 
and run sosreport then again?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068577

Title:
  [UBUNTU 24.04] Running sosreport causes the system to crash and
  produce a dump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2068577/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [tor-relays] Relay bandwidth issue

[Frank Lý via tor-relays]

v0.4.8.12 just released, so try updating to the latest version and see if your 
situation improves. Other than bandwidth shaping, you may want to consider 
using accounting options as well.

https://support.torproject.org/relay-operators/limit-total-bandwidth/

Frank

Jun 5, 2024, 6:24 AM by tor-relays@lists.torproject.org:

> Hello everyone,
>
> i got a local relay running with v0.4.8.11 and the following configuration:
>
> ...
> RelayBandwidthRate 4 MBytes
> RelayBandwidthBurst 7 MBytes
> ExitPolicy reject *:*
> ExitRelay 0
> SocksPort 0
>
> About a month ago, the relay started to behave differently than it used to:
> A few hours after each restart, it didn't respect the bandwidth limits 
> anymore, meaning it took what it could get. After a while my isp interrupts 
> my connection, i guess because of exhaustive traffic or connections being 
> established, not sure.
>
> This leads to the following loop:
> 1. The relay notices it's ip changed and starts over
> 2. It consumes max bandwidth after a while
> 3. The isp disconnects
> 4. Start at 1, until after enough loops the relay is broken and doesn't 
> connect anymore
>
> I'm not sure what caused the different behaviour, i don't have a close look 
> on when my relay gets an update. The issue is severe for me though, so any 
> help in fixing the bandwidth limit again would be really appreciated.
>
> --
> Sent with Tuta; enjoy secure & ad-free emails:
> https://tuta.com
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [gentoo-user] Mobo, CPU, memory and a m.2 thingy. This work together?

[Frank Steinmetzger]

Am Tue, Jun 04, 2024 at 05:49:31AM -0400 schrieb Rich Freeman:

> On Tue, Jun 4, 2024 at 2:44 AM Dale  wrote:
> >
> > I did some more digging.  It seems that all the LSI SAS cards I found
> > need a PCIe x8 slot.  The only slot available is the one intended for
> > video.
> 
> The board you linked has 2 4x slots that are physically 16x, so the
> card should work fine in those, just at 4x speed.

I can never remember the available throughput for each generation. So I 
think about my own board: it as a 2.0×2 NVMe slot that gives me 1 GB/s 
theoretical bandwidth. So if you have 3.0×4, that is twice the lanes and 
twice the BW/lane, which yields 4 GB/s gross throughput. If you attach 
spinning rust to that, you’d need around 15 to 20 HDDs to saturate that 
link. So I wouldn’t worry too much about underperformance.

> > I'd rather not
> > use it on the new build because I've thought about having another
> > monitor added for desktop use so I would need three ports at least.

DisplayPort supports daisy-chaining. So if you do get another monitor some 
day, look for one that has this feature and you can drive two monitors with 
one port on the PC.

> > The little SATA controllers I currently use tend to only need PCIe x1.
> > That is slower but at least it works.

PCIe 3.0×1 is still fast enough for four HDDs at full speed. You may get 
saturation at the outermost tracks, but how often does that happen anyways?
I can think of two cases that produce enough I/O for that:
- copy stuff from one internal RAID to another
  (you use LVM, does that support striping to distribute I/O?)
- a RAID scrub

Everything else involves two disks at most—when you copy stuff from one to 
another. Getting data into the system is limited by the network which is far 
slower than PCIe. And a full SMART test does not use the data bus at all.


But what I also just remembered: only the ×16 GPU slot and the primary M.2 
slots (which are often one gen faster than the other M.2 slots) are 
connected to the CPU via dedicated links. All other PCIe slots are behind 
the chipset. And that in turn is connected to the CPU via a PCIe 4.0×4 link. 
This is probably the technical reason why there are so few boards with slots 
wider than ×4 – there is just no way to make use of them, because they all 
most go through that ×4 bottleneck to the CPU.

┌───┐ 5.0×4 ┌───┐ 4.0×4 ┌─┐   ┌───┐
│M.2┝===┥CPU┝━━━┥ Chipset ┝━━━┥M.2│
└───┘   └─┰─┘   └─┰─┰─┘   └───┘
5.0×16┃   ┃ ┃
┌─┸─┐┌┸─┐ ┌─┸┐
│GPU││PCIe 1│ │PCIe 2│
└───┘└──┘ └──┘

Here are block diagrams of AM5 B- and X-chipsets and a more verbose 
explanation:
https://www.anandtech.com/show/17585/amd-zen-4-ryzen-9-7950x-and-ryzen-5-7600x-review-retaking-the-high-end/4

Theoretically, the PCIe controller in the CPU has the ability to split up 
the ×16 GPU link into 2×8 and other subdivisions, but that would cripple the 
GPU, which is the normal use case for such mobos, so the feature is very 
seldomly found.

If I look at all available AM5 mobos that have at least two ×8 slots, there 
are just seven out of 126: https://skinflint.co.uk/?cat=mbam5=19227_2
You can also use the filter to look for boards with 3 ×4 slots.

-- 
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

“If I could explain it to the average person, I wouldn't have been worth
the Nobel Prize.” – Richard Feynman

Re: [PATCH 2/5] PCI: endpoint: Introduce 'epc_deinit' event and notify the EPF drivers

[Frank Li]

On Thu, Jun 06, 2024 at 12:56:35PM +0530, Manivannan Sadhasivam wrote:
> As like the 'epc_init' event, that is used to signal the EPF drivers about
> the EPC initialization, let's introduce 'epc_deinit' event that is used to
> signal EPC deinitialization.
> 
> The EPC deinitialization applies only when any sort of fundamental reset
> is supported by the endpoint controller as per the PCIe spec.
> 
> Reference: PCIe Base spec v5.0, sections 4.2.4.9.1 and 6.6.1.
> 
> Currently, some EPC drivers like pcie-qcom-ep and pcie-tegra194 support
> PERST# as the fundamental reset. So the 'deinit' event will be notified to
> the EPF drivers when PERST# assert happens in the above mentioned EPC
> drivers.
> 
> The EPF drivers, on receiving the event through the epc_deinit() callback
> should reset the EPF state machine and also cleanup any configuration that
> got affected by the fundamental reset like BAR, DMA etc...
> 
> This change also warrants skipping the cleanups in unbind() if already done
> in epc_deinit().
> 
> Reviewed-by: Niklas Cassel 
> Signed-off-by: Manivannan Sadhasivam 

Reviewed-by: Frank Li 

> ---
>  drivers/pci/controller/dwc/pcie-designware-ep.c |  1 -
>  drivers/pci/controller/dwc/pcie-qcom-ep.c   |  1 +
>  drivers/pci/controller/dwc/pcie-tegra194.c  |  1 +
>  drivers/pci/endpoint/functions/pci-epf-mhi.c| 19 +++
>  drivers/pci/endpoint/functions/pci-epf-test.c   | 17 +++--
>  drivers/pci/endpoint/pci-epc-core.c | 25 
> +
>  include/linux/pci-epc.h | 13 +
>  include/linux/pci-epf.h |  2 ++
>  8 files changed, 76 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
> b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 2e69f81baf99..78d5fc72c9cb 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -620,7 +620,6 @@ void dw_pcie_ep_cleanup(struct dw_pcie_ep *ep)
>   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>  
>   dw_pcie_edma_remove(pci);
> - ep->epc->init_complete = false;
>  }
>  EXPORT_SYMBOL_GPL(dw_pcie_ep_cleanup);
>  
> diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c 
> b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> index 4d2d7457dcb3..2324e56c9bfc 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> @@ -507,6 +507,7 @@ static void qcom_pcie_perst_assert(struct dw_pcie *pci)
>   return;
>   }
>  
> + pci_epc_deinit_notify(pci->ep.epc);
>   dw_pcie_ep_cleanup(>ep);
>   qcom_pcie_disable_resources(pcie_ep);
>   pcie_ep->link_status = QCOM_PCIE_EP_LINK_DISABLED;
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
> b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 432ed9d9a463..4ca7404246a3 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -1715,6 +1715,7 @@ static void pex_ep_event_pex_rst_assert(struct 
> tegra_pcie_dw *pcie)
>   if (ret)
>   dev_err(pcie->dev, "Failed to go Detect state: %d\n", ret);
>  
> + pci_epc_deinit_notify(pcie->pci.ep.epc);
>   dw_pcie_ep_cleanup(>pci.ep);
>  
>   reset_control_assert(pcie->core_rst);
> diff --git a/drivers/pci/endpoint/functions/pci-epf-mhi.c 
> b/drivers/pci/endpoint/functions/pci-epf-mhi.c
> index 205c02953f25..5832989e55e8 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-mhi.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-mhi.c
> @@ -764,6 +764,24 @@ static int pci_epf_mhi_epc_init(struct pci_epf *epf)
>   return 0;
>  }
>  
> +static void pci_epf_mhi_epc_deinit(struct pci_epf *epf)
> +{
> + struct pci_epf_mhi *epf_mhi = epf_get_drvdata(epf);
> + const struct pci_epf_mhi_ep_info *info = epf_mhi->info;
> + struct pci_epf_bar *epf_bar = >bar[info->bar_num];
> + struct mhi_ep_cntrl *mhi_cntrl = _mhi->mhi_cntrl;
> + struct pci_epc *epc = epf->epc;
> +
> + if (mhi_cntrl->mhi_dev) {
> + mhi_ep_power_down(mhi_cntrl);
> + if (info->flags & MHI_EPF_USE_DMA)
> + pci_epf_mhi_dma_deinit(epf_mhi);
> + mhi_ep_unregister_controller(mhi_cntrl);
> + }
> +
> + pci_epc_clear_bar(epc, epf->func_no, epf->vfunc_no, epf_bar);
> +}
> +
>  static int pci_epf_mhi_link_up(struct pci_epf *epf)
>  {
>   struct pci_epf_mhi *epf_mhi = epf_get_drvdata(epf);
> @@ -898,6 +916,7 @@ static void pci_epf_mhi_unbind(struct pci_epf *epf)
>

Re: [PATCH 1/5] PCI: dwc: ep: Remove dw_pcie_ep_init_notify() wrapper

[Frank Li]

On Thu, Jun 06, 2024 at 12:56:34PM +0530, Manivannan Sadhasivam wrote:
> Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify()
> directly. So this wrapper provides no benefit to the glue drivers.
> 
> So let's remove it and call pci_epc_init_notify() directly from glue
> drivers.
> 
> Suggested-by: Bjorn Helgaas 
> Signed-off-by: Manivannan Sadhasivam 

Reviewed-by: Frank Li 

> ---
>  drivers/pci/controller/dwc/pci-dra7xx.c   |  2 +-
>  drivers/pci/controller/dwc/pci-imx6.c |  2 +-
>  drivers/pci/controller/dwc/pci-keystone.c |  2 +-
>  drivers/pci/controller/dwc/pci-layerscape-ep.c|  2 +-
>  drivers/pci/controller/dwc/pcie-artpec6.c |  2 +-
>  drivers/pci/controller/dwc/pcie-designware-ep.c   | 12 
>  drivers/pci/controller/dwc/pcie-designware-plat.c |  2 +-
>  drivers/pci/controller/dwc/pcie-designware.h  |  5 -
>  drivers/pci/controller/dwc/pcie-keembay.c |  2 +-
>  drivers/pci/controller/dwc/pcie-qcom-ep.c |  2 +-
>  drivers/pci/controller/dwc/pcie-rcar-gen4.c   |  2 +-
>  drivers/pci/controller/dwc/pcie-tegra194.c|  2 +-
>  drivers/pci/controller/dwc/pcie-uniphier-ep.c |  2 +-
>  13 files changed, 11 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c 
> b/drivers/pci/controller/dwc/pci-dra7xx.c
> index d2d17d37d3e0..e491d0ff3962 100644
> --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> @@ -474,7 +474,7 @@ static int dra7xx_add_pcie_ep(struct dra7xx_pcie *dra7xx,
>   return ret;
>   }
>  
> - dw_pcie_ep_init_notify(ep);
> + pci_epc_init_notify(ep->epc);
>  
>   return 0;
>  }
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 917c69edee1d..a876b8e6e741 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1131,7 +1131,7 @@ static int imx6_add_pcie_ep(struct imx6_pcie *imx6_pcie,
>   return ret;
>   }
>  
> - dw_pcie_ep_init_notify(ep);
> + pci_epc_init_notify(ep->epc);
>  
>   /* Start LTSSM. */
>   imx6_pcie_ltssm_enable(dev);
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c 
> b/drivers/pci/controller/dwc/pci-keystone.c
> index d3a7d14ee685..ca1054f5c79a 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -1293,7 +1293,7 @@ static int ks_pcie_probe(struct platform_device *pdev)
>   goto err_ep_init;
>   }
>  
> - dw_pcie_ep_init_notify(>ep);
> + pci_epc_init_notify(pci->ep.epc);
>  
>   break;
>   default:
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c 
> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index 7dde6d5fa4d8..35bb481564c7 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -286,7 +286,7 @@ static int __init ls_pcie_ep_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> - dw_pcie_ep_init_notify(>ep);
> + pci_epc_init_notify(pci->ep.epc);
>  
>   return ls_pcie_ep_interrupt_init(pcie, pdev);
>  }
> diff --git a/drivers/pci/controller/dwc/pcie-artpec6.c 
> b/drivers/pci/controller/dwc/pcie-artpec6.c
> index a4630b92489b..dc8dd7f27b78 100644
> --- a/drivers/pci/controller/dwc/pcie-artpec6.c
> +++ b/drivers/pci/controller/dwc/pcie-artpec6.c
> @@ -452,7 +452,7 @@ static int artpec6_pcie_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> - dw_pcie_ep_init_notify(>ep);
> + pci_epc_init_notify(pci->ep.epc);
>  
>   break;
>   default:
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
> b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 47391d7d3a73..2e69f81baf99 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -27,18 +27,6 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
>  }
>  EXPORT_SYMBOL_GPL(dw_pcie_ep_linkup);
>  
> -/**
> - * dw_pcie_ep_init_notify - Notify EPF drivers about EPC initialization 
> complete
> - * @ep: DWC EP device
> - */
> -void dw_pcie_ep_init_notify(struct dw_pcie_ep *ep)
> -{
> - struct pci_epc *epc = ep->epc;
> -
> - pci_epc_init_notify(epc);
> -}
> -EXPORT_SYMBOL_GPL(dw_pcie_ep_init_notify);
> -
>  /**
>   * dw_pcie_ep_get_func_from_ep - Get the struct dw_pcie_ep_fun

Re: [PATCH 5/5] PCI: layerscape-ep: Use the generic dw_pcie_ep_linkdown() API to handle Link Down event

[Frank Li]

On Thu, Jun 06, 2024 at 12:56:38PM +0530, Manivannan Sadhasivam wrote:
> Now that the API is available, let's make use of it. It also handles the
> reinitialization of DWC non-sticky registers in addition to sending the
> notification to EPF drivers.
> 
> Reported-by: Bjorn Helgaas 
> Closes: https://lore.kernel.org/linux-pci/20240528195539.GA458945@bhelgaas/
> Signed-off-by: Manivannan Sadhasivam 

Reviewed-by: Frank Li 

> ---
>  drivers/pci/controller/dwc/pci-layerscape-ep.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c 
> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index 35bb481564c7..a4a800699f89 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -104,7 +104,7 @@ static irqreturn_t ls_pcie_ep_event_handler(int irq, void 
> *dev_id)
>   dev_dbg(pci->dev, "Link up\n");
>   } else if (val & PEX_PF0_PME_MES_DR_LDD) {
>   dev_dbg(pci->dev, "Link down\n");
> - pci_epc_linkdown(pci->ep.epc);
> + dw_pcie_ep_linkdown(>ep);
>   } else if (val & PEX_PF0_PME_MES_DR_HRD) {
>   dev_dbg(pci->dev, "Hot reset\n");
>   }
> 
> -- 
> 2.25.1
> 

[PATCH v2 1/1] dt-bindings: remoteproc: imx_rproc: add minItems for power-domain

[Frank Li]

"fsl,imx8qxp-cm4" and "fsl,imx8qm-cm4" need minimum 2 power domains. Keep
the same restriction for other compatible string.

Signed-off-by: Frank Li 
---

Notes:
Change from v1 to v2
- set minitem to 2 at top
- Add imx8qm compatible string also
- use not logic to handle difference compatible string restriction
- update commit message.

pass dt_binding_check.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check 
DT_SCHEMA_FILES=fsl,imx-rproc.yaml
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  CHKDT   Documentation/devicetree/bindings
  LINTDocumentation/devicetree/bindings
  DTEX
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dts
  DTC_CHK 
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dtb

 .../bindings/remoteproc/fsl,imx-rproc.yaml | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index df36e29d974ca..da108a39df435 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -59,6 +59,7 @@ properties:
 maxItems: 32
 
   power-domains:
+minItems: 2
 maxItems: 8
 
   fsl,auto-boot:
@@ -99,6 +100,19 @@ allOf:
   properties:
 fsl,iomuxc-gpr: false
 
+  - if:
+  properties:
+compatible:
+  not:
+contains:
+  enum:
+- fsl,imx8qxp-cm4
+- fsl,imx8qm-cm4
+then:
+  properties:
+power-domains:
+  minItems: 8
+
 additionalProperties: false
 
 examples:
-- 
2.34.1

[Bug 2065579] Re: [UBUNTU 22.04] OS guest boot issues on 9p filesystem

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065579

Title:
  [UBUNTU 22.04] OS guest boot issues on 9p filesystem

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2065579/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

Hi,

Thanks for your review.

On 05/06/2024 14:50, Nuo Mi wrote:
> Hi Frank,
> Thank you for the patch
> 
> On Wed, Jun 5, 2024 at 5:24 PM Frank Plowman  wrote:
> 
>> On the top of p. 112 in VVC (09/2023):
>>
>> It is a requirement of bitstream conformance that the values of
>> qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
>> of −QpBdOffset to 63, inclusive for i in the range of 0 to
>>
> Then, why do we not check −QpBdOffset?

sps_delta_qp_in_val_minus1 is unsigned, therefore we would only need to
check the first elements qp{In,Out}Val[i][0], both of which are set to
sps_qp_table_start_minus26[i] + 26.

sps_qp_table_start_minus26[i] is already constrained to the range
[-26-QpBdOffset..36] (see VVC (09/2023) p. 111 and
libavcodec/cbs_h266_syntax_template.c:1387).

I don't get why the standard reiterates the constraint here, it seems
redundant.

> 
>> numQpTables − 1, inclusive, and j in the range of 0 to
>> sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.
>>
>> Signed-off-by: Frank Plowman 
>> ---
>>  libavcodec/vvc/ps.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
>> index bfc3c121fd..c4f64d5da7 100644
>> --- a/libavcodec/vvc/ps.c
>> +++ b/libavcodec/vvc/ps.c
>> @@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
>>
>>  qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
>>  for (int j = 0; j < num_points_in_qp_table; j++ ) {
>> +const uint8_t delta_qp_out =
>> (r->sps_delta_qp_in_val_minus1[i][j] ^ r->sps_delta_qp_diff_val[i][j]);
>>  delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
>> +if (qp_in[j] + delta_qp_in[j] > 63)
>> +return AVERROR(EINVAL);
>>  qp_in[j+1] = qp_in[j] + delta_qp_in[j];
>> -qp_out[j+1] = qp_out[j] +
>> (r->sps_delta_qp_in_val_minus1[i][j] ^ r->sps_delta_qp_diff_val[i][j]);
>> +if (qp_out[j] + delta_qp_out > 63)
>> +return AVERROR(EINVAL);
>> +qp_out[j+1] = qp_out[j] + delta_qp_out;
>>
> Instead of changing so many lines, we can  add 2 lines here
> if (qp_in[j+1] < 63 ||  qp_out[j+1] < 63)
> return AVERROR(EINVAL);

v3 sent with this tweak & squashing the other patch.

> 
>>  }
>>  sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
>>  for (int k = qp_in[0] - 1 + off; k >= 0; k--)
>> --
>> 2.45.1
>>

Cheers,
-- 
Frank
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Additionally, don't discard the return code from sps_chroma_qp_table.

Signed-off-by: Frank Plowman 
---
Changes since v2:
* Squash discarded return code patch and QP overflow patch.
* Combine QpIn and QpOut validation into a single if statement.

 libavcodec/vvc/ps.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..ea5d0e9959 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,12 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63 || qp_out[j] + delta_qp_out > 
63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
@@ -186,8 +189,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[Bug 2068577] Re: [UBUNTU 24.04] Running sosreport causes the system to crash and produce a dump

[Frank Heimes]

Thanks for having reported this issue.

I tried to recreate this on the systems that I have at hand (which is a z13 in 
PS/SM mode and a LinuxONE 3 in DPM mode) and ran sosreport twice on both 
systems in an LPAR, with a default 24.04 install, and after  having 24.04 
upgraded to the latest level (incl. kernel) with:
sudo apt update && sudo apt full-upgrade # and reboot
and in none of the four cases sosreport crashed for me.
Would you please retry (like my colleagues above already mentioned) with the 
latest kernel (means after full-upgrade)? Even if I cannot recreate with the GA 
kernel on my system(s).

So I'm now trying to figure out differences between your setup and mine.

You sosreport package versions is the same than mine: sosreport (version
4.5.6)

Then I though that you may use a filesystem formatted other than ext4, which 
may cause issues, since the last line that you see seems to be:
"Starting 21/74 filesys [Running: block btrfs ebpf filesys]"
but the debuginfo tells you that you are also on ext4 (like me).

Looks like you system is a IBM z16 Model A01, Machine Type 3931 (that I
do not have at hand).

Is this really happening for you on an LPAR or in a zVM guest? (since
dbginfo also incl. zvm data)?

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Changed in: sosreport (Ubuntu)
 Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068577

Title:
  [UBUNTU 24.04] Running sosreport causes the system to crash and
  produce a dump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2068577/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2068577] Re: [UBUNTU 24.04] Running sosreport causes the system to crash and produce a dump

[Frank Heimes]

** Package changed: linux (Ubuntu) => sosreport (Ubuntu)

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068577

Title:
  [UBUNTU 24.04] Running sosreport causes the system to crash and
  produce a dump

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2068577/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH] drm/amdgpu: tolerate allocating GTT bo with dcc flag

[Min, Frank]

[AMD Official Use Only - AMD Internal Distribution Only]

From: Frank Min 

Do not return failure for allocating GTT bo with dcc flag on gfx12. This will 
improve compatibility for UMD.

Signed-off-by: Frank Min 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 9041c63cabb0..58186de61403 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -409,11 +409,6 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void 
*data,
if (args->in.domains & ~AMDGPU_GEM_DOMAIN_MASK)
return -EINVAL;

-   if ((flags & AMDGPU_GEM_CREATE_GFX12_DCC) &&
-   ((amdgpu_ip_version(adev, GC_HWIP, 0) < IP_VERSION(12, 0, 0)) ||
-!(args->in.domains & AMDGPU_GEM_DOMAIN_VRAM)))
-   return -EINVAL;
-
if (!amdgpu_is_tmz(adev) && (flags & AMDGPU_GEM_CREATE_ENCRYPTED)) {
DRM_NOTE_ONCE("Cannot allocate secure buffer since TMZ is 
disabled\n");
return -EINVAL;
--
2.34.1

[PATCH 1/1] dt-bindings: remoteproc: imx_rproc: add minItems for power-domain

[Frank Li]

"fsl,imx8qxp-cm4" just need 2 power domains. Keep the same restriction for
other compatible string.

Signed-off-by: Frank Li 
---

Notes:
pass dt_binding_check.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8  dt_binding_check 
DT_SCHEMA_FILES=fsl,imx-rproc.yaml
  SCHEMA  Documentation/devicetree/bindings/processed-schema.json
  CHKDT   Documentation/devicetree/bindings
  LINTDocumentation/devicetree/bindings
  DTEX
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dts
  DTC_CHK 
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.example.dtb

 .../bindings/remoteproc/fsl,imx-rproc.yaml   | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index df36e29d974ca..60267c1ba94e0 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -59,6 +59,7 @@ properties:
 maxItems: 32
 
   power-domains:
+minItems: 1
 maxItems: 8
 
   fsl,auto-boot:
@@ -99,6 +100,21 @@ allOf:
   properties:
 fsl,iomuxc-gpr: false
 
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - fsl,imx8qxp-cm4
+then:
+  properties:
+power-domains:
+  minItems: 2
+else:
+  properties:
+power-domains:
+  minItems: 8
+
 additionalProperties: false
 
 examples:
-- 
2.34.1

Re: [PATCH 16/18] drm/vc4: Use phys addresses for slave DMA config

[Frank Li]

On Fri, May 24, 2024 at 07:27:00PM +0100, Dave Stevenson wrote:
> From: Phil Elwell 
> 
> Slave addresses for DMA are meant to be supplied as physical addresses
> (contrary to what struct snd_dmaengine_dai_dma_data does).

Can you use the same content for patch 14-17?

Frank

> 
> Signed-off-by: Phil Elwell 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index d30f8e8e8967..c2afd72bd96e 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -2696,7 +2696,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi 
> *vc4_hdmi)
>   struct snd_soc_card *card = _hdmi->audio.card;
>   struct device *dev = _hdmi->pdev->dev;
>   struct platform_device *codec_pdev;
> - const __be32 *addr;
> + struct resource *iomem;
>   int index, len;
>   int ret;
>  
> @@ -2732,22 +2732,15 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi 
> *vc4_hdmi)
>   }
>  
>   /*
> -  * Get the physical address of VC4_HD_MAI_DATA. We need to retrieve
> -  * the bus address specified in the DT, because the physical address
> -  * (the one returned by platform_get_resource()) is not appropriate
> -  * for DMA transfers.
> -  * This VC/MMU should probably be exposed to avoid this kind of hacks.
> +  * Get the physical address of VC4_HD_MAI_DATA.
>*/
>   index = of_property_match_string(dev->of_node, "reg-names", "hd");
>   /* Before BCM2711, we don't have a named register range */
>   if (index < 0)
>   index = 1;
> + iomem = platform_get_resource(vc4_hdmi->pdev, IORESOURCE_MEM, index);
>  
> - addr = of_get_address(dev->of_node, index, NULL, NULL);
> - if (!addr)
> - return -EINVAL;
> -
> - vc4_hdmi->audio.dma_data.addr = be32_to_cpup(addr) + mai_data->offset;
> + vc4_hdmi->audio.dma_data.addr = iomem->start + mai_data->offset;
>   vc4_hdmi->audio.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>   vc4_hdmi->audio.dma_data.maxburst = 2;
>  
> -- 
> 2.34.1
> 

Re: [PATCH 11/18] dmaengine: bcm2835: Use dma_map_resource to map addresses

[Frank Li]

On Fri, May 24, 2024 at 07:26:55PM +0100, Dave Stevenson wrote:
> There is a need to account for dma-ranges and iommus in the
> dma mapping process, and the public API for handling that is
> dma_map_resource.

what's means?

> 
> Add support for mapping addresses to the DMA driver.
> 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 46 ++-
>  1 file changed, 41 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 9531c0b82071..e48008b06716 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -67,6 +67,10 @@ struct bcm2835_cb_entry {
>  
>  struct bcm2835_dma_chan_map {
>   dma_addr_t addr;
> + enum dma_data_direction dir;
> +
> + phys_addr_t slave_addr;
> + unsigned int xfer_size;
>  };
>  
>  struct bcm2835_chan {
> @@ -294,12 +298,44 @@ static int bcm2835_dma_map_slave_addr(struct dma_chan 
> *chan,
>   return 0;
>   }

where umap function? I suppose you should unmap all when terminate chan
or free chan by client driver. 

>  
> - /*
> -  * This path will be updated to handle new clients, but currently should
> -  * never be used.
> -  */
> + if (dev_size != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + return -EIO;
> +
> + /* Reuse current map if possible. */
> + if (dev_addr == map->slave_addr &&
> + dev_size == map->xfer_size &&
> + dev_dir == map->dir)
> + return 0;
> +
> + /* Remove old mapping if present. */
> + if (map->xfer_size) {
> + dev_dbg(chan->device->dev, "chan: unmap %zx@%pap to %pad dir: 
> %s\n",
> + dev_size, _addr, >addr,
> + dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : 
> "DMA_FROM_DEVICE");
> + dma_unmap_resource(chan->device->dev, map->addr,
> +map->xfer_size, map->dir, 0);
> + }
> + map->xfer_size = 0;
>  
> - return -EINVAL;
> + /* Create new slave address map. */
> + map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
> +  dev_dir, 0);
> +
> + if (dma_mapping_error(chan->device->dev, map->addr)) {
> + dev_err(chan->device->dev, "chan: failed to map %zx@%pap",
> + dev_size, _addr);
> + return -EIO;
> + }
> +
> + dev_dbg(chan->device->dev, "chan: map %zx@%pap to %pad dir: %s\n",
> + dev_size, _addr, >addr,
> + dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" : "DMA_FROM_DEVICE");
> +
> + map->slave_addr = dev_addr;
> + map->xfer_size = dev_size;
> + map->dir = dev_dir;
> +
> + return 0;
>  }
>  
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
> -- 
> 2.34.1
> 

Re: [PATCH 09/18] dmaengine: bcm2835: Add function to handle DMA mapping

[Frank Li]

On Fri, May 24, 2024 at 07:26:53PM +0100, Dave Stevenson wrote:
> The code handling DMA mapping is currently incorrect and
> needs a sequence of fixups.

Can you descript what incorrect here? 

> Move the mapping out into a separate function and structure
> to allow for those fixes to be applied more cleanly.
> 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 46 ---
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index aefaa1f01d7f..ef1d95bae84e 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -65,6 +65,10 @@ struct bcm2835_cb_entry {
>   dma_addr_t paddr;
>  };
>  
> +struct bcm2835_dma_chan_map {
> + dma_addr_t addr;
> +};
> +
>  struct bcm2835_chan {
>   struct virt_dma_chan vc;
>  
> @@ -74,6 +78,7 @@ struct bcm2835_chan {
>   int ch;
>   struct bcm2835_desc *desc;
>   struct dma_pool *cb_pool;
> + struct bcm2835_dma_chan_map map;

I suppose map should in bcm2835_desc.  if put in chan, how about client
driver create two desc by bcm2835_dma_prep_slave_sg()?

prep_slave_sg()
submit()
prep_savle_sg()
submit()
issue_pending()

Frank

>  
>   void __iomem *chan_base;
>   int irq_number;
> @@ -268,6 +273,19 @@ static inline bool need_dst_incr(enum 
> dma_transfer_direction direction)
>   }
>  
>   return false;
> +};
> +
> +static int bcm2835_dma_map_slave_addr(struct dma_chan *chan,
> +   phys_addr_t dev_addr,
> +   size_t dev_size,
> +   enum dma_data_direction dev_dir)
> +{
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
> + struct bcm2835_dma_chan_map *map = >map;
> +
> + map->addr = dev_addr;
> +
> + return 0;
>  }
>  
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
> @@ -734,13 +752,19 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   }
>  
>   if (direction == DMA_DEV_TO_MEM) {
> - if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.src_addr,
> +c->cfg.src_addr_width,
> +DMA_TO_DEVICE))
>   return NULL;
> - src = c->cfg.src_addr;
> +
> + src = c->map.addr;
>   } else {
> - if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.dst_addr,
> +c->cfg.dst_addr_width,
> +DMA_FROM_DEVICE))
>   return NULL;
> - dst = c->cfg.dst_addr;
> +
> + dst = c->map.addr;
>   }
>  
>   /* count frames in sg list */
> @@ -795,14 +819,20 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
> __func__, buf_len, period_len);
>  
>   if (direction == DMA_DEV_TO_MEM) {
> - if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.src_addr,
> +c->cfg.src_addr_width,
> +DMA_TO_DEVICE))
>   return NULL;
> - src = c->cfg.src_addr;
> +
> + src = c->map.addr;
>   dst = buf_addr;
>   } else {
> - if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> + if (bcm2835_dma_map_slave_addr(chan, c->cfg.dst_addr,
> +c->cfg.dst_addr_width,
> +DMA_FROM_DEVICE))
>   return NULL;
> - dst = c->cfg.dst_addr;
> +
> + dst = c->map.addr;
>   src = buf_addr;
>   }
>  
> -- 
> 2.34.1
> 

Re: [PATCH 08/18] dmaengine: bcm2835: pass dma_chan to generic functions

[Frank Li]

On Fri, May 24, 2024 at 07:26:52PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> In preparation to support more platforms pass the dma_chan to the
> generic functions. This provides access to the DMA device and possible
> platform specific data.

why need this change? you can easy convert between dma_chan and
bcm2835_chan.


> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index e2f9c8692e6b..aefaa1f01d7f 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -288,12 +288,13 @@ static void bcm2835_dma_desc_free(struct virt_dma_desc 
> *vd)
>  }
>  
>  static bool
> -bcm2835_dma_create_cb_set_length(struct bcm2835_chan *chan,
> +bcm2835_dma_create_cb_set_length(struct dma_chan *chan,
>struct bcm2835_dma_cb *control_block,
>size_t len, size_t period_len,
>size_t *total_len)
>  {
> - size_t max_len = bcm2835_dma_max_frame_length(chan);
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
> + size_t max_len = bcm2835_dma_max_frame_length(c);
>  
>   /* set the length taking lite-channel limitations into account */
>   control_block->length = min_t(u32, len, max_len);
> @@ -417,7 +418,7 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   /* set up length in control_block if requested */
>   if (buf_len) {
>   /* calculate length honoring period_length */
> - if (bcm2835_dma_create_cb_set_length(c, control_block,
> + if (bcm2835_dma_create_cb_set_length(chan, 
> control_block,
>len, period_len,
>_len)) {
>   /* add extrainfo bits in info */
> @@ -485,8 +486,9 @@ static void bcm2835_dma_fill_cb_chain_with_sg(
>   }
>  }
>  
> -static void bcm2835_dma_abort(struct bcm2835_chan *c)
> +static void bcm2835_dma_abort(struct dma_chan *chan)
>  {
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   void __iomem *chan_base = c->chan_base;
>   long int timeout = 1;
>  
> @@ -513,8 +515,9 @@ static void bcm2835_dma_abort(struct bcm2835_chan *c)
>   writel(BCM2835_DMA_RESET, chan_base + BCM2835_DMA_CS);
>  }
>  
> -static void bcm2835_dma_start_desc(struct bcm2835_chan *c)
> +static void bcm2835_dma_start_desc(struct dma_chan *chan)
>  {
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct virt_dma_desc *vd = vchan_next_desc(>vc);
>   struct bcm2835_desc *d;
>  
> @@ -533,7 +536,8 @@ static void bcm2835_dma_start_desc(struct bcm2835_chan *c)
>  
>  static irqreturn_t bcm2835_dma_callback(int irq, void *data)
>  {
> - struct bcm2835_chan *c = data;
> + struct dma_chan *chan = data;
> + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   unsigned long flags;
>  
> @@ -566,7 +570,7 @@ static irqreturn_t bcm2835_dma_callback(int irq, void 
> *data)
>   vchan_cyclic_callback(>vd);
>   } else if (!readl(c->chan_base + BCM2835_DMA_ADDR)) {
>   vchan_cookie_complete(>desc->vd);
> - bcm2835_dma_start_desc(c);
> + bcm2835_dma_start_desc(chan);
>   }
>   }
>  
> @@ -594,7 +598,7 @@ static int bcm2835_dma_alloc_chan_resources(struct 
> dma_chan *chan)
>   }
>  
>   return request_irq(c->irq_number, bcm2835_dma_callback,
> -c->irq_flags, "DMA IRQ", c);
> +c->irq_flags, "DMA IRQ", chan);
>  }
>  
>  static void bcm2835_dma_free_chan_resources(struct dma_chan *chan)
> @@ -682,7 +686,7 @@ static void bcm2835_dma_issue_pending(struct dma_chan 
> *chan)
>  
>   spin_lock_irqsave(>vc.lock, flags);
>   if (vchan_issue_pending(>vc) && !c->desc)
> - bcm2835_dma_start_desc(c);
> + bcm2835_dma_start_desc(chan);
>  
>   spin_unlock_irqrestore(>vc.lock, flags);
>  }
> @@ -846,7 +850,7 @@ static int bcm2835_dma_terminate_all(struct dma_chan 
> *chan)
>   if (c->desc) {
>   vchan_terminate_vdesc(>desc->vd);
>   c->desc = NULL;
> - bcm2835_dma_abort(c);
> + bcm2835_dma_abort(chan);
>   }
>  
>   vchan_get_all_descriptors(>vc, );
> -- 
> 2.34.1
> 

Re: [PATCH 07/18] dmaengine: bcm2385: drop info parameters

[Frank Li]

On Fri, May 24, 2024 at 07:26:51PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> The parameters info and finalextrainfo are platform specific. So drop
> them by generating them within bcm2835_dma_create_cb_chain().

Drop 'info' and 'finalextrainfo' because these can be generated by 
bcm2835_dma_create_cb_chain().

> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 83 +++
>  1 file changed, 40 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index d6c5a2762a46..e2f9c8692e6b 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -287,13 +287,11 @@ static void bcm2835_dma_desc_free(struct virt_dma_desc 
> *vd)
>   container_of(vd, struct bcm2835_desc, vd));
>  }
>  
> -static void bcm2835_dma_create_cb_set_length(
> - struct bcm2835_chan *chan,
> - struct bcm2835_dma_cb *control_block,
> - size_t len,
> - size_t period_len,
> - size_t *total_len,
> - u32 finalextrainfo)
> +static bool
> +bcm2835_dma_create_cb_set_length(struct bcm2835_chan *chan,
> +  struct bcm2835_dma_cb *control_block,
> +  size_t len, size_t period_len,
> +  size_t *total_len)

Can you document this function, what's return value means? look like if
need extrainfo?

>  {
>   size_t max_len = bcm2835_dma_max_frame_length(chan);
>  
> @@ -302,7 +300,7 @@ static void bcm2835_dma_create_cb_set_length(
>  
>   /* finished if we have no period_length */
>   if (!period_len)
> - return;
> + return false;
>  
>   /*
>* period_len means: that we need to generate
> @@ -316,7 +314,7 @@ static void bcm2835_dma_create_cb_set_length(
>   if (*total_len + control_block->length < period_len) {
>   /* update number of bytes in this period so far */
>   *total_len += control_block->length;
> - return;
> + return false;
>   }
>  
>   /* calculate the length that remains to reach period_length */
> @@ -325,8 +323,7 @@ static void bcm2835_dma_create_cb_set_length(
>   /* reset total_length for next period */
>   *total_len = 0;
>  
> - /* add extrainfo bits in info */
> - control_block->info |= finalextrainfo;
> + return true;
>  }
>  
>  static inline size_t bcm2835_dma_count_frames_for_sg(
> @@ -352,7 +349,6 @@ static inline size_t bcm2835_dma_count_frames_for_sg(
>   * @chan:   the @dma_chan for which we run this
>   * @direction:  the direction in which we transfer
>   * @cyclic: it is a cyclic transfer
> - * @info:   the default info bits to apply per controlblock
>   * @frames: number of controlblocks to allocate
>   * @src:the src address to assign
>   * @dst:the dst address to assign
> @@ -360,22 +356,24 @@ static inline size_t bcm2835_dma_count_frames_for_sg(
>   * @period_len: the period length when to apply @finalextrainfo
>   *  in addition to the last transfer
>   *  this will also break some control-blocks early
> - * @finalextrainfo: additional bits in last controlblock
> - *  (or when period_len is reached in case of cyclic)
>   * @gfp:the GFP flag to use for allocation
> + * @flags
>   */
>  static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   struct dma_chan *chan, enum dma_transfer_direction direction,
> - bool cyclic, u32 info, u32 finalextrainfo, size_t frames,
> - dma_addr_t src, dma_addr_t dst, size_t buf_len,
> - size_t period_len, gfp_t gfp)
> + bool cyclic, size_t frames, dma_addr_t src, dma_addr_t dst,
> + size_t buf_len, size_t period_len, gfp_t gfp, unsigned long flags)
>  {
> + struct bcm2835_dmadev *od = to_bcm2835_dma_dev(chan->device);
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   size_t len = buf_len, total_len;
>   size_t frame;
>   struct bcm2835_desc *d;
>   struct bcm2835_cb_entry *cb_entry;
>   struct bcm2835_dma_cb *control_block;
> + u32 extrainfo = bcm2835_dma_prepare_cb_extra(c, direction, cyclic,
> +  false, flags);
> + bool zero_page = false;
>  
>   if (!frames)
>   return NULL;
> @@ -389,6 +387,14 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   d->dir = direction;
>   d->cyclic = cyclic;
>  
> + switch (direction) {
> + case DMA_MEM_TO_MEM:
> + case DMA_DEV_TO_MEM:
> + break;
> + default:
> + zero_page = src == od->zero_page;
> + }
> +
>   /*
>* Iterate over all frames, create a control block
>* for each frame and link them together.
> @@ -402,7 +408,8 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>  
>   /* fill 

Re: [PATCH 06/18] dmaengine: bcm2835: make address increment platform independent

[Frank Li]

On Fri, May 24, 2024 at 07:26:50PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Actually the criteria to increment source & destination address doesn't
> based on platform specific bits. It's just the DMA transfer direction which
> is translated into the info bits. So introduce two new helper functions
> and get the rid of these platform specifics.
> 

Fix increment source & destination address depend on the platform drvdata.
It should be depend on dma_transfer_direction.

look like it is bug fixes. Can you add fixes tag.

> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index ef452ebb3c15..d6c5a2762a46 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -252,6 +252,24 @@ static u32 bcm2835_dma_prepare_cb_extra(struct 
> bcm2835_chan *c,
>   return result;
>  }
>  
> +static inline bool need_src_incr(enum dma_transfer_direction direction)
> +{
> + return direction != DMA_DEV_TO_MEM;
> +}
> +
> +static inline bool need_dst_incr(enum dma_transfer_direction direction)
> +{
> + switch (direction) {
> + case DMA_MEM_TO_MEM:
> + case DMA_DEV_TO_MEM:
> + return true;
> + default:
> + break;
> + }
> +
> + return false;
> +}
> +
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
>  {
>   size_t i;
> @@ -336,10 +354,8 @@ static inline size_t bcm2835_dma_count_frames_for_sg(
>   * @cyclic: it is a cyclic transfer
>   * @info:   the default info bits to apply per controlblock
>   * @frames: number of controlblocks to allocate
> - * @src:the src address to assign (if the S_INC bit is set
> - *  in @info, then it gets incremented)
> - * @dst:the dst address to assign (if the D_INC bit is set
> - *  in @info, then it gets incremented)
> + * @src:the src address to assign
> + * @dst:the dst address to assign
>   * @buf_len:the full buffer length (may also be 0)
>   * @period_len: the period length when to apply @finalextrainfo
>   *  in addition to the last transfer
> @@ -408,9 +424,9 @@ static struct bcm2835_desc *bcm2835_dma_create_cb_chain(
>   d->cb_list[frame - 1].cb->next = cb_entry->paddr;
>  
>   /* update src and dst and length */
> - if (src && (info & BCM2835_DMA_S_INC))
> + if (src && need_src_incr(direction))
>   src += control_block->length;
> - if (dst && (info & BCM2835_DMA_D_INC))
> + if (dst && need_dst_incr(direction))
>   dst += control_block->length;
>  
>   /* Length of total transfer */
> -- 
> 2.34.1
> 

Re: [PATCH 05/18] dmaengine: bcm2835: move CB final extra info generation into function

[Frank Li]

On Fri, May 24, 2024 at 07:26:49PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Similar to the info generation, generate the final extra info with a
> separate function. This is necessary to introduce other platforms
> with different info bits.

Each patch commit is independent. 

Introduce common help function to generate the final extra info to reduce
duplicate codes in each DMA operation.


> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 7cef7ff89575..ef452ebb3c15 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -229,6 +229,29 @@ static u32 bcm2835_dma_prepare_cb_info(struct 
> bcm2835_chan *c,
>   return result;
>  }
>  
> +static u32 bcm2835_dma_prepare_cb_extra(struct bcm2835_chan *c,
> + enum dma_transfer_direction direction,
> + bool cyclic, bool final,
> + unsigned long flags)
> +{
> + u32 result = 0;
> +
> + if (cyclic) {
> + if (flags & DMA_PREP_INTERRUPT)
> + result |= BCM2835_DMA_INT_EN;
> + } else {
> + if (!final)
> + return 0;
> +
> + result |= BCM2835_DMA_INT_EN;
> +
> + if (direction == DMA_MEM_TO_MEM)
> + result |= BCM2835_DMA_WAIT_RESP;
> + }


move if (direction == DMA_MEM_TO_MEM) outof else branch. 
DMA_MEM_TO_MEM is impossible for cyclic. Reduce if level can help
easy to follow up.


if (cyclic)
...
else
...

if (direction == DMA_MEM_TO_MEM)
result |= BCM2835_DMA_WAIT_RESP; 



> +
> + return result;
> +}
> +
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
>  {
>   size_t i;
> @@ -644,7 +667,8 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_memcpy(
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   u32 info = bcm2835_dma_prepare_cb_info(c, DMA_MEM_TO_MEM, false);
> - u32 extra = BCM2835_DMA_INT_EN | BCM2835_DMA_WAIT_RESP;
> + u32 extra = bcm2835_dma_prepare_cb_extra(c, DMA_MEM_TO_MEM, false,
> +  true, 0);
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
>  
> @@ -675,7 +699,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   struct bcm2835_desc *d;
>   dma_addr_t src = 0, dst = 0;
>   u32 info = bcm2835_dma_prepare_cb_info(c, direction, false);
> - u32 extra = BCM2835_DMA_INT_EN;
> + u32 extra = bcm2835_dma_prepare_cb_extra(c, direction, false, true, 0);
>   size_t frames;
>  
>   if (!is_slave_direction(direction)) {
> @@ -723,7 +747,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
>   dma_addr_t src, dst;
>   u32 info = bcm2835_dma_prepare_cb_info(c, direction,
>  buf_addr == od->zero_page);
> - u32 extra = 0;
> + u32 extra = bcm2835_dma_prepare_cb_extra(c, direction, true, true, 0);
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
>  
> @@ -739,9 +763,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
>   return NULL;
>   }
>  
> - if (flags & DMA_PREP_INTERRUPT)
> - extra |= BCM2835_DMA_INT_EN;
> - else
> + if (!(flags & DMA_PREP_INTERRUPT))
>   period_len = buf_len;
>  
>   /*
> -- 
> 2.34.1
> 

Re: [PATCH 04/18] dmaengine: bcm2835: move CB info generation into separate function

[Frank Li]

On Fri, May 24, 2024 at 07:26:48PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Actually the generation of the Control Block info follows some simple
> rules. So handle this with a separate function to avoid open coding
> for every DMA operation. Another advantage is that we can easier
> introduce other platforms with different info bits.

May simple said as:

Introduce common help funtion to prepare Control Block Info to avoid
dupicate code in every DMA operation.
 
> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 50 +--
>  1 file changed, 32 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 528c4593b45a..7cef7ff89575 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -201,6 +201,34 @@ static inline struct bcm2835_desc *to_bcm2835_dma_desc(
>   return container_of(t, struct bcm2835_desc, vd.tx);
>  }
>  
> +static u32 bcm2835_dma_prepare_cb_info(struct bcm2835_chan *c,
> +enum dma_transfer_direction direction,
> +bool zero_page)
> +{
> + u32 result;
> +
> + if (direction == DMA_MEM_TO_MEM)
> + return BCM2835_DMA_D_INC | BCM2835_DMA_S_INC;
> +
> + result = BCM2835_DMA_WAIT_RESP;
> +
> + /* Setup DREQ channel */
> + if (c->dreq != 0)
> + result |= BCM2835_DMA_PER_MAP(c->dreq);
> +
> + if (direction == DMA_DEV_TO_MEM) {
> + result |= BCM2835_DMA_S_DREQ | BCM2835_DMA_D_INC;
> + } else {
> + result |= BCM2835_DMA_D_DREQ | BCM2835_DMA_S_INC;
> +
> + /* non-lite channels can write zeroes w/o accessing memory */
> + if (zero_page && !c->is_lite_channel)
> + result |= BCM2835_DMA_S_IGNORE;
> + }
> +
> + return result;
> +}
> +
>  static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
>  {
>   size_t i;
> @@ -615,7 +643,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_memcpy(
>  {
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
> - u32 info = BCM2835_DMA_D_INC | BCM2835_DMA_S_INC;
> + u32 info = bcm2835_dma_prepare_cb_info(c, DMA_MEM_TO_MEM, false);
>   u32 extra = BCM2835_DMA_INT_EN | BCM2835_DMA_WAIT_RESP;
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
> @@ -646,7 +674,7 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   dma_addr_t src = 0, dst = 0;
> - u32 info = BCM2835_DMA_WAIT_RESP;
> + u32 info = bcm2835_dma_prepare_cb_info(c, direction, false);
>   u32 extra = BCM2835_DMA_INT_EN;
>   size_t frames;
>  
> @@ -656,19 +684,14 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_slave_sg(
>   return NULL;
>   }
>  
> - if (c->dreq != 0)
> - info |= BCM2835_DMA_PER_MAP(c->dreq);
> -
>   if (direction == DMA_DEV_TO_MEM) {
>   if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   src = c->cfg.src_addr;
> - info |= BCM2835_DMA_S_DREQ | BCM2835_DMA_D_INC;
>   } else {
>   if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   dst = c->cfg.dst_addr;
> - info |= BCM2835_DMA_D_DREQ | BCM2835_DMA_S_INC;
>   }
>  
>   /* count frames in sg list */
> @@ -698,7 +721,8 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>   struct bcm2835_desc *d;
>   dma_addr_t src, dst;
> - u32 info = BCM2835_DMA_WAIT_RESP;
> + u32 info = bcm2835_dma_prepare_cb_info(c, direction,
> +buf_addr == od->zero_page);
>   u32 extra = 0;
>   size_t max_len = bcm2835_dma_max_frame_length(c);
>   size_t frames;
> @@ -729,26 +753,16 @@ static struct dma_async_tx_descriptor 
> *bcm2835_dma_prep_dma_cyclic(
> "%s: buffer_length (%zd) is not a multiple of 
> period_len (%zd)\n",
> __func__, buf_len, period_len);
>  
> - /* Setup DREQ channel */
> - if (c->dreq != 0)
> - info |= BCM2835_DMA_PER_MAP(c->dreq);
> -
>   if (direction == DMA_DEV_TO_MEM) {
>   if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   src = c->cfg.src_addr;
>   dst = buf_addr;
> - info |= BCM2835_DMA_S_DREQ | BCM2835_DMA_D_INC;
>   } else {
>   if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>   return NULL;
>   dst = c->cfg.dst_addr;
> 

Re: [PATCH 02/18] dmaengine: bcm2835: Support common dma-channel-mask

[Frank Li]

On Fri, May 24, 2024 at 07:26:46PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren 
> 
> Nowadays there is a generic property for dma-channel-mask in the DMA
> controller binding. So prefer this one instead of the old vendor specific
> one. Print a warning in case the old one is used. Btw use the result of
> of_property_read_u32() as return code in error case.

Use generic 'dma-channel-mask' property. Print a warning in case the
old brcm,dma-channel-mask is used.

Did you update binding doc?

> 
> Signed-off-by: Stefan Wahren 
> Signed-off-by: Dave Stevenson 
> ---
>  drivers/dma/bcm2835-dma.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 9d74fe97452e..528c4593b45a 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -941,12 +941,19 @@ static int bcm2835_dma_probe(struct platform_device 
> *pdev)
>   }
>  
>   /* Request DMA channel mask from device tree */
> - if (of_property_read_u32(pdev->dev.of_node,
> - "brcm,dma-channel-mask",
> - _available)) {
> - dev_err(>dev, "Failed to get channel mask\n");
> - rc = -EINVAL;
> - goto err_no_dma;
> + rc = of_property_read_u32(pdev->dev.of_node, "dma-channel-mask",
> +   _available);
> +
> + if (rc) {
> + /* Try deprecated property */
> + if (of_property_read_u32(pdev->dev.of_node,
> +  "brcm,dma-channel-mask",
> +  _available)) {
> + dev_err(>dev, "Failed to get channel mask\n");
> + goto err_no_dma;
> + }
> +
> + dev_warn(>dev, "brcm,dma-channel-mask deprecated - please 
> update DT\n");
>   }
>  
>   /* get irqs for each channel that we support */
> -- 
> 2.34.1
> 

[med-svn] [Git][med-team/simrisc][upstream] New upstream version 16.01.00

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch upstream at Debian Med / simrisc


Commits:
9fefa13a by Frank B. Brokken at 2024-06-05T17:02:13+02:00
New upstream version 16.01.00
- - - - -


30 changed files:

- INSTALL.im
- VERSION
- analysis/run.cc
- changelog
- costs/cost.cc
- costs/costs.h
- costs/discount.cc
- costs/othertreatment.cc
- documentation/man/include/configfiles.yo
- documentation/man/simrisc.yo
- documentation/man/simriscparams.yo
- documentation/manual/simrisc.yo
- dot.config/simrisc
- icmake/beep
- + icmake/cxxdefine
- + loop/addbiopcosts.cc
- − loop/addcost.cc
- loop/caseinit.cc
- loop/characteristics.cc
- loop/cptindices.cc
- loop/data.cc
- + loop/falsenegative.cc
- loop/gencases.cc
- loop/headerdata.cc
- loop/headerrounds.cc
- loop/intervalcancer.cc
- loop/iterate.cc
- loop/leaving.cc
- + loop/left.cc
- loop/loop.h


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/9fefa13afb94240e6876f88c1c3298cbf77ef6e2

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/9fefa13afb94240e6876f88c1c3298cbf77ef6e2
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[med-svn] [Git][med-team/simrisc][debian/latest] 3 commits: Ready for simrisc 16.01.00-1

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch debian/latest at Debian Med / simrisc


Commits:
963b3369 by Frank B. Brokken at 2024-06-05T17:02:10+02:00
Ready for simrisc 16.01.00-1

- - - - -
9fefa13a by Frank B. Brokken at 2024-06-05T17:02:13+02:00
New upstream version 16.01.00
- - - - -
7ac640ad by Frank B. Brokken at 2024-06-05T17:02:17+02:00
Update upstream source from tag upstream/16.01.00

Update to upstream version 16.01.00
with Debian dir 4867f3311751423174e33300abbfdccf96b0a8ba
- - - - -


30 changed files:

- INSTALL.im
- VERSION
- analysis/run.cc
- changelog
- costs/cost.cc
- costs/costs.h
- costs/discount.cc
- costs/othertreatment.cc
- debian/changelog
- debian/tests/simrisc-test1.expected.gz
- debian/tests/simrisc-test2.expected.gz
- documentation/man/include/configfiles.yo
- documentation/man/simrisc.yo
- documentation/man/simriscparams.yo
- documentation/manual/simrisc.yo
- dot.config/simrisc
- icmake/beep
- + icmake/cxxdefine
- + loop/addbiopcosts.cc
- − loop/addcost.cc
- loop/caseinit.cc
- loop/characteristics.cc
- loop/cptindices.cc
- loop/data.cc
- + loop/falsenegative.cc
- loop/gencases.cc
- loop/headerdata.cc
- loop/headerrounds.cc
- loop/intervalcancer.cc
- loop/iterate.cc


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/compare/dae74bf0d44b00b5268cd56742cdb944ad68c54e...7ac640adb9e14b1ec952443ae235e5cf8f47a84e

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/compare/dae74bf0d44b00b5268cd56742cdb944ad68c54e...7ac640adb9e14b1ec952443ae235e5cf8f47a84e
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

[med-svn] [Git][med-team/simrisc][pristine-tar] pristine-tar data for simrisc_16.01.00.orig.tar.gz

[Frank B. Brokken (@fbb-guest)]

Frank B. Brokken pushed to branch pristine-tar at Debian Med / simrisc


Commits:
519d94b6 by Frank B. Brokken at 2024-06-05T17:02:17+02:00
pristine-tar data for simrisc_16.01.00.orig.tar.gz

- - - - -


2 changed files:

- + simrisc_16.01.00.orig.tar.gz.delta
- + simrisc_16.01.00.orig.tar.gz.id


Changes:

=
simrisc_16.01.00.orig.tar.gz.delta
=
Binary files /dev/null and b/simrisc_16.01.00.orig.tar.gz.delta differ


=
simrisc_16.01.00.orig.tar.gz.id
=
@@ -0,0 +1 @@
+81809260e0e8acd95cc722ce0789cab51b0072b0



View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/519d94b6b9dc2698b3280f2ad6b4ebee6d71a58f

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://salsa.debian.org/med-team/simrisc/-/commit/519d94b6b9dc2698b3280f2ad6b4ebee6d71a58f
You're receiving this email because of your account on salsa.debian.org.


___
debian-med-commit mailing list
debian-med-com...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-commit

Re: PS: virtualbox 7.0.16 and Windows 11 guest

[Frank]

Am Mittwoch, dem 05.06.2024 um 13:59 +0200 schrieb Frank:
> Am Freitag, dem 19.04.2024 um 17:31 +0200 schrieb Ralf Mardorf:
> > On Fri, 2024-04-19 at 16:47 +0200, Frank wrote:
> > > https://linuxtldr.com/windows-docker-container/
> > 
> > 
> I installed Win in the above mentioned docker container and that went
> pretty smooth, though I haven't figuered out how to share data with
> the
> host.
> One issue I have is that there's no sound output, does this work with
> Virtualbox?
> Frank
ok,
I've been playing around a little more and with the right settings in
Remmina I can connect to the container via RDP incl. data sharing
between host and client as well as sound in/output working.

Frank

Re: PS: virtualbox 7.0.16 and Windows 11 guest

[Frank]

Am Freitag, dem 19.04.2024 um 17:31 +0200 schrieb Ralf Mardorf:
> On Fri, 2024-04-19 at 16:47 +0200, Frank wrote:
> > https://linuxtldr.com/windows-docker-container/
> 
> Thank you. The article doesn't mention how to share data between
> "host"
> and "guest"/container. The article doesn't mention, if it's possible
> to
> migrate the license from my current Windows 11 install to the
> Docker's
Have you been able to further advance, either witht he docker setup or
your Virtualbox?
I installed Win in the above mentioned docker container and that went
pretty smooth, though I haven't figuered out how to share data with the
host.
One issue I have is that there's no sound output, does this work with
Virtualbox?
Frank

Re: Request permissions to Create KIP

[Frank Yang]

Hi Josep,

I just got Confluence account, too. Could you grant me the permission to create 
KIP as well? Thank you.

JIRA: yangpoan
Confluence: yangpoan

Best Regards,
PoAn Yang

> On Jun 5, 2024, at 7:35 PM, Josep Prat  wrote:
> 
> Hi!
> Thanks for your interest in Apache Kafka. Your accounts are now all set.
> 
> Best,
> 
> On Wed, Jun 5, 2024 at 1:32 PM Kuan Po Tseng  wrote:
> 
>> Hello everyone,
>> 
>> I hope this message finds you well.
>> I am writing to request permissions to create a KIP. Below are my JIRA and
>> Confluence IDs:
>> 
>> JIRA: brandboat
>> Confluence: brandboat
>> Could you please grant me the necessary permissions?
>> 
>> Thank you very much for your time and assistance.
>> 
>> Best regards,
>> Kuan Po Tseng
>> 
> 
> 
> -- 
> [image: Aiven] 
> 
> *Josep Prat*
> Open Source Engineering Director, *Aiven*
> josep.p...@aiven.io   |   +491715557497
> aiven.io    |   
>     
> *Aiven Deutschland GmbH*
> Alexanderufer 3-7, 10117 Berlin
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> Amtsgericht Charlottenburg, HRB 209739 B

[digikam] [Bug 488061] New: the tool Image Mosaic Wall will crashes

[Frank]

https://bugs.kde.org/show_bug.cgi?id=488061

Bug ID: 488061
   Summary: the tool Image Mosaic Wall will crashes
Classification: Applications
   Product: digikam
   Version: 8.3.0
  Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: ImageEditor-Plugins
  Assignee: digikam-bugs-n...@kde.org
  Reporter: fwi...@web.de
  Target Milestone: ---

Hello,
I would like to create a mosaic image using the Image Mosaic Wall... tool
(Extras/Image Mosaic Wall..), which works well with the standard grid settings
of 100 x 100. However, if I change the grid settings, e.g. 150 x 150, and then
click on "Create Mosaic", the entire digikam program usually crashes without an
error message. Sometimes you also get an error message that the read operation
could not be carried out in the memory.
Perhaps you can fix the problem in a future version.
Many thanks and best regards
Frank

STEPS TO REPRODUCE
1.  open the Tool Image Mosaic Wall
2.  create a mosaic with the default settings
3.  change the default settings (for example grid settings 150 x150)
4. click the button "Create Mosaic" the program will crashes immediately

OBSERVED RESULT
- the program crashes immediately

EXPECTED RESULT
- creation of the mosaic

SOFTWARE/OS VERSIONS
Windows: 11 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[FFmpeg-devel] [PATCH v2 2/2] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index bfc3c121fd..c4f64d5da7 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63)
+return AVERROR(EINVAL);
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+if (qp_out[j] + delta_qp_out > 63)
+return AVERROR(EINVAL);
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/2] lavc/vvc: Use sps_chroma_qp_table return code

[Frank Plowman]

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..bfc3c121fd 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -186,8 +186,11 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
 sps_inter(sps);
 sps_partition_constraints(sps);
 sps_ladf(sps);
-if (r->sps_chroma_format_idc != 0)
-sps_chroma_qp_table(sps);
+if (r->sps_chroma_format_idc != 0) {
+ret = sps_chroma_qp_table(sps);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/vvc: Prevent overflow in chroma QP derivation

[Frank Plowman]

On the top of p. 112 in VVC (09/2023):

It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ps.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 1b23675c98..b024caf460 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -101,9 +101,14 @@ static int sps_chroma_qp_table(VVCSPS *sps)
 
 qp_out[0] = qp_in[0] = r->sps_qp_table_start_minus26[i] + 26;
 for (int j = 0; j < num_points_in_qp_table; j++ ) {
+const uint8_t delta_qp_out = (r->sps_delta_qp_in_val_minus1[i][j] 
^ r->sps_delta_qp_diff_val[i][j]);
 delta_qp_in[j] = r->sps_delta_qp_in_val_minus1[i][j] + 1;
+if (qp_in[j] + delta_qp_in[j] > 63)
+return AVERROR_INVALIDDATA;
 qp_in[j+1] = qp_in[j] + delta_qp_in[j];
-qp_out[j+1] = qp_out[j] + (r->sps_delta_qp_in_val_minus1[i][j] ^ 
r->sps_delta_qp_diff_val[i][j]);
+if (qp_out[j] + delta_qp_out > 63)
+return AVERROR_INVALIDDATA;
+qp_out[j+1] = qp_out[j] + delta_qp_out;
 }
 sps->chroma_qp_table[i][qp_in[0] + off] = qp_out[0];
 for (int k = qp_in[0] - 1 + off; k >= 0; k--)
-- 
2.45.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[Bug 2064321] Re: Power guest secure boot with key management: kernel portion

[Frank Heimes]

Hello, is there already a list of (kernel) commits that are required?
(So that we can check whether they are incl. in the Ubuntu kernel or not; and 
in case not do the submissions to the Ubuntu kernel team.)

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

** Changed in: linux (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064321

Title:
  Power guest secure boot with key management: kernel portion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064321/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064345] Re: Power guest secure boot with key management: userspace portion

[Frank Heimes]

Since this is about a new ppc64el specific tool ("secvarctl", that does not yet 
exists in LP),
I'll marked this ticket as temp. affecting "powerpc-utils", until we have a 
first upload.

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage 
(ubuntu-power-triage)

** Changed in: linux (Ubuntu)
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => 
(unassigned)

** Package changed: linux (Ubuntu) => powerpc-utils (Ubuntu)

** Changed in: powerpc-utils (Ubuntu)
 Assignee: (unassigned) => Patricia Domingues (patriciasd)

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

** Changed in: powerpc-utils (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064345

Title:
  Power guest secure boot with key management: userspace portion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064345/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064345] Re: Power guest secure boot with key management: userspace portion

[Frank Heimes]

I'm assuming that this is the upstream repository of 'secvarctl':
https://github.com/open-power/secvarctl

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064345

Title:
  Power guest secure boot with key management: userspace portion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2064345/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH 0/6] Introduce extension implied rules

[Frank Chang]

Patchset resend:
https://lists.gnu.org/archive/html/qemu-riscv/2024-06/msg00130.html


 於 2024年6月3日 週一 下午2:07寫道：

> From: Frank Chang 
>
> Currently, the implied extensions are enabled and checked in
> riscv_cpu_validate_set_extensions(). However, the order of enabling the
> implied extensions must follow a strict sequence, which is error-prone.
>
> This patchset introduce extension implied rule helpers to enable the
> implied extensions. This also eliminates the old-fashioned ordering
> requirement. For example, Zvksg implies Zvks, Zvks implies Zvksed, etc.,
> removing the need to check the implied rules of Zvksg before Zvks.
>
> The idea [1] and the implied rules [2] are referenced from LLVM.
>
> [1]
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/TargetParser/RISCVISAInfo.cpp#L875
> [2]
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVFeatures.td
>
> Frank Chang (6):
>   target/riscv: Introduce extension implied rules definition
>   target/riscv: Introduce extension implied rule helpers
>   target/riscv: Add MISA implied rules
>   target/riscv: Add standard extension implied rules
>   target/riscv: Add Zc extension implied rule
>   target/riscv: Remove extension auto-update check statements
>
>  target/riscv/cpu.c | 396 +
>  target/riscv/cpu.h |  17 ++
>  target/riscv/tcg/tcg-cpu.c | 233 +++---
>  3 files changed, 531 insertions(+), 115 deletions(-)
>
> --
> 2.43.2
>
>
>

[PATCH RESEND 6/6] target/riscv: Remove extension auto-update check statements

[frank . chang]

From: Frank Chang 

Remove the old-fashioned extension auto-update check statements as
they are replaced by the extension implied rules.

Signed-off-by: Frank Chang 
---
 target/riscv/tcg/tcg-cpu.c | 115 -
 1 file changed, 115 deletions(-)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index ed10ac799a..c1926db370 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -469,10 +469,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }
 
-if (cpu->cfg.ext_zfh) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zfhmin), true);
-}
-
 if (cpu->cfg.ext_zfhmin && !riscv_has_ext(env, RVF)) {
 error_setg(errp, "Zfh/Zfhmin extensions require F extension");
 return;
@@ -494,9 +490,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, Error 
**errp)
 error_propagate(errp, local_err);
 return;
 }
-
-/* The V vector extension depends on the Zve64d extension */
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64d), true);
 }
 
 /* The Zve64d extension depends on the Zve64f extension */
@@ -505,18 +498,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 error_setg(errp, "Zve64d/V extensions require D extension");
 return;
 }
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64f), true);
-}
-
-/* The Zve64f extension depends on the Zve64x and Zve32f extensions */
-if (cpu->cfg.ext_zve64f) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve64x), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32f), true);
-}
-
-/* The Zve64x extension depends on the Zve32x extension */
-if (cpu->cfg.ext_zve64x) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32x), true);
 }
 
 /* The Zve32f extension depends on the Zve32x extension */
@@ -525,11 +506,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 error_setg(errp, "Zve32f/Zve64f extensions require F extension");
 return;
 }
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zve32x), true);
-}
-
-if (cpu->cfg.ext_zvfh) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvfhmin), true);
 }
 
 if (cpu->cfg.ext_zvfhmin && !cpu->cfg.ext_zve32f) {
@@ -552,11 +528,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }
 
-/* Set the ISA extensions, checks should have happened above */
-if (cpu->cfg.ext_zhinx) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-}
-
 if ((cpu->cfg.ext_zdinx || cpu->cfg.ext_zhinxmin) && !cpu->cfg.ext_zfinx) {
 error_setg(errp, "Zdinx/Zhinx/Zhinxmin extensions require Zfinx");
 return;
@@ -574,27 +545,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 }
 }
 
-if (cpu->cfg.ext_zce) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcb), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmp), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmt), true);
-if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
-}
-}
-
-/* zca, zcd and zcf has a PRIV 1.12.0 restriction */
-if (riscv_has_ext(env, RVC) && env->priv_ver >= PRIV_VERSION_1_12_0) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
-if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
-}
-if (riscv_has_ext(env, RVD)) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcd), true);
-}
-}
-
 if (mcc->misa_mxl_max != MXL_RV32 && cpu->cfg.ext_zcf) {
 error_setg(errp, "Zcf extension is only relevant to RV32");
 return;
@@ -628,48 +578,6 @@ void riscv_cpu_validate_set_extensions(RISCVCPU *cpu, 
Error **errp)
 return;
 }
 
-/*
- * Shorthand vector crypto extensions
- */
-if (cpu->cfg.ext_zvknc) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkn), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvbc), true);
-}
-
-if (cpu->cfg.ext_zvkng) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkn), true);
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkg), true);
-}
-
-if (cpu->cfg.ext_zvkn) {
-cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zvkned), true);
-cpu_cfg_ext_auto_update(cpu

[PATCH RESEND 1/6] target/riscv: Introduce extension implied rules definition

[frank . chang]

From: Frank Chang 

RISCVCPUImpliedExtsRule is created to store the implied rules.
'is_misa' flag is used to distinguish whether the rule is derived
from the MISA or other extensions.
'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores
the offset of the extension defined in RISCVCPUConfig. 'ext' will also
serve as the key of the hash tables to look up the rule in the following
commit.

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c |  8 
 target/riscv/cpu.h | 18 ++
 2 files changed, 26 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index cee6fc4a9a..c7e5cec7ef 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2242,6 +2242,14 @@ RISCVCPUProfile *riscv_profiles[] = {
 NULL,
 };
 
+RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
+NULL
+};
+
+RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
+NULL
+};
+
 static Property riscv_cpu_properties[] = {
 DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
 
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 1501868008..b5a036cf27 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -122,6 +122,24 @@ typedef enum {
 EXT_STATUS_DIRTY,
 } RISCVExtStatus;
 
+typedef struct riscv_cpu_implied_exts_rule RISCVCPUImpliedExtsRule;
+
+struct riscv_cpu_implied_exts_rule {
+/* Bitmask indicates the rule enabled status for the harts. */
+uint64_t enabled;
+/* True if this is a MISA implied rule. */
+bool is_misa;
+/* ext is MISA bit if is_misa flag is true, else extension offset. */
+const uint32_t ext;
+const uint32_t implied_misas;
+const uint32_t implied_exts[];
+};
+
+extern RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[];
+extern RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[];
+
+#define RISCV_IMPLIED_EXTS_RULE_END -1
+
 #define MMU_USER_IDX 3
 
 #define MAX_RISCV_PMPS (16)
-- 
2.43.2

[PATCH RESEND 0/6] Introduce extension implied rules

[frank . chang]

From: Frank Chang 

Currently, the implied extensions are enabled and checked in
riscv_cpu_validate_set_extensions(). However, the order of enabling the
implied extensions must follow a strict sequence, which is error-prone.

This patchset introduce extension implied rule helpers to enable the
implied extensions. This also eliminates the old-fashioned ordering
requirement. For example, Zvksg implies Zvks, Zvks implies Zvksed, etc.,
removing the need to check the implied rules of Zvksg before Zvks.

The idea [1] and the implied rules [2] are referenced from LLVM.

[1] 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/TargetParser/RISCVISAInfo.cpp#L875
[2] 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVFeatures.td

Frank Chang (6):
  target/riscv: Introduce extension implied rules definition
  target/riscv: Introduce extension implied rule helpers
  target/riscv: Add MISA implied rules
  target/riscv: Add standard extension implied rules
  target/riscv: Add Zc extension implied rule
  target/riscv: Remove extension auto-update check statements

 target/riscv/cpu.c | 396 +
 target/riscv/cpu.h |  18 ++
 target/riscv/tcg/tcg-cpu.c | 238 +++---
 3 files changed, 537 insertions(+), 115 deletions(-)

--
2.43.2

[PATCH RESEND 4/6] target/riscv: Add standard extension implied rules

[frank . chang]

From: Frank Chang 

Add standard extension implied rules to enable the implied extensions of
the standard extension recursively.

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c | 340 +
 1 file changed, 340 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index a6e9055c5f..80b238060a 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2289,12 +2289,352 @@ static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
 },
 };
 
+static RISCVCPUImpliedExtsRule ZCB_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcb),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCD_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcd),
+.implied_misas = RVD,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCE_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zce),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zcb), CPU_CFG_OFFSET(ext_zcmp),
+CPU_CFG_OFFSET(ext_zcmt),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCF_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcf),
+.implied_misas = RVF,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCMP_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcmp),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZCMT_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zcmt),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zca), CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZDINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zdinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfinx),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZFA_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfa),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFBFMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfbfmin),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFH_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfh),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfhmin),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZFHMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfhmin),
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule ZFINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zfinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZHINX_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zhinx),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zhinxmin),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZHINXMIN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zhinxmin),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zfinx),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZICNTR_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zicntr),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZIHPM_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zihpm),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZK_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zk),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zkn), CPU_CFG_OFFSET(ext_zkr),
+CPU_CFG_OFFSET(ext_zkt),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZKN_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zkn),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
+CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zkne),
+CPU_CFG_OFFSET(ext_zknd), CPU_CFG_OFFSET(ext_zknh),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZKS_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zks),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
+CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zksed),
+CPU_CFG_OFFSET(ext_zksh),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZVBB_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zvbb),
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zvkb),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule ZVE32F_IMPLIED = {
+.ext = CPU_CFG_OFFSET(ext_zve32f),
+.implied_misas = RVF

[PATCH RESEND 2/6] target/riscv: Introduce extension implied rule helpers

[frank . chang]

From: Frank Chang 

Introduce helpers to enable the extensions based on the implied rules.
The implied extensions are enabled recursively, so we don't have to
expand all of them manually. This also eliminates the old-fashioned
ordering requirement. For example, Zvksg implies Zvks, Zvks implies
Zvksed, etc., removing the need to check the implied rules of Zvksg
before Zvks.

Signed-off-by: Frank Chang 
---
 target/riscv/tcg/tcg-cpu.c | 89 ++
 1 file changed, 89 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 683f604d9f..899d605d36 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -36,6 +36,9 @@
 static GHashTable *multi_ext_user_opts;
 static GHashTable *misa_ext_user_opts;
 
+static GHashTable *misa_implied_rules;
+static GHashTable *ext_implied_rules;
+
 static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
 {
 return g_hash_table_contains(multi_ext_user_opts,
@@ -833,11 +836,95 @@ static void riscv_cpu_validate_profiles(RISCVCPU *cpu)
 }
 }
 
+static void riscv_cpu_init_implied_exts_rules(void)
+{
+RISCVCPUImpliedExtsRule *rule;
+int i;
+
+for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
+g_hash_table_insert(misa_implied_rules, GUINT_TO_POINTER(rule->ext),
+(gpointer)rule);
+}
+
+for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
+g_hash_table_insert(ext_implied_rules, GUINT_TO_POINTER(rule->ext),
+(gpointer)rule);
+}
+}
+
+static void cpu_enable_implied_rule(RISCVCPU *cpu,
+RISCVCPUImpliedExtsRule *rule)
+{
+CPURISCVState *env = >env;
+RISCVCPUImpliedExtsRule *ir;
+target_ulong hartid = 0;
+int i;
+
+#if !defined(CONFIG_USER_ONLY)
+hartid = env->mhartid;
+#endif
+
+if (!(rule->enabled & BIT_ULL(hartid))) {
+/* Enable the implied MISAs. */
+if (rule->implied_misas) {
+riscv_cpu_set_misa_ext(env, env->misa_ext | rule->implied_misas);
+
+for (i = 0; misa_bits[i] != 0; i++) {
+if (rule->implied_misas & misa_bits[i]) {
+ir = g_hash_table_lookup(misa_implied_rules,
+ GUINT_TO_POINTER(misa_bits[i]));
+
+if (ir) {
+cpu_enable_implied_rule(cpu, ir);
+}
+}
+}
+}
+
+/* Enable the implied extensions. */
+for (i = 0; rule->implied_exts[i] != RISCV_IMPLIED_EXTS_RULE_END; i++) 
{
+cpu_cfg_ext_auto_update(cpu, rule->implied_exts[i], true);
+
+ir = g_hash_table_lookup(ext_implied_rules,
+ GUINT_TO_POINTER(rule->implied_exts[i]));
+
+if (ir) {
+cpu_enable_implied_rule(cpu, ir);
+}
+}
+
+rule->enabled |= BIT_ULL(hartid);
+}
+}
+
+static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
+{
+RISCVCPUImpliedExtsRule *rule;
+int i;
+
+/* Enable the implied MISAs. */
+for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
+if (riscv_has_ext(>env, rule->ext)) {
+cpu_enable_implied_rule(cpu, rule);
+}
+}
+
+/* Enable the implied extensions. */
+for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
+if (isa_ext_is_enabled(cpu, rule->ext)) {
+cpu_enable_implied_rule(cpu, rule);
+}
+}
+}
+
 void riscv_tcg_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
 {
 CPURISCVState *env = >env;
 Error *local_err = NULL;
 
+riscv_cpu_init_implied_exts_rules();
+riscv_cpu_enable_implied_rules(cpu);
+
 riscv_cpu_validate_misa_priv(env, _err);
 if (local_err != NULL) {
 error_propagate(errp, local_err);
@@ -1343,6 +1430,8 @@ static void riscv_tcg_cpu_instance_init(CPUState *cs)
 
 misa_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
 multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
+misa_implied_rules = g_hash_table_new(NULL, g_direct_equal);
+ext_implied_rules = g_hash_table_new(NULL, g_direct_equal);
 riscv_cpu_add_user_properties(obj);
 
 if (riscv_cpu_has_max_extensions(obj)) {
-- 
2.43.2

[PATCH RESEND 5/6] target/riscv: Add Zc extension implied rule

[frank . chang]

From: Frank Chang 

Zc extension has special implied rules that need to be handled separately.

Signed-off-by: Frank Chang 
---
 target/riscv/tcg/tcg-cpu.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 899d605d36..ed10ac799a 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -897,11 +897,45 @@ static void cpu_enable_implied_rule(RISCVCPU *cpu,
 }
 }
 
+/* Zc extension has special implied rules that need to be handled separately. 
*/
+static void cpu_enable_zc_implied_rules(RISCVCPU *cpu)
+{
+RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
+CPURISCVState *env = >env;
+
+if (cpu->cfg.ext_zce) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcb), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmp), true);
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcmt), true);
+
+if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
+}
+}
+
+/* Zca, Zcd and Zcf has a PRIV 1.12.0 restriction */
+if (riscv_has_ext(env, RVC) && env->priv_ver >= PRIV_VERSION_1_12_0) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zca), true);
+
+if (riscv_has_ext(env, RVF) && mcc->misa_mxl_max == MXL_RV32) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcf), true);
+}
+
+if (riscv_has_ext(env, RVD)) {
+cpu_cfg_ext_auto_update(cpu, CPU_CFG_OFFSET(ext_zcd), true);
+}
+}
+}
+
 static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
 {
 RISCVCPUImpliedExtsRule *rule;
 int i;
 
+/* Enable the implied extensions for Zc. */
+cpu_enable_zc_implied_rules(cpu);
+
 /* Enable the implied MISAs. */
 for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
 if (riscv_has_ext(>env, rule->ext)) {
-- 
2.43.2

[PATCH RESEND 3/6] target/riscv: Add MISA implied rules

[frank . chang]

From: Frank Chang 

Add MISA extension implied rules to enable the implied extensions
of MISA recursively.

Signed-off-by: Frank Chang 
---
 target/riscv/cpu.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index c7e5cec7ef..a6e9055c5f 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -2242,8 +2242,56 @@ RISCVCPUProfile *riscv_profiles[] = {
 NULL,
 };
 
+static RISCVCPUImpliedExtsRule RVA_IMPLIED = {
+.is_misa = true,
+.ext = RVA,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zalrsc), CPU_CFG_OFFSET(ext_zaamo),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVD_IMPLIED = {
+.is_misa = true,
+.ext = RVD,
+.implied_misas = RVF,
+.implied_exts = { RISCV_IMPLIED_EXTS_RULE_END },
+};
+
+static RISCVCPUImpliedExtsRule RVF_IMPLIED = {
+.is_misa = true,
+.ext = RVF,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zicsr),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVM_IMPLIED = {
+.is_misa = true,
+.ext = RVM,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zmmul),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
+static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
+.is_misa = true,
+.ext = RVV,
+.implied_exts = {
+CPU_CFG_OFFSET(ext_zve64d),
+
+RISCV_IMPLIED_EXTS_RULE_END
+},
+};
+
 RISCVCPUImpliedExtsRule *riscv_misa_implied_rules[] = {
-NULL
+_IMPLIED, _IMPLIED, _IMPLIED,
+_IMPLIED, _IMPLIED, NULL
 };
 
 RISCVCPUImpliedExtsRule *riscv_ext_implied_rules[] = {
-- 
2.43.2

Re: [PATCH 2/6] target/riscv: Introduce extension implied rule helpers

[Frank Chang]

 於 2024年6月3日 週一 下午2:06寫道：
>
> From: Frank Chang 
>
> Introduce helpers to enable the extensions based on the implied rules.
> The implied extensions are enabled recursively, so we don't have to
> expand all of them manually. This also eliminates the old-fashioned
> ordering requirement. For example, Zvksg implies Zvks, Zvks implies
> Zvksed, etc., removing the need to check the implied rules of Zvksg
> before Zvks.
>
> Signed-off-by: Frank Chang 
> Reviewed-by: Jerry Zhang Jian 
> ---
>  target/riscv/tcg/tcg-cpu.c | 84 ++
>  1 file changed, 84 insertions(+)
>
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 683f604d9f..243a8547a2 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -36,6 +36,9 @@
>  static GHashTable *multi_ext_user_opts;
>  static GHashTable *misa_ext_user_opts;
>
> +static GHashTable *misa_implied_rules;
> +static GHashTable *ext_implied_rules;
> +
>  static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
>  {
>  return g_hash_table_contains(multi_ext_user_opts,
> @@ -833,11 +836,90 @@ static void riscv_cpu_validate_profiles(RISCVCPU *cpu)
>  }
>  }
>
> +static void riscv_cpu_init_implied_exts_rules(void)
> +{
> +RISCVCPUImpliedExtsRule *rule;
> +int i;
> +
> +for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
> +g_hash_table_insert(misa_implied_rules, GUINT_TO_POINTER(rule->ext),
> +(gpointer)rule);
> +}
> +
> +for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
> +g_hash_table_insert(ext_implied_rules, GUINT_TO_POINTER(rule->ext),
> +(gpointer)rule);
> +}
> +}
> +
> +static void cpu_enable_implied_rule(RISCVCPU *cpu,
> +RISCVCPUImpliedExtsRule *rule)
> +{
> +CPURISCVState *env = >env;
> +RISCVCPUImpliedExtsRule *ir;
> +int i;
> +
> +if (!rule->enabled) {

Sorry that I found that the rule is not properly applied to the
secondary cores when SMP > 1.
I will fix the issue and resend the patchset.

Regards,
Frank Chang

> +/* Enable the implied MISAs. */
> +if (rule->implied_misas) {
> +riscv_cpu_set_misa_ext(env, env->misa_ext | rule->implied_misas);
> +
> +for (i = 0; misa_bits[i] != 0; i++) {
> +if (rule->implied_misas & misa_bits[i]) {
> +ir = g_hash_table_lookup(misa_implied_rules,
> + GUINT_TO_POINTER(misa_bits[i]));
> +
> +if (ir) {
> +cpu_enable_implied_rule(cpu, ir);
> +}
> +}
> +}
> +}
> +
> +/* Enable the implied extensions. */
> +for (i = 0; rule->implied_exts[i] != RISCV_IMPLIED_EXTS_RULE_END; 
> i++) {
> +cpu_cfg_ext_auto_update(cpu, rule->implied_exts[i], true);
> +
> +ir = g_hash_table_lookup(ext_implied_rules,
> + 
> GUINT_TO_POINTER(rule->implied_exts[i]));
> +
> +if (ir) {
> +cpu_enable_implied_rule(cpu, ir);
> +}
> +}
> +
> +rule->enabled = true;
> +}
> +}
> +
> +static void riscv_cpu_enable_implied_rules(RISCVCPU *cpu)
> +{
> +RISCVCPUImpliedExtsRule *rule;
> +int i;
> +
> +/* Enable the implied MISAs. */
> +for (i = 0; (rule = riscv_misa_implied_rules[i]); i++) {
> +if (riscv_has_ext(>env, rule->ext)) {
> +cpu_enable_implied_rule(cpu, rule);
> +}
> +}
> +
> +/* Enable the implied extensions. */
> +for (i = 0; (rule = riscv_ext_implied_rules[i]); i++) {
> +if (isa_ext_is_enabled(cpu, rule->ext)) {
> +cpu_enable_implied_rule(cpu, rule);
> +}
> +}
> +}
> +
>  void riscv_tcg_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
>  {
>  CPURISCVState *env = >env;
>  Error *local_err = NULL;
>
> +riscv_cpu_init_implied_exts_rules();
> +riscv_cpu_enable_implied_rules(cpu);
> +
>  riscv_cpu_validate_misa_priv(env, _err);
>  if (local_err != NULL) {
>  error_propagate(errp, local_err);
> @@ -1343,6 +1425,8 @@ static void riscv_tcg_cpu_instance_init(CPUState *cs)
>
>  misa_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
>  multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
> +misa_implied_rules = g_hash_table_new(NULL, g_direct_equal);
> +ext_implied_rules = g_hash_table_new(NULL, g_direct_equal);
>  riscv_cpu_add_user_properties(obj);
>
>  if (riscv_cpu_has_max_extensions(obj)) {
> --
> 2.43.2
>
>

Re: [tor-relays] Relay migration

[Frank Lý via tor-relays]

Keep the same Tor identity keys.

Frank

Jun 4, 2024, 9:56 AM by tor-relays@lists.torproject.org:

> Hello everyone.
> I have to move somewhere else a a (middle) relay I have been running for a few
> years. It will be down for 2-4 weeks, then be back online in a different
> location, with different ISP, at better speed. But it will run on the same
> hardware and software. Should I keep the same keys, or start from scratch?
>
>
> --
> Eldalië
> My private key is attached. Please, use it and provide me yours!
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [FRIAM] St John's Coffee Shop Open This Friday

[Frank Wimberly]

George has been told that the coffee shop at St John's will be open this
Friday.  Let's plan to meet there unless we hear otherwise before then.

Frank

---
Frank C. Wimberly
140 Calle Ojo Feliz,
Santa Fe, NM 87505

505 670-9918
Santa Fe, NM

On Mon, Jun 3, 2024, 9:42 AM George Duncan  wrote:

> I called and they said they will be open this Friday. With construction,
> one week at a time.
>
> George Duncan
> Emeritus Professor of Statistics, Carnegie Mellon University
> georgeduncanart.com
> See posts on Facebook, Twitter, and Instagram
> Land: (505) 983-6895
> Mobile: (505) 469-4671
>
> My art theme: Dynamic exposition of the tension between matrix order and
> luminous chaos.
>
> "Attempt what is not certain. Certainty may or may not come later. It may
> then be a valuable delusion."
> From "Notes to myself on beginning a painting" by Richard Diebenkorn.
>
> "It's that knife-edge of uncertainty where we come alive to our truest
> power." Joanna Macy.
>
>
>
-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
FRIAM Applied Complexity Group listserv
Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom 
https://bit.ly/virtualfriam
to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/
archives:  5/2017 thru present https://redfish.com/pipermail/friam_redfish.com/
  1/2003 thru 6/2021  http://friam.383.s1.nabble.com/

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Frank Ch. Eigler]

Hi, Denys -


dvlasenk wrote:

> [...]
> Now readelf, annobin and hell knows what else started to talk to
> REMOTE SERVERS, deep out of internals of complicated build infrastructure
> running on presumably secure build machines of various IT corporations
> and whatnot!

(It may not be appropriate for secure build machines to have general
internet access, but that's for the operators to decide.)

> [...] Do you understand how many fetches of debuginfo will be
> attempted by e.g.  a kernel build tooling when it runs readelf on 8000
> freshly built modules _for every kernel build_? How slow it is?

If remote debuginfo is not needed for these particular readelf
invocations, then the tools should not be making debuginfod calls.
Can you help identify examples?

> Now various tools need to forcibly unset the variable to stop this madness.

The defaults are set with normal developers in mind.


- FChE
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue