fixup __forceinline for cpp code

note the "const" pointer values in the struct headers cause a warning in cpp mode, arguably because they really aren't useful (telling the compiler that the constant value is constant)

CI is failing with:
CMake Error at test/kitchen_sink/CMakeLists.txt:118 (add_executable):
  Cannot find source file:

    /opt/actions-runner/_work/pico-sdk/pico-sdk/test/kitchen_sink/kitchen_sink_cpp.cpp

Whoops?

Can confirm that running:
apt update && apt install -y git python3 g++ cmake gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib wget unzip
git clone https://github.com/raspberrypi/pico-sdk.git --depth 1 --branch forceline
wget https://github.com/raspberrypi/pico-sdk/files/7613614/Minimal.zip
unzip Minimal.zip && cd Minimal
mkdir build && cd build
PICO_SDK_PATH=../../pico-sdk cmake ..
make

in a debian:10 docker container now builds without error :+1:
However if I try building the SDK itself (i.e. kitchen_sink_cpp?) in a debian:11 docker container I get a whole bunch of errors about:
/pico-sdk/src/rp2040/hardware_regs/include/hardware/regs/addressmap.h:64:21: error: type qualifiers ignored on cast result type [-Werror=ignored-qualifiers]
 #define DMA_BASE _u(0x50000000)
                     ^~~~~~~~~~
/pico-sdk/src/rp2040/hardware_regs/include/hardware/platform_defs.h:16:15: note: in definition of macro '_u'
 #define _u(x) x ## u
               ^
/pico-sdk/src/rp2040/hardware_structs/include/hardware/structs/dma.h:197:34: note: in expansion of macro 'DMA_BASE'
 #define dma_hw ((dma_hw_t *const)DMA_BASE)
                                  ^~~~~~~~
/pico-sdk/src/rp2_common/hardware_dma/include/hardware/dma.h:63:13: note: in expansion of macro 'dma_hw'
     return &dma_hw->ch[channel];
             ^~~~~~

Based on the similar changes in this PR, if I do:
diff --git a/src/rp2040/hardware_structs/include/hardware/structs/dma.h b/src/rp2040/hardware_structs/include/hardware/structs/dma.h
index 0d20641..4281ddf 100644
--- a/src/rp2040/hardware_structs/include/hardware/structs/dma.h
+++ b/src/rp2040/hardware_structs/include/hardware/structs/dma.h
@@ -194,8 +194,8 @@ typedef struct {
     } ch[NUM_DMA_CHANNELS];
 } dma_debug_hw_t;

-#define dma_hw ((dma_hw_t *const)DMA_BASE)
-#define dma_debug_hw ((dma_debug_hw_t *const)(DMA_BASE + DMA_CH0_DBG_CTDREQ_OFFSET))
+#define dma_hw ((dma_hw_t *)DMA_BASE)
+#define dma_debug_hw ((dma_debug_hw_t *)(DMA_BASE + DMA_CH0_DBG_CTDREQ_OFFSET))

 static_assert( NUM_DMA_TIMERS == 4, "");
 static_assert( NUM_DMA_CHANNELS == 12, "");

then those errors disappear. (Although I can't be 100% certain if that's the correct fix)

argh; i made the dma.h change, but then i pulled a new version of svd2struct and I think maybe changes in that may have caused that one harnd-coded fix to disappear

Yep, injected text like that has been moved from the global extras.txt into the YAML file.
I'll raise a PR to patch the YAML, but we should consider moving that file out of the tool repo

Looks fine. The changes to svd2struct should make sure that the struct header changes here don't get wiped out by re-run.

As long as Graham remembers to add the changes to dma.h before merging :slightly_smiling_face:


Heroku Scoreboard Application Failure on Live Demo Scoreboard

Trying to view the scoreboard of the live demo fails server-side with the comment "An error occurred in the application and your page could not be served." displayed on page by Heroku

Thanks for the heads-up!  Back up and running.


fn Rav1dRefmvsDSPContext::splat_mv is slow

When processing the "chimera 8-bit" bitstream, the decoder spends about 3% of its time in fn Rav1dRefmvsDSPContext::splat_mv. There is no equivalent C function. Also, this is much more time than what is spent in the dav1d_splat_mv_* assembly functions that do the actual data processing.

Let me look into this.  We should hopefully be able to make it faster but a bit less safe.

Okay I think I figured how to eliminate most of the overhead (basically only compute the r ptr for the elements we're using).  I'll open a PR soon.


Imhotep doesn't clean up folders for overwritten shards

Minor issue:
If I upload a new tsv with same name as an existing tsv, it will over-write the data from the old with the new.
If I look in the databucket, I can see that the old shard file is gone, however the folder it was in still sticks around.

Actually, looks like in some cases it doesn't overwrite the shardfile either.
For now we can periodically clean up manually, but it would be unfortunate to need to write a series of cronjobs and parsers to automate it.


Orin TensorRT MaxQ configuration

I've built two TensorRT engine plans for BERT Offline as follows:
$ make generate_engines RUN_ARGS="--benchmarks=bert --scenarios=offline"
$ make generate_engines RUN_ARGS="--benchmarks=bert --scenarios=offline --config_ver=maxq"
$ find build/engines/Orin/bert/Offline/ -name *.plan -exec du -hs {} \;
355M    build/engines/Orin/bert/Offline/bert-Offline-gpu-int8_S_384_B_256_P_1_vs_il.custom_k_99_MaxP.plan
355M    build/engines/Orin/bert/Offline/bert-Offline-gpu-int8_S_384_B_256_P_1_vs_il.custom_k_99_MaxQ.plan

(The files have practically the same size but are slightly different perhaps due to included timestamps?)
I've validated that if I run either plan with:
$ time MLPERF_SCRATCH_PATH=/datasets/nvidia_scratch make run_harness \
RUN_ARGS="--benchmarks=bert --scenarios=offline --test_mode=PerformanceOnly"

the performance is up to 489 samples/second and the power drawn is around 78 W (as observed on the front panel of the attached WT310E power meter).
(To validate this for the *.MaxQ.plan file in the same setting, I copied it over the *.MaxP.plan file and re-run the experiment.)

================================================                                                                                MLPerf Results Summary
================================================
SUT name : BERT SERVER
Scenario : Offline
Mode     : PerformanceOnly
Samples per second: 488.866
Result is : VALID
  Min duration satisfied : Yes
  Min queries satisfied : Yes
  Early stopping satisfied: Yes
================================================
Additional Stats
================================================
Min latency (ns)                :<PHONE_NUMBER>
Max latency (ns)                :<PHONE_NUMBER>38
Mean latency (ns)               :<PHONE_NUMBER>45
50.00 percentile latency (ns)   :<PHONE_NUMBER>54
90.00 percentile latency (ns)   :<PHONE_NUMBER>45
95.00 percentile latency (ns)   :<PHONE_NUMBER>62
97.00 percentile latency (ns)   :<PHONE_NUMBER>26
99.00 percentile latency (ns)   :<PHONE_NUMBER>09
99.90 percentile latency (ns)   :<PHONE_NUMBER>56
================================================
Test Parameters Used
================================================
samples_per_query : 323400
target_qps : 490
target_latency (ns): 0
max_async_queries : 1
min_duration (ms): 600000
max_duration (ms): 0
min_query_count : 1
max_query_count : 0
qsl_rng_seed :<PHONE_NUMBER>603136530
sample_index_rng_seed :<PHONE_NUMBER>2028895792
schedule_rng_seed :<PHONE_NUMBER>9680847247
accuracy_log_rng_seed : 0
accuracy_log_probability : 0
accuracy_log_sampling_target : 0
print_timestamps : 0
performance_issue_unique : 0
performance_issue_same : 0
performance_issue_same_index : 0
performance_sample_count : 10833
No warnings encountered during test.
No errors encountered during test.

@nv-ananjappa

I looks like we have reproduced the expected performance (280 QPS) according to the submitted configuration:
@ConfigRegistry.register(HarnessType.Custom, AccuracyTarget.k_99, PowerSetting.MaxQ)
class Orin_MaxQ(Orin):
    soc_cpu_freq = 1036800
    soc_gpu_freq = 726750000
    soc_dla_freq = 0
    soc_emc_freq =<PHONE_NUMBER>
    orin_num_cores = 4
    offline_expected_qps = 280

but it's NOT the same configuration that NVIDIA used for the submitted experiment.


A few php .ini files are in the wrong place

Xdebug wasn't working for me immediately after install. Turns out that xdebug.ini was in /etc/php5/conf.d but Apache only cared about /etc/php5/apache2/conf.d (screenshot showing that: https://www.dropbox.com/s/3zgzpbrevy8f035/Screenshot 2015-04-17 12.38.36.png?dl=0). Moving xdebug.ini into that directory and restarting apache fixed it.
I noticed that xhprof.ini and 20-apc.ini were also in the first directory, but not sure if those were broken as well.

Ugh, Debian/Ubuntu Apache installation--
If everyone just used a saner Linux distro, this would just be a moot point :P
Yep—that's an issue that will need to be filed upstream in geerlingguy.xdebug. Could you file an issue there and references this issue?

Sure thing. https://github.com/geerlingguy/ansible-role-php-xdebug/issues/9 -- should we close this ticket now?
Which distro do you tend to use with drupal-vm? I'm only on ubuntu since it seems to be the default in the Vagrantfile, but if there's something you recommend over it, then I'd be happy to switch.

I've standardized on Ubuntu 14.04 (was originally on 10.04, then 12.04), since following the LTS releases seems to be simpler for long-term stability, plus for some strange reason the majority of devs I know prefer Ubuntu over most other distros (probably because it's the most unified/holistic desktop experience—though that says nothing of the server side).
Almost all the roles I built are compatible with RedHat/CentOS 6/7, Debian 6/7, and Ubuntu 12.04/14.04, so technically you could switch this VM to use geerlingguy/centos6 or geerlingguy/centos7 as the base box and most things would Just Work™; but there are a few steps in the Drupal VM playbooks that would need to be changed to work on a non-Debian-based distro.
Regardless, I'll end up fixing the paths in the xdebug role.

Couldn't get it to work with Nginx out of the box. Needed to add the xdebug.ini to /etc/php5/mods-available and then add the symlink in /etc/php5/fpm/conf.d

I've also released geerlingguy.php-xdebug 1.1.4, which includes fixes related to this issue, so that along with the updates to example.config.yml should guarantee that Xdebug will work great out of the box with PHP CLI, FPM, through mod_php/Apache2, etc.

Thanks! Just ran into this issue again when building a new box so came back here to see what I had done before and this helped.

@geerlingguy Question:
What actually creates: /etc/php5/fpm/pool.d/www.conf?
Can this easily be edited? I want to change something that persists when running vagrant provision.


Next.js API routes are cached by cloudfront

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting questions.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
d3jneonuggifo0
AWS Region
eu-central-1
Amplify Hosting feature
Custom headers, Public APIs, SSR
Question
Hi all!
I recognized that requests to an Next.js API route are cached for 2 seconds. In between I get an X-Cache Header "Hit from cloudfront". Is there a way to change this behaviour?
In my local environment, I cannot reproduce this behavior. There I always get a freshly generated response.
Thank you
Markus

I have the same problem - why it happens?

Hi,
This problem has been resolved. CloudFront doesn't cache for 2 seconds anymore, and it will respect the cache-control response header that your api returns.
I'm closing this issue as it's been resolved.


Bounty: Mazda

Migrating PR #762 to master
Signed-off-by: Jafar Al-Gharaibeh<EMAIL_ADDRESS>

I have worked on adding alerts for steer lockout and low speed and working on improving various aspects of the port. Will be updating this PR in the new few days.

@geohot I have pushed a few updates to this PR with a few improvements and also to address several situations including  your comment above. Notable new changes:
  * Do not engage if LKAS is not available at low speeds. This happens anytime  the speed dips below 28mph and doesn't get enabled until the speed hits 32mpg. If the user tried to engage they get "OpenPilot Unavailable, Speed Two Low"

  * If OP is engaged and the speeds dips below 28mpg where LKAs becomes unavailable the user see a continuous "TAKE CONTROL: Steer Unavailable Below 28MPH"  warning. OP doesn't disengage in this case but the warning will be shown as long as the LKAs is not available. Once the speed requirement is met the warning goes away and OP resumes normal operation.

* If the user have their hands off the steering wheel and the steer lockout timeout is triggered,  a Warning is issued "TAKE CONTROL: Steering is Temporarily Unavailable". We can create a specific warning for cars with lockout timeout if we want to make it more obvious way it is not available. The stock car system itself also issues a HUD warning and an audible alert in that situation, so the user is very aware of what  is going on.

Disengage on gas press which is required by Comma AI safety guidelines. break/seatbelt/door disengagement were already there.

Refactored a lot of the car params/constants and moved them to values.py

Improved the handling of cruise buttons presses to give a better user feedback

Added CX-2019 GT fingerprint as a couple of new Mazda users have that car and use it with Comma 2

The only remaining issue is that sometimes I get steer limit warnings even when driving on straight  lines. More tuning is needed for that.
Please let me know if you have any comments or questions!

I did write a guide for Mazda user covering all aspects of this port.  I will update the guide with screen shots of the various warnings as examples when I get a chance:
<EMAIL_ADDRESS>

I update the Mazda guide above with example warnings. Will add one for hands off warning when I get one.

The expectation from every car in openpilot is that it be able perform on the highway without many disengagements ( referenced in #1060 ), and unfortunately with a 10 second lockout that's unlikely. I want to be clear on this policy going forward, sorry for being indecisive.
If some cars don't have the lockout, we can upstream them. I still think the warning is a good idea, and we'll keep this PR open in hopes future Mazda's don't have the lockout, or a way is found to bypass it.

@geohot, I understand.  I'd like to point out that on the highway I hardly get any disengagement for long stretches, 10+ minutes, with a neatly hidden weight under a steering wheel cover. All Mazda users are using this trick.

Let's merge this as a dashcam only port for now.

@geohot Thanks for the update!
@pd0wm aside from updating the PR to address the merge conflicts, please let me know what other things you want added/dropped to make it work in dashcam mode only.

Can you fix test car models?

Just set     ret.dashcamOnly = True in interface.py. (https://github.com/commaai/openpilot/blob/master/selfdrive/car/ford/interface.py#L22). Also make sure the route gets marked as such in test_car_models. Just copy what ford does.
Also there have been some refactors lately in carstate/carinterface. Can you make sure you follow the same conventionts:

Build carState struct in carstate.py, not in interface. That save a lot of copies
Use the create_common_events method to avoid some duplication in the regular events like door, seatbelt, etc.
Use the kalman filter from CarStateBase
I see the gear is not parsed. Make sure it disengages when going in reverse.

@geohot  @pd0wm will do!  I will update the PR and test in the next few days.

Finally got some time to move a bit on this, still more work to do. Will update when I get more time to work on it.

@geohot
test is working now
@pd0wm

Code was refactored following the new convention.
Gear is parsed
gas/brake events including pressure are all added
Fingerprints were added to cover many of the Mazda cars on the road now
refactored the code to prepare for future updates for the new gen Mazda  such as Mazda 3

Remaining items:
* Force dashmode: I'm keeping this as the last step after everything else is working/approved
* Disengage on gas-press , this was working before, missing something in my refactoring
* Fix process_replay test, the drive is synced by you but I still get this error:
AssertionError: Failed to download /tmp/openpilot/selfdrive/test/process_replay/32a319f057902bb3|2020-04-27--15-18-58--2_controlsd_b33259e2dae9852c58b0507dbb98fb01d8b884b8.bz2
If you have any comments please let me know.

@Jafaral process replay needs both the drive synced and the reference logs it compares against. That error means the reference logs are missing from the CI bucket

@quillford The drive 32a319f057902bb3|2020-04-27--15-18-58 is used with test_car_models as well and I was getting an error there until @pd0wm synced it. After the sync, the test_Cat_models went away but the the error for the segment within that drive here persist, not sure what that means.

@quillford Aside from parsing the gear, all other comments are addressed. Will test drive this tomorrow. Will wait for the dbc updates to refactor gear parsing.
Thanks for taking the  time to look at this!

@Jafaral I merged your opendbc PR, so you can fix the gear parsing now.
Before this gets merged, the mazda panda safety should have tests. You can use the toyota safety test as an example. At a minimum, it should include all the tests from common.PandaSafetyTest.

Thanks @quillford , it also needs to be synced to the OP's git submodules before it actually works, right?
I will address your latest comment and prepare for gear parsing. Will do panda tests as well.
One of my changes last night caused controlsd crash this morning. I will track that down. Can  you please find out why  process_replay is crashing? That  should help me catch runtime errors before I roll them on to the car. I can provide a new segment ID if that fixes the issue.
Thanks Again!

Just pushed a Dashcam only commit as requested to finalize this PR.

Can you add Mazda to the README? Thanks for all the work on this port, it's looking pretty good now.


Change Why the web religious phrasing. [EN] Feedback for: /index.html

I am as Atheist as they come but don't like the following phrasing or the association with religious wars:

There are religious all-out battles between developers who embrace native applications and those that live and die for the openness of the web platform. Unfortunately, both sides are blinded in their beliefs and forget that choosing a platform needs to be a well researched and thoughtful decision that works for your business.

We can still create a strong phrasing. How about:

There are many philosophical debates between developers who embrace native application development and those who build on the open web platform about why their platform is best.  We believe the web is a good platform to build up for the following reasons:

@pbakaus can you please address

The suggested intro is good, but there's still useful material we haven't reused. So...
"There are many philosophical debates between developers who embrace native application development and those who build on the open web about why their platform is best. We believe the web is a good platform to build up for many reasons."
"Let’s explore why you should choose the web and walk through some of the unique user-facing abilities and features the open web platform provides."

Sgtm.
On Tue, 31 Mar 2015 04:03 Joe Medley<EMAIL_ADDRESS>wrote:

The suggested intro is good, but there's still useful material we haven't
reused. So...
"There are many philosophical debates between developers who embrace
native application development and those who build on the open web about
why their platform is best. We believe the web is a good platform to build
up for many reasons."
"Let’s explore why you should choose the web and walk through some of the
unique user-facing abilities and features the open web platform provides."
—
Reply to this email directly or view it on GitHub
https://github.com/google/WebFundamentals/issues/1195#issuecomment-87915818
.


zarf tools registry ls <img> --full-ref has strange port in output

Environment
Device and OS:  HP ZBook Fury 17 G7 Mobile Workstation / Ubuntu 20.04.6 LTS
App version:  Zarf v0.29.2
Kubernetes distro being used:  k3d version v5.6.0 / k3s version v1.27.4-k3s1
Other:
Steps to reproduce

Run zarf tools registry ls <img> with the --full-ref flag multiple times.

Expected result
I expect the returned images' registry port to reflect the one I passed in.
Actual Result
I see a rando registry port output with my result.  And the port seems to change every time I call..?
Visual Proof (screenshots, videos, text, etc)
$ zarf tools registry ls <IP_ADDRESS>:31999/tekton-releases/github.com/tektoncd/pipeline/cmd/controller --full-ref
<IP_ADDRESS>:41117/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1
<IP_ADDRESS>:41117/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1-zarf-3557375598

$ zarf tools registry ls <IP_ADDRESS>:31999/tekton-releases/github.com/tektoncd/pipeline/cmd/controller --full-ref
<IP_ADDRESS>:42923/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1
<IP_ADDRESS>:42923/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1-zarf-3557375598

$ zarf tools registry ls <IP_ADDRESS>:31999/tekton-releases/github.com/tektoncd/pipeline/cmd/controller --full-ref
<IP_ADDRESS>:42461/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1
<IP_ADDRESS>:42461/tekton-releases/github.com/tektoncd/pipeline/cmd/controller:v0.50.1-zarf-3557375598

Severity/Priority
Low/Low
Additional Context
It's my first bug report to this project... so if I did a dumb, be sure to let me know.  Many thanks & keep up the good work!

definitely looks suspicious to me too @btlghrants

This is actually due to our wrapping logic.  if we detect the repository matches the repo in Zarf state we will open a tunnel (on a random open port) to connect and get the information back - on most commands that doesn't affect the output but here it does - we could look to see if 1) we can modify the headers to tell the registry that there is a proxy in the way and it should act as the original address or 2) mutate the response to contain the correct host/port if we are using a tunnel.

on most commands that doesn't affect the output but here it does

I believe this also impacts zarf tools registry catalog --full-ref (and probably any command which uses an automatic port-forward). Catalog appears to display the random local port-forwarded port rather than the proper ref to the node port:
~ zarf tools registry catalog --full-ref

 NOTE  Retrieving registry information from Zarf state

 NOTE  Opening a tunnel from <IP_ADDRESS>:49658 locally to <IP_ADDRESS>:31999 in the cluster
<IP_ADDRESS>:49658/bitnami/redis
<IP_ADDRESS>:49658/defenseunicorns/uds/identity-config
<IP_ADDRESS>:49658/defenseunicorns/zarf/agent
<IP_ADDRESS>:49658/gitea/gitea
...

This can then impact subsequent commands. For example, if I check the catalog for a ref, and then try to pull the tags with zarf tools registry ls <IP_ADDRESS>:49658/bitnami/redis -- the automatic port-forward isn't triggered, and it hits an (expected) connection refused error:
Error: reading tags for <IP_ADDRESS>:49658/bitnami/redis: Get "https://<IP_ADDRESS>:49658/v2/": dial tcp <IP_ADDRESS>:49658: connect: connection refused; Get "http://<IP_ADDRESS>:49658/v2/": dial tcp <IP_ADDRESS>:49658: connect: connection refused