[Sprinklerforum] Re: Standpipe NFPA14 2019

[Chris Wilson]

Steve,
Yes there is a hose connection at the first floor landing of the remote stand 
pipe. Yes there is access to occupied first floor space via the exit passage 
and the remote stairway.
Thanks

Christopher S. Wilson SET
Project Design Manager
Treasure Valley Fire Protection
2731 S. Saturn Way
Boise, ID 83709
Phone:  208-362-1888
Fax: 208-362-2207

please note all TVFP email
addresses have changed
new email below

chr...@tvfpinc.com<mailto:chr...@tvfp.us>

From: Steve Leyton 
Sent: Friday, May 10, 2024 7:29 PM
To: Discussion list on issues relating to automatic fire sprinklers 

Subject: [Sprinklerforum] Re: Standpipe NFPA14 2019

Do you have a hose connection on the 1st floor landing of the remote standpipe 
stairwell in addition to the one at the exit passageway door?   And is there 
access to occupiable areas on the first floor from the passageway or stairwell?

Obviously, two or more hose connections supplied by a feed main on a single 
floor is a horizontal standpipe by definition, but it would seem to me that in 
this type of egress system that would be redundant or not of value depending on 
where a firefighter would be going with the water after connection to one or 
the other hose connection.

The foregoing does not represent any opinion or interpretation of the standard 
on behalf of NFPA or the NFPA 14 Technical Committee.

[cid:image001.jpg@01DAA509.E0D5AF00]
Steve Leyton, President
T  |  619.255.8964 x 102  |  
www.protectiondesign.com<http://www.protectiondesign.com/>
2851 Camino Del Rio South  |  Suite 210  |  San Diego, CA  92108
Fire Protection System Design | Consulting | Planning | Training



From: Chris Wilson [mailto:chr...@tvfpinc.com]
Sent: Friday, May 10, 2024 7:42 AM
To: 
sprinklerforum@lists.firesprinkler.org<mailto:sprinklerforum@lists.firesprinkler.org>
Subject: [Sprinklerforum] Standpipe NFPA14 2019


To all,
I have a 4 story building with 2 exit stairways I am installing a class I 
manual wet standpipe combination sprinkler system. The remote stair is on the 
interior of the building and has a rated exit passageway  on the first floor 
that is 73' long. I am placing all hose valves on the main floor landings and 
one a the exit door of the exit passage way.

I am planning on calculating 500 gpm from the remote stand pipe and 250 for the 
2nd standpipe. The exit passage way hose connection will be fed by a  2/12 
lateral pipe fed from the  4" horizontal supply to the remote standpipe as it 
pass by the exit passageway.

Do I need to include an additional 250 gpm in my calcs at the hose valve at the 
exit passageway?

Thanks
Christopher S. Wilson SET
Project Design Manager
Treasure Valley Fire Protection
2731 S. Saturn Way
Boise, ID 83709
Phone:  208-362-1888
Fax: 208-362-2207

please note all TVFP email
addresses have changed
new email below

chr...@tvfpinc.com<mailto:chr...@tvfp.us>


_
SprinklerForum mailing list:
https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org

[Sprinklerforum] Standpipe NFPA14 2019

[Chris Wilson]

To all,
I have a 4 story building with 2 exit stairways I am installing a class I 
manual wet standpipe combination sprinkler system. The remote stair is on the 
interior of the building and has a rated exit passageway  on the first floor 
that is 73' long. I am placing all hose valves on the main floor landings and 
one a the exit door of the exit passage way.

I am planning on calculating 500 gpm from the remote stand pipe and 250 for the 
2nd standpipe. The exit passage way hose connection will be fed by a  2/12 
lateral pipe fed from the  4" horizontal supply to the remote standpipe as it 
pass by the exit passageway.

Do I need to include an additional 250 gpm in my calcs at the hose valve at the 
exit passageway?

Thanks
Christopher S. Wilson SET
Project Design Manager
Treasure Valley Fire Protection
2731 S. Saturn Way
Boise, ID 83709
Phone:  208-362-1888
Fax: 208-362-2207

please note all TVFP email
addresses have changed
new email below

chr...@tvfpinc.com


_
SprinklerForum mailing list:
https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org

[Touch-packages] [Bug 2057944] [NEW] pidwait doesn't work. Instead behaves like pgrep

[Chris Wilson]

Public bug reported:

pidwait doesn't work at all.

Seems like pidwait was renamed in an Ubuntu patch from upstream pwait -
however the executable that is built acts as "pgrep" unless it's called
as "pwait"; this check also needs to be updated with the executable name
"pidwait".

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/2057944

Title:
  pidwait doesn't work. Instead behaves like pgrep

Status in procps package in Ubuntu:
  New

Bug description:
  pidwait doesn't work at all.

  Seems like pidwait was renamed in an Ubuntu patch from upstream pwait
  - however the executable that is built acts as "pgrep" unless it's
  called as "pwait"; this check also needs to be updated with the
  executable name "pidwait".

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 2057944] Re: pidwait doesn't work. Instead behaves like pgrep

[Chris Wilson]

This is the case for jammy - for numbat the pwait -> pidwait change has
happened upstream.

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

Title:
  pidwait doesn't work. Instead behaves like pgrep

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


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

[Bug 2057944] [NEW] pidwait doesn't work. Instead behaves like pgrep

[Chris Wilson]

Public bug reported:

pidwait doesn't work at all.

Seems like pidwait was renamed in an Ubuntu patch from upstream pwait -
however the executable that is built acts as "pgrep" unless it's called
as "pwait"; this check also needs to be updated with the executable name
"pidwait".

** Affects: procps (Ubuntu)
 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/2057944

Title:
  pidwait doesn't work. Instead behaves like pgrep

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


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

[Touch-packages] [Bug 2057944] Re: pidwait doesn't work. Instead behaves like pgrep

[Chris Wilson]

This is the case for jammy - for numbat the pwait -> pidwait change has
happened upstream.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/2057944

Title:
  pidwait doesn't work. Instead behaves like pgrep

Status in procps package in Ubuntu:
  New

Bug description:
  pidwait doesn't work at all.

  Seems like pidwait was renamed in an Ubuntu patch from upstream pwait
  - however the executable that is built acts as "pgrep" unless it's
  called as "pwait"; this check also needs to be updated with the
  executable name "pidwait".

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Sprinklerforum] Re: FDC for Standpipe

[Chris Wilson]

I would hope there would be a provision that if you hydraulicly prove it whit 
one connection that should be acceptable.

Christopher S. Wilson SET
Project Design Manager
Treasure Valley Fire Protection
2731 S. Saturn Way
Boise, ID 83709
Phone:  208-362-1888
Fax: 208-362-2207

please note all TVFP email
addresses have changed
new email below

chr...@tvfpinc.com

From: Steve Leyton 
Sent: Thursday, March 14, 2024 10:48 AM
To: Discussion list on issues relating to automatic fire sprinklers 

Cc: Dewayne Martinez 
Subject: [Sprinklerforum] Re: FDC for Standpipe

That’s hydraulics.  If you can deliver the demand with no more inlet pressure 
than the FD is willing to accept, I think you can use 4” for the FDC.


The foregoing is my opinion only and does not represent NFPA or the NFPA 14 
Technical Committee, nor intended to serve as an interpretation of the standard.

Protection Design and Consulting
Steve Leyton, President
T  |  619.255.8964 x 102  |  
www.protectiondesign.com
2851 Camino Del Rio South  |  Suite 210  |  San Diego, CA  92108
Fire Protection System Design | Consulting | Planning | Training







From: Dewayne Martinez 
mailto:dmarti...@total-mechanical.com>>
Sent: Thursday, March 14, 2024 9:30 AM
To: Discussion list on issues relating to automatic fire sprinklers 
mailto:sprinklerforum@lists.firesprinkler.org>>
Cc: Dewayne Martinez 
mailto:dmarti...@total-mechanical.com>>
Subject: [Sprinklerforum] Re: FDC for Standpipe

Would a 5”x4” Storz be 750gpm because of the Storz connection size or 500gpm 
because of the pipe?

From: John Denhardt 
mailto:jdenha...@firesprinkler.org>>
Sent: Thursday, March 14, 2024 10:39 AM
To: Discussion list on issues relating to automatic fire sprinklers 
mailto:sprinklerforum@lists.firesprinkler.org>>
Subject: [Sprinklerforum] Re: FDC for Standpipe

Here is the reference:
NFPA 14 - 2024
10.7.3.1.1

Where a 4 in. (100 mm) inlet is used, the assumed flow per inlet shall be 500 
gpm (1900 L/min).
10.7.3.1.2

Where a 5 in. (125 mm) inlet is used, the assumed flow per inlet shall be 750 
gpm (2850 L/min).

The above is my opinion and has not been processed as a formal interpretation 
in accordance with the NFPA Regulations Governing Committee Projects. This is 
provided with the understanding that the AFSA assumes no liability for this 
opinion or actions taken on it and they are not to be considered the official 
position of the AFSA, and/or NFPA or its technical committees.AFSA cannot 
provide design or consulting engineering services, and this opinion should 
therefore not be considered, nor relied upon, as such.

Thanks,
John

[https://www.dropbox.com/s/g4h8r7hdtsr6154/AFSA_L.png?raw=1]
John August Denhardt, PE
Vice President, Engineering and Technical Services
American Fire Sprinkler Association
m: p:
301-343-1457
214-349-5965 ext 121
w:
firesprinkler.org


Treat Your Apprentices Like VIPs!
AFSA’s Virtual Instruction Program (VIP) for Apprentices is training that comes 
straight from our expert instructors. They lead the way to ensure your men and 
women are trained, letting you focus on OJT. Click 
here
 to learn more and enroll.


On Thu, Mar 14, 2024 at 11:25 AM John Denhardt 
mailto:jdenha...@firesprinkler.org>> wrote:
To all - review NFPA 14 -2024 as it has new requirements for 4" and 5" storz 
connections.
4" is limited to 500 GPM per connection
5" is limited to 750 GPM per connection

Unfortunately, I'm at a conference where my internet connection is very 
limited, otherwise I would give you a section reference.


The above is my opinion and has not been processed as a formal interpretation 
in accordance with the NFPA Regulations Governing Committee Projects. This is 
provided with the understanding that the AFSA assumes no liability for this 
opinion or actions taken on it and they are not to be considered the official 
position of the AFSA, and/or NFPA or its technical committees.AFSA cannot 
provide design or consulting engineering services, and this opinion should 
therefore not be considered, nor relied upon, as such.

Thanks,
John

[https://www.dropbox.com/s/g4h8r7hdtsr6154/AFSA_L.png?raw=1]
John August Denhardt, PE
Vice President, Engineering and Technical Services
American Fire Sprinkler Association
m: p:
301-343-1457
214-349-5965 ext 121
w:
firesprinkler.org


Treat Your Apprentices Like VIPs!
AFSA’s Virtual Instruction Program (VIP) for Apprentices is training that comes 
straight from our expert instructors. They lead the way to ensure your men and 
women are trained, letting you focus on OJT. Click 

[Sprinklerforum] Re: Manual Wet Standpipe Inspection

[Chris Wilson]

In our area they don’t make us perform the test but we are required to have a 
sign at the fdc with the flow and pressure needed to get the 100 psi at the 
remote hose conecttion.

Christopher S. Wilson SET
Project Design Manager
Treasure Valley Fire Protection
2731 S. Saturn Way
Boise, ID 83709
Phone:  208-362-1888
Fax: 208-362-2207

please note all TVFP email
addresses have changed
new email below

chr...@tvfpinc.com

From: Steve Mackinnon 
Sent: Thursday, March 7, 2024 7:08 AM
To: Discussion list on issues relating to automatic fire sprinklers 

Subject: [Sprinklerforum] Re: Manual Wet Standpipe Inspection

Good morning,

We’ve found it all depends on the district and individual AHJ…

We do a number of manual wet/dry standpipes in our area and each one comes with 
it’s own challenges.

One of my colleagues just invested in a used fire truck figuring the best 
course of action is to be over prepared than under.

Another company gives “donations” to the local Fire Dept. to come and flow the 
standpipe at test time (this can get expensive over time).

But we always provide a hydraulic calculation for the required flow beforehand.

I found most Fire Pump operators start with 90-100 psi and increase by 10 psi 
until we reach the desired flow and pressure on the roof.

From: Chris Dorn 
mailto:chris.d...@dornfireprotection.com>>
Sent: Wednesday, March 6, 2024 6:53 PM
To: Discussion list on issues relating to automatic fire sprinklers 
mailto:sprinklerforum@lists.firesprinkler.org>>
Subject: [Sprinklerforum] Re: Manual Wet Standpipe Inspection

We have been required to perform a flow test using the city fire truck and the 
top two hose valves. I only did it once but the firemen seemed excited to do 
it. I have been required to run some quick calculations to tell them what 
pressure the pumper needed to provide at the FDC to give them the pressure they 
wanted at the top of a standpipe pretty much every one we do.

Christopher Dorn
Dorn Fire Protection LLC
4132 Dumont Street #4
Cincinnati, Ohio 45226
(513) 295-2499

On Mar 6, 2024, at 5:06 PM, Anthony Carrizosa 
mailto:anth...@archerconstruction.com>> wrote:

Derik,
NFPA 25 states flow tests 6.3.1 Shall be conducted every 5 years on all 
automatic standpipe systems.. your system is not automatic but manual. Since it 
is under water pressure at all times no need for a hydro test either.

Anthony Carrizosa
Project Manager | Fire Protection
7855 S 206th St Kent, WA 98032
Cell: 206-679-5283 | Office Dir: 253-341-4593

https://archerconstruction.com

From: Derik Rich mailto:dr...@certfs.com>>
Sent: Wednesday, March 6, 2024 1:53 PM
To: 
sprinklerforum@lists.firesprinkler.org
Subject: [Sprinklerforum] Manual Wet Standpipe Inspection

Looking for some guidance on flow testing a manual wet standpipe. I have been 
told; A. You don’t have to flow test. B. Perform flow test and calculate 
assistance needed. C. You need to do a proper test with a pumper truck. The 
only thing I can find in 25 is that no hydrostatic test is required on manual 
wet. Can anybody steer me in the right direction? Thanks,


Derik Rich
Estimator


O:
801-281-0746
C:
801-231-6375
A:
1015 S. 3600 W. SLC, UT 84104
E:
dr...@certfs.com









_
SprinklerForum mailing list:
https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
To unsubscribe send an email to 
sprinklerforum-le...@lists.firesprinkler.org

_
SprinklerForum mailing list:
https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org

[blink-dev] Re: Intent to Ship: Deprecate old CSS custom state syntax

['Chris Wilson' via blink-dev]

Oh yes, I recall this now.  :) IIRC, we generally follow this convention
anyway; that feature had some communication gaps, but we did follow that
convention.

On Wed, Oct 4, 2023 at 5:24 PM Jeffrey Yasskin 
wrote:

> Apparently +Chris Wilson  had part of this discussion
> with Alan Stearns in April at
> https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658,
> and the suggestion was that if a CSS spec for a feature is "unstable"
> (meaning 'not at CR'?), then we should either post "we're about to send an
> intent" to the last issue discussing it, or file an "Is X ready to ship?"
> issue. I think +Chris Harrelson  is likely to have
> the strongest opinions about this: should we add such a rule to our launch
> process for CSS features?
>
> Jeffrey
>
> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin 
> wrote:
>
>> On Wed, Oct 4, 2023 at 1:08 PM Joey Arhar  wrote:
>>
>>> > I'd like to understand better how we wound up shipping :--foo and then
>>> having the CSSWG ask us to change it to :state(foo) instead, and what we
>>> could do in the future to avoid it happening again.
>>>
>>> I think if this was specced before shipping that would have been better
>>> and is a practice that I (and we?) currently follow, but this was shipped a
>>> number of years ago.
>>>
>>
>> Yeah, good point: it's totally possible that our more recent process
>> rigor is sufficient, and we don't need anything new to prevent this in the
>> future. No matter what, we should expect the occasional old feature to pop
>> up and be an exception.
>>
>> I do think that it's worth finding a way to write down your current
>> practice, so that it doesn't regress if you switch teams. I think you mean
>> that you do "hold off on shipping CSS features until they land in an
>> official draft", so let's try to record that if it's our idea of the
>> solution.
>>
>>
>>> > As far as I can see, nobody asked for the ergonomic evidence that
>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
>>> says we can expect after Chrome has shipped a feature.
>>>
>>> This was my bad, I didn't realize or didn't completely consider
>>> usecounters before I presented the name change to the CSSWG.
>>> I am hoping that with an answer from the API owners, I can go back to
>>> the CSSWG and potentially change it back.
>>> There is still no merged spec in HTML or CSS for this feature yet, but I
>>> have open PRs in both specs.
>>>
>>
>> Thanks!
>>
>> On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin 
>>> wrote:
>>>
>>>> +1 on the API owners discussing this.
>>>>
>>>> I'd like to understand better how we wound up shipping :--foo and then
>>>> having the CSSWG ask us to change it to :state(foo) instead, and what we
>>>> could do in the future to avoid it happening again.
>>>>
>>>> It looks like the initial proposal was :state(foo); the CSSWG asked to
>>>> change it to :--foo in 2020
>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-591547956>;
>>>> we shipped that in M90 in 2021
>>>> <https://chromestatus.com/feature/6537562418053120> (with a feature
>>>> entry that still says :state ); then Ryosuke suggested undoing that
>>>> change in January 2023
>>>> <https://github.com/whatwg/html/pull/8467#issuecomment-1381645661>,
>>>> and the CSSWG accepted that suggestion in August
>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980>.
>>>> As far as I can see, nobody asked for the ergonomic evidence that
>>>> https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews
>>>> says we can expect after Chrome has shipped a feature. It doesn't seem like
>>>> this feature was so contentious that the team needed to use a name change
>>>> as a bargaining chip, so we should probably have insisted on more evidence
>>>> before agreeing with the change. Maybe that's still a "should" instead of a
>>>> "should have": Joey's second email
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/wPAHJzIvAQAJ>
>>>>  might
>>>> say that the CSSWG's resolution
>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980>
>>>> about this isn't as 

Processing Folders loop issue

[Chris Wilson]

  Is there any hope of the long standing bug where, if you view TB! over the LAN using Windows Remote Desktop and close TB!  it gets stuck in a loop "Processing Folders" that requires Task Manager to get out of please?

-- Best regards, Chris                          mailto:ch...@chriswilson.tv


"Using The Bat! v10.2.1 on Windows 7 6.1 Build 7601 Service Pack 1"




'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Drop igt_cs_tlb

[Chris Wilson]

Quoting Jonathan Cavitt (2023-02-17 17:20:19)
> The gt_tlb live selftest has the same code coverage as the
> igt_cs_tlb subtest of gtt.

True, the intent of the code is the same, but gt_tlb has had a much high
success rate at hitting TLB bugs, so is my preferred test.

> However, igt_cs_tlb is hitting
> an issue in that we are updating PTE in gt0->vm but
> executing on the media tile without updating gt1->vm.

I'm no longer convinced this a good explanation of the issue, as unlike
the i915_requests selftest this is using a GEM context and not the local
kernel contexts. The GEM context->vm should work equally on the mtl
render and media tiles, afaict.

The failure is very early in running on media tile (after running on the
render tile) so I think it should be easy enough to reproduce in a
simpler test to narrow down the cause.

> This issue is corrected in gt_tlb, and thus igt_cs_tlb
> is obsolete and should be removed.

gt_tlb supersedes igt_cs_tlb, that I can agree on,
Acked-by: Chris Wilson 
-Chris

gnubg crash

[Chris Wilson]

Using gnubg version 1.07.001 on Windows 11 with 16 GB of RAM and a
i7-11700K processor. Changed analysis settings to 5-ply under user-defined
settings for both checker play and cube decisions. Opened a .MAT file and
started the analysis. gnubg crashed at about 3 minutes in. The application
just closed with no warning or message. I received the same result using a
different match file. (including an .SGF file) No move information was
displayed in the lower right status window, so gnubg was unable to complete
the analysis of the very first move. In fact, no move information was
displayed at all. (e.g. 1/36)

Chris Wilson

Re[2]: 10.2.1 no option showing to clear account logs

[Chris Wilson]

Hello Adrian,

I didn't realise that the X meant erase the log. The X is there and works, now I know what it's for. I was expecting a text box as in earlier versions. Sorry for many confusion and thanks for the help.

On Monday, October 24, 2022,  you wrote:

That should have been "reinstall version 10.2.1". Another thought struck me. Are you using the normal (WITHOUTautoupdate) version or the alternative "with autoupdate" version? I always use the former.



Adrian


Sunday, October 23, 2022, 9:43:05 PM, Adrian Godfrey li...@ags.lu wrote:



Then I suggest you get either version 10.2 (I see a "red X) in this version or 10.2.1 (this seems to be new when I did a "check for updates" a few minutes ago, but I haven't downloaded 10.2.1 yet.




Adrian




Sunday, October 23, 2022, 9:00:01 PM, Chris Wilson ch...@chriswilson.tv wrote:





With 10.2.1 there is no button to clear an account log.





 




Current version is 9.1.18 | 'Using TBUDL' information:http://www.silverstones.com/thebat/TBUDLInfo.html








-- 

Chris Wilson

"Using The Bat! v10.2.1 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: 10.2.1 no option showing to clear account logs

[Chris Wilson]

Hello Adrian,

On Sunday, October 23, 2022,  you wrote:

It should be there as a red X (without any text) between "Search"and "Highlights only"  at the top of the screen.


Adrian


Sunday, October 23, 2022, 8:16:48 PM, Chris Wilson ch...@chriswilson.tv wrote:



With 10.2.1 there is no button to clear an account log.



 



Current version is 9.1.18 | 'Using TBUDL' information:http://www.silverstones.com/thebat/TBUDLInfo.html




Yes, it was there all the time, I was expecting the old text, and frankly I think that was a better option. I appreciate your rapid reply, thanks Adrian.



-- 

Chris Wilson

"Using The Bat! v10.2.1 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

10.2.1 no option showing to clear account logs

[Chris Wilson]

23 October 2022



With 10.2.1 there is no button to clear an account log.


-- 

          Best Regards, Chris Wilson

          mailto:ch...@chriswilson.tv


"Using The Bat! v10.2.1 on Windows 7 6.1 Build 7601 Service Pack 1"




Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: Tools to convert xg file format to sgf

[Chris Wilson]

I thought there was something lying around that explained the .sgf format
but I'm not sure where it came from. It's been a number of years ago, and
the format may have changed a bit since then. I think I wrote something to
parse the file. I'll have to take a look through my old programs.

On Sat, Oct 15, 2022 at 8:03 AM Chris Wilson  wrote:

> Sounds interesting. Would you be willing to make your program public? I'd
> love to see its output.
>
> On Sat, Oct 15, 2022 at 7:50 AM Turker Eflanli 
> wrote:
>
>> Thanks! However, I have a program that reads an XG file and creates a
>> report. I would like to do the same on an sgf file, so I either need to
>> convert it to xg format or need to figure out the sgf format itself so I
>> can update my own program. I want to be able to do all this without the
>> help of either XG or GNU interfaces
>>
>> On Sat, Oct 15, 2022 at 10:44 AM Chris Wilson  wrote:
>>
>>> XG supports importing .sgf files. Look under File>Import>GnuBG.
>>>
>>> Chris
>>>
>>> On Sat, Oct 15, 2022 at 7:36 AM Turker Eflanli 
>>> wrote:
>>>
>>>> Does anyone know a way to convert a GNU analyzed sgf file to xg format?
>>>> If not, is there documentation that explains the sgf format?
>>>>
>>>> Thanks in advance
>>>> Turker Eflanli
>>>>
>>>> On Sun, Aug 14, 2022 at 3:36 AM Øystein Schønning-Johansen <
>>>> oyste...@gmail.com> wrote:
>>>>
>>>>> Thank you so much, Turker.
>>>>>
>>>>> I see I get some problems with this code when I try to read the WC2022
>>>>> final, however, I think the problems are solvable.
>>>>>
>>>>> I've gathered the code in a github repository:
>>>>> https://github.com/oysteijo/xgdatatools
>>>>>
>>>>> And just as I did that, I also saw that another github user has
>>>>> already done the same 3 years ago:
>>>>> https://github.com/zkitX/xgdatatools
>>>>>
>>>>> -Øystein
>>>>>
>>>>> fre. 12. aug. 2022 kl. 19:09 skrev Turker Eflanli <
>>>>> turkerefla...@gmail.com>:
>>>>>
>>>>>> Here they are - I don't remember where I had downloaded them from
>>>>>>
>>>>>> On Fri, Aug 12, 2022 at 12:01 PM Øystein Schønning-Johansen <
>>>>>> oyste...@gmail.com> wrote:
>>>>>>
>>>>>>> Thank you so much, Turker!
>>>>>>>
>>>>>>> However, it would still be good to have the Petch-tools. :-)
>>>>>>>
>>>>>>> -Øystein
>>>>>>>
>>>>>>> fre. 12. aug. 2022 kl. 16:58 skrev Turker Eflanli <
>>>>>>> turkerefla...@gmail.com>:
>>>>>>>
>>>>>>>> Øystein,
>>>>>>>>
>>>>>>>> Find attached the raw file that you can analyze in GNU
>>>>>>>>
>>>>>>>> On Fri, Aug 12, 2022 at 10:12 AM Øystein Schønning-Johansen <
>>>>>>>> oyste...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> I was thinking of analysing the WC 2022 final and found the final
>>>>>>>>> available in .xg format.
>>>>>>>>>
>>>>>>>>> I think Michael Petch wrote some tools to convert xg file into sgf
>>>>>>>>> format. Are these tools available somewhere?
>>>>>>>>>
>>>>>>>>> It states at: https://www.extremegammon.com/XGformat.aspx
>>>>>>>>> that the python source for his tools are here:
>>>>>>>>> http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git
>>>>>>>>>
>>>>>>>>> However, it looks like this site is down.
>>>>>>>>>
>>>>>>>>> BTW: How is Michael? Is he still subscribing to this list? I've
>>>>>>>>> not heard from him in a long time. He posts on his FB profile, but he 
>>>>>>>>> isn't
>>>>>>>>> very responsive. :-)
>>>>>>>>>
>>>>>>>>> -Øystein
>>>>>>>>>
>>>>>>>>

Re: Tools to convert xg file format to sgf

[Chris Wilson]

Sounds interesting. Would you be willing to make your program public? I'd
love to see its output.

On Sat, Oct 15, 2022 at 7:50 AM Turker Eflanli 
wrote:

> Thanks! However, I have a program that reads an XG file and creates a
> report. I would like to do the same on an sgf file, so I either need to
> convert it to xg format or need to figure out the sgf format itself so I
> can update my own program. I want to be able to do all this without the
> help of either XG or GNU interfaces
>
> On Sat, Oct 15, 2022 at 10:44 AM Chris Wilson  wrote:
>
>> XG supports importing .sgf files. Look under File>Import>GnuBG.
>>
>> Chris
>>
>> On Sat, Oct 15, 2022 at 7:36 AM Turker Eflanli 
>> wrote:
>>
>>> Does anyone know a way to convert a GNU analyzed sgf file to xg format?
>>> If not, is there documentation that explains the sgf format?
>>>
>>> Thanks in advance
>>> Turker Eflanli
>>>
>>> On Sun, Aug 14, 2022 at 3:36 AM Øystein Schønning-Johansen <
>>> oyste...@gmail.com> wrote:
>>>
>>>> Thank you so much, Turker.
>>>>
>>>> I see I get some problems with this code when I try to read the WC2022
>>>> final, however, I think the problems are solvable.
>>>>
>>>> I've gathered the code in a github repository:
>>>> https://github.com/oysteijo/xgdatatools
>>>>
>>>> And just as I did that, I also saw that another github user has already
>>>> done the same 3 years ago:
>>>> https://github.com/zkitX/xgdatatools
>>>>
>>>> -Øystein
>>>>
>>>> fre. 12. aug. 2022 kl. 19:09 skrev Turker Eflanli <
>>>> turkerefla...@gmail.com>:
>>>>
>>>>> Here they are - I don't remember where I had downloaded them from
>>>>>
>>>>> On Fri, Aug 12, 2022 at 12:01 PM Øystein Schønning-Johansen <
>>>>> oyste...@gmail.com> wrote:
>>>>>
>>>>>> Thank you so much, Turker!
>>>>>>
>>>>>> However, it would still be good to have the Petch-tools. :-)
>>>>>>
>>>>>> -Øystein
>>>>>>
>>>>>> fre. 12. aug. 2022 kl. 16:58 skrev Turker Eflanli <
>>>>>> turkerefla...@gmail.com>:
>>>>>>
>>>>>>> Øystein,
>>>>>>>
>>>>>>> Find attached the raw file that you can analyze in GNU
>>>>>>>
>>>>>>> On Fri, Aug 12, 2022 at 10:12 AM Øystein Schønning-Johansen <
>>>>>>> oyste...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I was thinking of analysing the WC 2022 final and found the final
>>>>>>>> available in .xg format.
>>>>>>>>
>>>>>>>> I think Michael Petch wrote some tools to convert xg file into sgf
>>>>>>>> format. Are these tools available somewhere?
>>>>>>>>
>>>>>>>> It states at: https://www.extremegammon.com/XGformat.aspx
>>>>>>>> that the python source for his tools are here:
>>>>>>>> http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git
>>>>>>>>
>>>>>>>> However, it looks like this site is down.
>>>>>>>>
>>>>>>>> BTW: How is Michael? Is he still subscribing to this list? I've not
>>>>>>>> heard from him in a long time. He posts on his FB profile, but he isn't
>>>>>>>> very responsive. :-)
>>>>>>>>
>>>>>>>> -Øystein
>>>>>>>>
>>>>>>>

Re: Tools to convert xg file format to sgf

[Chris Wilson]

XG supports importing .sgf files. Look under File>Import>GnuBG.

Chris

On Sat, Oct 15, 2022 at 7:36 AM Turker Eflanli 
wrote:

> Does anyone know a way to convert a GNU analyzed sgf file to xg format? If
> not, is there documentation that explains the sgf format?
>
> Thanks in advance
> Turker Eflanli
>
> On Sun, Aug 14, 2022 at 3:36 AM Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Thank you so much, Turker.
>>
>> I see I get some problems with this code when I try to read the WC2022
>> final, however, I think the problems are solvable.
>>
>> I've gathered the code in a github repository:
>> https://github.com/oysteijo/xgdatatools
>>
>> And just as I did that, I also saw that another github user has already
>> done the same 3 years ago:
>> https://github.com/zkitX/xgdatatools
>>
>> -Øystein
>>
>> fre. 12. aug. 2022 kl. 19:09 skrev Turker Eflanli <
>> turkerefla...@gmail.com>:
>>
>>> Here they are - I don't remember where I had downloaded them from
>>>
>>> On Fri, Aug 12, 2022 at 12:01 PM Øystein Schønning-Johansen <
>>> oyste...@gmail.com> wrote:
>>>
 Thank you so much, Turker!

 However, it would still be good to have the Petch-tools. :-)

 -Øystein

 fre. 12. aug. 2022 kl. 16:58 skrev Turker Eflanli <
 turkerefla...@gmail.com>:

> Øystein,
>
> Find attached the raw file that you can analyze in GNU
>
> On Fri, Aug 12, 2022 at 10:12 AM Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Hi!
>>
>> I was thinking of analysing the WC 2022 final and found the final
>> available in .xg format.
>>
>> I think Michael Petch wrote some tools to convert xg file into sgf
>> format. Are these tools available somewhere?
>>
>> It states at: https://www.extremegammon.com/XGformat.aspx
>> that the python source for his tools are here:
>> http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git
>>
>> However, it looks like this site is down.
>>
>> BTW: How is Michael? Is he still subscribing to this list? I've not
>> heard from him in a long time. He posts on his FB profile, but he isn't
>> very responsive. :-)
>>
>> -Øystein
>>
>

Re[2]: Can I load a none "nau" beta over an nau release version?

[Chris Wilson]

Good day beta list members,

Tuesday, September 27, 2022, 2:23:31 PM, you wrote:

> Howdy!

> Вы писали 27 сентября 2022 г., 13:31:12:
>> Can I load a none "nau" beta over this nau release version?
>>  
> Did you mean install? Yep, you can 

> Best Regards, George Salnik
> RitLabs Russian Forum Moderator



> 
> 'Using TBBETA' information:
> http://www.silverstones.com/thebat/TBUDLInfo.html


OK, thanks very much George.
 
 

-- 
Best regards,
 Chris                            mailto:ch...@chriswilson.tv
"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Can I load a none "nau" beta over an nau release version?

[Chris Wilson]

Can I load a none "nau" beta over this nau release version?
 
Thanks .
  

-- 
Best regards,
 Chris                          mailto:ch...@chriswilson.tv

"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Re the Remote Desktop folder processing issue

[Chris Wilson]

Good day beta list members,

Saturday, August 27, 2022, 7:12:16 PM, you wrote:

> On 2022-08-25 at 13:19 (UTC +0100) Chris Wilson wrote:
>> hard drive to the base TB! files is having an effect on the Remote
>> Desktop folder processing problem? I am assuming not all v10.* users
>> of Remote Desktop have this issue, so there must be some difference

> Could you please provide a link to this bug you posted in Ritlabs bug
> tracker?



I didn't post one as Stefan was aware of it and trying to fix it when I myself 
discovered it. Should I post a bug report even if Stefan knows about this? 
Thanks.

-- 
Best regards,
 Chris                            mailto:ch...@chriswilson.tv
"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re the Remote Desktop folder processing issue

[Chris Wilson]

Do you think the fact I have the TB! mail database on a different hard drive to 
the base TB! files is having an effect on the Remote Desktop folder processing 
problem? I am assuming not all v10.* users of Remote Desktop have this issue, 
so there must be some difference in their installations? 
 
Just trying to help the developers get a fix fo this... Thanks.
  

-- 
Best regards,
 Chris                          mailto:ch...@chriswilson.tv

"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Blue vertical bars in HTML message

[Chris Wilson]

Good day beta list members,

Friday, August 12, 2022, 9:38:17 PM, you wrote:

> G'day Martin,

> On Monday, August 8, 2022, at 4:25:37 AM, you (Martin) wrote:

>> Hi TBBETA

>> What's about these strange blue vertical bars in a HTML message I want 
>> to print. In print preview you can see them - see the screenshot as 
>> attachment.

>> Is there any possibility to switch them off?

> Aren't they the equivalent of the > >> >>> threading indicators for in plain 
> text messages?


> Regards



That is what I have always thought, although being a Luddite I tend to avoid 
HTML in e-mail.

-- 
Best regards,
 Chris                            mailto:ch...@chriswilson.tv
"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Message filtering problem

[Chris Wilson]

---
 -1.9 BAYES_00   BODY: Bayes spam probability is 0 to 1%
 [score: 0.]
 -2.5 RCVD_IN_HOSTKARMA_WRBL: Sender listed in HOSTKARMA-WHITE
[172.104.30.75 listed in hostkarma.junkemailfilter.com]
 -0.0 SPF_PASS   SPF: sender matches SPF record
 -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
  0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily
 valid
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
 -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
 manager
X-Spam-Flag: NO

My filter : Sender contains time-nuts
            OR: Recipient contains time nuts 
 
Action : Move to the folder \\Zen Account\Amateur Radio\Time Nuts Forum
 
 
This folder exists, the filter is active and works on some messages from that 
particular forum
 
Thanks for any ideas.  



-- 
          Best Regards, Chris Wilson
          mailto:ch...@chriswilson.tv

"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Test

[Chris Wilson]

11 August 2022


Test message, I sent a message about 24 hours ago, but I don't see it showing, 
so testing...


-- 
          Best Regards, Chris Wilson
          mailto:ch...@chriswilson.tv

"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"
Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Bat Beta Series

[Chris Wilson]

Good day beta list members,

Tuesday, July 26, 2022, 12:49:26 PM, you wrote:

JS> On Tuesday, July 26, 2022, 13:43:07, Chris Wilson wrote:

>> May I ask if the next beta is likely to fix the Remote Desktop issue please?

JS> What remote desktop issue? (I'm asking because I often remote to my home 
computer, and never noticed any problems with TB)


When I close a RD session with TB running on the remote machine, and then later 
start the RD session again, TB is "doing something" with the Maintenance 
Centre, something that never progresses, and needs Task manager to kill it. 
Stefan says it is a bug that's hard to trace. 

I updated to v10.1 to be able to still use a GMAIL account and then discovered 
this RD anomaly. If it's any help I have also found starting the "resting" 
remote PC directly also sees The Bat! starting its maintenance tricks. What I 
really want to know is if there's an intermediate version of TB! that still 
supports the new GMAIL authentication, but DOES NOT have this Remote Desktop 
bug?


-- 

Best regards,
 Chrismailto:ch...@chriswilson.tv

"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Bat Beta Series

[Chris Wilson]

Good day beta list members,

Tuesday, July 26, 2022, 11:11:59 AM, you wrote:

STvT> Hello Ethan, 



STvT> Quick question - has beta testing ended?



STvT> Quick answer - no. :-)


STvT> We're preparing a new Beta right now.




May I ask if the next beta is likely to fix the Remote Desktop issue please?

-- 

Best regards,
 Chrismailto:ch...@chriswilson.tv

"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Another v1.1 bug?

[Chris Wilson]

 The user selected  Global View Mode is not sticking. Every time TB! is closed 
it reopens with Global View Mode set to 

-- 
Best regards,
 Chris  mailto:ch...@chriswilson.tv


"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Bug in v1.1 ??

[Chris Wilson]

  Evaluation version, open despatch centre to download a message with an 
attachment over the size limit. Click to download the message and attachment. 
TB! opens the evaluation screen showing ho many days left as if TB! were closed.

-- 
Best regards,
 Chris  mailto:ch...@chriswilson.tv


"Using The Bat! v10.1 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: "Processing Folders" box is running every morning

[Chris Wilson]

Hello everyone,

On Monday, June 27, 2022,  you wrote:



CW> 27 June 2022



CW> Hi all, I have an issue with my new V10 TB! Nearly every morning I find The 
Bat! has a box up saying it's processing folders. I can't cancel nor close it, 
other than using the Windows 7 64 bit Task Manager. It's progress bar never 
shows anything as happening. 

CW> If I try running all options in the Maintenance Centre manually then, apart 
from some options showing in a corrupted font when running, it finishes all 
tasks OK.

CW> Anyone know why TB! is taking it upon itself to maintain folders or 
whatever it's trying to overnight without being asked to?

CW> Thanks.


This is now becoming intolerable and unless I can find a fix I have to choose 
between an earlier TB, and lose full access to GMAIL, or keep the current one 
and have it lock up every time I close the Windows Remote DEesktop cconnection 
to the remote Windows 7 PC it is running on.

I suspect a file or something from my previous legacy version is lurking 
somewhere and effecting things. Some options show as corrupted fonts when I 
manually run the Maintenance Centre, and one option, run on its own, locks up 
TB completely, never completes its task and needs Task Manager to kill it.

I have never come across any application run remotely that "knows" the remote 
connection has been closed and takes it upon itself to "do thing". How can this 
occur and are there any logging options to help find the cause please?

Below is an excerpt from one log I found, the ex_log.txt log:


v10.0.10 64-bit / 13/07/2022 23:07:24.400 StartupMgr:FinalizeTBXProps 
EAccessViolation Access violation at address 0041B852 in module 
'TheBat64.exe'. Read of address 
v10.0.10 64-bit / 13/07/2022 23:07:24.407 MainForm:SecondAct EAccessViolation 
Access violation at address 0041B852 in module 'TheBat64.exe'. Read of 
address 
v10.0.10 64-bit / 13/07/2022 23:07:52.223 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:07:53.615 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:07:53.885 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:07:54.867 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:08:11.974 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:13:00.988 UpdateHelper:OnZipProgress  Exception 
DownLoadTaskError: 
https://www.ritlabs.com/download/files3/the_bat/beta/v10/main64-10.1.zip
v10.0.10 64-bit / 13/07/2022 23:22:39.078 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:22:40.191 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:22:40.568 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:22:42.602 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:22:58.938 UpdateHelper:Unzip EFCreateError 
Cannot create file "C:\Users\Chris Wilson\AppData\Local\The Bat!\DelMsi.lst". 
The system cannot find the path specified
v10.0.10 64-bit / 13/07/2022 23:41:22.199 UpdateHelper:OnZipProgress  Exception 
DownLoadTaskError: 
https://www.ritlabs.com/download/files3/the_bat/beta/v10/main64-10.1.zip
v10.1 64-bit / 13/07/2022 23:57:05.292 MainForm:CheckTimerTimer 
EAccessViolation Access violation at address 777BD196 in module 
'ntdll.dll'. Write of address 0018



and from the exceptions log, another excerpt:

Date: 13 Jul 2022 23:57:05
OS: Windows 7 Professional SP1 X64 (AMD or Intel) build 7601
PhysMemFreeTotal: 12281/16265 MB
VirtMemFreeTotal: 8355208/8388607 MB
MAPI #0: The Bat! [The Bat!]; Path: C:\The Bat!\tbmapi32.dll (not valid)
MAPI #1: The Bat! Simple MAPI 64-bit [The Bat! Simple MAPI 64-bit]; Path: 
C:\The Bat!\tbmapi64.dll (valid)
MAPI #2:  [Windows Mail]; Path:  (n

[Ubuntu-x-swat] [Bug 1922414] Re: ssh-agent fails to start (has_option: command not found)

[Chris Wilson]

I'm affected by this on jammy with lightdm and wmaker.

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

Title:
  ssh-agent fails to start (has_option: command not found)

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


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1922414] Re: ssh-agent fails to start (has_option: command not found)

[Chris Wilson]

I'm affected by this on jammy with lightdm and wmaker.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1922414

Title:
  ssh-agent fails to start (has_option: command not found)

Status in gdm3 package in Ubuntu:
  Fix Released
Status in xorg package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I have been using ssh-agent for years and since I upgraded my system
  to Ubuntu 21.04/groovy, ssh-agent fails to start.

  Here is the error message:

  # journalctl | grep ssh-agent
  [...]
  Apr 02 20:16:32 vougeot /usr/libexec/gdm-x-session[3752]: 
/etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not 
found

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: x11-common 1:7.7+22ubuntu1
  Uname: Linux 5.11.11-05-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu61
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: unknown
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Sat Apr  3 09:02:46 2021
  Dependencies: lsb-base 11.1.0ubuntu2
  DistUpgraded: Fresh install
  DistroCodename: hirsute
  DistroVariant: ubuntu
  DkmsStatus:
   tuxedo-keyboard, 3.0.4, 5.11.0-13-generic, x86_64: installed
   tuxedo-keyboard, 3.0.4, 5.11.0-13-lowlatency, x86_64: installed
   tuxedo-keyboard, 3.0.4, 5.11.11-05-lowlatency, x86_64: installed
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) 
(prog-if 00 [VGA controller])
 Subsystem: CLEVO/KAPOK Computer Iris Xe Graphics [1558:51a1]
  MachineType: TUXEDO TUXEDO InfinityBook S 15 Gen6
  PackageArchitecture: all
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.11-05-lowlatency 
root=/dev/mapper/MonVolume2-UbuntuRacine ro vsyscall=none security=apparmor 
quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/07/2020
  dmi.bios.release: 7.3
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: 1.07.03RTR
  dmi.board.name: NS50MU
  dmi.board.vendor: TUXEDO
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.ec.firmware.release: 7.2
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvr1.07.03RTR:bd09/07/2020:br7.3:efr7.2:svnTUXEDO:pnTUXEDOInfinityBookS15Gen6:pvrNotApplicable:rvnTUXEDO:rnNS50MU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:
  dmi.product.family: Not Applicable
  dmi.product.name: TUXEDO InfinityBook S 15 Gen6
  dmi.product.sku: Not Applicable
  dmi.product.version: Not Applicable
  dmi.sys.vendor: TUXEDO
  version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu4
  version.libdrm2: libdrm2 2.4.104-1build1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1-1
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.1-1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.10-3ubuntu5
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1922414] Re: ssh-agent fails to start (has_option: command not found)

[Chris Wilson]

I'm affected by this on jammy with lightdm and wmaker.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1922414

Title:
  ssh-agent fails to start (has_option: command not found)

Status in gdm3 package in Ubuntu:
  Fix Released
Status in xorg package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I have been using ssh-agent for years and since I upgraded my system
  to Ubuntu 21.04/groovy, ssh-agent fails to start.

  Here is the error message:

  # journalctl | grep ssh-agent
  [...]
  Apr 02 20:16:32 vougeot /usr/libexec/gdm-x-session[3752]: 
/etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not 
found

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: x11-common 1:7.7+22ubuntu1
  Uname: Linux 5.11.11-05-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu61
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: unknown
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  CurrentDesktop: KDE
  Date: Sat Apr  3 09:02:46 2021
  Dependencies: lsb-base 11.1.0ubuntu2
  DistUpgraded: Fresh install
  DistroCodename: hirsute
  DistroVariant: ubuntu
  DkmsStatus:
   tuxedo-keyboard, 3.0.4, 5.11.0-13-generic, x86_64: installed
   tuxedo-keyboard, 3.0.4, 5.11.0-13-lowlatency, x86_64: installed
   tuxedo-keyboard, 3.0.4, 5.11.11-05-lowlatency, x86_64: installed
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) 
(prog-if 00 [VGA controller])
 Subsystem: CLEVO/KAPOK Computer Iris Xe Graphics [1558:51a1]
  MachineType: TUXEDO TUXEDO InfinityBook S 15 Gen6
  PackageArchitecture: all
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.11-05-lowlatency 
root=/dev/mapper/MonVolume2-UbuntuRacine ro vsyscall=none security=apparmor 
quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/07/2020
  dmi.bios.release: 7.3
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: 1.07.03RTR
  dmi.board.name: NS50MU
  dmi.board.vendor: TUXEDO
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.ec.firmware.release: 7.2
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvr1.07.03RTR:bd09/07/2020:br7.3:efr7.2:svnTUXEDO:pnTUXEDOInfinityBookS15Gen6:pvrNotApplicable:rvnTUXEDO:rnNS50MU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:
  dmi.product.family: Not Applicable
  dmi.product.name: TUXEDO InfinityBook S 15 Gen6
  dmi.product.sku: Not Applicable
  dmi.product.version: Not Applicable
  dmi.sys.vendor: TUXEDO
  version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu4
  version.libdrm2: libdrm2 2.4.104-1build1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1-1
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.1-1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.10-3ubuntu5
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1

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


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 1922414] Re: ssh-agent fails to start (has_option: command not found)

[Chris Wilson]

I'm affected by this on jammy with lightdm and wmaker.

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

Title:
  ssh-agent fails to start (has_option: command not found)

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


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

Re[2]: Slimming Down the database / Archiving

[Chris Wilson]

Hello Tom,

On Sunday, July 3, 2022,  you wrote:



T> Hi Chris,

T> I finally got around to doing this and I am happy to report a successful 
outcome.
T> All these older messages are now combined in subfolders under Archive XXX 
and 
T> having this Account stored on a separate drive, does indeed reduce the size 
used for
T> my main OS and any twice-weekly backups.  The size for the TBK complete 
backup file has reduced from 16.2 gb to 5.8 gb.
T> The benefit of the password protection of the account compared to my 
original idea of just
T> moving the actual folders somewhere else is that I can now still open the 
archive easily and 
T> check on something if necessary.   Based on my experience that the minute 
you clear out something, you will need it,
T> this is quite a nice benefit. The only drawback I found was that moving 
messages was a bit more involved than
T> using cut/paste of some folders. 

T> Thanks Chris and Thomas for the suggestion.

T> Cheers
T> Tom

Glad my finding Thomas' message was useful to you.

What would be a highly useful feature to me would be to have a function where 
you command TB to make a new database mimicking the current ones structure, but 
with all folders showing an Archive and pre date identifier. 

So one would select an account, select a cut off month and year and tell it to 
archive, the result being a separate database created on a destination medium 
of user choice, containing only messages created or received pre whatever month 
and year. The database remaining within TB would then only contain messages 
created or received after the cut off date desired.



















-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Font corruption in Maintenance Centre

[Chris Wilson]

Good day beta list members,

Friday, July 1, 2022, 2:27:04 AM, you wrote:

TM> Hello Chris,

TM> Thursday, June 30, 2022, 5:18:58 PM, you wrote:

CW>>>   See link to screen shot. Plus, overnight a Processing Folders box 
appaears of its own accord, cannot be stopped nor closed and needs task Manager 
to kill it, at which point TB! restarts itself, despite it having been left 
running

CW>>> http://www.chriswilson.tv/maintenance-font.jpg

CW>>> Thanks, if it matters I updated from a legacy version the other day, I 
was running v5.8.10


>> OK, some more info on Processing Folders starting up on its own, that may or 
>> may not be relevant. I use TB! remotely, it's actually on another PC on a 
>> hard wired LAN and I access that PC with Microsoft's Remote Desktop. If TB 
>> is running on the remote PC and the Remote Desktop link is closed, when the 
>> link is re-opened, that's when it is likely to start processing folders of 
>> its own accord. Very annoying as Task Manager is needed to kill it. My 
>> legacy version 5.5.10  has no issues all and has never done this. HTH.

TM> Try Folder / Properties / Additional / On Exit

TM> Maybe this is the problem. I have taken all tickmarks off and do the 
maintenance manually.

TM> --
TM> Cheers,
TM> Thomas.

TM> Message reply created with The Bat! Version 9.5.1 (64-bit)
TM> under Windows 10.0 Build 19043


TM> 
TM> 'Using TBBETA' information:
TM> http://www.silverstones.com/thebat/TBUDLInfo.html


Sadly it has made no difference, but thanks for the idea Thomas. If I 
disconnect the Remote Desktop session to the PC actually running TB, with TB 
still running normally on the remote PC,  when i next connect a Remote Desktop 
session TB just shows it's running folder maintenance, this won't cancel or 
close, and the progress bar is empty and never populates, let alone moves. Task 
Manager is the only fix, and TB then starts as if it were never running. 5.8.10 
never, ever did this, so it's something in later versions I am sure. It's 100 
percent repeatable. Can I log anything?

-- 

Best regards,
 Chrismailto:ch...@chriswilson.tv

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Font corruption in Maintenance Centre

[Chris Wilson]

Good day beta list members,

Friday, July 1, 2022, 2:27:04 AM, you wrote:

TM> Hello Chris,

TM> Thursday, June 30, 2022, 5:18:58 PM, you wrote:

CW>>>   See link to screen shot. Plus, overnight a Processing Folders box 
appaears of its own accord, cannot be stopped nor closed and needs task Manager 
to kill it, at which point TB! restarts itself, despite it having been left 
running

CW>>> http://www.chriswilson.tv/maintenance-font.jpg

CW>>> Thanks, if it matters I updated from a legacy version the other day, I 
was running v5.8.10


>> OK, some more info on Processing Folders starting up on its own, that may or 
>> may not be relevant. I use TB! remotely, it's actually on another PC on a 
>> hard wired LAN and I access that PC with Microsoft's Remote Desktop. If TB 
>> is running on the remote PC and the Remote Desktop link is closed, when the 
>> link is re-opened, that's when it is likely to start processing folders of 
>> its own accord. Very annoying as Task Manager is needed to kill it. My 
>> legacy version 5.5.10  has no issues all and has never done this. HTH.

TM> Try Folder / Properties / Additional / On Exit

TM> Maybe this is the problem. I have taken all tickmarks off and do the 
maintenance manually.

TM> --
TM> Cheers,
TM> Thomas.

TM> Message reply created with The Bat! Version 9.5.1 (64-bit)
TM> under Windows 10.0 Build 19043


OK, I hadn’t seen those options, but I have un-ticked them now and will see if 
it cures the problem, thank you.




-- 

Best regards,
 Chrismailto:ch...@chriswilson.tv

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: Font corruption in Maintenance Centre

[Chris Wilson]

Good day beta list members,

Tuesday, June 28, 2022, 7:31:49 PM, you wrote:



CW>   See link to screen shot. Plus, overnight a Processing Folders box 
appaears of its own accord, cannot be stopped nor closed and needs task Manager 
to kill it, at which point TB! restarts itself, despite it having been left 
running

CW> http://www.chriswilson.tv/maintenance-font.jpg

CW> Thanks, if it matters I updated from a legacy version the other day, I was 
running v5.8.10


OK, some more info on Processing Folders starting up on its own, that may or 
may not be relevant. I use TB! remotely, it's actually on another PC on a hard 
wired LAN and I access that PC with Microsoft's Remote Desktop. If TB is 
running on the remote PC and the Remote Desktop link is closed, when the link 
is re-opened, that's when it is likely to start processing folders of its own 
accord. Very annoying as Task Manager is needed to kill it. My legacy version 
5.5.10  has no issues all and has never done this. HTH.


-- 

Best regards,
 Chrismailto:ch...@chriswilson.tv

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Font corruption in Maintenance Centre

[Chris Wilson]

  See link to screen shot. Plus, overnight a Processing Folders box appaears of 
its own accord, cannot be stopped nor closed and needs task Manager to kill it, 
at which point TB! restarts itself, despite it having been left running

http://www.chriswilson.tv/maintenance-font.jpg

Thanks, if it matters I updated from a legacy version the other day, I was 
running v5.8.10

-- 
Best regards,
 Chris  mailto:ch...@chriswilson.tv


"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"



'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Slimming Down the database / Archiving

[Chris Wilson]

Hello Tom,

On Saturday, June 25, 2022,  you wrote:

T> Saturday, June 25, 2022, 6:33:05 PM, you wrote:

>> On Saturday, June 25, 2022, 10:25:45, Chris Wilson wrote:

>>> Watching with interest 40 + GB of mail and attachments here, which stored 
>>> in the current database is ridiculous

>> 152 GB here…


T> So, you guys never felt the need for this ?  With 152 gb I would expect TB 
to be quite slow to open and having proper backups to be a pain?

I am getting old and forgetful. It suddenly occurred to me that I had once 
asked a similar question here, and as I have kept all messages from starting to 
use TB! I found it for you. See below, Thomas Fernandez answered and although 
based on an earlier TB! version his response should still be applicable, I 
would have thought.


@@@

On Sat, 27 Apr 2019 15:20:04 +0100 GMT (27-Apr-19, 20:50 +0700 GMT),
Chris Wilson wrote:

> I am happily running a legacy version of TB! but my message base is
> now huge. I was wondering if it is possible to somehow split the
> message base based on date so I keep say the last two year's messages
> in TB!' directory structure, and store older stuff elsewhere, perhaps
> on tape or DVD? Thanks

What I do is I "archive" old messages to other folders. For example, I
name a subfolder "2016" and then move all messages from that year into
that subfolder. This keep each folder with a manageable size. (Make
sure you compact the folders in which the messages were stored
previously.)

If you want to store those messages somewhere else, you create a dummy
account called "Archive". Under Account / Properties / Files &
Directories, you to an external drive or a drive in the cloud (nobody
uses tape or DVD any more). This way, you don't need to keep them on
your computer's hard disk.

--

Cheers,
Thomas.

@







-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

"Processing Folders" box is running every morning

[Chris Wilson]

27 June 2022



Hi all, I have an issue with my new V10 TB! Nearly every morning I find The 
Bat! has a box up saying it's processing folders. I can't cancel nor close it, 
other than using the Windows 7 64 bit Task Manager. It's progress bar never 
shows anything as happening. 

If I try running all options in the Maintenance Centre manually then, apart 
from some options showing in a corrupted font when running, it finishes all 
tasks OK.

Anyone know why TB! is taking it upon itself to maintain folders or whatever 
it's trying to overnight without being asked to?

Thanks.


-- 

  Best Regards, Chris Wilson

  mailto:ch...@chriswilson.tv


"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Slimming Down the database / Archiving

[Chris Wilson]

Hello Jernej,

On Saturday, June 25, 2022,  you wrote:

JS> On Saturday, June 25, 2022, 10:25:45, Chris Wilson wrote:

>> Watching with interest 40 + GB of mail and attachments here, which stored in 
>> the current database is ridiculous

JS> 152 GB here…

That's an amazing amount of mail, people must either really love you or really 
hate you :)






-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Can I test TB! V on a time limied basis before purchase?

[Chris Wilson]

Hello Jernej,

On Saturday, June 25, 2022,  you wrote:

JS> On Saturday, June 25, 2022, 10:24:27, Chris Wilson wrote:

>> Thanks Jernej and MAU, that's remarkable, I never thought that would still 
>> be an option. I really do like my threading lines :)

JS> You'll probably also like the option next to it - "Use denser display of 
items" :)


I do indeed like that original look. If only it could take me back in time, 
too :) Thanks for the tip.







-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: Slimming Down the database / Archiving

[Chris Wilson]

Hello Tom,

On Saturday, June 25, 2022,  you wrote:

T> Hello Everyone,

T> my TB has grown over the years and the backup files are now more than 
T>  gb in size.
T> I would like to tidy up a bit without messing up everything.

T> My idea is to create new Archive folders and then moving older emails into 
these archive folders. 
T> Can I then remove these completely to a different harddrive/backup storage 
in case I ever need them again? 
T> Currently my mail directory is at on my OS drive at %APPDATA%\The Bat!\

Watching with interest 40 + GB of mail and attachments here, which stored in 
the current database is ridiculous....









-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Can I test TB! V on a time limied basis before purchase?

[Chris Wilson]

Hello MAU,

On Friday, June 24, 2022,  you wrote:

M> Hello Chris,

>> Only disappointment so far is that in my preferred threaded view
>> mode the interconnecting lines between messages have gone and are
>> replaced by arrows and unmarked indents. I do not suppose there's a
>> way of getting the thread lines back is there? 

M> As you can see in my signature below, I am using V9. But I think it is 
M> just the same in v10.

M> From the top menu, select Options/Preferences/Other Options and tick  
M> Display "old style" lines in tree views.

Thanks Jernej and MAU, that's remarkable, I never thought that would still be 
an option. I really do like my threading lines :)








-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re[2]: Can I test TB! V on a time limied basis before purchase?

[Chris Wilson]

Hello Jernej,

On Friday, June 24, 2022,  you wrote:

JS> On Friday, June 24, 2022, 11:33:33, Chris Wilson wrote:

>> Silly me, the 30 day trial offer is prominent on the Ritlabs home page, my 
>> apologies. But what's the difference between the auto updating versions and 
>> the none auto updating ones please?

JS> Auto-updating version will update itself automatically in the background 
(similar to how most browsers update), while the regular version requires you 
to update it manually whenever a new release is made.

>> Is there much to importing a very large message and attachment base from 
>> this v5.8.10 version to the current one along with my filters, address book 
>> and Sorting Office settings?

JS> Make a backup first (in case you decide to return to older version), but 
other than that, the new version should import the old messages and filters 
automatically.

As my sig hopefully shows I got v10.0.10 working. The only issue is it saw 
duplicates (which really existed) in my address book, but the Bat! splash 
screen hid the overwrite confirmation box and I had to keep using Task Manager 
to get rid of the main splash screen to enable each confirmation. I deleted all 
the duplicates in the end, and it has calmed down now :)

Only disappointment so far is that in my preferred threaded view mode the 
interconnecting lines between messages have gone and are replaced by arrows and 
unmarked indents. I do not suppose there's a way of getting the thread lines 
back is there? 

I have the message bases on my D: drive at D:\TB_Mail, and the basic TB! files 
at C:\TheBat I installed V10 in the same C:\TheBat directory as the old one, 
can I, once happy with V10, just delete the older files in there?

Thanks again.



-- 

Chris Wilson

"Using The Bat! v10.0.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: Can I test TB! V on a time limied basis before purchase?

[Chris Wilson]

Hello Chris,

On Friday, June 24, 2022,  you wrote:



CW> 24 June 2022



CW> I can't decide if I should abandon GMAIL or update my legacy TB!
CW> version to the current one. I am getting a bit old to learn a new
CW> interface, and it were not for GMAIL playing   silly beggars I'd
CW> be quite content with this v5.8.10

CW> Can I download v10* and try it first? Thanks.




Silly me, the 30 day trial offer is prominent on the Ritlabs home page, my 
apologies. But what's the difference between the auto updating versions and the 
none auto updating ones please?

Is there much to importing a very large message and attachment base from this 
v5.8.10 version to the current one along with my filters, address book and 
Sorting Office settings?

Thanks.



-- 

Chris Wilson

"Using The Bat! v5.8.10 on Windows 7 6.1 Build 7601 Service Pack 1"








-- 



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Can I test TB! V on a time limied basis before purchase?

[Chris Wilson]

24 June 2022



I can't decide if I should abandon GMAIL or update my legacy TB! version to the 
current one. I am getting a bit old to learn a new interface, and it were not 
for GMAIL playing   silly beggars I'd be quite content with this v5.8.10

Can I download v10* and try it first? Thanks.

-- 

  Best Regards, Chris Wilson

  mailto:ch...@chriswilson.tv


"Using The Bat! v5.8.10 on Windows 7 6.1 Build 7601 Service Pack 1"



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Is my legacy TB! version usable with the upcoming Google security changes please?

[Chris Wilson]

29 April 2022



Good afternoon all, today I received this message from Google. I use an elderly 
version of The Bat! and need to know if I can still use it when Google 
implement these security changes, as I have one GMAIL  account I use TB! for, 
thanks. I am using v5.8.10 on Windows 7 64 bit Pro. Is such an elderly version 
still painlessly upgradeable to the current one if required?

>From Google today:

To help keep your account secure, Google will no longer support the use of
third-party apps or devices which ask you to sign in to your Google Account
using only your username and password. Instead, you’ll need to sign in
using Sign in with Google
<https://accounts.google.com/AccountChooser?Email=dead.f...@gmail.com=https://support.google.com/accounts/answer/112802?rfn%3D1651110186525%26anexp%3Dnret-fa>
or other more secure technologies, like OAuth 2.0. Learn more
<https://accounts.google.com/AccountChooser?Email=dead.f...@gmail.com=https://support.google.com/accounts/answer/6010255?rfn%3D1651110186525%26anexp%3Dnret-fa>
--
*What do you need to do?*

*Email software, like Outlook 2016 or earlier,* has less secure access to
your Gmail. Switch to Office 365, Outlook 2019 or newer, or any other email
software where you can sign in using *Sign in with Google*.
Learn more
<https://accounts.google.com/AccountChooser?Email=dead.f...@gmail.com=https://support.google.com/accounts/answer/6010255?rfn%3D1651110186525%26anexp%3Dnret-fa>
You received this email to let you know about important changes to your
Google Account and services.
© 2022 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA


-- 

      Best Regards, Chris Wilson

  mailto:ch...@chriswilson.tv


"Using The Bat! v5.8.10 on Windows 7 6.1 Build 7601 Service Pack 1"



Current version is 9.1.18 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

[Chris Wilson]

Quoting fei.y...@intel.com (2022-03-02 18:26:57)
> From: Fei Yang 
> 
> GPU hangs have been observed when multiple engines write to the
> same aux_inv register at the same time. To avoid this each engine
> should only invalidate its own auxiliary table. The function
> gen12_emit_flush_xcs() currently invalidate the auxiliary table for
> all engines because the rq->engine is not necessarily the engine
> eventually carrying out the request, and potentially the engine
> could even be a virtual one (with engine->instance being -1).
> With this patch, auxiliary table invalidation is done only for the
> engine executing the request. And the mmio address for the aux_inv
> register is set after the engine instance becomes certain.
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Fei Yang 
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 41 ---
>  .../drm/i915/gt/intel_execlists_submission.c  | 38 +
>  drivers/gpu/drm/i915/i915_request.h   |  2 +
>  3 files changed, 47 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index b1b9c3fd7bf9..af62e2bc2c9b 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
> return MI_ARB_CHECK | 1 << 8 | state;
>  }
>  
> -static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
> -{
> -   static const i915_reg_t vd[] = {
> -   GEN12_VD0_AUX_NV,
> -   GEN12_VD1_AUX_NV,
> -   GEN12_VD2_AUX_NV,
> -   GEN12_VD3_AUX_NV,
> -   };
> -
> -   static const i915_reg_t ve[] = {
> -   GEN12_VE0_AUX_NV,
> -   GEN12_VE1_AUX_NV,
> -   };
> -
> -   if (engine->class == VIDEO_DECODE_CLASS)
> -   return vd[engine->instance];
> -
> -   if (engine->class == VIDEO_ENHANCEMENT_CLASS)
> -   return ve[engine->instance];
> -
> -   GEM_BUG_ON("unknown aux_inv reg\n");
> -   return INVALID_MMIO_REG;
> -}
> -
>  static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
>  {
> *cs++ = MI_LOAD_REGISTER_IMM(1);
> @@ -288,7 +264,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
> if (mode & EMIT_INVALIDATE)
> aux_inv = rq->engine->mask & ~BIT(BCS0);
> if (aux_inv)
> -   cmd += 2 * hweight32(aux_inv) + 2;
> +   cmd += 4;
>  
> cs = intel_ring_begin(rq, cmd);
> if (IS_ERR(cs))
> @@ -319,16 +295,13 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
> *cs++ = 0; /* value */
>  
> if (aux_inv) { /* hsdes: 1809175790 */
> -   struct intel_engine_cs *engine;
> -   unsigned int tmp;
> -
> -   *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
> -   for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
> -   *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
> -   *cs++ = AUX_INV;
> -   }
> +   *cs++ = MI_LOAD_REGISTER_IMM(1);
> +   rq->vd_ve_aux_inv = cs;
> +   *cs++ = 0; /* address to be set at submission to HW */
> +   *cs++ = AUX_INV;
> *cs++ = MI_NOOP;
> -   }
> +   } else
> +   rq->vd_ve_aux_inv = NULL;
>  
> if (mode & EMIT_INVALIDATE)
> *cs++ = preparser_disable(false);
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 1c602d4ae297..a018de6dcac5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1258,6 +1258,34 @@ static bool completed(const struct i915_request *rq)
> return __i915_request_is_complete(rq);
>  }
>  
> +static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
> +{
> +   static const i915_reg_t vd[] = {
> +   GEN12_VD0_AUX_NV,
> +   GEN12_VD1_AUX_NV,
> +   GEN12_VD2_AUX_NV,
> +   GEN12_VD3_AUX_NV,
> +   };
> +
> +   static const i915_reg_t ve[] = {
> +   GEN12_VE0_AUX_NV,
> +   GEN12_VE1_AUX_NV,
> +   };
> +
> +   if (engine->class == VIDEO_DECODE_CLASS) {
> +   GEM_BUG_ON(engine->instance >= ARRAY_SIZE(vd));
> +   return vd[engine->insta

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

[Chris Wilson]

Quoting fei.y...@intel.com (2022-03-02 18:26:57)
> From: Fei Yang 
> 
> GPU hangs have been observed when multiple engines write to the
> same aux_inv register at the same time. To avoid this each engine
> should only invalidate its own auxiliary table. The function
> gen12_emit_flush_xcs() currently invalidate the auxiliary table for
> all engines because the rq->engine is not necessarily the engine
> eventually carrying out the request, and potentially the engine
> could even be a virtual one (with engine->instance being -1).
> With this patch, auxiliary table invalidation is done only for the
> engine executing the request. And the mmio address for the aux_inv
> register is set after the engine instance becomes certain.
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Fei Yang 
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  | 41 ---
>  .../drm/i915/gt/intel_execlists_submission.c  | 38 +
>  drivers/gpu/drm/i915/i915_request.h   |  2 +
>  3 files changed, 47 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index b1b9c3fd7bf9..af62e2bc2c9b 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
> return MI_ARB_CHECK | 1 << 8 | state;
>  }
>  
> -static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
> -{
> -   static const i915_reg_t vd[] = {
> -   GEN12_VD0_AUX_NV,
> -   GEN12_VD1_AUX_NV,
> -   GEN12_VD2_AUX_NV,
> -   GEN12_VD3_AUX_NV,
> -   };
> -
> -   static const i915_reg_t ve[] = {
> -   GEN12_VE0_AUX_NV,
> -   GEN12_VE1_AUX_NV,
> -   };
> -
> -   if (engine->class == VIDEO_DECODE_CLASS)
> -   return vd[engine->instance];
> -
> -   if (engine->class == VIDEO_ENHANCEMENT_CLASS)
> -   return ve[engine->instance];
> -
> -   GEM_BUG_ON("unknown aux_inv reg\n");
> -   return INVALID_MMIO_REG;
> -}
> -
>  static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
>  {
> *cs++ = MI_LOAD_REGISTER_IMM(1);
> @@ -288,7 +264,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
> if (mode & EMIT_INVALIDATE)
> aux_inv = rq->engine->mask & ~BIT(BCS0);
> if (aux_inv)
> -   cmd += 2 * hweight32(aux_inv) + 2;
> +   cmd += 4;
>  
> cs = intel_ring_begin(rq, cmd);
> if (IS_ERR(cs))
> @@ -319,16 +295,13 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
> mode)
> *cs++ = 0; /* value */
>  
> if (aux_inv) { /* hsdes: 1809175790 */
> -   struct intel_engine_cs *engine;
> -   unsigned int tmp;
> -
> -   *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
> -   for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
> -   *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
> -   *cs++ = AUX_INV;
> -   }
> +   *cs++ = MI_LOAD_REGISTER_IMM(1);
> +   rq->vd_ve_aux_inv = cs;
> +   *cs++ = 0; /* address to be set at submission to HW */
> +   *cs++ = AUX_INV;
> *cs++ = MI_NOOP;
> -   }
> +   } else
> +   rq->vd_ve_aux_inv = NULL;
>  
> if (mode & EMIT_INVALIDATE)
> *cs++ = preparser_disable(false);
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 1c602d4ae297..a018de6dcac5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1258,6 +1258,34 @@ static bool completed(const struct i915_request *rq)
> return __i915_request_is_complete(rq);
>  }
>  
> +static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
> +{
> +   static const i915_reg_t vd[] = {
> +   GEN12_VD0_AUX_NV,
> +   GEN12_VD1_AUX_NV,
> +   GEN12_VD2_AUX_NV,
> +   GEN12_VD3_AUX_NV,
> +   };
> +
> +   static const i915_reg_t ve[] = {
> +   GEN12_VE0_AUX_NV,
> +   GEN12_VE1_AUX_NV,
> +   };
> +
> +   if (engine->class == VIDEO_DECODE_CLASS) {
> +   GEM_BUG_ON(engine->instance >= ARRAY_SIZE(vd));
> +   return vd[engine->insta

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib/igt_device: Add support for accessing unbound VF PCI devices

[Chris Wilson]

Quoting Janusz Krzysztofik (2022-02-18 17:08:41)
> Hi Chris,
> 
> On Friday, 18 February 2022 17:03:01 CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> > > @@ -206,15 +229,19 @@ static struct pci_device 
> > > *__igt_device_get_pci_device(int fd)
> > > igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
> > >  pci_addr.domain, pci_addr.bus,
> > >  pci_addr.device, pci_addr.function);
> > > -   return NULL;
> > > +   goto cleanup;
> > > }
> > >  
> > > if (pci_device_probe(pci_dev)) {
> > > igt_warn("Couldn't probe PCI device\n");
> > > -   return NULL;
> > > +   goto cleanup;
> > > }
> > >  
> > > return pci_dev;
> > > +
> > > +cleanup:
> > > +   pci_system_cleanup();
> > 
> > This is a global cleanup of libpciaccess iirc, such that if anyone else
> > was using the library they would be affected.
> 
> Right, but shouldn't we also drop pci_system_init() from here and request 
> users to manage initialization and cleanup of that data themselves?  On each 
> call pci_system_init() abandons existing data and overwrites a pointer to it 
> with that of newly allocated memory, then tests calling 
> igt_device_get_pci_device() multiple times are going to suffer from 
> significant memory leaking.

Right, I thought it only inited once -- I just remember the issue with
calling pci_system_cleanup() while others were still using it.

Stick the call to init in an __attribute__((constructor)) or pthread_once.
-Chris

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib/igt_device: Add support for accessing unbound VF PCI devices

[Chris Wilson]

Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> @@ -206,15 +229,19 @@ static struct pci_device 
> *__igt_device_get_pci_device(int fd)
> igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
>  pci_addr.domain, pci_addr.bus,
>  pci_addr.device, pci_addr.function);
> -   return NULL;
> +   goto cleanup;
> }
>  
> if (pci_device_probe(pci_dev)) {
> igt_warn("Couldn't probe PCI device\n");
> -   return NULL;
> +   goto cleanup;
> }
>  
> return pci_dev;
> +
> +cleanup:
> +   pci_system_cleanup();

This is a global cleanup of libpciaccess iirc, such that if anyone else
was using the library they would be affected.

> +   return NULL;
>  }

Re: cross-platform backup tool Duplicate timestamp date after copying rdiff-backup repository.

[Chris Wilson]

Hi Reio,

You need to delete files from the destination that have been removed from
the source, especially the current_mirror file.

Use rsync with --delete to do that.

Thanks, Chris.

On Thu, 23 Dec 2021 at 11:24, Reio Remma via Any discussion of rdiff-backup
 wrote:

> Hello!
>
> I'm migrating my backups from an LVM volume to ZFS dataset, however after
> rsyncing the data over, I'm getting the following error:
>
> $ rdiff-backup --verify backup-zfs/hostname
> Warning, two different times for current mirror found
> Fatal Error: Metadata file
> '/mnt/backup-zfs/hostname/rdiff-backup-data/mirror_metadata.2021-12-23T06:17:32+02:00.diff.gz'
> has a duplicate timestamp date, you might not be able to recover files on
> or earlier than this date. Check the man page on how to clean up your
> repository using the '--allow-duplicate-timestamps' option.
>
> I'm unsure what to make of it or how to avoid it.
>
> I used the following rsync command to copy the data:
>
> rsync -avhA --progress --stats backup/ backup-zfs/
>
> It seems that it breaks when I run rsync again after an initial run and
> when data has changed at the source by then.
>
> Thanks!
>
> Reio
>

Re: [Intel-gfx] [PATCH 0/2] Backport upstream commit e49a8b2cc852

[Chris Wilson]

Quoting Janusz Krzysztofik (2021-12-03 13:21:06)
> diff --git a/0001-drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch 
> b/0001-drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch
> index efadd30d8cad..62b0a41d4aa4 100644
> --- a/0001-drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch
> +++ b/0001-drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch
> @@ -8,20 +8,20 @@ some engines will be fully setup and some not. Those 
> incompletely setup
>  engines only have 'engine->release == NULL' and so will leak any of the
>  common objects allocated.
>  
> -Incorporates some suggestions from Janusz for handling pinned context
> -cleanup.
> +v2: no longer incorporates suggestions from Janusz for handling pinned
> +context cleanup since upstream version has been backported

Noting the absence of something not explained just adds confusion.

You've handled this appropriately as a standalone patch, no more needs
to be said here (and the chunk doesn't even appear in the patch
anymore).

The covernote explained why this chunk disappears, so we have a story
for the pile, which is a different story as that told by the series of
individual patches.

Reviewed-by: Chris Wilson 
-Chris

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename gt to gt0

[Chris Wilson]

Quoting Andi Shyti (2021-11-17 13:34:56)
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 089fb4658b216..0bbf8c0c42eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -817,7 +817,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>  * maximum clocks following a vblank miss (see do_rps_boost()).
>  */
> if (!state->rps_interactive) {
> -   intel_rps_mark_interactive(_priv->gt.rps, true);
> +   intel_rps_mark_interactive(_priv->gt0.rps, true);

This should be across all gt, so probably wants a fresh interface that
takes i915 and does for_each_gt in a later patch. (Since we could be
rendering on a remote tile to present on a display.)

> state->rps_interactive = true;
> }
>  
> @@ -851,7 +851,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> return;
>  
> if (state->rps_interactive) {
> -   intel_rps_mark_interactive(_priv->gt.rps, false);
> +   intel_rps_mark_interactive(_priv->gt0.rps, false);
> state->rps_interactive = false;
> }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ceee8ac66717..d4fcd8f236476 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -838,7 +838,7 @@ __intel_display_resume(struct drm_device *dev,
>  static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
>  {
> return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
> -   intel_has_gpu_reset(_priv->gt));
> +   intel_has_gpu_reset(_priv->gt0));

All these display consumers probably want to use
dev_priv->ggtt->vm.gt, since the scanout capable GGTT would seem to be
the defining feature.

to_scanout_gt(i915) ?

>  static bool pxp_is_borked(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ebd775cb1661c..c62253d0af044 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -237,7 +237,7 @@ static int proto_context_set_persistence(struct 
> drm_i915_private *i915,
>  * colateral damage, and we should not pretend we can by
>  * exposing the interface.
>  */
> -   if (!intel_has_reset_engine(>gt))
> +   if (!intel_has_reset_engine(>gt0))
> return -ENODEV;

Prep for all gt. A lot of these need an all-gt interface so we don't
have for_each_gt spread all other the place.

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index ef22d4ed66ad6..69ad407eb15f3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -166,7 +166,7 @@ static struct dma_fence *i915_ttm_accel_move(struct 
> ttm_buffer_object *bo,
> enum i915_cache_level src_level, dst_level;
> int ret;
>  
> -   if (!i915->gt.migrate.context || intel_gt_is_wedged(>gt))
> +   if (!i915->gt0.migrate.context || intel_gt_is_wedged(>gt0))

This should already be looking at lmem->gt

> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 8f8bea08e734d..176ea5c7d422f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -116,7 +116,7 @@ static void set_scheduler_caps(struct drm_i915_private 
> *i915)
> disabled |= (I915_SCHEDULER_CAP_ENABLED |
>  I915_SCHEDULER_CAP_PRIORITY);
>  
> -   if (intel_uc_uses_guc_submission(>gt.uc))
> +   if (intel_uc_uses_guc_submission(>gt0.uc))

This shouldn't be looking at gt at all, but if it must, that information
must be coming via engine->gt. Kind of renders the mapping moot
currently.
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 07ff7ba7b2b71..63089e671a242 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2302,7 +2302,7 @@ unsigned long i915_read_mch_val(void)
> return 0;
>  
> with_intel_runtime_pm(>runtime_pm, wakeref) {
> -   struct intel_ips *ips = >gt.rps.ips;
> +   struct intel_ips *ips = >gt0.rps.ips;

Make mchdev_get() return the gt or rps, at the slight cost of making the
drm_dev_put() more complicated (but can be pushed into a mchdev_put for
symmetry).

> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a9727447c0379..4bfedc04f5c70 100644

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename gt to gt0

[Chris Wilson]

Quoting Andi Shyti (2021-11-17 13:34:56)
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 089fb4658b216..0bbf8c0c42eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -817,7 +817,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>  * maximum clocks following a vblank miss (see do_rps_boost()).
>  */
> if (!state->rps_interactive) {
> -   intel_rps_mark_interactive(_priv->gt.rps, true);
> +   intel_rps_mark_interactive(_priv->gt0.rps, true);

This should be across all gt, so probably wants a fresh interface that
takes i915 and does for_each_gt in a later patch. (Since we could be
rendering on a remote tile to present on a display.)

> state->rps_interactive = true;
> }
>  
> @@ -851,7 +851,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> return;
>  
> if (state->rps_interactive) {
> -   intel_rps_mark_interactive(_priv->gt.rps, false);
> +   intel_rps_mark_interactive(_priv->gt0.rps, false);
> state->rps_interactive = false;
> }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0ceee8ac66717..d4fcd8f236476 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -838,7 +838,7 @@ __intel_display_resume(struct drm_device *dev,
>  static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
>  {
> return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
> -   intel_has_gpu_reset(_priv->gt));
> +   intel_has_gpu_reset(_priv->gt0));

All these display consumers probably want to use
dev_priv->ggtt->vm.gt, since the scanout capable GGTT would seem to be
the defining feature.

to_scanout_gt(i915) ?

>  static bool pxp_is_borked(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ebd775cb1661c..c62253d0af044 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -237,7 +237,7 @@ static int proto_context_set_persistence(struct 
> drm_i915_private *i915,
>  * colateral damage, and we should not pretend we can by
>  * exposing the interface.
>  */
> -   if (!intel_has_reset_engine(>gt))
> +   if (!intel_has_reset_engine(>gt0))
> return -ENODEV;

Prep for all gt. A lot of these need an all-gt interface so we don't
have for_each_gt spread all other the place.

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index ef22d4ed66ad6..69ad407eb15f3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -166,7 +166,7 @@ static struct dma_fence *i915_ttm_accel_move(struct 
> ttm_buffer_object *bo,
> enum i915_cache_level src_level, dst_level;
> int ret;
>  
> -   if (!i915->gt.migrate.context || intel_gt_is_wedged(>gt))
> +   if (!i915->gt0.migrate.context || intel_gt_is_wedged(>gt0))

This should already be looking at lmem->gt

> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 8f8bea08e734d..176ea5c7d422f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -116,7 +116,7 @@ static void set_scheduler_caps(struct drm_i915_private 
> *i915)
> disabled |= (I915_SCHEDULER_CAP_ENABLED |
>  I915_SCHEDULER_CAP_PRIORITY);
>  
> -   if (intel_uc_uses_guc_submission(>gt.uc))
> +   if (intel_uc_uses_guc_submission(>gt0.uc))

This shouldn't be looking at gt at all, but if it must, that information
must be coming via engine->gt. Kind of renders the mapping moot
currently.
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 07ff7ba7b2b71..63089e671a242 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -2302,7 +2302,7 @@ unsigned long i915_read_mch_val(void)
> return 0;
>  
> with_intel_runtime_pm(>runtime_pm, wakeref) {
> -   struct intel_ips *ips = >gt.rps.ips;
> +   struct intel_ips *ips = >gt0.rps.ips;

Make mchdev_get() return the gt or rps, at the slight cost of making the
drm_dev_put() more complicated (but can be pushed into a mchdev_put for
symmetry).

> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a9727447c0379..4bfedc04f5c70 100644

Re: [Intel-gfx] [PATCH] drm/i915: remove IS_ACTIVE

[Chris Wilson]

Quoting Lucas De Marchi (2021-10-01 08:40:41)
> When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
> provide much value just encapsulating it in a boolean context. So I also
> added the support for handling undefined macros as the IS_ENABLED()
> counterpart. However the feedback received from Masahiro Yamada was that
> it is too ugly, not providing much value. And just wrapping in a boolean
> context is too dumb - we could simply open code it.
> 
> As detailed in commit babaab2f4738 ("drm/i915: Encapsulate kconfig
> constant values inside boolean predicates"), the IS_ACTIVE macro was
> added to workaround a compilation warning. However after checking again
> our current uses of IS_ACTIVE it turned out there is only
> 1 case in which it would potentially trigger a warning. All the others
>   can simply use the shorter version, without wrapping it in any macro.
> And even that single one didn't trigger any warning in gcc 10.3.
> 
> So here I'm dialing all the way back to simply removing the macro. If it
> triggers warnings in future we may change the few cases to check for > 0
> or != 0. Another possibility would be to use the great "not not
> operator" for all positive checks, which would allow us to maintain
> consistency.  However let's try first the simplest form though, hopefully
> we don't hit broken compilers spitting a warning:

You didn't prevent the compilation warning this re-introduces.

drivers/gpu/drm/i915/i915_config.c:11 i915_fence_context_timeout() warn: should 
this be a bitwise op?
drivers/gpu/drm/i915/i915_request.c:1679 i915_request_wait() warn: should this 
be a bitwise op?
-Chris

Re: gnubg-1_06_002-20180802-setup.exe Win10 Crashes

[Chris Wilson]

No issues here. I'm running on the latest insider preview build.

On Fri, Jul 30, 2021 at 1:58 AM Ian Shaw  wrote:

> Hi James, sorry to hear you are having problems - it must be very
> frustrating.
>
> Have you tried any other version?
> Have you tried this version on another PC?
>
> You could try messing with compatibility mode settings
> https://www.laptopmag.com/uk/articles/set-compatibility-mode-windows-10
> Or perhaps right-click and Run as Administrator
>
> I can't help much, I'm afraid. I'm running Version GNU Backgammon
> 1.06.001-mingw 32-Bit 20171216 on Windows 7 Pro, so it's a completey
> different environment.
>
> Regards,
> Ian Shaw
>
> -Original Message-
> From: Bug-gnubg [mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org]
> On Behalf Of James Eric Bjornsson
> Sent: 28 July 2021 15:44
> To: bug-gnubg@gnu.org
> Subject: gnubg-1_06_002-20180802-setup.exe Win10 Crashes
>
> After installation, select "settings/options".  Crash.  Happens every time
> on my Win10 system.   (Which I discovered --and find annoying-- because I
> prefer setting the match value to 21.)
>
> --JBj
>
> tea
>

[time-nuts] Re: Ublox NEO-M8T-0-10​as a LO question

[Chris Wilson]

Hello everyone

 Monday, March 29, 2021

 Thanks for the replies, some went a little over my head, which is not hard :) 
I am wondering how people successfully use a Leo Bodnar programmable GPS source 
to provide an external LO for an LNB as opposed to its internal xtal. What is 
different, in simple terms please, between my Ublox output and the Leo Bodnar 
one?


Best regards,
 Chrismailto:ch...@chriswilson.tv


LJ> On 3/29/21 10:14 AM, John Ackermann N8UR wrote:
>> That's probably a really bad idea.  The phase noise from the TIMEPULSE 
>> output is pretty bad compared to a "real" RF source, and by the time 
>> it's multiplied up to 10 GHz you'll have more noise than signal. 
>> Attached are some phase noise plots and a couple of spectrum analyzer 
>> captures to give you some idea what to expect.

>> BTW, even the Bodnar unit may not look too good at 10 GHz -- remember 
>> that you increase phase noise by 20 dB for 10 times multiplication.

>> John

LJ> What's the signal bandwidth from Es'Hail?

LJ> The optimum strategy is a *very quiet* crystal oscillator that you 
LJ> discipline with the 1pps, and choose that oscillator so its frequency is
LJ> what you need.

LJ> What we've done in the past is use the reference to clock a NCO in FPGA,
LJ> and use one of the well known spur reduction techniques that pushes the
LJ> spurs away from the center before running it to the DAC. This degrades
LJ> the performance at, say, 100kHz away, but improves the performance 
LJ> within 1 kHz. This relies on knowing what the loop bandwidth is in your
LJ> 10GHz LO PLL, since inside that bandwidth it's the reference, but 
LJ> outside it's the DRO or GaAs oscillator.


LJ> There might be some DDS chips that implement this kind of thing - the 
LJ> latest chips from ADI are pretty sophisticated.





>> On 3/29/21 12:25 PM, Chris Wilson wrote:


>>>29/03/2021 17:20

>>> Can I use my Ublox NEO-M8T-0-10​  as a LO for  a  modified satellite 
>>> LNB on 10 GHz? It needs 25 MHz and the Ublox is my only GPS locked 
>>> source for such a frequency. I want to receive the Es Hail downlink 
>>> with excellent stability. I can lock the receiver to 10 MHz which is 
>>> available from my Trimble Thunderbolt. If the Ublox would do I would 
>>> not have to buy something like the Leo Bodnar GPS. Thanks.


>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
>> email to time-nuts-le...@lists.febo.com
>> To unsubscribe, go to and follow the instructions there.

LJ> ___
LJ> time-nuts mailing list -- time-nuts@lists.febo.com -- To
LJ> unsubscribe send an email to time-nuts-le...@lists.febo.com
LJ> To unsubscribe, go to and follow the instructions there.
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

[time-nuts] Ublox NEO-M8T-0-10​as a LO question

[Chris Wilson]

  29/03/2021 17:20

Can I use my Ublox NEO-M8T-0-10​  as a LO for  a  modified satellite LNB on 10 
GHz? It needs 25 MHz and the Ublox is my only GPS locked source for such a 
frequency. I want to receive the Es Hail downlink with excellent stability. I 
can lock the receiver to 10 MHz which is available from my Trimble Thunderbolt. 
If the Ublox would do I would not have to buy something like the Leo Bodnar 
GPS. Thanks.

-- 
   Best Regards,
   Chris Wilson.
mailto: ch...@chriswilson.tv
___
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an 
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.

Re: [Intel-gfx] [PATCH] drm/i915: Avoid div-by-zero on gen2

[Chris Wilson]

Quoting Ville Syrjälä (2021-03-22 14:48:44)
> On Sun, Mar 21, 2021 at 04:30:32PM +0000, Chris Wilson wrote:
> > Quoting Chris Wilson (2021-03-21 16:28:07)
> > > Quoting Ville Syrjala (2021-03-21 16:10:38)
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > index ec28a6cde49b..0b2434e29d00 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > @@ -189,7 +189,7 @@ compute_partial_view(const struct 
> > > > drm_i915_gem_object *obj,
> > > > struct i915_ggtt_view view;
> > > >  
> > > > if (i915_gem_object_is_tiled(obj))
> > > > -   chunk = roundup(chunk, tile_row_pages(obj));
> > > > +   chunk = roundup(chunk, tile_row_pages(obj) ?: 1);
> > > 
> > > I was thinking the answer would be to align to the next page, and hey
> > > presto!
> > 
> > Wait, the tile row cannot be a single page. Something else is zero that
> > should not be.
> 
> How come? At least i915_tiling_ok() doesn't enforce any
> bigger lower bound.

This maybe the trap I'm falling into, thinking that all arch have at
least 4K tile rows. Some might say, "shouldn't the chunk be aligned to an
even tile row" as well, but I was never certain about that.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid div-by-zero on gen2

[Chris Wilson]

Quoting Chris Wilson (2021-03-21 16:30:32)
> Quoting Chris Wilson (2021-03-21 16:28:07)
> > Quoting Ville Syrjala (2021-03-21 16:10:38)
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > index ec28a6cde49b..0b2434e29d00 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > @@ -189,7 +189,7 @@ compute_partial_view(const struct drm_i915_gem_object 
> > > *obj,
> > > struct i915_ggtt_view view;
> > >  
> > > if (i915_gem_object_is_tiled(obj))
> > > -   chunk = roundup(chunk, tile_row_pages(obj));
> > > +   chunk = roundup(chunk, tile_row_pages(obj) ?: 1);
> > 
> > I was thinking the answer would be to align to the next page, and hey
> > presto!
> 
> Wait, the tile row cannot be a single page. Something else is zero that
> should not be.

Which fortunately does not matter here, as we start with a 2MiB chunk
and want to align that to a multiple of tile rows. Still, as you said,
something stinks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid div-by-zero on gen2

[Chris Wilson]

Quoting Chris Wilson (2021-03-21 16:28:07)
> Quoting Ville Syrjala (2021-03-21 16:10:38)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index ec28a6cde49b..0b2434e29d00 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -189,7 +189,7 @@ compute_partial_view(const struct drm_i915_gem_object 
> > *obj,
> > struct i915_ggtt_view view;
> >  
> > if (i915_gem_object_is_tiled(obj))
> > -   chunk = roundup(chunk, tile_row_pages(obj));
> > +   chunk = roundup(chunk, tile_row_pages(obj) ?: 1);
> 
> I was thinking the answer would be to align to the next page, and hey
> presto!

Wait, the tile row cannot be a single page. Something else is zero that
should not be.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid div-by-zero on gen2

[Chris Wilson]

Quoting Ville Syrjala (2021-03-21 16:10:38)
> From: Ville Syrjälä 
> 
> Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size()
> can in fact return <4KiB, which leads to div-by-zero here.
> Avoid that.

So long as we overestimate it is fine, since we only care to find a
suitably small chunk that is large enough. I thought it was
overestimating, oh well.
 
> Not sure i915_gem_object_get_tile_row_size() is entirely
> sane anyway since it doesn't account for the different tile
> layouts on i8xx/i915...

It should not matter so long as we pick a common divisor, suitable for
the fence register.
 
> I'm not able to hit this before commit 6846895fde05 ("drm/i915:
> Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks
> like I also need to run recent version of Mesa. With those in
> place xonotic trips on this quite easily on my 85x.

NOEVICT will make it much less eager to remove older bindings, with the
preference then to use smaller views of objects. The theory being that
the workingset is less than the whole object, so we can fit more active
pages in and cause less thrashing when moving the unused pages around
in the GTT.

> Cc: Chris Wilson 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index ec28a6cde49b..0b2434e29d00 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -189,7 +189,7 @@ compute_partial_view(const struct drm_i915_gem_object 
> *obj,
> struct i915_ggtt_view view;
>  
> if (i915_gem_object_is_tiled(obj))
> -   chunk = roundup(chunk, tile_row_pages(obj));
> +   chunk = roundup(chunk, tile_row_pages(obj) ?: 1);

I was thinking the answer would be to align to the next page, and hey
presto!

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[issue43566] Docs say int('010', 0) is not legal, but it is

[Chris Wilson]

Chris Wilson  added the comment:

Actually, octal is not a legal literal in Python 3, sorry.

--
resolution:  -> rejected

___
Python tracker 
<https://bugs.python.org/issue43566>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43566] Docs say int('010', 0) is not legal, but it is

[Chris Wilson]

New submission from Chris Wilson :

The documentation for the int() builtin says:

Base 0 means to interpret exactly as a code literal, so that the actual base is 
2, 8, 10, or 16, and so that int('010', 0) is not legal, while int('010') is, 
as well as int('010', 8).

https://docs.python.org/3/library/functions.html#int

However 010 is a valid code literal, and int('010', 0) is legal (both are 
correctly interpreted as octal).

--
assignee: docs@python
components: Documentation
messages: 389145
nosy: docs@python, wilscm
priority: normal
severity: normal
status: open
title: Docs say int('010', 0) is not legal, but it is
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue43566>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: [Intel-gfx] [PATCH] i915: Drop relocation support on all new hardware (v3)

[Chris Wilson]

Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> > 
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
> > 
> > v2 (Jason Ekstrand):
> >  - Allow TGL-LP platforms as they've already shipped
> > 
> > v3 (Jason Ekstrand):
> >  - WARN_ON platforms with LMEM support in case the check is wrong
> 
> I was asked to review of this patch. It works along with expected
> IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954=25
> 
> Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> to do for loop just after copy_from_user() and check relocation_count?
> We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering 
> i915_gem_do_execbuffer().

There's a NORELOC flag you can enforce as mandatory. That's trivial for
userspace to set, really makes sure they are aware of the change afoot,
and i915_gem_ceck_execbuffer() will perform the validation upfront with
the other flag checks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Chris Wilson]

Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> > only supported by iris which never uses relocations.  The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+.  The
> > compute driver also never uses relocations.  This only leaves the media
> > driver which is supposed to be switching to softpin going forward.
> > Making softpin a requirement for all future hardware seems reasonable.
> > 
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory.  Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
> > 
> > v2 (Jason Ekstrand):
> >  - Allow TGL-LP platforms as they've already shipped
> > 
> > v3 (Jason Ekstrand):
> >  - WARN_ON platforms with LMEM support in case the check is wrong
> 
> I was asked to review of this patch. It works along with expected
> IGT check https://patchwork.freedesktop.org/patch/423361/?series=82954=25
> 
> Before I'll give you r-b - isn't i915_gem_execbuffer2_ioctl() better place
> to do for loop just after copy_from_user() and check relocation_count?
> We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering 
> i915_gem_do_execbuffer().

There's a NORELOC flag you can enforce as mandatory. That's trivial for
userspace to set, really makes sure they are aware of the change afoot,
and i915_gem_ceck_execbuffer() will perform the validation upfront with
the other flag checks.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

[Chris Wilson]

Quoting Daniel Vetter (2021-03-11 16:01:46)
> On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote:
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7.  Ever
> > since that commit, we've been having issues where a hang in one client
> > can propagate to another.  In particular, a hang in an app can propagate
> > to the X server which causes the whole desktop to lock up.
> > 
> > Signed-off-by: Jason Ekstrand 
> > Reported-by: Marcin Slusarz 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already 
> > signaled fences")
> 
> Yeah I suggested to just go with the revert, so I guess on my to give you
> the explainer to be added to the commit message.

If you took the patch this was copied from and only revert on the
dma-resv, things do not break horribly.

> Error propagation along fences sound like a good idea, but as your bug
> shows, surprising consequences, since propagating errors across security
> boundaries is not a good thing.
> 
> What we do have is track the hangs on the ctx, and report information to
> userspace using RESET_STATS.

And by the fence, which is far more precise.

> That's how arb_robustness works. Also, if my
> understanding is still correct, the EIO from execbuf is when your context
> is banned (because not recoverable or too many hangs). And in all these
> cases it's up to userspace to figure out what is all impacted and should
> be reported to the application, that's not on the kernel to guess and
> automatically propagate.
> 
> What's more, we're also building more features on top of ctx error
> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> userspace fence wait also relies on that mechanism. So it is the path
> going forward for reporting gpu hangs and resets to userspace.

That ioctl is not a solid basis, it never did quite work as expected and
we kept realising the limitations of the information and the accuracy
that it could report.
 
> So all together that's why I think we should just bury this idea again as
> not quite the direction we want to go to, hence why I think the revert is
> the right option here.

No, as shown by igt it's a critical issue that we have to judicially
chose which errors to ignore. And it's not just the ability to subvert
gen7 and gen9, it's the error tracking employed for preempting contexts
among others.  Hence go with the original patch to undo the propagation
along dma-resv.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

[Chris Wilson]

Quoting Daniel Vetter (2021-03-11 16:01:46)
> On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote:
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7.  Ever
> > since that commit, we've been having issues where a hang in one client
> > can propagate to another.  In particular, a hang in an app can propagate
> > to the X server which causes the whole desktop to lock up.
> > 
> > Signed-off-by: Jason Ekstrand 
> > Reported-by: Marcin Slusarz 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already 
> > signaled fences")
> 
> Yeah I suggested to just go with the revert, so I guess on my to give you
> the explainer to be added to the commit message.

If you took the patch this was copied from and only revert on the
dma-resv, things do not break horribly.

> Error propagation along fences sound like a good idea, but as your bug
> shows, surprising consequences, since propagating errors across security
> boundaries is not a good thing.
> 
> What we do have is track the hangs on the ctx, and report information to
> userspace using RESET_STATS.

And by the fence, which is far more precise.

> That's how arb_robustness works. Also, if my
> understanding is still correct, the EIO from execbuf is when your context
> is banned (because not recoverable or too many hangs). And in all these
> cases it's up to userspace to figure out what is all impacted and should
> be reported to the application, that's not on the kernel to guess and
> automatically propagate.
> 
> What's more, we're also building more features on top of ctx error
> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> userspace fence wait also relies on that mechanism. So it is the path
> going forward for reporting gpu hangs and resets to userspace.

That ioctl is not a solid basis, it never did quite work as expected and
we kept realising the limitations of the information and the accuracy
that it could report.
 
> So all together that's why I think we should just bury this idea again as
> not quite the direction we want to go to, hence why I think the revert is
> the right option here.

No, as shown by igt it's a critical issue that we have to judicially
chose which errors to ignore. And it's not just the ability to subvert
gen7 and gen9, it's the error tracking employed for preempting contexts
among others.  Hence go with the original patch to undo the propagation
along dma-resv.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-03-10 10:19:12)
> 
> Hi,
> 
> On 08/03/2021 17:32, Chiou, Cooper wrote:
> > I've tested on GLK, KBL, CFL Intel NUC devices and got the following 
> > performance results, there is no performance regression per my testing.
> > 
> > Patch: [v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads 
> > for Gen9
> > Test suite: 
> > phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second
> > Kernel version: 5.12.0-rc1 (drm-tip)
> > 
> > a. Device: Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2 Cores)
> >  Without patch, fps=57.45
> >  With patch, fps=57.49
> > b. Device: Intel NUC kit NUC8BEH Coffee Lake Core i3-8109U @3.6GHz(4 Cores)
> >  Without patch, fps=117.23
> >  With patch, fps=117.27
> > c. Device: Intel NUC kit NUC7i3BNH Kaby Lake Core i3-7100U @2.4GHz(4 Cores)
> >  Without patch, fps=114.05
> >  With patch, fps=114.34
> > 
> > Meanwhile, Intel lkp team has validated performance on lkp-kbl-nuc1 and no 
> > regression.
> > f69d02e37a85645a  d912096c40cdc3bc9364966971 testcase/testparams/testbox
> >   -- ---
> >%stddev  change %stddev
> >\  |\
> >29.79   29.67
> > phoronix-test-suite/performance-true-Fullscreen-Ultimate-1-Gran_Paradiso_Island__Approxima-supertuxkart-1.5.2-ucode=0xde/lkp-kbl-nuc1
> >29.79   29.67GEO-MEAN 
> > phoronix-test-suite.supertuxkart.1280x1024.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second
> > 
> 
> CI results are green so that is good.
> 
> Do the machines used for performance testing include unusual fusing? 
> Worrying thing is that we were never able to reproduce the reported 
> regression in house due lack of identical machine, right? Although I 
> guess avoiding hangs trumps performance.

The issue is that if the regression is reproducible it means that the
broadcast mask is no longer correct (or never was, one or the other ;)
And another w/a is going astray because it depends on the previous
undefined value of the mcr.

Which raises the question as to whether the hang prevention seen here is
also because some other w/a (or other mmio) is not being applied to the
relevant units. Or vice versa.

Either way there remains an underlying issue in that some register
writes for gen9 require mcr being set that were are not handling
correctly. Changing the mask here changing results elsewhere indicate
that the issues are fully addressed, and the fear that undoing some
other mmio is going to introduce other subtle hangs. And we are all
blindly poking at the issue as no one has access to the affected skus.

What would be useful is if we print the value before changing it so that
we can see if we have any machines in CI where we are making significant
changes to the broadcast mask.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] gpu: drm: i915: fix error return code of igt_buddy_alloc_smoke()

[Chris Wilson]

Quoting Jia-Ju Bai (2021-03-08 08:59:52)
> When i915_random_order() returns NULL to order, no error return code of
> igt_buddy_alloc_smoke() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.

It would not be EINVAL since that is used for a reference failure, but
in this case the idea was to return 0 as no testing was done and the
ENOMEM was raised before testing began i.e. not an internal and
unexpected driver allocation failure.
-Chris

Re: [Intel-gfx] [PATCH] gpu: drm: i915: fix error return code of igt_buddy_alloc_smoke()

[Chris Wilson]

Quoting Jia-Ju Bai (2021-03-08 08:59:52)
> When i915_random_order() returns NULL to order, no error return code of
> igt_buddy_alloc_smoke() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.

It would not be EINVAL since that is used for a reference failure, but
in this case the idea was to return 0 as no testing was done and the
ENOMEM was raised before testing began i.e. not an internal and
unexpected driver allocation failure.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] gpu: drm: i915: fix error return code of igt_buddy_alloc_smoke()

[Chris Wilson]

Quoting Jia-Ju Bai (2021-03-08 08:59:52)
> When i915_random_order() returns NULL to order, no error return code of
> igt_buddy_alloc_smoke() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.

It would not be EINVAL since that is used for a reference failure, but
in this case the idea was to return 0 as no testing was done and the
ENOMEM was raised before testing began i.e. not an internal and
unexpected driver allocation failure.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: i915: fix error return code of igt_threaded_blt()

[Chris Wilson]

Quoting Jia-Ju Bai (2021-03-08 09:07:22)
> When kcalloc() returns NULL to tsk or thread, no error code of 
> igt_threaded_blt() is returned.
> To fix this bug, -ENOMEM is returned as error code.

Because we decided to skip the test if it could not be run due to
insufficient memory, as opposed to an internal allocation failure from
the driver.
-Chris

Re: [PATCH] gpu: drm: i915: fix error return code of igt_threaded_blt()

[Chris Wilson]

Quoting Jia-Ju Bai (2021-03-08 09:07:22)
> When kcalloc() returns NULL to tsk or thread, no error code of 
> igt_threaded_blt() is returned.
> To fix this bug, -ENOMEM is returned as error code.

Because we decided to skip the test if it could not be run due to
insufficient memory, as opposed to an internal allocation failure from
the driver.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] gpu: drm: i915: fix error return code of igt_threaded_blt()

[Chris Wilson]

Quoting Jia-Ju Bai (2021-03-08 09:07:22)
> When kcalloc() returns NULL to tsk or thread, no error code of 
> igt_threaded_blt() is returned.
> To fix this bug, -ENOMEM is returned as error code.

Because we decided to skip the test if it could not be run due to
insufficient memory, as opposed to an internal allocation failure from
the driver.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

[Chris Wilson]

Quoting Jason Ekstrand (2021-03-05 17:05:46)
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7.  Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another.  In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.

The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

[Chris Wilson]

Quoting Jason Ekstrand (2021-03-05 17:05:46)
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7.  Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another.  In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.

The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Chris Wilson]

Quoting Chris Wilson (2021-03-05 12:20:45)
> Quoting Tvrtko Ursulin (2021-03-05 09:23:02)
> > I am not sure if PC8 and DMC could also be involved from what Cooper was 
> > saying in a different thread. Maybe another CI run without the DMC, both 
> > ffs and fls. Another for limiting cstates.
> 
> Disabling the dmc leaves the display code in an inconsistent state so we
> don't complete a BAT run; but since the warnings are thrown during boot
> we can say that disabling the dmc does clear up the workaround issues on
> ehl/jsl:
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7612/fi-ehl-2/boot0.txt
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7612/fi-jsl-1/boot0.txt

Fwiw, disabling the dmc and using fls for gen9 is not enough to avoid
the warnings though:

https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7614/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html

So far only ffs works for gen9 mcr.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] rtc: cmos: Disable irq around direct invocation of cmos_interrupt()

[Chris Wilson]

9b/0xaa0
<4>[  254.194066]  pm_suspend.cold.8+0x301/0x34a
<4>[  254.194094]  state_store+0x7b/0xe0
<4>[  254.194124]  kernfs_fop_write_iter+0x11d/0x1c0
<4>[  254.194151]  new_sync_write+0x11d/0x1b0
<4>[  254.194183]  vfs_write+0x265/0x390
<4>[  254.194207]  ksys_write+0x5a/0xd0
<4>[  254.194232]  do_syscall_64+0x33/0x80
<4>[  254.194251]  entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[  254.194274] RIP: 0033:0x7f07d79691e7
<4>[  254.194293] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 
00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 
00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
<4>[  254.194312] RSP: 002b:7ffd9cc2c768 EFLAGS: 0246 ORIG_RAX: 
0001
<4>[  254.194337] RAX: ffda RBX: 0004 RCX: 
7f07d79691e7
<4>[  254.194352] RDX: 0004 RSI: 556ebfc63590 RDI: 
000b
<4>[  254.194366] RBP: 556ebfc63590 R08:  R09: 
0004
<4>[  254.194379] R10: 556ebf0ec2a6 R11: 0246 R12: 
0004

which breaks S3-resume on fi-kbl-soraka presumably as that's slow enough
to trigger the alarm during the suspend.

Fixes: 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in 
hard IRQ")
References: 66e4f4a9cc38 ("rtc: cmos: Use spin_lock_irqsave() in 
cmos_interrupt()"):
Signed-off-by: Chris Wilson 
Cc: Xiaofei Tan 
Cc: Alexandre Belloni 
Cc: Alessandro Zummo 
Cc: Ville Syrjälä 
---
 drivers/rtc/rtc-cmos.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 670fd8a2970e..6545afb2f20e 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -1053,7 +1053,9 @@ static void cmos_check_wkalrm(struct device *dev)
 * ACK the rtc irq here
 */
if (t_now >= cmos->alarm_expires && cmos_use_acpi_alarm()) {
+   local_irq_disable();
cmos_interrupt(0, (void *)cmos->rtc);
+   local_irq_enable();
return;
}
 
-- 
2.20.1

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-03-05 09:23:02)
> I am not sure if PC8 and DMC could also be involved from what Cooper was 
> saying in a different thread. Maybe another CI run without the DMC, both 
> ffs and fls. Another for limiting cstates.

Disabling the dmc leaves the display code in an inconsistent state so we
don't complete a BAT run; but since the warnings are thrown during boot
we can say that disabling the dmc does clear up the workaround issues on
ehl/jsl:

https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7612/fi-ehl-2/boot0.txt
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7612/fi-jsl-1/boot0.txt
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] dma-buf: Fix confusion of dynamic dma-buf vs dynamic attachment

[Chris Wilson]

Commit c545781e1c55 ("dma-buf: doc polish for pin/unpin") disagrees with
the introduction of dynamism in commit: bb42df4662a4 ("dma-buf: add
dynamic DMA-buf handling v15") resulting in warning spew on
importing dma-buf. Silence the warning from the latter by only pinning
the attachment if the attachment rather than the dmabuf is to be
dynamic.

Fixes: bb42df4662a4 ("dma-buf: add dynamic DMA-buf handling v15")
Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Christian König 
Cc:  # v5.7+
---
 drivers/dma-buf/dma-buf.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..09f5ae458515 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -758,8 +758,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
 
-   if (dma_buf_is_dynamic(attach->dmabuf)) {
-   dma_resv_lock(attach->dmabuf->resv, NULL);
+   if (dma_buf_attachment_is_dynamic(attach)) {
+   dma_resv_lock(dmabuf->resv, NULL);
ret = dma_buf_pin(attach);
if (ret)
goto err_unlock;
@@ -772,8 +772,9 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
+   if (dma_buf_attachment_is_dynamic(attach))
+   dma_resv_unlock(dmabuf->resv);
+
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: rename DISP_STEPPING->DISPLAY_STEP and GT_STEPPING->GT_STEP

[Chris Wilson]

Quoting Jani Nikula (2021-02-24 08:46:55)
> On Tue, 23 Feb 2021, Lucas De Marchi  wrote:
> > On Tue, Feb 23, 2021 at 05:35:11PM +0200, Jani Nikula wrote:
> >>Matter of taste. STEP matches the enums.
> >>
> >>Signed-off-by: Jani Nikula 
> >>---
> >> drivers/gpu/drm/i915/display/intel_display_power.c |  2 +-
> >> drivers/gpu/drm/i915/display/intel_psr.c   |  4 ++--
> >> drivers/gpu/drm/i915/display/skl_universal_plane.c |  2 +-
> >> drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 +-
> >> drivers/gpu/drm/i915/i915_drv.h| 10 +-
> >> drivers/gpu/drm/i915/intel_device_info.c   |  2 +-
> >> drivers/gpu/drm/i915/intel_pm.c|  2 +-
> >> 7 files changed, 16 insertions(+), 16 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> >>b/drivers/gpu/drm/i915/display/intel_display_power.c
> >>index f00c1750febd..1f7b2700947a 100644
> >>--- a/drivers/gpu/drm/i915/display/intel_display_power.c
> >>+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> >>@@ -5349,7 +5349,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private 
> >>*dev_priv)
> >>
> >>  if (IS_ALDERLAKE_S(dev_priv) ||
> >>  IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
> >>- IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_B0))
> >>+ IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> >>  /* Wa_1409767108:tgl,dg1,adl-s */
> >>  table = wa_1409767108_buddy_page_masks;
> >>  else
> >>diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> >>b/drivers/gpu/drm/i915/display/intel_psr.c
> >>index 7c6e561f86c1..da5084b54eb6 100644
> >>--- a/drivers/gpu/drm/i915/display/intel_psr.c
> >>+++ b/drivers/gpu/drm/i915/display/intel_psr.c
> >>@@ -548,7 +548,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> >>
> >>  if (intel_dp->psr.psr2_sel_fetch_enabled) {
> >>  /* WA 1408330847 */
> >>- if (IS_TGL_DISP_STEPPING(dev_priv, STEP_A0, STEP_A0) ||
> >>+ if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> >
> > I always hated the DISP vs DISPLAY. It should be in the commit message.
> >
> > But if you are doing the s/STEPPING/STEP/, shouldn't the filename also use
> > step and all the functions/structs?
> 
> To be honest, the rename came as an afterthought, after Aditya (I think)
> added the STEP_X enums.
> 
> For me step everywhere sounds good, I wonder what the native speakers
> think.

IS_DISPLAY_STEPPING(STEP_X) is more flamboyant than
IS_DISPLAY_STEP(STEP_X), but we often make the concession for brevity
and in this case the consistency between macro and enum beats the
inconsistency in English. So STEP reads as a perfectly acceptable synonym
for STEPPING.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Chris Wilson]

Quoting Chris Wilson (2021-03-04 11:56:16)
> Quoting Chris Wilson (2021-03-04 09:19:24)
> > Quoting Tvrtko Ursulin (2021-03-04 09:12:26)
> > > 
> > > On 02/03/2021 06:27, Cooper Chiou wrote:
> > > > WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to
> > > > resolve VP8 hardware encoding system hang up on GT1 sku for
> > > > ChromiumOS projects
> > > > 
> > > > Slice specific MMIO read inaccurate so MGSR needs to be programmed
> > > > appropriately to get correct reads from these slicet-related MMIOs.
> > > > 
> > > > It dictates that before any MMIO read into Slice/Subslice specific
> > > > registers, MCR packet control register(0xFDC) needs to be programmed
> > > > to point to any enabled slice/subslice pair, especially GT1 fused sku
> > > > since this issue can be reproduced on VP8 hardware encoding via ffmpeg
> > > > on ChromiumOS devices.
> > > > When exit PC7, MGSR will reset so that we have to skip fused subslice 
> > > > ID.
> > > > 
> > > > Reference: HSD#1508045018,1405586840, BSID#0575
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Jani Nikula 
> > > > Cc: Chris Wilson 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: William Tseng 
> > > > Cc: Lee Shawn C 
> > > > 
> > > > Signed-off-by: Cooper Chiou 
> > > > ---
> > > >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 +
> > > >   1 file changed, 38 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > index 3b4a7da60f0b..4ad598a727a6 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > @@ -878,9 +878,47 @@ hsw_gt_workarounds_init(struct drm_i915_private 
> > > > *i915, struct i915_wa_list *wal)
> > > >   wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> > > >   }
> > > >   
> > > > +static void
> > > > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list 
> > > > *wal)
> > > > +{
> > > > + const struct sseu_dev_info *sseu = >gt.info.sseu;
> > > > + unsigned int slice, subslice;
> > > > + u32 mcr, mcr_mask;
> > > > +
> > > > + GEM_BUG_ON(INTEL_GEN(i915) < 9);
> > > > +
> > > > + /*
> > > > +  * WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml
> > > > +  * Before any MMIO read into slice/subslice specific registers, 
> > > > MCR
> > > > +  * packet control register needs to be programmed to point to any
> > > > +  * enabled s/ss pair. Otherwise, incorrect values will be 
> > > > returned.
> > > > +  * This means each subsequent MMIO read will be forwarded to an
> > > > +  * specific s/ss combination, but this is OK since these registers
> > > > +  * are consistent across s/ss in almost all cases. In the rare
> > > > +  * occasions, such as INSTDONE, where this value is dependent
> > > > +  * on s/ss combo, the read should be done with read_subslice_reg.
> > > > +  */
> > > > + slice = fls(sseu->slice_mask) - 1;
> > > > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
> > > > + subslice = fls(intel_sseu_get_subslices(sseu, slice));
> > > > + GEM_BUG_ON(!subslice);
> > > > + subslice--;
> > > > +
> > > > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> > > > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
> > > > +
> > > > + drm_dbg(>drm, "MCR slice:%d/subslice:%d = %x\n", slice, 
> > > > subslice, mcr);
> > > > +
> > > > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
> > > > +}
> > > 
> > > Have you considered reusing existing wa_init_mcr? Just needs the 
> > > top-level assert changed and otherwise it looks it would do the right 
> > > thing for Gen9. Advantage being a smaller patch and less code to carry.
> > 
> > That was the first patch, and fails for the same reason. The problem
> > would appear to be in the mcr_mask for gt3.
> 
> For the record, it appears to be an issue with fls vs ffs. Switching to
> ffs also removes the warnings for workaround failures on ehl/jsl.

Of course the icl in farm2 started spewing warnigns, but the other icl
in farm1 were happy.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Chris Wilson]

Quoting Chris Wilson (2021-03-04 09:19:24)
> Quoting Tvrtko Ursulin (2021-03-04 09:12:26)
> > 
> > On 02/03/2021 06:27, Cooper Chiou wrote:
> > > WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to
> > > resolve VP8 hardware encoding system hang up on GT1 sku for
> > > ChromiumOS projects
> > > 
> > > Slice specific MMIO read inaccurate so MGSR needs to be programmed
> > > appropriately to get correct reads from these slicet-related MMIOs.
> > > 
> > > It dictates that before any MMIO read into Slice/Subslice specific
> > > registers, MCR packet control register(0xFDC) needs to be programmed
> > > to point to any enabled slice/subslice pair, especially GT1 fused sku
> > > since this issue can be reproduced on VP8 hardware encoding via ffmpeg
> > > on ChromiumOS devices.
> > > When exit PC7, MGSR will reset so that we have to skip fused subslice ID.
> > > 
> > > Reference: HSD#1508045018,1405586840, BSID#0575
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: Rodrigo Vivi 
> > > Cc: Jani Nikula 
> > > Cc: Chris Wilson 
> > > Cc: Tvrtko Ursulin 
> > > Cc: William Tseng 
> > > Cc: Lee Shawn C 
> > > 
> > > Signed-off-by: Cooper Chiou 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 +
> > >   1 file changed, 38 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 3b4a7da60f0b..4ad598a727a6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -878,9 +878,47 @@ hsw_gt_workarounds_init(struct drm_i915_private 
> > > *i915, struct i915_wa_list *wal)
> > >   wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> > >   }
> > >   
> > > +static void
> > > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
> > > +{
> > > + const struct sseu_dev_info *sseu = >gt.info.sseu;
> > > + unsigned int slice, subslice;
> > > + u32 mcr, mcr_mask;
> > > +
> > > + GEM_BUG_ON(INTEL_GEN(i915) < 9);
> > > +
> > > + /*
> > > +  * WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml
> > > +  * Before any MMIO read into slice/subslice specific registers, MCR
> > > +  * packet control register needs to be programmed to point to any
> > > +  * enabled s/ss pair. Otherwise, incorrect values will be returned.
> > > +  * This means each subsequent MMIO read will be forwarded to an
> > > +  * specific s/ss combination, but this is OK since these registers
> > > +  * are consistent across s/ss in almost all cases. In the rare
> > > +  * occasions, such as INSTDONE, where this value is dependent
> > > +  * on s/ss combo, the read should be done with read_subslice_reg.
> > > +  */
> > > + slice = fls(sseu->slice_mask) - 1;
> > > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
> > > + subslice = fls(intel_sseu_get_subslices(sseu, slice));
> > > + GEM_BUG_ON(!subslice);
> > > + subslice--;
> > > +
> > > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> > > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
> > > +
> > > + drm_dbg(>drm, "MCR slice:%d/subslice:%d = %x\n", slice, 
> > > subslice, mcr);
> > > +
> > > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
> > > +}
> > 
> > Have you considered reusing existing wa_init_mcr? Just needs the 
> > top-level assert changed and otherwise it looks it would do the right 
> > thing for Gen9. Advantage being a smaller patch and less code to carry.
> 
> That was the first patch, and fails for the same reason. The problem
> would appear to be in the mcr_mask for gt3.

For the record, it appears to be an issue with fls vs ffs. Switching to
ffs also removes the warnings for workaround failures on ehl/jsl.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/query: Correlate engine and cpu timestamps with better accuracy

[Chris Wilson]

Quoting Lionel Landwerlin (2021-03-04 09:45:47)
> On 04/03/2021 10:58, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2021-03-04 08:28:59)
> >> On 04/03/2021 02:09, Chris Wilson wrote:
> >>> Quoting Umesh Nerlige Ramappa (2021-03-03 21:28:00)
> >>>> Perf measurements rely on CPU and engine timestamps to correlate
> >>>> events of interest across these time domains. Current mechanisms get
> >>>> these timestamps separately and the calculated delta between these
> >>>> timestamps lack enough accuracy.
> >>>>
> >>>> To improve the accuracy of these time measurements to within a few us,
> >>>> add a query that returns the engine and cpu timestamps captured as
> >>>> close to each other as possible.
> >>>>
> >>>> v2: (Tvrtko)
> >>>> - document clock reference used
> >>>> - return cpu timestamp always
> >>>> - capture cpu time just before lower dword of cs timestamp
> >>>>
> >>>> v3: (Chris)
> >>>> - use uncore-rpm
> >>>> - use __query_cs_timestamp helper
> >>>>
> >>>> v4: (Lionel)
> >>>> - Kernel perf subsytem allows users to specify the clock id to be used
> >>>> in perf_event_open. This clock id is used by the perf subsystem to
> >>>> return the appropriate cpu timestamp in perf events. Similarly, let
> >>>> the user pass the clockid to this query so that cpu timestamp
> >>>> corresponds to the clock id requested.
> >>>>
> >>>> v5: (Tvrtko)
> >>>> - Use normal ktime accessors instead of fast versions
> >>>> - Add more uApi documentation
> >>>>
> >>>> v6: (Lionel)
> >>>> - Move switch out of spinlock
> >>>>
> >>>> v7: (Chris)
> >>>> - cs_timestamp is a misnomer, use cs_cycles instead
> >>>> - return the cs cycle frequency as well in the query
> >>>>
> >>>> v8:
> >>>> - Add platform and engine specific checks
> >>>>
> >>>> v9: (Lionel)
> >>>> - Return 2 cpu timestamps in the query - captured before and after the
> >>>> register read
> >>>>
> >>>> Signed-off-by: Umesh Nerlige Ramappa 
> >>>> ---
> >>>>drivers/gpu/drm/i915/i915_query.c | 144 ++
> >>>>include/uapi/drm/i915_drm.h   |  47 ++
> >>>>2 files changed, 191 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> >>>> b/drivers/gpu/drm/i915/i915_query.c
> >>>> index fed337ad7b68..acca22ee6014 100644
> >>>> --- a/drivers/gpu/drm/i915/i915_query.c
> >>>> +++ b/drivers/gpu/drm/i915/i915_query.c
> >>>> @@ -6,6 +6,8 @@
> >>>>
> >>>>#include 
> >>>>
> >>>> +#include "gt/intel_engine_pm.h"
> >>>> +#include "gt/intel_engine_user.h"
> >>>>#include "i915_drv.h"
> >>>>#include "i915_perf.h"
> >>>>#include "i915_query.h"
> >>>> @@ -90,6 +92,147 @@ static int query_topology_info(struct 
> >>>> drm_i915_private *dev_priv,
> >>>>   return total_length;
> >>>>}
> >>>>
> >>>> +typedef u64 (*__ktime_func_t)(void);
> >>>> +static __ktime_func_t __clock_id_to_func(clockid_t clk_id)
> >>>> +{
> >>>> +   /*
> >>>> +* Use logic same as the perf subsystem to allow user to select 
> >>>> the
> >>>> +* reference clock id to be used for timestamps.
> >>>> +*/
> >>>> +   switch (clk_id) {
> >>>> +   case CLOCK_MONOTONIC:
> >>>> +   return _get_ns;
> >>>> +   case CLOCK_MONOTONIC_RAW:
> >>>> +   return _get_raw_ns;
> >>>> +   case CLOCK_REALTIME:
> >>>> +   return _get_real_ns;
> >>>> +   case CLOCK_BOOTTIME:
> >>>> +   return _get_boottime_ns;
> >>>> +   case CLOCK_TAI:
> >>>> +   return _get_clocktai_ns;
> >>>> +   default:
> >>>> +   

Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-03-04 09:12:26)
> 
> On 02/03/2021 06:27, Cooper Chiou wrote:
> > WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to
> > resolve VP8 hardware encoding system hang up on GT1 sku for
> > ChromiumOS projects
> > 
> > Slice specific MMIO read inaccurate so MGSR needs to be programmed
> > appropriately to get correct reads from these slicet-related MMIOs.
> > 
> > It dictates that before any MMIO read into Slice/Subslice specific
> > registers, MCR packet control register(0xFDC) needs to be programmed
> > to point to any enabled slice/subslice pair, especially GT1 fused sku
> > since this issue can be reproduced on VP8 hardware encoding via ffmpeg
> > on ChromiumOS devices.
> > When exit PC7, MGSR will reset so that we have to skip fused subslice ID.
> > 
> > Reference: HSD#1508045018,1405586840, BSID#0575
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: William Tseng 
> > Cc: Lee Shawn C 
> > 
> > Signed-off-by: Cooper Chiou 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 +
> >   1 file changed, 38 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 3b4a7da60f0b..4ad598a727a6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -878,9 +878,47 @@ hsw_gt_workarounds_init(struct drm_i915_private *i915, 
> > struct i915_wa_list *wal)
> >   wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> >   }
> >   
> > +static void
> > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
> > +{
> > + const struct sseu_dev_info *sseu = >gt.info.sseu;
> > + unsigned int slice, subslice;
> > + u32 mcr, mcr_mask;
> > +
> > + GEM_BUG_ON(INTEL_GEN(i915) < 9);
> > +
> > + /*
> > +  * WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml
> > +  * Before any MMIO read into slice/subslice specific registers, MCR
> > +  * packet control register needs to be programmed to point to any
> > +  * enabled s/ss pair. Otherwise, incorrect values will be returned.
> > +  * This means each subsequent MMIO read will be forwarded to an
> > +  * specific s/ss combination, but this is OK since these registers
> > +  * are consistent across s/ss in almost all cases. In the rare
> > +  * occasions, such as INSTDONE, where this value is dependent
> > +  * on s/ss combo, the read should be done with read_subslice_reg.
> > +  */
> > + slice = fls(sseu->slice_mask) - 1;
> > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
> > + subslice = fls(intel_sseu_get_subslices(sseu, slice));
> > + GEM_BUG_ON(!subslice);
> > + subslice--;
> > +
> > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
> > +
> > + drm_dbg(>drm, "MCR slice:%d/subslice:%d = %x\n", slice, 
> > subslice, mcr);
> > +
> > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
> > +}
> 
> Have you considered reusing existing wa_init_mcr? Just needs the 
> top-level assert changed and otherwise it looks it would do the right 
> thing for Gen9. Advantage being a smaller patch and less code to carry.

That was the first patch, and fails for the same reason. The problem
would appear to be in the mcr_mask for gt3.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/query: Correlate engine and cpu timestamps with better accuracy

[Chris Wilson]

Quoting Lionel Landwerlin (2021-03-04 08:28:59)
> On 04/03/2021 02:09, Chris Wilson wrote:
> > Quoting Umesh Nerlige Ramappa (2021-03-03 21:28:00)
> >> Perf measurements rely on CPU and engine timestamps to correlate
> >> events of interest across these time domains. Current mechanisms get
> >> these timestamps separately and the calculated delta between these
> >> timestamps lack enough accuracy.
> >>
> >> To improve the accuracy of these time measurements to within a few us,
> >> add a query that returns the engine and cpu timestamps captured as
> >> close to each other as possible.
> >>
> >> v2: (Tvrtko)
> >> - document clock reference used
> >> - return cpu timestamp always
> >> - capture cpu time just before lower dword of cs timestamp
> >>
> >> v3: (Chris)
> >> - use uncore-rpm
> >> - use __query_cs_timestamp helper
> >>
> >> v4: (Lionel)
> >> - Kernel perf subsytem allows users to specify the clock id to be used
> >>in perf_event_open. This clock id is used by the perf subsystem to
> >>return the appropriate cpu timestamp in perf events. Similarly, let
> >>the user pass the clockid to this query so that cpu timestamp
> >>corresponds to the clock id requested.
> >>
> >> v5: (Tvrtko)
> >> - Use normal ktime accessors instead of fast versions
> >> - Add more uApi documentation
> >>
> >> v6: (Lionel)
> >> - Move switch out of spinlock
> >>
> >> v7: (Chris)
> >> - cs_timestamp is a misnomer, use cs_cycles instead
> >> - return the cs cycle frequency as well in the query
> >>
> >> v8:
> >> - Add platform and engine specific checks
> >>
> >> v9: (Lionel)
> >> - Return 2 cpu timestamps in the query - captured before and after the
> >>register read
> >>
> >> Signed-off-by: Umesh Nerlige Ramappa 
> >> ---
> >>   drivers/gpu/drm/i915/i915_query.c | 144 ++
> >>   include/uapi/drm/i915_drm.h   |  47 ++
> >>   2 files changed, 191 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> >> b/drivers/gpu/drm/i915/i915_query.c
> >> index fed337ad7b68..acca22ee6014 100644
> >> --- a/drivers/gpu/drm/i915/i915_query.c
> >> +++ b/drivers/gpu/drm/i915/i915_query.c
> >> @@ -6,6 +6,8 @@
> >>   
> >>   #include 
> >>   
> >> +#include "gt/intel_engine_pm.h"
> >> +#include "gt/intel_engine_user.h"
> >>   #include "i915_drv.h"
> >>   #include "i915_perf.h"
> >>   #include "i915_query.h"
> >> @@ -90,6 +92,147 @@ static int query_topology_info(struct drm_i915_private 
> >> *dev_priv,
> >>  return total_length;
> >>   }
> >>   
> >> +typedef u64 (*__ktime_func_t)(void);
> >> +static __ktime_func_t __clock_id_to_func(clockid_t clk_id)
> >> +{
> >> +   /*
> >> +* Use logic same as the perf subsystem to allow user to select the
> >> +* reference clock id to be used for timestamps.
> >> +*/
> >> +   switch (clk_id) {
> >> +   case CLOCK_MONOTONIC:
> >> +   return _get_ns;
> >> +   case CLOCK_MONOTONIC_RAW:
> >> +   return _get_raw_ns;
> >> +   case CLOCK_REALTIME:
> >> +   return _get_real_ns;
> >> +   case CLOCK_BOOTTIME:
> >> +   return _get_boottime_ns;
> >> +   case CLOCK_TAI:
> >> +   return _get_clocktai_ns;
> >> +   default:
> >> +   return NULL;
> >> +   }
> >> +}
> >> +
> >> +static inline int
> >> +__read_timestamps(struct intel_uncore *uncore,
> >> + i915_reg_t lower_reg,
> >> + i915_reg_t upper_reg,
> >> + u64 *cs_ts,
> >> + u64 *cpu_ts,
> >> + __ktime_func_t cpu_clock)
> >> +{
> >> +   u32 upper, lower, old_upper, loop = 0;
> >> +
> >> +   upper = intel_uncore_read_fw(uncore, upper_reg);
> >> +   do {
> >> +   cpu_ts[0] = cpu_clock();
> >> +   lower = intel_uncore_read_fw(uncore, lower_reg);
> >> +   cpu_ts[1] = cpu_clock();
> >> +   old_upper = upper;
> 

Re: [Intel-gfx] [PATCH] i915/query: Correlate engine and cpu timestamps with better accuracy

[Chris Wilson]

Quoting Umesh Nerlige Ramappa (2021-03-03 21:28:00)
> Perf measurements rely on CPU and engine timestamps to correlate
> events of interest across these time domains. Current mechanisms get
> these timestamps separately and the calculated delta between these
> timestamps lack enough accuracy.
> 
> To improve the accuracy of these time measurements to within a few us,
> add a query that returns the engine and cpu timestamps captured as
> close to each other as possible.
> 
> v2: (Tvrtko)
> - document clock reference used
> - return cpu timestamp always
> - capture cpu time just before lower dword of cs timestamp
> 
> v3: (Chris)
> - use uncore-rpm
> - use __query_cs_timestamp helper
> 
> v4: (Lionel)
> - Kernel perf subsytem allows users to specify the clock id to be used
>   in perf_event_open. This clock id is used by the perf subsystem to
>   return the appropriate cpu timestamp in perf events. Similarly, let
>   the user pass the clockid to this query so that cpu timestamp
>   corresponds to the clock id requested.
> 
> v5: (Tvrtko)
> - Use normal ktime accessors instead of fast versions
> - Add more uApi documentation
> 
> v6: (Lionel)
> - Move switch out of spinlock
> 
> v7: (Chris)
> - cs_timestamp is a misnomer, use cs_cycles instead
> - return the cs cycle frequency as well in the query
> 
> v8:
> - Add platform and engine specific checks
> 
> v9: (Lionel)
> - Return 2 cpu timestamps in the query - captured before and after the
>   register read
> 
> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/i915_query.c | 144 ++
>  include/uapi/drm/i915_drm.h   |  47 ++
>  2 files changed, 191 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> b/drivers/gpu/drm/i915/i915_query.c
> index fed337ad7b68..acca22ee6014 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -6,6 +6,8 @@
>  
>  #include 
>  
> +#include "gt/intel_engine_pm.h"
> +#include "gt/intel_engine_user.h"
>  #include "i915_drv.h"
>  #include "i915_perf.h"
>  #include "i915_query.h"
> @@ -90,6 +92,147 @@ static int query_topology_info(struct drm_i915_private 
> *dev_priv,
> return total_length;
>  }
>  
> +typedef u64 (*__ktime_func_t)(void);
> +static __ktime_func_t __clock_id_to_func(clockid_t clk_id)
> +{
> +   /*
> +* Use logic same as the perf subsystem to allow user to select the
> +* reference clock id to be used for timestamps.
> +*/
> +   switch (clk_id) {
> +   case CLOCK_MONOTONIC:
> +   return _get_ns;
> +   case CLOCK_MONOTONIC_RAW:
> +   return _get_raw_ns;
> +   case CLOCK_REALTIME:
> +   return _get_real_ns;
> +   case CLOCK_BOOTTIME:
> +   return _get_boottime_ns;
> +   case CLOCK_TAI:
> +   return _get_clocktai_ns;
> +   default:
> +   return NULL;
> +   }
> +}
> +
> +static inline int
> +__read_timestamps(struct intel_uncore *uncore,
> + i915_reg_t lower_reg,
> + i915_reg_t upper_reg,
> + u64 *cs_ts,
> + u64 *cpu_ts,
> + __ktime_func_t cpu_clock)
> +{
> +   u32 upper, lower, old_upper, loop = 0;
> +
> +   upper = intel_uncore_read_fw(uncore, upper_reg);
> +   do {
> +   cpu_ts[0] = cpu_clock();
> +   lower = intel_uncore_read_fw(uncore, lower_reg);
> +   cpu_ts[1] = cpu_clock();
> +   old_upper = upper;
> +   upper = intel_uncore_read_fw(uncore, upper_reg);

Both register reads comprise the timestamp returned to userspace, so
presumably you want cpu_ts[] to wrap both.

   do {
   old_upper = upper;

   cpu_ts[0] = cpu_clock();
   lower = intel_uncore_read_fw(uncore, lower_reg);
   upper = intel_uncore_read_fw(uncore, upper_reg);
   cpu_ts[1] = cpu_clock();
   } while (upper != old_upper && loop++ < 2);
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 13/16] drm/i915/pxp: User interface for Protected buffer

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:57)
> From: Bommu Krishnaiah 
> 
> This api allow user mode to create Protected buffers. Only contexts
> marked as protected are allowed to operate on protected buffers.
> 
> We only allow setting the flags at creation time.
> 
> All protected objects that have backing storage will be considered
> invalid when the session is destroyed and they won't be usable anymore.
> 
> This is a rework of the original code by Bommu Krishnaiah. I've
> authorship unchanged since significant chunks have not been modified.
> 
> v2: split context changes, fix defines and improve documentation (Chris),
> add object invalidation logic
> 
> Signed-off-by: Bommu Krishnaiah 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Telukuntla Sreedhar 
> Cc: Kondapally Kalyan 
> Cc: Gupta Anshuman 
> Cc: Huang Sean Z 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_create.c| 27 +++--
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 +
>  drivers/gpu/drm/i915/gem/i915_gem_object.c|  6 +++
>  drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 ++
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  | 13 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 40 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  | 13 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  5 +++
>  include/uapi/drm/i915_drm.h   | 22 ++
>  9 files changed, 145 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> index 3ad3413c459f..d02e5938afbe 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
> @@ -5,6 +5,7 @@
>  
>  #include "gem/i915_gem_ioctls.h"
>  #include "gem/i915_gem_region.h"
> +#include "pxp/intel_pxp.h"
>  
>  #include "i915_drv.h"
>  #include "i915_user_extensions.h"
> @@ -13,7 +14,8 @@ static int
>  i915_gem_create(struct drm_file *file,
> struct intel_memory_region *mr,
> u64 *size_p,
> -   u32 *handle_p)
> +   u32 *handle_p,
> +   u64 user_flags)
>  {
> struct drm_i915_gem_object *obj;
> u32 handle;
> @@ -35,12 +37,17 @@ i915_gem_create(struct drm_file *file,
>  
> GEM_BUG_ON(size != obj->base.size);
>  
> +   obj->user_flags = user_flags;
> +
> ret = drm_gem_handle_create(file, >base, );
> /* drop reference from allocate - handle holds it now */
> i915_gem_object_put(obj);
> if (ret)
> return ret;
>  
> +   if (user_flags & I915_GEM_OBJECT_PROTECTED)
> +   intel_pxp_object_add(obj);
> +
> *handle_p = handle;
> *size_p = size;
> return 0;
> @@ -89,11 +96,12 @@ i915_gem_dumb_create(struct drm_file *file,
> return i915_gem_create(file,
>intel_memory_region_by_type(to_i915(dev),
>mem_type),
> -  >size, >handle);
> +  >size, >handle, 0);
>  }
>  
>  struct create_ext {
> struct drm_i915_private *i915;
> +   unsigned long user_flags;
>  };
>  
>  static int __create_setparam(struct drm_i915_gem_object_param *args,
> @@ -104,6 +112,19 @@ static int __create_setparam(struct 
> drm_i915_gem_object_param *args,
> return -EINVAL;
> }
>  
> +   switch (lower_32_bits(args->param)) {
> +   case I915_OBJECT_PARAM_PROTECTED_CONTENT:
> +   if (!intel_pxp_is_enabled(_data->i915->gt.pxp))
> +   return -ENODEV;
> +   if (args->size) {
> +   return -EINVAL;
> +   } else if (args->data) {
> +   ext_data->user_flags |= I915_GEM_OBJECT_PROTECTED;
> +   return 0;
> +   }
> +   break;
> +   }
> +
> return -EINVAL;
>  }
>  
> @@ -148,5 +169,5 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
> return i915_gem_create(file,
>intel_memory_region_by_type(i915,
>
> INTEL_MEMORY_SYSTEM),
> -  >size, >handle);
> +  >size, >handle, 
> ext_data.user_flags);
>  }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/ge

Re: [Intel-gfx] [PATCH v2 11/16] drm/i915/pxp: interface for creation of protected contexts

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:55)
> Usage of protected objects, coming in a follow-up patch, will be
> restricted to protected contexts. Contexts can only be marked as
> protected at creation time and they must be both bannable and not
> recoverable.
> 
> When a PXP teardown occurs, all gem contexts marked as protected that
> have been used at least once will be marked as invalid and all new
> submissions using them will be rejected. All intel contexts within the
> invalidated gem contexts will be marked banned.
> A new flag has been added to the RESET_STATS ioctl to report the
> invalidation to userspace.
> 
> v2: split to its own patch and improve doc (Chris), invalidate contexts
> on teardown
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 59 ++-
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   | 18 ++
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |  2 +
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 38 
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  |  1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  3 +
>  include/uapi/drm/i915_drm.h   | 19 ++
>  8 files changed, 150 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ca37d93ef5e7..19ac24a3c42c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -76,6 +76,8 @@
>  #include "gt/intel_gpu_commands.h"
>  #include "gt/intel_ring.h"
>  
> +#include "pxp/intel_pxp.h"
> +
>  #include "i915_drm_client.h"
>  #include "i915_gem_context.h"
>  #include "i915_globals.h"
> @@ -2006,6 +2008,40 @@ static int set_priority(struct i915_gem_context *ctx,
> return 0;
>  }
>  
> +static int set_protected(struct i915_gem_context *ctx,
> +const struct drm_i915_gem_context_param *args)
> +{
> +   int ret = 0;
> +
> +   if (!intel_pxp_is_enabled(>i915->gt.pxp))
> +   ret = -ENODEV;
> +   else if (ctx->client) /* can't change this after creation! */
> +   ret = -EEXIST;
> +   else if (args->size)
> +   ret = -EINVAL;
> +   else if (!args->value)
> +   clear_bit(UCONTEXT_PROTECTED, >user_flags);
> +   else if (i915_gem_context_is_recoverable(ctx) ||
> +!i915_gem_context_is_bannable(ctx))
> +   ret = -EPERM;
> +   else
> +   set_bit(UCONTEXT_PROTECTED, >user_flags);
> +
> +   return ret;
> +}
> +
> +static int get_protected(struct i915_gem_context *ctx,
> +struct drm_i915_gem_context_param *args)
> +{
> +   if (!intel_pxp_is_enabled(>i915->gt.pxp))
> +   return -ENODEV;
> +
> +   args->size = 0;
> +   args->value = i915_gem_context_can_use_protected_content(ctx);
> +
> +   return 0;
> +}
> +
>  static int ctx_setparam(struct drm_i915_file_private *fpriv,
> struct i915_gem_context *ctx,
> struct drm_i915_gem_context_param *args)
> @@ -2038,6 +2074,8 @@ static int ctx_setparam(struct drm_i915_file_private 
> *fpriv,
> ret = -EPERM;
> else if (args->value)
> i915_gem_context_set_bannable(ctx);
> +   else if (i915_gem_context_can_use_protected_content(ctx))
> +   ret = -EPERM; /* can't clear this for protected 
> contexts */
> else
> i915_gem_context_clear_bannable(ctx);
> break;
> @@ -2045,10 +2083,12 @@ static int ctx_setparam(struct drm_i915_file_private 
> *fpriv,
> case I915_CONTEXT_PARAM_RECOVERABLE:
> if (args->size)
> ret = -EINVAL;
> -   else if (args->value)
> -   i915_gem_context_set_recoverable(ctx);
> -   else
> +   else if (!args->value)
> i915_gem_context_clear_recoverable(ctx);
> +   else if (i915_gem_context_can_use_protected_content(ctx))
> +   ret = -EPERM; /* can't set this for protected 
> contexts */
> +   else
> +   i915_gem_context_set_recoverable(ctx);
> break;
>  
> case I915_CONTE

Re: [Intel-gfx] [PATCH v2 10/16] drm/i915/pxp: Enable PXP power management

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:54)
> +int intel_pxp_runtime_resume(struct intel_pxp *pxp)
> +{
> +   struct intel_gt *gt = pxp_to_gt(pxp);
> +   int ret;
> +
> +   if (!intel_pxp_is_enabled(pxp))
> +   return 0;
> +
> +   intel_pxp_irq_enable(pxp);
> +   pxp->global_state_in_suspend = false;
> +
> +   /*
> +* if the display loses power during runtime suspend it will cause the
> +* session to become invalid, so to be safe we always re-create it. 
> The
> +* MEI module is still bound, so this is the same as a teardown event,
> +* hence we can just pretend we received the irq.
> +*/
> +   intel_pxp_mark_termination_in_progress(pxp);
> +
> +   spin_lock_irq(>irq_lock);
> +   intel_pxp_irq_handler(pxp, 
> GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
> +   spin_unlock_irq(>irq_lock);
> +
> +   return ret;

return random() ?

> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> index 488006a0cf39..bb981d38c2fe 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
> @@ -25,8 +25,14 @@ static bool intel_pxp_session_is_in_play(struct intel_pxp 
> *pxp, u32 id)
> intel_wakeref_t wakeref;
> u32 sip = 0;
>  
> -   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> -   sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
> +   /* if we're suspended the session is considered off */
> +   wakeref = intel_runtime_pm_get_if_in_use(gt->uncore->rpm);
> +   if (!wakeref)
> +   return false;
> +
> +   sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
> +
> +   intel_runtime_pm_put(gt->uncore->rpm, wakeref);

with_intel_runtime_pm_if_in_use(gt->uncore->rpm, wakeref)
sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);

>  
> return sip & BIT(id);
>  }
> @@ -43,12 +49,18 @@ static int pxp_wait_for_session_state(struct intel_pxp 
> *pxp, u32 id, bool in_pla
> u32 mask = BIT(id);
> int ret;
>  
> -   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> -   ret = intel_wait_for_register(gt->uncore,
> - GEN12_KCR_SIP,
> - mask,
> - in_play ? mask : 0,
> - 100);
> +   /* if we're suspended the session is considered off */
> +   wakeref = intel_runtime_pm_get_if_in_use(gt->uncore->rpm);
> +   if (!wakeref)
> +   return in_play ? -ENODEV : 0;
> +
> +   ret = intel_wait_for_register(gt->uncore,
> + GEN12_KCR_SIP,
> + mask,
> + in_play ? mask : 0,
> + 100);
> +
> +   intel_runtime_pm_put(gt->uncore->rpm, wakeref);

Ditto
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 09/16] drm/i915/pxp: Implement PXP irq handler

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:53)
> +static int pxp_terminate(struct intel_pxp *pxp)
> +{
> +   int ret = 0;
> +
> +   mutex_lock(>mutex);
> +
> +   pxp->global_state_attacked = true;

global_state_attacked is serialised by pxp->work

> +
> +   ret = intel_pxp_arb_terminate_session_with_global_terminate(pxp);
> +
> +   mutex_unlock(>mutex);
> +
> +   return ret;

Fake error returns.

> +}
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 09/16] drm/i915/pxp: Implement PXP irq handler

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:53)
> From: "Huang, Sean Z" 
> 
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate another interrupt, at
> which point it is safe to re-create the session.

Why do we do the auto recreation after the teardown interrupt?

> 
> v2: use struct completion instead of bool (Chris)
> 
> Signed-off-by: Huang, Sean Z 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c   |   7 +
>  drivers/gpu/drm/i915/i915_reg.h  |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |  34 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h |  16 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 151 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_irq.h |  33 
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c |   9 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.h |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  10 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |   8 +
>  11 files changed, 268 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8b605f326039..5e9bd34dec38 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -274,6 +274,7 @@ i915-y += i915_perf.o
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> +   pxp/intel_pxp_irq.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index d29126c458ba..0d3585efe2b8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
>  #include "intel_lrc_reg.h"
>  #include "intel_uncore.h"
>  #include "intel_rps.h"
> +#include "pxp/intel_pxp_irq.h"
>  
>  static void guc_irq_handler(struct intel_guc *guc, u16 iir)
>  {
> @@ -64,6 +65,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>rps, iir);
>  
> +   if (instance == OTHER_KCR_INSTANCE)
> +   return intel_pxp_irq_handler(>pxp, iir);
> +
> WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
>   instance, iir);
>  }
> @@ -190,6 +194,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK,  ~0);
> +
> +   intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
> +   intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK,  ~0);
>  }
>  
>  void gen11_gt_irq_postinstall(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e5dd0203991b..97a6d0c638ec 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7958,6 +7958,7 @@ enum {
>  /* irq instances for OTHER_CLASS */
>  #define OTHER_GUC_INSTANCE 0
>  #define OTHER_GTPM_INSTANCE1
> +#define OTHER_KCR_INSTANCE 4
>  
>  #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index cbec9395bde9..0ca1c2c16972 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -2,7 +2,9 @@
>  /*
>   * Copyright(c) 2020 Intel Corporation.
>   */
> +#include 
>  #include "intel_pxp.h"
> +#include "intel_pxp_irq.h"
>  #include "intel_pxp_tee.h"
>  #include "gt/intel_context.h"
>  #include "i915_drv.h"
> @@ -67,12 +69,23 @@ void intel_pxp_init(struct intel_pxp *pxp)
>  
> mutex_init(>mutex);
>  
> +   /*
> +* we'll use the completion to check if there is a termination 
> pending,
> +* so we start it as completed and we reinit it when a termination
> +* is triggered.
> +*/
> +   init_completion(>termination);
> +   complete_all(>termination);
> +
> kcr_p

Re: [Intel-gfx] [PATCH v2 04/16] drm/i915/pxp: allocate a vcs context for pxp usage

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:48)
> @@ -232,6 +235,13 @@ ktime_t intel_engine_get_busy_time(struct 
> intel_engine_cs *engine,
>  
>  u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
>  
> +struct intel_context *
> +intel_engine_pinned_context_create(struct intel_engine_cs *engine,
> +  unsigned int hwsp,
> +  struct lock_class_key *key,
> +  const char *name);

intel_engine_create_pinned_context()

Other users would want to pass in vm and ring size (ring size may be
useful here as well for larger SESSION_TERMINATE_LEN())
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 07/16] drm/i915/pxp: Create the arbitrary session after boot

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:51)
> +static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
> +{
> +   return pxp->arb_is_in_play;
> +}

> +static bool intel_pxp_session_is_in_play(struct intel_pxp *pxp, u32 id)
> +{
> +   struct intel_gt *gt = pxp_to_gt(pxp);
> +   intel_wakeref_t wakeref;
> +   u32 sip = 0;
> +
> +   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> +   sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
> +
> +   return sip & BIT(id);
> +}
> +
> +bool intel_pxp_arb_session_is_in_play(struct intel_pxp *pxp)
> +{
> +   return intel_pxp_session_is_in_play(pxp, ARB_SESSION);
> +}

So pxp->arb_is_in_play is not the same as intel_pxp_arb_session_is_in_play().

That's confusing.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/pxp: Implement arb session teardown

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:52)
> From: "Huang, Sean Z" 
> 
> Teardown is triggered when the display topology changes and no
> long meets the secure playback requirement, and hardware trashes
> all the encryption keys for display. Additionally, we want to emit a
> teardown operation to make sure we're clean on boot and resume
> 
> v2: emit in the ring, use high prio request (Chris)
> 
> Signed-off-by: Huang, Sean Z 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 166 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h |  15 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  38 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.h |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |   5 +-
>  6 files changed, 225 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index d6d510e4875e..8b605f326039 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -273,6 +273,7 @@ i915-y += i915_perf.o
>  # Protected execution platform (PXP) support
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> +   pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> new file mode 100644
> index ..ffab09839cd3
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "intel_pxp.h"
> +#include "intel_pxp_session.h"
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +#include "gt/intel_gpu_commands.h"
> +#include "gt/intel_ring.h"
> +
> +#include "i915_trace.h"
> +
> +/* PXP GPU command definitions */
> +
> +/* MI_SET_APPID */
> +#define   MI_SET_APPID_SESSION_ID(x)((x) << 0)
> +
> +/* MI_FLUSH_DW */
> +#define   MI_FLUSH_DW_DW0_PROTECTED_MEMORY_ENABLE   BIT(22)
> +
> +/* MI_WAIT */
> +#define   MFX_WAIT_DW0_PXP_SYNC_CONTROL_FLAG BIT(9)
> +#define   MFX_WAIT_DW0_MFX_SYNC_CONTROL_FLAG  BIT(8)

We've been using REG_BIT() for the explicit (u32) casting.

> +/* CRYPTO_KEY_EXCHANGE */
> +#define CRYPTO_KEY_EXCHANGE ((0x3 << 29) | (0x01609 << 16))

#define __INSTR(client) ((client) << INSTR_CLIENT_SHIFT)

#define MI_INSTR(opcode, flags) \
(__INSTR(INSTR_MI_CLIENT) | (opcode) << 23 | (flags))
#define RC_INTR(foo) (__INSTR(INSTR_RC_CLIENT) | (foo) << 16)

#define CRYPTO_KEY_EXCHANGE RC_INSTR(0x1609)

With a better (foo).

> +
> +/* stall until prior PXP and MFX/HCP/HUC objects are cmopleted */
> +#define MFX_WAIT_PXP \
> +   MFX_WAIT | \
> +   MFX_WAIT_DW0_PXP_SYNC_CONTROL_FLAG | \
> +   MFX_WAIT_DW0_MFX_SYNC_CONTROL_FLAG;
> +
> +static u32 *pxp_emit_session_selection(u32 *cs, u32 idx)
> +{
> +   *cs++ = MFX_WAIT_PXP;

One day someone will proofread bspec.

> +   /* pxp off */
> +   *cs++ = MI_FLUSH_DW;
> +   *cs++ = 0;
> +   *cs++ = 0;

Hmm. Can the immediate data be dropped? TIL.

> +   /* select session */
> +   *cs++ = MI_SET_APPID | MI_SET_APPID_SESSION_ID(idx);
> +
> +   *cs++ = MFX_WAIT_PXP;
> +
> +   /* pxp on */
> +   *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_DW0_PROTECTED_MEMORY_ENABLE;
> +   *cs++ = 0;
> +   *cs++ = 0;

Bspec says "after completion of the flush...", which says to me we
should not initiate the wait until after the flush, so we would need a
post-sync op here to stall the CS (or else we may complete the wait
before the operation is begun). I don't see any programming notes to
that effect, so could just be my paranoia from handling atomics.

> +   *cs++ = MFX_WAIT_PXP;

Fwiw, the bspec language would seem to imply that nothing should happen
with this wait at this point. Perhaps more reason to make the pxp-on
MI_FLUSH_DW be synchronous. (Though we will have a sync point at the
breadcrumb, so meh.)

> +
> +   return cs;
> +}
> +
> +static u32 *pxp_emit_inline_termination(u32 *cs)
> +{
> +   /* session inline termination */
> +   *cs++ = CRYPTO_KEY_EXCHANGE;
> +   *cs++ = 0;
> +
> +   return cs;
> +}
> +
> +static u32 *pxp_emit_wait(u32 *cs)
> +{
> +   /* wait 

Re: [Intel-gfx] [PATCH v2 09/16] drm/i915/pxp: Implement PXP irq handler

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2021-03-01 19:31:53)
> From: "Huang, Sean Z" 
> 
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate another interrupt, at
> which point it is safe to re-create the session.
> 
> v2: use struct completion instead of bool (Chris)
> 
> Signed-off-by: Huang, Sean Z 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c   |   7 +
>  drivers/gpu/drm/i915/i915_reg.h  |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |  34 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h |  16 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 151 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_irq.h |  33 
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c |   9 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.h |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  10 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |   8 +
>  11 files changed, 268 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8b605f326039..5e9bd34dec38 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -274,6 +274,7 @@ i915-y += i915_perf.o
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_cmd.o \
> +   pxp/intel_pxp_irq.o \
> pxp/intel_pxp_session.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index d29126c458ba..0d3585efe2b8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
>  #include "intel_lrc_reg.h"
>  #include "intel_uncore.h"
>  #include "intel_rps.h"
> +#include "pxp/intel_pxp_irq.h"
>  
>  static void guc_irq_handler(struct intel_guc *guc, u16 iir)
>  {
> @@ -64,6 +65,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>rps, iir);
>  
> +   if (instance == OTHER_KCR_INSTANCE)
> +   return intel_pxp_irq_handler(>pxp, iir);
> +
> WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
>   instance, iir);
>  }
> @@ -190,6 +194,9 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK,  ~0);
> +
> +   intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_ENABLE, 0);
> +   intel_uncore_write(uncore, GEN11_CRYPTO_RSVD_INTR_MASK,  ~0);
>  }
>  
>  void gen11_gt_irq_postinstall(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e5dd0203991b..97a6d0c638ec 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7958,6 +7958,7 @@ enum {
>  /* irq instances for OTHER_CLASS */
>  #define OTHER_GUC_INSTANCE 0
>  #define OTHER_GTPM_INSTANCE1
> +#define OTHER_KCR_INSTANCE 4
>  
>  #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4))
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index cbec9395bde9..0ca1c2c16972 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -2,7 +2,9 @@
>  /*
>   * Copyright(c) 2020 Intel Corporation.
>   */
> +#include 
>  #include "intel_pxp.h"
> +#include "intel_pxp_irq.h"
>  #include "intel_pxp_tee.h"
>  #include "gt/intel_context.h"
>  #include "i915_drv.h"
> @@ -67,12 +69,23 @@ void intel_pxp_init(struct intel_pxp *pxp)
>  
> mutex_init(>mutex);
>  
> +   /*
> +* we'll use the completion to check if there is a termination 
> pending,
> +* so we start it as completed and we reinit it when a termination
> +* is triggered.
> +*/
> +   init_completion(>termination);
> +   complete_all(>termination);
> +
> kcr_pxp_enable(gt);
>  
> ret = create_v