text:
BLE MESH: mesh proxy server fails due to failed ext adv param update for mesh gatt advs

Description
MESH GATT advertisements attempts fails after any  bt_le_ext_adv_update_param(..) call.
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/mesh/adv_ext.c#L158
To Reproduce
Failing PTS test cases: with latest AutoPTS
Most of the MESH/SR/PROX tests and MESH/SR/RPR/SCN tests.
A few of them:

MESH/SR/RPR/SCN/BV-08-C
MESH/SR/RPR/SCN/BV-05-C
MESH/SR/RPR/SCN/BV-04-C
MESH/SR/PROX/BV-22-C
MESH/SR/PROX/BV-23-C
MESH/SR/PROX/BV-24-C
MESH/SR/PROX/BV-04-C

Expected behavior
Passing PTS tests
Impact
Ble Mesh RPR server and Proxy Server is not qualifiable
Logs and console output
[00:00:33.811,035]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:00:33.811,065]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:00:33.811,096]  bt_mesh_gatt: Advertising proxy failed (err: -105)
[00:00:33.813,171]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:00:33.813,171]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:00:33.813,201]  bt_mesh_gatt: Advertising proxy failed (err: -105)
[00:00:35.372,711]  bt_mesh_crypto: Enc beacon: 0x02, 0x0000000b
[00:00:38.806,823]  bt_conn: Send auto LE param update failed (err -105)
[00:00:52.816,009]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:00:52.816,040]  bt_mesh_beacon: Failed to send beacon: err -105
[00:00:52.816,375]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:00:52.816,375]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:00:52.816,406]  bt_mesh_gatt: Advertising proxy failed (err: -105)
[00:01:02.816,650]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:02.816,680]  bt_mesh_beacon: Failed to send beacon: err -105
[00:01:02.817,108]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:02.817,108]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:01:02.817,108]  bt_mesh_gatt: Advertising proxy failed (err: -105)
[00:01:12.817,352]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:12.817,382]  bt_mesh_beacon: Failed to send beacon: err -105
[00:01:12.817,718]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:12.817,718]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:01:12.817,749]  bt_mesh_gatt: Advertising proxy failed (err: -105)
[00:01:20.683,929]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:20.683,959]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:01:20.683,959]  bt_mesh_gatt: Advertising proxy failed (err: -105)
[00:01:22.817,962]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:22.817,993]  bt_mesh_beacon: Failed to send beacon: err -105
[00:01:22.818,572]  bt_mesh_adv_ext: Failed updating adv params : -105
[00:01:22.818,572]  bt_mesh_gatt: Failed to advertise using type 0x02 (err -105)
[00:01:22.818,572]  bt_mesh_gatt: Advertising proxy failed (err: -105)

@m-alperen-sener , I guess it is due to #77241?

we can close this issue then, thanks.

source: gharchive/issue

authors: PavelVPV m-alperen-sener

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
drivers: fix and optimization of arc timer

For single core:
the pulse triggered timer irq doesn't work for all targets. In
iotdk, we found the clear of IP bit will clear int request
when elapsed called in thread context. So come back to level
triggered way, and use the sw triggered irq to remember the
irq request which may be cleared in thread context with an
exception that elapsed called in timer irq handler.
For SMP:

still need to clear IP bit in timer irq handler

last_time should be aligned to ticks, old code will miss some
cycles, (curret_time - last_time) % CYC_PER_TICK

in timeout set, the operations of timer aux regs require some cycles
, use MIN_DELAY to guarantee this.

Code optimizations:

rename overflow_cyc to overflow_cycles for better understanding
use MIN macro to replace if .. else ..

Signed-off-by: Wayne Ren wei.ren@synopsys.com
Fixes #25178
Fixes #25179

@vonhust will you address the review comments this week? This fixes to high-priority bugs so it's important that we get it merged.

May we have more precise explanation of what and why doesn't work on IoTDK as expected. Why do we see behavior which differs from other boards? Is that ARC EM version that has some (known?) specifics or it's ARC core configuration which leads to such a behavior? In any case I'd like to see a reference either to some documentation or bug-tracker entry which has a valid explanation of this phenomenon.
Please de-couple clean-up changes from real meat of this fix/change so we may focus on important changes.
Given yet another iteration of our timer driver rework maybe we start from design specification where we may capture known problems and explain how are we trying to get the ultimate implementation that just works? :)

I already split this PR into 3 commits.  For the root cause why iotdk doesn't work,  i think  it depends on how it configured in Architect.

@ruuddw  @abrodkin ,  now the sanitycheck tests of iotdk are clean.  Let's get it merged to fix the high priority issues, to not block the release of Zephyr.

source: gharchive/pull-request

authors: carlescufi vonhust


text:
Revert "cmake: introduction of ZephyrExtension package"

This reverts commit ac898bc49ea8387dc96e8ba7fc21d6d0ed12e34c.
This commit was merged by mistake, but in a way that was against the
decision of the TSC on May 20, 2020, which was to wait a week to let
people digest before merging.

FYI @henrikbrixandersen


text:
boards: Add support for the Serpente Board

The Serpente Boards are small low-cost Atmel SAMD21 based development boards by @arturo182
Signed-off-by: Alexander Falb fal3xx@gmail.com

Thanks for the pointers to seeeduino_xiao, I'll have a look.
Do you want me to amend to my original commit or just add a 2nd commit with the requested changes?

Thanks for the pointers to seeeduino_xiao, I'll have a look.
Do you want me to amend to my original commit or just add a 2nd commit with the requested changes?

Best practice is to amend / fixup and then do a force push.  Make sure you resolve the comments first though, else Github seems to lose them.

I'm a bit lost regarding PWM.
Because the user LED is ACTIVE_LOW I'd like to set the PWM to PWM_POLARITY_INVERTED (is this the right approach?). However this does not seem to be supported by the driver or I'm doing it wrong:
pwmleds {
	compatible = "pwm-leds";
	red_led_pwm: pwm_led_0 {
		pwms = <&tcc0 0 PWM_POLARITY_INVERTED>;
	};
}

Results in errors during the build $ west build samples/basic/blinky_pwm --board=serpente -p:
[...snip...]
serpente.dts.pre.tmp:336.4-30: Warning (pwms_property): /pwmleds/pwm_led_0:pwms: cell 2 is not a phandle reference
serpente.dts.pre.tmp:335.26-337.5: Warning (pwms_property): /pwmleds/pwm_led_0: Missing property '#pwm-cells' in node /soc/interrupt-controller@e000e100 or bad phandle (referred from pwms[2])
devicetree error: <Node /soc/interrupt-controller@e000e100 in 'serpente.dts.pre.tmp'> lacks #pwm-cells
[...snip...]

PWM is now working, however the output is inverted (the LED on the Serpente is ACTIVE_HIGH which is currently not supported by the DTS for SAM0-TCC-PWM). I'm working on another PR to add this feature.

PWM is now working, however the output is inverted (the LED on the Serpente is ACTIVE_HIGH which is currently not supported by the DTS for SAM0-TCC-PWM). I'm working on another PR to add this feature.

Sounds good, I was about to do the same.  Let me know if you run out of time and I can take over the PWM change.

The Serpente board has a very limited pin count, but the pins are well chosen. It is possible to have 2UART or 1UART+1SPI or 1I2C+1SPI or 1UART+1I2C and so on (see notes in schematics).
What is the best practice in Zephyr for the default sercom definition in the board DTS? The options I was thinking about are:

Having both available sercoms with status okay, but nothing else in the DTS + overlay for all tests. (Probably the "cleanest" and most time consuming solution I could think of)
Having some defaults like 1SPI+1I2C in the DTS + overlays for the UART tests (I'm not sure which pinout should be the default)
Remove the supported flags from yaml (This feels like a quick and dirty hack)

Are there any better ways I missed? Which one do you prefer?

I just updated the PR and added a few overlay files to configure the board for the tests/samples. However I'm still not sure this is the way to go - please advice!

Please move serpente.overlay files in samples and tests to a separate commit as it has nothing to do with the commit boards: Add support for the Serpente Board

The tests and samples won't compile without warning (buildkite will fail), if I remove the overlay files. I would also have to remove the supported field from serpente.yaml, to simply not compile and tests and samples. But then the serpente.yml would not be aligned with the docs that also state what is supported by the board/mcu. I would like to keep this in one PR, but what do you think?

The tests and samples won't compile without warning (buildkite will fail), if I remove the overlay files. I would also have to remove the supported field from serpente.yaml, to simply not compile and tests and samples. But then the serpente.yml would not be aligned with the docs that also state what is supported by the board/mcu. I would like to keep this in one PR, but what do you think?

It was just a request to move the overlays to a separate commit, not a separate PR (so one commit to introduce the board and then one commit to add the overlays)

It was just a request to move the overlays to a separate commit, not a separate PR (so one commit to introduce the board and then one commit to add the overlays)

Sorry, I misunderstood. I just splittet the commit into two.

How do you want me to proceed with the failing build_all tests? The serpente only supports 2 different interfaces out of [UART, SPI, I2C] simultaneously, but some tests use all 3 of them. What is the best practice in this scenario?

How do you want me to proceed with the failing build_all tests? The serpente only supports 2 different interfaces out of [UART, SPI, I2C] simultaneously, but some tests use all 3 of them. What is the best practice in this scenario?

You could blacklist the board for the test that require the 3 interfaces. Have a look at tests/drivers/build_all/testcase.yaml, some of the test cases in there already blacklist (platform_exclude:) the frdm_kw41z board

I guess I messed up the review resolving. Are there still any changes pending that I missed?

@nzmichaelh I'm sorry, but somewhere on the way to finalize this PR it seems like I forgot to resolve a change request from you. Is there still anything you want me to fix in this PR?
Aside from that, is there anything else I can do to help finish up this PR?

@nzmichaelh please revisit

@nzmichaelh just a friendly reminder that this PR still needs your attention :-)

authors: MaureenHelm elexx nzmichaelh vanwinkeljan


text:
arm: final release notes for Cortex-R and Cortex-M

v2.6.0 release notes for Cortex-R and final entries for Cortex-M.

Can you remove the blank lines between bullets.

Will remove also for the other ARCHes, then :)


text:
drivers: eeprom: add support for Microchip 24AA0AXEXX EEPROM with EUI

Add support for the Microchip 24AA0AXEXX (e.g. the 24AA0AE48) - an
I2C EEPROM pre-programmed with a EUI (e.g. for use as a unique MAC
address). Due to #38506, support for errors during writing is somewhat
weak - real errors on writes might be retried a few times.
Tested on 24AA0A2E48.
Signed-off-by: Dr. Benjamin S. Scarlet scarlet@alum.mit.edu

Doesn't the this device work with the existing eeprom_at2x.c driver?

It does work with the at2x driver, thanks.

authors: bscarlet henrikbrixandersen


text:
samples: kernel: cycle64: modify default timeout

Integration platforms for cycle64 are those that exhibit a "time warp" characteristic - such as qemu_riscv64 where the application runs to completion almost instantly but the clock says that 14 minutes has passed.
Fast integration tests are good for CI, and so the timeout for integration tests is lowered to 5s.
However, some users have reported that the test fails when run under twister but succeeds under west for non-integration platforms. I've observed the test taking up to 86 seconds on qemu_cortex_a53, which is beyond the default 60s timeout allows with twister.
This change should address both cases.
Fixes #40367

On my desk, qemu_x86_64 ended up taking 136s. Would be great if someone else could reproduce.
west build -p auto -b qemu_x86_64 -t run samples/kernel/cycle64

What's the purpose of this sample? Right now, the timeout() function doesn't seem to working correctly, but it's not documented what the actual intent of it is.
It calculates a new timeout that is 2^32 ticks away, but then masks off the top 32 bits, so it takes all the way until the 64-bit counter wraps to actually time out. Reducing the number of loops to 2 (to abort right after the cycle counter reaches beyond 32-bit space) doesn't seem like the right thing to do.
Wouldn't the better fix here be to let timeout() return the cycle counter beyond 32-bit values, and then just wait on it to wrap as expected?  It's also a lot more valuable to show this for values beyond the 32-bit ones, quitting on the second iteration doesn't do that.

@cfriedt  this looks more like a test, not a sample, can you move this to some existing test please?
btw, the sample also fails on m2gl025_miv on main branch.

rebase to see why CI did not catch the failure here.

@cfriedt this looks more like a test, not a sample, can you move this to some existing test please? btw, the sample also fails on m2gl025_miv on main branch.

A timeout under twister I guess? I have not run this test under renode for m2gl025_miv. However, it works fine on qemu_riscv32 (in twister and via west).
The main reason that this is a sample and not a test, is that if someone were to blanket-run twister without -G, assuming the average time across N boards to run the test was T seconds, then twister would take N [boards] * T [s/board] longer to run than it does today, which I'm guessing nobody wants.
Of course, the amount of time for the test to run successfully in twister varies per platform. Therefore, in order to make twister succeed, the timeout would need to be at least as long as it takes for the longest timer to wrap around the 32-bit boundary, which is an awfully long time to wait for SUCCESS.

The main reason that this is a sample and not a test...

well, this does not make a difference really if you put it under sample, the test is just run exactly the same way. That is not really the point here, but it would better go into tests, it does not qualify as a sample, no docs, and anything here could for example be part of the docs.
If the failures are all timeouts and the test just takes too long to run, then mark it as slow: True in the yaml file or limit it to the platforms where results come fast: platforms_allow: native_posix, with slow twister will ignore it unless twister is run with --enable-slow.
Right now this test is failing on multiple platforms due to the timeout...
integration_platforms is not the right way to filter the platforms here. The test has to pass without -G, see how it fails here:  https://github.com/zephyrproject-rtos/zephyr/runs/4348498579?check_suite_focus=true

The main reason that this is a sample and not a test...

well, this does not make a difference really if you put it under sample, the test is just run exactly the same way. That is not really the point here, but it would better go into tests, it does not qualify as a sample, no docs, and anything here could for example be part of the docs.
If the failures are all timeouts and the test just takes too long to run, then mark it as slow: True in the yaml file or limit it to

Done!
$ twister --enable-slow -T tests/kernel/timer/cycle64
...
INFO    - Total complete:   30/  30  100%  skipped:   20, failed:    0
INFO    - 16 of 16 test configurations passed (100.00%), 0 failed, 20 skipped with 0 warnings in 143.98 seconds
INFO    - In total 16 test cases were executed, 20 skipped on 30 out of total 407 platforms (7.37%)
INFO    - 15 test configurations executed on platforms, 1 test configurations were only built.
INFO    - Saving reports...
INFO    - Writing xunit report /home/cfriedt/workspace/zephyrproject/zephyr/twister-out/twister.xml...
INFO    - Writing xunit report /home/cfriedt/workspace/zephyrproject/zephyr/twister-out/twister_report.xml...
INFO    - Run completed

What's the purpose of this sample? Right now, the timeout() function doesn't seem to working correctly, but it's not documented what the actual intent of it is.

Sorry - missed this comment. The timeout() function calculates the number of cycles until the next 32-bit wrap-around (which is by definition only 32-bits).

authors: cfriedt nashif olofj


text:
net: lib: app: If NET_LOG_GLOBAL is enabled, enable NET_DEBUG_APP

This is similar to the changes made previously to other network
components: if user selected NET_LOG_GLOBAL, they really mean
they want logging (first of all, error/warning logging) across
the entire network stack.
Signed-off-by: Paul Sokolovsky paul.sokolovsky@linaro.org

The patch is fine, I just wonder is your plan to send these enhancements one by one. It would probably not be a big effort to add these support to all relevant parts in one go.

@jukkar : Yeah, I'm trying to come up with a more general plan how to deal with it - as warned by Anas and AndrewB during the RFC discussion, it's not going to be that simple, because we have "impedance mismatch" if various logging domains. In the meantime, other stuff gets pushed in front of that work, e.g. I was tasked to look into 15.4. And one of the first thing I see the device being misconfigured due to a missing setting - silently (https://github.com/zephyrproject-rtos/zephyr/issues/4182). So, this is fix for that particular issue which also may affect other people working in parallel, I'd appreciate it being merged. And yes, I should grep thoroughly thru the codebase and apply remaining changes like this, on my TODO.

authors: jukkar pfalcon


text:
wifi: esp_at: use UART device pointer directly instead of label

UART device pointer is already used directly when configuring modem
interface. Convert the case when UART is reconfigured when 'target-speed'
DT property is specified.

Just rebased on top of main.


text:
cmake: detect sysroot for cross-compile toolchains

Fixes: #49587
Try to detect sysroot for cross-compile toolchain if not specified by the user with -DSYSROOT_DIR=<path>.
First, the C compiler is asked if it knows its sysroot, some C compilers are able to return the sysroot, as an example:
$ arm-none-eabi-gcc -print-sysroot
<path>/bin/../arm-none-eabi
$

but majority of gcc-based C compilers seems to return empty string:
$ arm-zephyr-eabi-gcc --print-sysroot
$

in such cases, the cross-compiler target CMake file will try to discover the sysroot by searching for libc.a, starting one level up from the compiler location.
If no sysroot candidate is found, a warning will be printed to the user. If a single sysroot candidate is found, this candidate will be selected. If multiply sysroot candidates are found, a warning is printed, and the first candiate in the list is selected. User may select another candidate with -DSYSROOT_DIR=<use-this>.
Signed-off-by: Torsten Rasmussen Torsten.Rasmussen@nordicsemi.no

Note that when the compiler (even without sysroot set) is installed in a non-default location, then GCC sets the GCC_EXEC_PREFIX environment variable during execution. This variable can be used in .specs files to locate all of the GCC-related files. I've submitted a patch to gcc to make it possible to take advantage of this even if gcc might be installed in the default location, but as zephyr sdk never does this, we could use GCC_EXEC_PREFIX in .specs files to locate associated files. Picolibc has support for this.

@stephanosio so what you're basically saying is that this code is obsolete and can be removed:
https://github.com/zephyrproject-rtos/sdk-ng/blob/01f76f05817d170b6a3df5268ed20c8a7b6e05f0/cmake/zephyr/target.cmake#L28

Technically, yes. But, as seen in #49587, there are some toolchain builds that require this patch for various reasons, so I would be in favour of keeping it.

But, as seen in https://github.com/zephyrproject-rtos/zephyr/issues/49587, there are some toolchain builds that require this patch for various reasons

but hopefully suchtoolchains are not used when setting ZEPHYR_TOOLCHAIN_VARIANT to zephyr, but only when using cross-compile 😉 .
Note that I on purpose linked to the Zephyr SDK specific target.cmake, and hopefully that is only used by the Zephyr SDK.
But agree, let's keep it, as it has proven to work for Zephyr SDK.

authors: keith-packard stephanosio tejlmand


text:
mgmt: mcumgr: Make SMP version 2 to legacy error lookup extensible

Replaces the manual lookup function with a lookup function which is provided when registering MCUmgr handlers which can be used to find the function to translate error codes, allowing out of tree MCUmgr handlers to provide error translation handlers.
Fixes #59343

[x] Code
[x] Release notes
[ ] Documentation update will do as part of #59492

@fabiobaltieri could you merge please?


text:
net: Set minimum number of Tx threads when ieee802154 is enabled

The ieee802154_radio APIs, such as .tx() are synchronous at the radio operation level and violate Zephyr guidelines forbiding blocking operations on the system workqueue thread.
For instance, IPv6 neighbor discovery activities are done from the context of the system workqueue. When ND/RS frames are transmitted directly from the workqueue thread, the ieee802154 radio API will block the thread execution until the radio completes the operation, which may take multiple milliseconds.
Delegating the sending of frames to a separate thread prevents this condition.

Pushed fixes for the unit tests.

Closed, because as it turns out this change does not fully solve my problems.


text:
boards: m5stack_core2: fix priorities override

Instead of those set, use the default ones for the MFD/REGULATOR_AXP192_INIT_PRIORITY/GPIO_AXP192_INIT_PRIORITY that are set to the 80/86/81 values correctly. Adjust the GPIO_HOGS_INIT_PRIORITY only to be executed after GPIO driver.

It should fix the https://github.com/zephyrproject-rtos/zephyr/actions/runs/6706887528/job/18224503269?pr=64592.

@dcpleung @nashif please take a look.


text:
tests: Bluetooth: Mesh: reduce blob and dfu models bsim tests execution time

Improvements those have been done so far:
1. General transfer size and block sizes are smaller for blob.
2. Waiting time is shorter for some blob bsim tests.
3. The long dfu srv persistence test suite has been split into two.
4. Retransmission for unicast messages has been reduced till zero.
Table with measurements.

Measurement without improvement has been done on main commit 5dd1cdda3b69f0970466cc4ab232b2cd99dfa247.

@PavelVPV, I guess it got stuck in review because they wait for your approval.


text:
Fix stm32wl i2c driver LPM

Description
This PR introduce a fix for this issue :https://github.com/zephyrproject-rtos/zephyr/issues/37414 by adding a timing reinitialization  when PM resume
Type of change

Bug fix

Test steps

Choose a i2c sensor sample (Choose the one you have). For example samples/sensor/bme280.
Add CONFIG_PM=y
Build for the nucleo_wl55jc
Check that the sample work well with and without CONFIG_PM

Please squash your commits and provide a commit with a clear message. See urls provided by bot in upper message.

@Martdur you have some CI compliance issues (https://github.com/zephyrproject-rtos/zephyr/actions/runs/9112793159/job/25053821771?pr=72805).
Code can be formatted using clang-format -i my_source_file.c & you can check for compliance issues locally before pushing again using ./scripts/ci/check_compliance.py --commits HEAD~n..HEAD (with n being the number of commits in your PR)

I have been testing this pull request on a fleet of ~100 devices in production for the past two weeks, and it works very well. Huge thanks to @Martdur - delivering our project on a tight schedule without your commit would be hard.

I have been testing this pull request on a fleet of ~100 devices in production for the past two weeks, and it works very well. Huge thanks to @Martdur - delivering our project on a tight schedule without your commit would be hard.

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is https://github.com/zephyrproject-rtos/zephyr/pull/72805#discussion_r1612262810

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is #72805 (comment)
@erwango The last modification that I brought doesn't satisfy what aurel32 said ?

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is #72805 (comment)
@erwango The last modification that I brought doesn't satisfy what aurel32 said ?

I understand this PR can be further optimized from a power consumption perspective, but this commit fixes something that is broken today. How about splitting this work into two steps - fix the main branch first and optimize it with the correct PM approach?
What do you think @Martdur and @aurel32 ?

Keep it open

Thanks for this feedback. Unfortunately, this can't be merged as is and basically the way to go is #72805 (comment)
@erwango The last modification that I brought doesn't satisfy what aurel32 said ?

@erwango Maybe @Martdur is stuck because there is an unanswered question in this thread. I have also overlooked this before... Thank you.

@erwango Maybe @Martdur is stuck because there is an unanswered question in this thread. I have also overlooked this before... Thank you.

@hubpav Are you referring to this comment ? I've just answered. If you see another point, just let me know.

authors: Martdur ajarmouni-st erwango hubpav


text:
Prevent null-deref to fix seg fault in cbvprintf on strlen(NULL)

Fix for https://github.com/zephyrproject-rtos/zephyr/issues/76509

@devanl please read the guidelines on how to format the git commits.
Also squash your commits into a single commit.

Also just force push on this PR, no need to open a new PR.

Is this waiting for anything besides review that I can support here?

Is this waiting for anything besides review that I can support here?

In my short experience I've found you usually need to get CI green before people start reviewing. I think it's because folks with review access usually have to optimize their time and so they probably filter PRs by those that have green CI
In your case it seems you're only failing two compliance checks:
"1: UC5 Commit title exceeds max length (83>75)"
"3: UC4 Commit message body line exceeds max length (93>75)"

Is this waiting for anything besides review that I can support here?

As suggested by @pdgendt , please read the contribution guidelines as they contain the answers regarding how to get the compliance check to stop complaining :) thanks!

bump @nordic-krch  can we get the 2nd approval? :D

not sure what I did to close this...

attempt to reopen

Something got messed up as commit show >5000 modified files.

authors: RafaelLaya devanl kartben nordic-krch pdgendt


text:
MAINTAINERS: Update maintainer for release notes

Update to the 4.1 Release managers

thanks for the PR @mmahadevan108! Hopefully our scripts are fine with that, but still you should prob remove kartben from collaborators?

thanks for the PR @mmahadevan108! Hopefully our scripts are fine with that, but still you should prob remove kartben from collaborators?

Don't know, I did not remove you as I did not want to lose your name in collaborators for release notes post-4.1 release.

thanks for the PR @mmahadevan108! Hopefully our scripts are fine with that, but still you should prob remove kartben from collaborators?

Don't know, I did not remove you as I did not want to lose your name in collaborators for release notes post-4.1 release.

makes sense :)


text:
Subject-Verb Agreement

New Task:
The subject and verb do not agree in plurality.
What is the task
The h1 for #feature says, "OUR CLIENT LOVE US BECAUSE".
Change it to say, "OUR CLIENTS LOVE US BECAUSE".
Who is the task for?

[x ] I created this task for me to complete, I will create a PR soon.
[ ] I created this task for someone else to claim.
[ ] I think this is a task that multiple people can do

Confirm all of the following:

[x] I have looked at all the issues currently available and this does not exist or overlap with another ticket

⚠ PLEASE ONLY SUBMIT A PR FOR THIS TASK IF THIS TASK WAS AVAILABLE FOR YOU TO CLAIM

I created this task for me to complete, I will create a PR soon.

repo: zero-to-mastery/Keiko-Corp

license: MIT


text:
Schematics

I added the schematic for the original version as KICAD project and also as PDF.
The schematic for the new revision with the STC15W408AS is updated (KICAD and PDF).

Added with the last commit the initial changes for the new revision, LED is toggled on and of with a long press of SW3, a short press of SW3 was starting voice output of the actual time (not working right now).
The changes are not tested, but there are no compile error.
Compiling of the original version is unchanged, if you want to compile for the new revision, then you have to type "make SDCCREV=-Dstc15w408as". The variable is initialized as stc15f204ea in the Makefile and can be overwritten. The result of the originial compile result has no diff to the version which is generated with the new Makefile.

license: mit

license_source: bigquery


text:
go-zero@v1.3.9 The generated xxxhandler.go references httpx twice! /go-zero@v1.3.9 生成的 xxxhandler.go 引用 httpx 两次

When using go-zero@v1.3.9 to generate the api, it is found that all handler.go references "github.com/zeromicro/go-zero/rest/httpx" twice!
(使用go-zero@v1.3.9 生成api时发现所有handler.go引用了两次"github.com/zeromicro/go-zero/rest/httpx")

I found the handler.tpl line 6 default had import httpx,but the variable "{{.ImportPackages}} " also  contain a httpx!
(我发现 handler.tpl 第 6 行默认有 import httpx，但变量“{{.ImportPackages}}”也包含一个 httpx！)

The variable "{{.ImportPackages}} " is  source from "genhandlers.go"
("{{.ImportPackages}} "的错误值来自于 "genhandlers.go")

same issue #2133

same issure #2141
remove one line.

@zhaobisheng @miaogaolin @LixvYang @kevwan 相关PR已提交 #2152

Duplicate of #2133

authors: LixvYang kevwan miaogaolin smithyj zhaobisheng

repo: zeromicro/go-zero


text:
README mistake

Something minor but the description of onDragEnd is not updated after copied from onDragStart.

Hi, hawkgs
Well spotted! Fixed it. Thanks for reporting!

authors: hawkgs zesik

repo: zesik/react-splitter-layout


text:
Expose addresses on npm

Summary

Split addresses pkg in two, one for public address other for tooling
Publish public addresses

Can we expose a getAddress util in the addresses package? It's a much better dev experience since it's typed.

@lucas-janon updated and updated all the other scripts to use from one pkg or the other

repo: zeta-chain/zetachain


text:
ocr_plate_all_gru.h5

请问可以提供一下ocr_plate_all_gru.h5训练代码吗？

我们后面都是基于ctc进行车牌识别，但是有些技术人员反应gru的效果不错，我们近期会把这部分训练代码整理开放出来，大家可以基于此训练。

repo: zeusees/HyperLPR


text:
add travis ci testing

and lint tests with shellcheck
fixes #84

when you get travis set up, drop me a comment here and I'll push another commit to kick off a test.

@msimerson Alrighty. I have signed up for Travis. If I had known it was a simple sign up form, I'd have done it right away. ;-)
---Alex

Okay @aqw , this PR is complete and you can see the results of running the lint tests against all your files.
I've disabled a handful of shellcheck tests but you ought to review them and make sure my guesses about how you'd choose were accurate. There remains a handful of shellcheck lint errors that I think should be changed in the scripts, but I'll leave that to you to decide if you prefer to fix or suppress the warning.
Once those are addressed, then the Travis CI tests will pass and you'll get automated tests run on every PR.

I have updated this PR further:

I updated the code with a couple POSIX updates (see commit messages)
I disabled a few more shellcheck tests (see tests/lint.sh & inline # shellcheck disable=...

Now the test suite is automatically run and the build passes. This PR is now safe to merge.
However, I'd still recommend going through the list of disabled tests. In a couple cases, I think it would be better to change the code than disable the test, but for now, I'm erring on the side of "make fewer changes."

ping

Hey @msimerson,
Thanks for the ping.
Quick mind-dump, as I'm in the middle of an all-consuming project at work that should be done in 4 weeks. After that, next on my list is zfsnap; cleaning things up, merging PRs, and finally, oh so finally, getting 2.0.0 released.
I've left a few comments on your commits, but my overall question is: can travis do what we need it to do? I have neither setup nor used travis before, so it's a question from ignorance rather than a counterargument.
More than anything, zfsnap needs to be tested across as many available shells on linux, FreeBSD, OS X, smartos, and Solaris. Different shells behave differently on different systems. The joys of portability...
The current vagrant system we're using is insecure and not easily used as CI.
At work, we are hoping to get a new server in 2 months; with that, I should be able to peel off off a few CPUs and use them for CI. Then we can have whatever OS targets we want.
So, the question for me is: how flexible is travis when it comes to integrating with private CI boxes?
---Alex

Your unknown preference is why that particular change was in it's own commit. So you could, if desired, use cherry-pick and only merge the others. I don't know how portable it is, but IIRC, it's part of the POSIX shell spec and bash for a very long time. Since you asked, here's some references for that change:

Shell Command Language
BASH FAQ Why is $(...) preferred over ... (backticks)?
ShellCheck SC2006

@msimerson Ok. I'll be sure to drop that commit if/when merging.
I understand well why $() is superior to ``; I use it all the time. I can't remember which shell was problematic; it's in my notes somewhere; it was 3 years ago.
---Alex

I have removed the $() commit and added SC2006 to the exclude list.

authors: aqw msimerson

repo: zfsnap/zfsnap


text:
定时任务问题

1.从前台新建一个定时任务
2.设置为启动状态,
3.这个时候如果重启后台, 重启后的后台 不会自动执行处于启动状态的任务
1.0版本中存在这个问题,得到的答复时2.0发布时解决,
2.0.1版本依然存在这个问题

收录，我测试下

测试没问题啊

authors: Ray-Sir-Like zhangdaiscott

repo: zhangdaiscott/jeecg-boot


text:
为什么不能支持多个外键

版本号：
2.4.3
问题描述：
比如商品，订单关系。那中间表：订单商品表，就应该是有两个外键。good_id, order_id。
这里有两个问题。
1：我只在一张表（订单表） 看到对应的附表。商品表没看到对应的附表。如图1,2,3
2：基于这种多对多的设计，订单商品表里面如何自动展示对应的商品名称，商品价格。我在功能测试中只能对应到具体的商品id。
如图4：
截图&代码：
问题1：
图1：

图2：

图3：

问题2：
图4:

友情提示： 未按格式要求发帖，会直接删掉。

暂时不支持多个外键，后期优化
归集到https://github.com/zhangdaiscott/jeecg-boot/issues/1312


text:
i18n Support

版本号：
The Latest version available in github
问题描述：
Is there any i18n Support? In my case, looking for Spanish.
截图&代码：
N/A

http://jeecg-boot.mydoc.io/?t=346061

authors: itzamnamx zhangdaiscott


text:
Where to find files in model_low_bit ?

"C:\OpenEduECNU\model_low_bit"
z这个目录下的文件，从哪下载？

同问

"C:\OpenEduECNU\model_low_bit" z这个目录下的文件，从哪下载？

好像是用来保存文件的，不用下载

authors: congweitao kskssskssss


text:
我用了glide4.6.1

java.lang.NoSuchMethodError: No virtual method load(Landroid/net/Uri;)Lcom/bumptech/glide/DrawableTypeRequest; in class Lcom/bumptech/glide/RequestManager; or its super classes (declaration of 'com.bumptech.glide.RequestManager' appears in /data/app/com.dfs168.ttxn-cXFwl7okLTkW8FHbv7Vczg==/split_lib_dependencies_apk.apk)
    at com.zhihu.matisse.engine.impl.GlideEngine.loadThumbnail(GlideEngine.java:36)
    at com.zhihu.matisse.internal.ui.widget.PhotoGrid.setImage(PhotoGrid.java:112)
    at com.zhihu.matisse.internal.ui.widget.PhotoGrid.bindPhoto(PhotoGrid.java:80)
    at com.zhihu.matisse.internal.ui.adapter.AlbumPhotosAdapter.onBindViewHolder(AlbumPhotosAdapter.java:111)
    at com.zhihu.matisse.internal.ui.adapter.RecyclerViewCursorAdapter.onBindViewHolder(RecyclerViewCursorAdapter.java:44)

不支持4.6.1，他们好像支持到3.7.0

Am getting the same issue too. Affecting the whole app as I have to use older versions now

楼主除了用低版本还有别的方法吗？

@Jakemesdg 换成其他的库，如果一定要用Matisse，可能把代码clone下来，直接引用工程

@liumingmad 看了其他人提的issue，换一个引擎就可以解决了

使用 Glide V4+ 的用户请参考  https://github.com/zhihu/Matisse#for-glide-v4

How about use different branch, artifacts ?
Like this,
https://jitpack.io/#ksc91u/Matisse
Contains two branches, master for glide 3, glide4 for glide 4.

authors: Jakemesdg KelvinPac REBOOTERS bluefish625 ksc91u liumingmad

repo: zhihu/Matisse


text:
between the agents on different hosts, any data compression applied?

we are investigating kids system, looks quite promising. just wondering if data compression supported when agents sending data to another agent/server?
since log data probably contains quite a lot duplicated msg, I think data compression would be very helpful.
thanks!

Currently no, and I don't think it is a good idea to do so. log is usually shot text that one TCP package can carry. In this situation, compression will not worth the cost of CPU usage I think. It is good idea if bulk transfer is introduced. But, kids is designed to be real-time. So bulk transfer is not on the TODO list.

maybe I misunderstand the kids configuration.
as the example shown, store buffer -> store network should be a typical use case when transferring log data between different hosts. looks like you buffer logs before send them out. compress one log line is meaningless while compress the whole buffer is another story.
is it possible to do so?

Buffer store is a abstract store. When primary store (usally network store) is not usable, the secondary store is used as a buffer. Then when primary store comes back, data was moved back to primary store. There is no log-level buffer when sending log between nodes using network store.

ah, get it.
you are correct, thanks for the rapid reply.

authors: dccmx thekiki

repo: zhihu/kids


text:
🛑 腾讯云 COS 节点 is down

In d21a6a9, 腾讯云 COS 节点 (https://lisz.ink) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 腾讯云 COS 节点 is back up in c9d9771.

repo: zhonger/upptime


text:
Prediciton Almost flattened

Hello! Thank you for your well-structured code! I am currently doing some task using Informer. I used same network settings as ETTH dataset. But the output is not making sense to me. It is something like that:

Noticing the prediction is almost flattened. Do you have any thoughts about what could be the problem? I think maybe I should adjust the hyperparameters of the network? Do you have any suggestions about that? Thank you very much!

Thanks for your attention to our work, maybe you can increase the seq_len of model, and use multivariate prediction if data allows.

authors: PeihanDou cookieminions


text:
For custom dataset

Congratulations on the best paper award!
I'm new to the transformers with time-series data and just found this cool paper!
It will be great if you could provide an example to show how to use the custom data.
Thanks in advance!

Thanks for your attention. We will release a colab to help people use our model on custom data. Please keep watching this repo.

model.forward(x_enc, x_mark_enc, x_dec, x_mark_dec)
Actually there only 4 tensor that you  need to figure the meaning of. And according to data/data_loader.py, I believe there shape are:

x_enc : batch_size ✖ input_seq_len✖ channel
x_dec : batch_size ✖ output_seq_len✖ channel
x_mark_enc: batch_size ✖ input_seq_len✖ 4.   represent the timestamp of each input_seq element, and formated as 4-len tuple： (month,day,weekday,hour)
x_mark_dec:batch_size ✖ output_seq_len✖ 4.

However, model arguments are more puzzling. Though I got some hints from main_informer.py.
Informer(     enc_in ## encoder input size    ,dec_in  ## decoder input size    ,c_out   ## output size    ,seq_len ## input series length    ,label_len ## help series length    ,pred_len ## predict series length )
I not sure what label_len means.  As far as I know,  output_seq_len=label_len+pred_len. And in the training process zeroing x_dec[:,-pred_len:,:]  before calling model.forward().
                dec_inp = torch.zeros_like(batch_y[:,-self.args.pred_len:,:]).double()
                dec_inp = torch.cat([batch_y[:,:self.args.label_len,:], dec_inp], dim=1).double().to(self.device)

However, since label_len=0 also works, It doesn't matter to much.

Yes, label_len means length of the start token series before the predict seires, so output_seq_len=label_len+pred_len.
The input sequence of Informer decoder is consist of a history series(label_len) before prediction and a series(pred_len) filled with zero. You can refer to the Figure 1.

Thank you for the explanation. I'm not sure if I understand it correctly. Please check it.
Let's take the default settings as an example. The enc_input are 4-day(1,2,3,4) 7-channel features, the dec_input are 2-day(3,4) 7-channel features and 1-day(5) 7-channel 0s. The output are 1-day(5) 7-channel predictions. Is it right?
I have several questions. Sorry if they are stupid.

The target is OT, but the output is 7-channel predictions when features is setting as "M". Then in the loss calculation step, you compare all channel predictions with the truth, not only OT. Is it correct?
For the input x_mark, if I want to use my custom data, is it a must to set the same format like (month,day,weekday,hour)?
Is there any good suggestion on the selection of input length and decode length?

Understanding: Accurate!
Question1: Yes, our multivariate experiments use multivarite input to predicte multivariate output, we will offer the option for  multivariate input predicting univariate output later.
Question2: No, you just need to offer date information like '2020-01-01 00:00:00' in your data and name the column as 'date'. The code of time encoding is in line 65-73 of data/data_loader.py and utils/timefeatures.py. I suggest you use defaut embed augment 'TimeF' and the timeenc in dataset will be 1.
Question3: We recommend considering some meaningful time period related to specific data or tasks when choosing the input length, for example, choose one week as encoder input length and one day as decoder start token length.

authors: HeroadZ cookieminions wywzxxz zhouhaoyi


text:
关于data_loader中的__read_data__函数

if self.features=='M' or self.features=='MS':       cols_data = df_raw.columns[1:]     df_data = df_raw[cols_data]
这里为什么让cols_data = df_raw.columns[1:]？这样的话不是把target也放到features里面了嘛？
数据进入模型之前计算出的 batch_x, batch_y, batch_x_mark, batch_y_mark这四个变量，batch_x中确实是包括了target，不知道后续的模型内部计算时是不是使用某种方法把batch_x的最后一列target给去掉了？
这个地方有些看不懂，期待解惑

更新：
target确实进入了batch_x，但其实是上一条的target，作为feature的一部分共同预测下一个target，这个地方的target如果是未来5日收益率这种时间序列相关的指标，那必然会暴露一部分未来数据

确实如此，所以你放弃了吗？还是改了代码？

确实如此，所以你放弃了吗？还是改了代码？

改动了代码，将target删掉，再新写代码单独计算target传送到model里进行训练

6阿，我目前就改了点简单的代码，导出带时间戳的预测和真实值，但是删除target和再传送，还得看看怎么改。

确实如此，所以你放弃了吗？还是改了代码？

改动了代码，将target删掉，再新写代码单独计算target传送到model里进行训练

6阿，能否请教一下代码该如何改呢？我一直疑惑transformer架构的，是运用于seq2seq，每次结果都是一个字一个字出来，似乎不能剥离target

把target换成不带未来信息的收益率就行了，但我实测效果相当一般

谢谢，可能架构不合适吧。我看了代码似乎没法改。我的实测效果也不好

我了解到的用这个框架预测收益率的似乎没有哪个说效果好的，可能就是不合适而已

authors: leoyinhaiqing xiaolve


text:
Refactoring: add helper class to bind qnn tensor -> ggml tensor

Self Reported Review Complexity:

[x] Review Complexity : Low
[ ] Review Complexity : Medium
[ ] Review Complexity : High

[x] I have read the contributing guidelines

As I said in your upstream PR, better to have a function for wrapping ggml_tensor into Qnn_Tensor_t.
So here i create a PR for it.
Run test on cpu backend, works well

Run on npu backend, also works well:

thanks for your PR. we can discuss this problem in my personal learning&study project:https://github.com/zhouwg/kantv/tree/ggml-qnn-quantize/core/ggml/llamacpp/tests/ggml-qnn.
可以在我的学习&研究项目里研究ggml-qnn相关问题。不用费劲提交给上游了。

thanks for your PR. we can discuss this problem in my personal learning&study project:https://github.com/zhouwg/kantv/tree/ggml-qnn-refine/core/ggml/llamacpp/tests/ggml-qnn.
不了解您是啥背景？类似我这样闲着没事干的独立个人开发者？还是AI相关公司雇员？如果您是公司雇员，可以联系面壁智能（他们应该已经做到了高通NPU的加速).
没想到您还对这个问题感兴趣。我现在对上游项目不感兴趣了，如您愿意，可以在我的学习&研究项目里研究ggml-qnn相关问题，可以用中文，这样更方便，最后将研究结果贡献给社区。不用费劲提交给上游了（事实上，自从哪个ggml-rpc.cpp相关的多个pr被合并到master分支后------我很失望，上游项目已经进入垃圾时间了，没啥核心改进)。

我个人对这个问题还是比较乐观，毕竟rpc那系列pr我也看过，并且日常我也用，和qnn这个，我认为也不冲突。
个人对llama.cpp添加qnn backend还是看好的，另外这个PR确实也大，所以review比较慢，还是请你别灰心，加油！要是有机会的话还是尽量merge到upstream，毕竟这样可以少很多事。
我做这个还是出于个人爱好，主要可以学习交流新东西，兴趣使然。所以也没打算和厂商联系，基于公开资料做做这样。

谢谢。
6月15号以前的确非常希望这个PR能够进master，现在已经无所谓了。
1.ggml backend system的作者/维护者可能有比较明显的双标行为：您说的rpc与这个pr的确没啥冲突，但是对比哪位维护者对这两个PR的态度，可以感觉到很明显的双标。正常来说，一个专注与端侧设备推理的框架，类似主流芯片高通加速的后端，很多人感兴趣，应该通过社区，一起来完成。
2.我此前在ggml-rpc.cpp的一个提交表达了个人的一些真实看法，可能上游社区的一些核心维护者不高兴。
3.我在llama.cpp的另外一个无足轻重但也有一定价值的pr在得到一位reviewer的approval后，那位所谓的核心维护者居然又跳出来挑毛病（这与ggml-rpc.cpp形成了强烈鲜明的对比）。

这个可能我还是说两句我的经验，我刚开始提PR也是这样，觉得PR的某些评论有点针对个人，后来打交道多了也就想开了，换个位置思考，其实大家都是基于兴趣爱好做点开源的东西，也不是工作，review的人可能也只是兴趣爱好，基于这个出发点，是不是大家合作就会好些。
PR review时间长的问题，我也经常遇到（我以前有过经验，一个大PR拖了几个月），这个可能确实无解，因为大家都是业余玩这个，时间也不固定，我一般会把我的思路写下来，然后每部分代码加点注释啥的，这样review也容易些。
PR优先级这个确实无解，有可能某些PR就是很重要，但是社区没有足够的有相关背景的人来review，这种情况确实存在，看起来您的PR就是处于类似的位置，所以对其他reviewer可能难度很大。
一个社区确实是会有不同的声音的，确实会有部分人反对，也是一种声音，但是社区内部还是比较民主的，经过这些年，我开始觉得有个反对的声音挺重要的。
另外，老哥，不必妄自菲薄，你能业余时间做些开源贡献，其实已经比很多人厉害了；另外，每天对着代码对着comment，确实会容易有情绪，这种情况确实存在，也只能说尽量控制，不影响判断，也尽量不泄露到其他地方（这个真难，我也做不到，唉），这样反倒容易让不相干的人卷进来。
还有就是语言的问题，其实我们自己都玩llm，现在llm已经能很好的处理语言之间转换的问题了，其实用好了，可以减少很多语言障碍。

感谢老哥回复，你用业余时间做到这样，已经不错了，加油！

@chraac
Thank you for the development.
i used dev-refactoring branch.
but Creating a tensor for a matmul node fails with an error and doesn't work.
Device:Snapdragon8 Gen3 16GB
-m models/Kitsunebi-v1-Gemma2-8k-9B.Q4_K_M.gguf -ngl 40
[ggml_qnn_graph, 27]: graph name MUL_MAT_3584x2048
x1x1_3584x2x1x1_2048x2x1x1
[ggml_qnn_graph, 75]: can't create qnn graph handl
e with graph name MUL_MAT_3584x2048x1x1_3584x2x1x1
_2048x2x1x1, error = 6003

@chraac
Thank you for the development. i used dev-refactoring branch. but Creating a tensor for a matmul node fails with an error and doesn't work.
Device:Snapdragon8 Gen3 16GB
llama-server -m models/Kitsunebi-v1-Gemma2-8k-9B.Q4_K_M.gguf -ngl 40

...
[ggml_qnn_graph, 27]: graph name MUL_MAT_3584x2048
x1x1_3584x2x1x1_2048x2x1x1
[ggml_qnn_graph, 75]: can't create qnn graph handl
e with graph name MUL_MAT_3584x2048x1x1_3584x2x1x1
_2048x2x1x1, error = 6003

diff --git a/ggml/src/ggml-backend.c b/ggml/src/gg
ml-backend.c
index a8eafac4..e2b421e2 100644
--- a/ggml/src/ggml-backend.c
+++ b/ggml/src/ggml-backend.c
@@ -287,6 +287,7 @@ bool ggml_backend_supports_op(
ggml_backend_t backend, const struct ggml_tensor *
 }

 bool ggml_backend_supports_buft(ggml_backend_t backend, ggml_backend_buffer_type_t buft) {
+    if (NULL == backend->iface.supports_buft) return true;
  ┆ ┆return backend->iface.supports_buft(backend, buft);
 }

Hi @myan-o , thanks your for the feedback, as i said before, in ggml, the input tensor of matmul operator need to be transposed, to achieve that i've a lot more refactoring work to do, so now the mulmat operator is still under constructiion, for more information, could have a look here: https://github.com/chraac/llama.cpp/commit/63dc587dffae40c0cd7f1468859f2d430039a29e

@chraac
Thank you for your answer. So does that mean that matmul operations are not implemented yet?
I have also made a pull request for some minor fixes, so please take a look.

@chraac
The termux development environment lacks the c++ std library and the build fails.

@chraac 抱歉打扰开发者，当前我也在高通骁龙Gen2的设备上基于llama.cpp部署LLM,使用的模型为Qwen2 0.5B，我已经注意到你的仓库中存在多个branch,请问如果我需要测试的话应该使用哪个分支呢？

@chraac 抱歉打扰开发者，当前我也在高通骁龙Gen2的设备上基于llama.cpp部署LLM,使用的模型为Qwen2 0.5B，我已经注意到你的仓库中存在多个branch,请问如果我需要测试的话应该使用哪个分支呢？

Hi @FranzKafkaYu , 可以用 dev-refactoring 这个分支哈，但是就像我前面说的，现在mulmat跑还有问题，还在改中哈

@chraac 抱歉打扰开发者，当前我也在高通骁龙Gen2的设备上基于llama.cpp部署LLM,使用的模型为Qwen2 0.5B，我已经注意到你的仓库中存在多个branch,请问如果我需要测试的话应该使用哪个分支呢？

Hi @FranzKafkaYu , 可以用 dev-refactoring 这个分支哈，但是就像我前面说的，现在mulmat跑还有问题，还在改中哈

今天有空测试了一下该分支，无法正常编译通过,编译command：
 mkdir build-android && cd build-android && cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=latest -DCMAKE_C_FLAGS=-march=armv8.4a+dotprod -DGGML_QNN=ON -DGGML_QNN_SDK_PATH=/home/franzkafka/Desktop/qnn/qairt/2.22.6.240515  .. && make -j4

相关报错日志：
-- Using latest available ANDROID_PLATFORM: 33.
-- The C compiler identification is Clang 14.0.7
-- The CXX compiler identification is Clang 14.0.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.34.1")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Found OpenMP_C: -fopenmp=libomp (found version "5.0")
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
-- OpenMP found
-- Using llamafile
QNN_SDK_PATH: /home/franzkafka/Desktop/qnn/qairt/2.22.6.240515
-- Warning: ccache not found - consider installing it for faster compilation or disable this warning with GGML_CCACHE=OFF
-- CMAKE_SYSTEM_PROCESSOR: aarch64
-- ARM detected
-- Performing Test COMPILER_SUPPORTS_FP16_FORMAT_I3E
-- Performing Test COMPILER_SUPPORTS_FP16_FORMAT_I3E - Failed
-- Configuring done
-- Generating done
-- Build files have been written to: /home/franzkafka/Desktop/llama/llama.cpp/build-android
[  0%] Generating build details from Git
[  1%] Building C object examples/gguf-hash/CMakeFiles/xxhash.dir/deps/xxhash/xxhash.c.o
[  2%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml.c.o
[  3%] Building C object examples/gguf-hash/CMakeFiles/sha256.dir/deps/sha256/sha256.c.o
-- Found Git: /usr/bin/git (found version "2.34.1")
[  4%] Building CXX object common/CMakeFiles/build_info.dir/build-info.cpp.o
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:2065:5: warning: implicit conversion increases floating-point precision: 'float32_t' (aka 'float') to 'ggml_float' (aka 'double') [-Wdouble-promotion]
    GGML_F16_VEC_REDUCE(sumf, sum);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1166:41: note: expanded from macro 'GGML_F16_VEC_REDUCE'
    #define GGML_F16_VEC_REDUCE         GGML_F32Cx4_REDUCE
                                        ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1156:38: note: expanded from macro 'GGML_F32Cx4_REDUCE'
    #define GGML_F32Cx4_REDUCE       GGML_F32x4_REDUCE
                                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1086:11: note: expanded from macro 'GGML_F32x4_REDUCE'
    res = GGML_F32x4_REDUCE_ONE(x[0]);         \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1071:34: note: expanded from macro 'GGML_F32x4_REDUCE_ONE'
#define GGML_F32x4_REDUCE_ONE(x) vaddvq_f32(x)
                                 ^~~~~~~~~~~~~
[  4%] Built target build_info
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:2113:9: warning: implicit conversion increases floating-point precision: 'float32_t' (aka 'float') to 'ggml_float' (aka 'double') [-Wdouble-promotion]
        GGML_F16_VEC_REDUCE(sumf[k], sum[k]);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1166:41: note: expanded from macro 'GGML_F16_VEC_REDUCE'
    #define GGML_F16_VEC_REDUCE         GGML_F32Cx4_REDUCE
                                        ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1156:38: note: expanded from macro 'GGML_F32Cx4_REDUCE'
    #define GGML_F32Cx4_REDUCE       GGML_F32x4_REDUCE
                                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1086:11: note: expanded from macro 'GGML_F32x4_REDUCE'
    res = GGML_F32x4_REDUCE_ONE(x[0]);         \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1071:34: note: expanded from macro 'GGML_F32x4_REDUCE_ONE'
#define GGML_F32x4_REDUCE_ONE(x) vaddvq_f32(x)
                                 ^~~~~~~~~~~~~
[  4%] Building C object examples/gguf-hash/CMakeFiles/sha1.dir/deps/sha1/sha1.c.o
[  4%] Built target sha256
[  4%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml-alloc.c.o
[  4%] Built target sha1
[  5%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml-backend.c.o
[  6%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml-quants.c.o
[  6%] Building CXX object ggml/src/CMakeFiles/ggml.dir/llamafile/sgemm.cpp.o
[  6%] Built target xxhash
[  7%] Building CXX object ggml/src/CMakeFiles/ggml.dir/ggml-qnn/backend-ops.cpp.o
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:2:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.hpp:5:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend.hpp:11:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/graph.hpp:13:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/op-config.hpp:9:
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/qnn-lib.hpp:254:47: error: no member named 'variant_npos' in namespace 'std'
        if (_backend_name.find("Htp") != std::variant_npos) {
                                         ~~~~~^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/qnn-lib.hpp:361:47: error: no member named 'variant_npos' in namespace 'std'
        if (_backend_name.find("Htp") != std::variant_npos) {
                                         ~~~~~^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/qnn-lib.hpp:412:47: error: no member named 'variant_npos' in namespace 'std'
        if (_backend_name.find("Htp") != std::variant_npos) {
                                         ~~~~~^
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:2:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.hpp:5:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend.hpp:11:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/graph.hpp:13:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/op-config.hpp:11:
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/tensor.hpp:193:41: error: implicit instantiation of undefined template 'std::array<unsigned int, 4>'
    std::array<uint32_t, GGML_MAX_DIMS> _dimensions = {};
                                        ^
/home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/__tuple:219:64: note: template is declared here
template <class _Tp, size_t _Size> struct _LIBCPP_TEMPLATE_VIS array;
                                                               ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:246:1: error: static_assert failed due to requirement 'sizeof (kGgmlOpToQnnOp) / sizeof (kGgmlOpToQnnOp[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT)' "GGML_OP_COUNT does not match the size of the kGgmlOpToQnnOp table"
static_assert(sizeof(kGgmlOpToQnnOp) / sizeof(kGgmlOpToQnnOp[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT),
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:248:1: error: static_assert failed due to requirement 'kGgmlOpToQnnOp[GGML_UNARY_OP_GELU + kGgmlUnaryOpStart] != nullptr' "GGML_UNARY_OP_GELU does not correspond to QNN_OP_GELU"
static_assert(kGgmlOpToQnnOp[GGML_UNARY_OP_GELU + kGgmlUnaryOpStart] != nullptr,
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:294:23: error: no matching function for call to 'get_qnn_graph_from_cache'
    auto *graph_ptr = get_qnn_graph_from_cache<2, 1>(ctx, _GgmlOp, { src0, src1 }, { dst });
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:252:22: note: candidate function template not viable: cannot convert initializer list argument to 'const std::array<ggml_tensor *, 2UL>'
qnn::ggml_qnn_graph *get_qnn_graph_from_cache(ggml_backend_qnn_context *ctx, size_t op,
                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:317:23: error: no matching function for call to 'get_qnn_graph_from_cache'
    auto *graph_ptr = get_qnn_graph_from_cache<1, 1>(ctx, _GgmlOp, { src }, { dst });
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:252:22: note: candidate function template not viable: cannot convert initializer list argument to 'const std::array<ggml_tensor *, 1UL>'
qnn::ggml_qnn_graph *get_qnn_graph_from_cache(ggml_backend_qnn_context *ctx, size_t op,
                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:431:1: error: static_assert failed due to requirement 'sizeof (kQnnUnaryOpsTable) / sizeof (kQnnUnaryOpsTable[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT)' "GGML_OP_COUNT does not match the size of the kQnnUnaryOpsTable table"
static_assert(sizeof(kQnnUnaryOpsTable) / sizeof(kQnnUnaryOpsTable[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT),
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:519:1: error: static_assert failed due to requirement 'sizeof (kQnnBinaryOpsTable) / sizeof (kQnnBinaryOpsTable[0]) == GGML_OP_COUNT' "GGML_OP_COUNT does not match the size of the kQnnBinaryOpsTable table"
static_assert(sizeof(kQnnBinaryOpsTable) / sizeof(kQnnBinaryOpsTable[0]) == GGML_OP_COUNT,
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:2:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.hpp:5:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend.hpp:4:
/home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/memory:3927:24: error: incompatible pointer types assigning to 'std::__shared_weak_count *' from 'std::__shared_ptr_emplace<qnn::ggml_qnn_tensor, std::allocator<qnn::ggml_qnn_tensor>> *'
        __r.__cntrl_ = __cntrl;
                       ^~~~~~~
/home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/memory:4444:29: note: in instantiation of function template specialization 'std::shared_ptr<qnn::ggml_qnn_tensor>::__create_with_control_block<qnn::ggml_qnn_tensor, std::__shared_ptr_emplace<qnn::ggml_qnn_tensor, std::allocator<qnn::ggml_qnn_tensor>>>' requested here
    return shared_ptr<_Tp>::__create_with_control_block(__ptr, __hold2.release());
                            ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/graph.hpp:108:22: note: in instantiation of function template specialization 'std::make_shared<qnn::ggml_qnn_tensor, std::basic_string<char>, const QNNBackend &, void *&, std::shared_ptr<qnn::qnn_instance> &>' requested here
                std::make_shared<ggml_qnn_tensor>(std::string(buffer), _device, _graph_handle, _qnn_instance);
                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:312:5: error: static_assert failed due to requirement 'kGgmlOpToQnnOp[86UL] != nullptr' "GGML_OP does not have a corresponding QNN_OP"
    static_assert(kGgmlOpToQnnOp[_GgmlOp] != nullptr, "GGML_OP does not have a corresponding QNN_OP");
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:424:5: note: in instantiation of function template specialization '(anonymous namespace)::qnn_unary_op_impl<86UL>' requested here
    qnn_unary_op_impl<GGML_UNARY_OP_GELU + kGgmlUnaryOpStart>, // GGML_UNARY_OP_GELU
    ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:289:5: error: static_assert failed due to requirement 'kGgmlOpToQnnOp[(ggml_op)25U] != nullptr' "GGML_OP does not have a corresponding QNN_OP"
    static_assert(kGgmlOpToQnnOp[_GgmlOp] != nullptr, "GGML_OP does not have a corresponding QNN_OP");
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:459:5: note: in instantiation of function template specialization '(anonymous namespace)::qnn_binary_op_impl<GGML_OP_MUL_MAT>' requested here
    qnn_binary_op_impl<GGML_OP_MUL_MAT>, // GGML_OP_MUL_MAT
    ^
13 errors generated.
make[2]: *** [ggml/src/CMakeFiles/ggml.dir/build.make:146: ggml/src/CMakeFiles/ggml.dir/ggml-qnn/backend-ops.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
2 warnings generated.
make[1]: *** [CMakeFiles/Makefile2:1603: ggml/src/CMakeFiles/ggml.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

不确定具体问题在哪里,也许是QNN SDK不对？
PS:是否可以开放仓库的issue区，相关问题我们可到你的仓库进行讨论，避免打扰其他开发者

@chraac 抱歉打扰开发者，当前我也在高通骁龙Gen2的设备上基于llama.cpp部署LLM,使用的模型为Qwen2 0.5B，我已经注意到你的仓库中存在多个branch,请问如果我需要测试的话应该使用哪个分支呢？

Hi @FranzKafkaYu , 可以用 dev-refactoring 这个分支哈，但是就像我前面说的，现在mulmat跑还有问题，还在改中哈

今天有空测试了一下该分支，无法正常编译通过,编译command：
 mkdir build-android && cd build-android && cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=latest -DCMAKE_C_FLAGS=-march=armv8.4a+dotprod -DGGML_QNN=ON -DGGML_QNN_SDK_PATH=/home/franzkafka/Desktop/qnn/qairt/2.22.6.240515  .. && make -j4

相关报错日志：
-- Using latest available ANDROID_PLATFORM: 33.
-- The C compiler identification is Clang 14.0.7
-- The CXX compiler identification is Clang 14.0.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.34.1")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Found OpenMP_C: -fopenmp=libomp (found version "5.0")
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
-- OpenMP found
-- Using llamafile
QNN_SDK_PATH: /home/franzkafka/Desktop/qnn/qairt/2.22.6.240515
-- Warning: ccache not found - consider installing it for faster compilation or disable this warning with GGML_CCACHE=OFF
-- CMAKE_SYSTEM_PROCESSOR: aarch64
-- ARM detected
-- Performing Test COMPILER_SUPPORTS_FP16_FORMAT_I3E
-- Performing Test COMPILER_SUPPORTS_FP16_FORMAT_I3E - Failed
-- Configuring done
-- Generating done
-- Build files have been written to: /home/franzkafka/Desktop/llama/llama.cpp/build-android
[  0%] Generating build details from Git
[  1%] Building C object examples/gguf-hash/CMakeFiles/xxhash.dir/deps/xxhash/xxhash.c.o
[  2%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml.c.o
[  3%] Building C object examples/gguf-hash/CMakeFiles/sha256.dir/deps/sha256/sha256.c.o
-- Found Git: /usr/bin/git (found version "2.34.1")
[  4%] Building CXX object common/CMakeFiles/build_info.dir/build-info.cpp.o
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:2065:5: warning: implicit conversion increases floating-point precision: 'float32_t' (aka 'float') to 'ggml_float' (aka 'double') [-Wdouble-promotion]
    GGML_F16_VEC_REDUCE(sumf, sum);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1166:41: note: expanded from macro 'GGML_F16_VEC_REDUCE'
    #define GGML_F16_VEC_REDUCE         GGML_F32Cx4_REDUCE
                                        ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1156:38: note: expanded from macro 'GGML_F32Cx4_REDUCE'
    #define GGML_F32Cx4_REDUCE       GGML_F32x4_REDUCE
                                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1086:11: note: expanded from macro 'GGML_F32x4_REDUCE'
    res = GGML_F32x4_REDUCE_ONE(x[0]);         \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1071:34: note: expanded from macro 'GGML_F32x4_REDUCE_ONE'
#define GGML_F32x4_REDUCE_ONE(x) vaddvq_f32(x)
                                 ^~~~~~~~~~~~~
[  4%] Built target build_info
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:2113:9: warning: implicit conversion increases floating-point precision: 'float32_t' (aka 'float') to 'ggml_float' (aka 'double') [-Wdouble-promotion]
        GGML_F16_VEC_REDUCE(sumf[k], sum[k]);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1166:41: note: expanded from macro 'GGML_F16_VEC_REDUCE'
    #define GGML_F16_VEC_REDUCE         GGML_F32Cx4_REDUCE
                                        ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1156:38: note: expanded from macro 'GGML_F32Cx4_REDUCE'
    #define GGML_F32Cx4_REDUCE       GGML_F32x4_REDUCE
                                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1086:11: note: expanded from macro 'GGML_F32x4_REDUCE'
    res = GGML_F32x4_REDUCE_ONE(x[0]);         \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml.c:1071:34: note: expanded from macro 'GGML_F32x4_REDUCE_ONE'
#define GGML_F32x4_REDUCE_ONE(x) vaddvq_f32(x)
                                 ^~~~~~~~~~~~~
[  4%] Building C object examples/gguf-hash/CMakeFiles/sha1.dir/deps/sha1/sha1.c.o
[  4%] Built target sha256
[  4%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml-alloc.c.o
[  4%] Built target sha1
[  5%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml-backend.c.o
[  6%] Building C object ggml/src/CMakeFiles/ggml.dir/ggml-quants.c.o
[  6%] Building CXX object ggml/src/CMakeFiles/ggml.dir/llamafile/sgemm.cpp.o
[  6%] Built target xxhash
[  7%] Building CXX object ggml/src/CMakeFiles/ggml.dir/ggml-qnn/backend-ops.cpp.o
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:2:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.hpp:5:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend.hpp:11:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/graph.hpp:13:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/op-config.hpp:9:
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/qnn-lib.hpp:254:47: error: no member named 'variant_npos' in namespace 'std'
        if (_backend_name.find("Htp") != std::variant_npos) {
                                         ~~~~~^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/qnn-lib.hpp:361:47: error: no member named 'variant_npos' in namespace 'std'
        if (_backend_name.find("Htp") != std::variant_npos) {
                                         ~~~~~^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/qnn-lib.hpp:412:47: error: no member named 'variant_npos' in namespace 'std'
        if (_backend_name.find("Htp") != std::variant_npos) {
                                         ~~~~~^
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:2:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.hpp:5:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend.hpp:11:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/graph.hpp:13:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/op-config.hpp:11:
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/tensor.hpp:193:41: error: implicit instantiation of undefined template 'std::array<unsigned int, 4>'
    std::array<uint32_t, GGML_MAX_DIMS> _dimensions = {};
                                        ^
/home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/__tuple:219:64: note: template is declared here
template <class _Tp, size_t _Size> struct _LIBCPP_TEMPLATE_VIS array;
                                                               ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:246:1: error: static_assert failed due to requirement 'sizeof (kGgmlOpToQnnOp) / sizeof (kGgmlOpToQnnOp[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT)' "GGML_OP_COUNT does not match the size of the kGgmlOpToQnnOp table"
static_assert(sizeof(kGgmlOpToQnnOp) / sizeof(kGgmlOpToQnnOp[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT),
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:248:1: error: static_assert failed due to requirement 'kGgmlOpToQnnOp[GGML_UNARY_OP_GELU + kGgmlUnaryOpStart] != nullptr' "GGML_UNARY_OP_GELU does not correspond to QNN_OP_GELU"
static_assert(kGgmlOpToQnnOp[GGML_UNARY_OP_GELU + kGgmlUnaryOpStart] != nullptr,
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:294:23: error: no matching function for call to 'get_qnn_graph_from_cache'
    auto *graph_ptr = get_qnn_graph_from_cache<2, 1>(ctx, _GgmlOp, { src0, src1 }, { dst });
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:252:22: note: candidate function template not viable: cannot convert initializer list argument to 'const std::array<ggml_tensor *, 2UL>'
qnn::ggml_qnn_graph *get_qnn_graph_from_cache(ggml_backend_qnn_context *ctx, size_t op,
                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:317:23: error: no matching function for call to 'get_qnn_graph_from_cache'
    auto *graph_ptr = get_qnn_graph_from_cache<1, 1>(ctx, _GgmlOp, { src }, { dst });
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:252:22: note: candidate function template not viable: cannot convert initializer list argument to 'const std::array<ggml_tensor *, 1UL>'
qnn::ggml_qnn_graph *get_qnn_graph_from_cache(ggml_backend_qnn_context *ctx, size_t op,
                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:431:1: error: static_assert failed due to requirement 'sizeof (kQnnUnaryOpsTable) / sizeof (kQnnUnaryOpsTable[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT)' "GGML_OP_COUNT does not match the size of the kQnnUnaryOpsTable table"
static_assert(sizeof(kQnnUnaryOpsTable) / sizeof(kQnnUnaryOpsTable[0]) == (GGML_OP_COUNT + GGML_UNARY_OP_COUNT),
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:519:1: error: static_assert failed due to requirement 'sizeof (kQnnBinaryOpsTable) / sizeof (kQnnBinaryOpsTable[0]) == GGML_OP_COUNT' "GGML_OP_COUNT does not match the size of the kQnnBinaryOpsTable table"
static_assert(sizeof(kQnnBinaryOpsTable) / sizeof(kQnnBinaryOpsTable[0]) == GGML_OP_COUNT,
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:2:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.hpp:5:
In file included from /home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend.hpp:4:
/home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/memory:3927:24: error: incompatible pointer types assigning to 'std::__shared_weak_count *' from 'std::__shared_ptr_emplace<qnn::ggml_qnn_tensor, std::allocator<qnn::ggml_qnn_tensor>> *'
        __r.__cntrl_ = __cntrl;
                       ^~~~~~~
/home/franzkafka/Desktop/ndk/android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/memory:4444:29: note: in instantiation of function template specialization 'std::shared_ptr<qnn::ggml_qnn_tensor>::__create_with_control_block<qnn::ggml_qnn_tensor, std::__shared_ptr_emplace<qnn::ggml_qnn_tensor, std::allocator<qnn::ggml_qnn_tensor>>>' requested here
    return shared_ptr<_Tp>::__create_with_control_block(__ptr, __hold2.release());
                            ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/graph.hpp:108:22: note: in instantiation of function template specialization 'std::make_shared<qnn::ggml_qnn_tensor, std::basic_string<char>, const QNNBackend &, void *&, std::shared_ptr<qnn::qnn_instance> &>' requested here
                std::make_shared<ggml_qnn_tensor>(std::string(buffer), _device, _graph_handle, _qnn_instance);
                     ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:312:5: error: static_assert failed due to requirement 'kGgmlOpToQnnOp[86UL] != nullptr' "GGML_OP does not have a corresponding QNN_OP"
    static_assert(kGgmlOpToQnnOp[_GgmlOp] != nullptr, "GGML_OP does not have a corresponding QNN_OP");
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:424:5: note: in instantiation of function template specialization '(anonymous namespace)::qnn_unary_op_impl<86UL>' requested here
    qnn_unary_op_impl<GGML_UNARY_OP_GELU + kGgmlUnaryOpStart>, // GGML_UNARY_OP_GELU
    ^
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:289:5: error: static_assert failed due to requirement 'kGgmlOpToQnnOp[(ggml_op)25U] != nullptr' "GGML_OP does not have a corresponding QNN_OP"
    static_assert(kGgmlOpToQnnOp[_GgmlOp] != nullptr, "GGML_OP does not have a corresponding QNN_OP");
    ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/franzkafka/Desktop/llama/llama.cpp/ggml/src/ggml-qnn/backend-ops.cpp:459:5: note: in instantiation of function template specialization '(anonymous namespace)::qnn_binary_op_impl<GGML_OP_MUL_MAT>' requested here
    qnn_binary_op_impl<GGML_OP_MUL_MAT>, // GGML_OP_MUL_MAT
    ^
13 errors generated.
make[2]: *** [ggml/src/CMakeFiles/ggml.dir/build.make:146: ggml/src/CMakeFiles/ggml.dir/ggml-qnn/backend-ops.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
2 warnings generated.
make[1]: *** [CMakeFiles/Makefile2:1603: ggml/src/CMakeFiles/ggml.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

不确定具体问题在哪里,也许是QNN SDK不对？
PS:是否可以开放仓库的issue区，相关问题我们可到你的仓库进行讨论，避免打扰其他开发者

Hi @FranzKafkaYu , 抱歉现在才回复，issue已经开了，另外你的这个问题也已经fix，这个是static assert，为了防止op增减造成内部op数组index错误故意设计的, 具体的设计可以到我的fork讨论

Hello, @chraac and @zhouwg. I wanted to thank you both for your work on this feature, just know that there are others like me that are following this closely. @AndreasKunar has mentioned this effort on his Performance of llama.cpp on Snapdragon X Elite/Plus discussion and the Support for Snapdragon X Elite NPU & GPU issue open in the ollama repo.
There is a bit of interest for those of us who want to use llama.cpp and ollama with Snapdragon X Elite, we are rooting for you!
As I was trying to see if there was anything I could do to give you a hand, I noticed that you seemed to be struggling a bit with a few things that might not be documented such as if the tensor should be freed up or if the SDK managed those resources internally, along with questions related to synchronization operations that might have made you consider waiting for technical support from Qualcomm.
How about engaging @yeonseok-zeticai? As he mentioned in the previously closed PR, he worked at Qualcomm until early this year, he has quite a bit of experience with the Qualcomm AI SDK, and he is interested in getting these things done. (Thank you @yeonseok-zeticai!)
It also appears that Andreas might have more time on October to also take a look at this. Would you like to coordinate any efforts? I know how to program in C++ but I am not as familiar with llama.cpp nor ollama as I would like to be; however, I can do my best to learn and aid, too, in any way possible.

Hi @jorge-abarca ,

Hello, @chraac and @zhouwg. I wanted to thank you both for your work on this feature, just know that there are others like me that are following this closely. @AndreasKunar has mentioned this effort on his Performance of llama.cpp on Snapdragon X Elite/Plus discussion and the Support for Snapdragon X Elite NPU & GPU issue open in the ollama repo.
There is a bit of interest for those of us who want to use llama.cpp and ollama with Snapdragon X Elite, we are rooting for you!

I'd like to start by thanking everyone for their attention to this project!
While this PR is currently inactive, I'm continuing to work on the refactoring in my own fork: chraac:dev-refactoring. If anyone is interested, please feel free to take a look and provide feedback!

As I was trying to see if there was anything I could do to give you a hand, I noticed that you seemed to be struggling a bit with a few things that might not be documented such as if the tensor should be freed up or if the SDK managed those resources internally, along with questions related to synchronization operations that might have made you consider waiting for technical support from Qualcomm.

We've made significant progress since my last comment. Here's our current status:

The ADD operator is now functional, and the test-backend-ops runs without errors for this operation.
We're currently working on implementing the MUL_MAT operation to pass the test-backend-ops. I've created a PR in my fork addressing this. Your feedback would be greatly appreciated!

How about engaging @yeonseok-zeticai? As he mentioned in the previously closed PR, he worked at Qualcomm until early this year, he has quite a bit of experience with the Qualcomm AI SDK, and he is interested in getting these things done. (Thank you @yeonseok-zeticai!)

Any assistance would be greatly appreciated! Please direct your comments and contributions to my fork: chraac:dev-refactoring

It also appears that Andreas might have more time on October to also take a look at this. Would you like to coordinate any efforts? I know how to program in C++ but I am not as familiar with llama.cpp nor ollama as I would like to be; however, I can do my best to learn and aid, too, in any way possible.

Reviewed the issue, and I'm delighted to hear that someone is interested in contributing to my fork. I'd be happy to discuss this further. Please feel free to raise issues and submit pull requests (PRs) on my fork. Your input is welcome and appreciated. Thank you!

@chraac 你好，我验证了dev-refactoring分支，使用一下命令编译
mkdir build-android && cd build-android  cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=latest -DCMAKE_C_FLAGS=-march=armv8.4a+dotprod -DGGML_QNN=ON -DGGML_QNN_SDK_PATH=$QNN_SDK_ROOT .. make -j4
编译完成后push到设备，使用llama-cli运行，发现还是使用cpu的，是因为MUL_MAT还没有实现的原因吗？
另外qnn的so如果不copy到/data/local/tmp，仍然能运行，不会报错

@chraac 你好，我验证了dev-refactoring分支，使用以下命令编译 mkdir build-android && cd build-android && cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=latest -DCMAKE_C_FLAGS=-march=armv8.4a+dotprod -DGGML_QNN=ON -DGGML_QNN_SDK_PATH=$QNN_SDK_ROOT .. && make -j4 编译完成后push到设备，使用llama-cli运行，发现还是使用cpu的，是因为MUL_MAT还没有实现的原因吗？ 另外qnn的so如果不copy到/data/local/tmp，仍然能运行，不会报错

Hi @Pateo-sunnyhuang , 你好，感谢关注，现在mat_mul的支持还没完成，这里还在进行，所以你这里提到还是用cpu的情况是正常的，另外qnn的so是通过dlopen动态加载的，如果不复制过去，那qnn backend会返回失败，这时候应该会fallback到cpu backend

Hi @Pateo-sunnyhuang , 你好，感谢关注，现在mat_mul的支持还没完成，这里还在进行，所以你这里提到还是用cpu的情况是正常的，另外qnn的so是通过dlopen动态加载的，如果不复制过去，那qnn backend会返回失败，这时候应该会fallback到cpu backend PS：Android的loader是google自己维护的，记得以前好像不会去LD_LIBRARY_PATH里面查找动态库，不知道现在改没有

感谢回复，关于推理过程我加了一些日志，发现两个问题
1. 使用cpu推理，是因为在llama_new_context_with_model方法中，ggml_backend_qnn_init没有被调用
在我推理的qwen2.5-1.5b大模型的时候，qnn model->n_gpu_layers=0, model->main_gpu=0，所以if (model->n_gpu_layers > 0)这个条件无法满足，当我去除这个条件时，发现程序运行出错，以下是console的部分日志
`
.........................................................................
llama_new_context_with_model: n_ctx      = 32768
llama_new_context_with_model: n_batch    = 2048
llama_new_context_with_model: n_ubatch   = 512
llama_new_context_with_model: flash_attn = 0
llama_new_context_with_model: freq_base  = 1000000.0
llama_new_context_with_model: freq_scale = 1
llama_new_context_with_model: qnn model->n_gpu_layers=0, model->main_gpu=0
ggml-qnn:[ggml_backend_qnn_init, 390]: ggml_backend_qnn_init(0, (null))
ggml-qnn:[ggml_backend_qnn_init, 393]: extend_lib_search_path is nullptr, will use /data/local/tmp/ as default
ggml-qnn:[ggml_backend_qnn_init, 429]: QNN-CPU backend setenv successfully
ggml-qnn:[load_system, 751]: find a valid qnn system interface
ggml-qnn:[qnn_system_interface, 10]: initialize qnn system successfully
ggml-qnn:[load_backend, 766]: lib_path:/data/local/tmp/libQnnCpu.so
ggml-qnn:[load_backend, 788]: num_providers=1
ggml-qnn:[load_backend, 801]: QNN_API_VERSION_MAJOR=2, major=2, QNN_API_VERSION_MINOR=14, minor=14,
ggml-qnn:[load_backend, 814]: find a valid qnn interface
ggml-qnn:[qnn_init, 248]: device property is not supported
ggml-qnn:[qnn_init, 299]: create QNN device successfully
ggml-qnn:[ggml_backend_qnn_init, 449]: qnn device name QNN-CPU
llama_kv_cache_init:        CPU KV buffer size =   896.00 MiB
llama_new_context_with_model: KV self size  =  896.00 MiB, K (f16):  448.00 MiB, V (f16):  448.00 MiB
llama_new_context_with_model:        CPU  output buffer size =     0.58 MiB
Segmentation fault
`
2. 希望使用npu而不是cpu/gpu进行推理
但是如上面打印的日志，传入ggml_backend_qnn_init方法的device参数是0不是2，如何才能使用NPU呢？
是否可以给出这两个问题的排查的方向或者指导。

Hi @Pateo-sunnyhuang , 你好，感谢关注，现在mat_mul的支持还没完成，这里还在进行，所以你这里提到还是用cpu的情况是正常的，另外qnn的so是通过dlopen动态加载的，如果不复制过去，那qnn backend会返回失败，这时候应该会fallback到cpu backend PS：Android的loader是google自己维护的，记得以前好像不会去LD_LIBRARY_PATH里面查找动态库，不知道现在改没有

感谢回复，关于推理过程我加了一些日志，发现两个问题 1. 使用cpu推理，是因为在llama_new_context_with_model方法中，ggml_backend_qnn_init没有被调用 在我推理的qwen2.5-1.5b大模型的时候，qnn model->n_gpu_layers=0, model->main_gpu=0，所以if (model->n_gpu_layers > 0)这个条件无法满足，当我去除这个条件时，发现程序运行出错，以下是console的部分日志 ` ......................................................................... llama_new_context_with_model: n_ctx = 32768llama_new_context_with_model：n_ctx = 32768 llama_new_context_with_model: n_batch = 2048llama_new_context_with_model：n_batch = 2048 llama_new_context_with_model: n_ubatch = 512llama_new_context_with_model：n_ubatch = 512 llama_new_context_with_model: flash_attn = 0llama_new_context_with_model：flash_attn = 0 llama_new_context_with_model: freq_base = 1000000.0llama_new_context_with_model：freq_base = 1000000.0 llama_new_context_with_model: freq_scale = 1llama_new_context_with_model：freq_scale = 1 llama_new_context_with_model: qnn model->n_gpu_layers=0, model->main_gpu=0llama_new_context_with_model：qnn model->n_gpu_layers=0， model->main_gpu=0 ggml-qnn:[ggml_backend_qnn_init, 390]: ggml_backend_qnn_init(0, (null))ggml-qnn：[ggml_backend_qnn_init， 390]： ggml_backend_qnn_init（0， （null）） ggml-qnn:[ggml_backend_qnn_init, 393]: extend_lib_search_path is nullptr, will use /data/local/tmp/ as defaultggml-qnn：[ggml_backend_qnn_init， 393]：extend_lib_search_path为 nullptr，默认使用 /data/local/tmp/ ggml-qnn:[ggml_backend_qnn_init, 429]: QNN-CPU backend setenv successfullyggml-qnn：[ggml_backend_qnn_init， 429]：QNN-CPU 后端 setenv 成功
ggml-qnn:[load_system, 751]: find a valid qnn system interfaceggml-qnn：[load_system， 751]：查找有效的 QNN 系统接口
ggml-qnn:[qnn_system_interface, 10]: initialize qnn system successfullyggml-qnn：[qnn_system_interface， 10]： 初始化 QNN 系统成功
ggml-qnn:[load_backend, 766]: lib_path:/data/local/tmp/libQnnCpu.soggml-qnn：[load_backend， 766]： lib_path：/data/local/tmp/libQnnCpu.so
ggml-qnn:[load_backend, 788]: num_providers=1ggml-qnn：[load_backend， 788]： num_providers=1
ggml-qnn:[load_backend, 801]: QNN_API_VERSION_MAJOR=2, major=2, QNN_API_VERSION_MINOR=14, minor=14,GGML-QNN：[load_backend， 801]： QNN_API_VERSION_MAJOR=2， 主要=2， QNN_API_VERSION_MINOR=14， 次要=14，
ggml-qnn:[load_backend, 814]: find a valid qnn interfaceGGGML-qnn：[load_backend， 814]： 查找有效的 QNN 接口
ggml-qnn:[qnn_init, 248]: device property is not supportedggml-qnn：[qnn_init， 248]：不支持 device 属性
ggml-qnn:[qnn_init, 299]: create QNN device successfullyggml-qnn：[qnn_init， 299]： 成功创建 QNN 设备
ggml-qnn:[ggml_backend_qnn_init, 449]: qnn device name QNN-CPUggml-qnn：[ggml_backend_qnn_init， 449]：qnn 设备名称 QNN-CPU llama_kv_cache_init: CPU KV buffer size = 896.00 MiBllama_kv_cache_init：CPU KV 缓冲区大小 = 896.00 MiB llama_new_context_with_model: KV self size = 896.00 MiB, K (f16): 448.00 MiB, V (f16): 448.00 MiBllama_new_context_with_model：KV 自身大小 = 896.00 MiB，K （f16）：448.00 MiB，V （f16）：448.00 MiB llama_new_context_with_model: CPU output buffer size = 0.58 MiBllama_new_context_with_model：CPU 输出缓冲区大小 = 0.58 MiB Segmentation fault 分段错误 ` 2. 希望使用npu而不是cpu/gpu进行推理 但是如上面打印的日志，传入ggml_backend_qnn_init方法的device参数是0不是2，如何才能使用NPU呢？
是否可以给出这两个问题的排查的方向或者指导。 另外，ggml_backend_registry_init中的代码似乎没走到，这里的qnn代码有什么作用。

Hi @Pateo-sunnyhuang , 你好，感谢关注，现在mat_mul的支持还没完成，这里还在进行，所以你这里提到还是用cpu的情况是正常的，另外qnn的so是通过dlopen动态加载的，如果不复制过去，那qnn backend会返回失败，这时候应该会fallback到cpu backend PS：Android的loader是google自己维护的，记得以前好像不会去LD_LIBRARY_PATH里面查找动态库，不知道现在改没有

感谢回复，关于推理过程我加了一些日志，发现两个问题 1. 使用cpu推理，是因为在llama_new_context_with_model方法中，ggml_backend_qnn_init没有被调用 在我推理的qwen2.5-1.5b大模型的时候，qnn model->n_gpu_layers=0, model->main_gpu=0，所以if (model->n_gpu_layers > 0)这个条件无法满足，当我去除这个条件时，发现程序运行出错，以下是console的部分日志 ` ......................................................................... llama_new_context_with_model: n_ctx = 32768 llama_new_context_with_model: n_batch = 2048 llama_new_context_with_model: n_ubatch = 512 llama_new_context_with_model: flash_attn = 0 llama_new_context_with_model: freq_base = 1000000.0 llama_new_context_with_model: freq_scale = 1 llama_new_context_with_model: qnn model->n_gpu_layers=0, model->main_gpu=0 ggml-qnn:[ggml_backend_qnn_init, 390]: ggml_backend_qnn_init(0, (null)) ggml-qnn:[ggml_backend_qnn_init, 393]: extend_lib_search_path is nullptr, will use /data/local/tmp/ as default ggml-qnn:[ggml_backend_qnn_init, 429]: QNN-CPU backend setenv successfully
ggml-qnn:[load_system, 751]: find a valid qnn system interface
ggml-qnn:[qnn_system_interface, 10]: initialize qnn system successfully
ggml-qnn:[load_backend, 766]: lib_path:/data/local/tmp/libQnnCpu.so
ggml-qnn:[load_backend, 788]: num_providers=1
ggml-qnn:[load_backend, 801]: QNN_API_VERSION_MAJOR=2, major=2, QNN_API_VERSION_MINOR=14, minor=14,
ggml-qnn:[load_backend, 814]: find a valid qnn interface
ggml-qnn:[qnn_init, 248]: device property is not supported
ggml-qnn:[qnn_init, 299]: create QNN device successfully
ggml-qnn:[ggml_backend_qnn_init, 449]: qnn device name QNN-CPU llama_kv_cache_init: CPU KV buffer size = 896.00 MiB llama_new_context_with_model: KV self size = 896.00 MiB, K (f16): 448.00 MiB, V (f16): 448.00 MiB llama_new_context_with_model: CPU output buffer size = 0.58 MiB Segmentation fault ` 2. 希望使用npu而不是cpu/gpu进行推理 但是如上面打印的日志，传入ggml_backend_qnn_init方法的device参数是0不是2，如何才能使用NPU呢？
是否可以给出这两个问题的排查的方向或者指导。 另外，ggml_backend_registry_init中的代码似乎没走到，这里的qnn代码有什么作用。

llama-cli 有参数选择使用deviceid， 参数是 -mg，  可以设置为2

Hi @Pateo-sunnyhuang , 你好，感谢关注，现在mat_mul的支持还没完成，这里还在进行，所以你这里提到还是用cpu的情况是正常的，另外qnn的so是通过dlopen动态加载的，如果不复制过去，那qnn backend会返回失败，这时候应该会fallback到cpu backend PS：Android的loader是google自己维护的，记得以前好像不会去LD_LIBRARY_PATH里面查找动态库，不知道现在改没有

感谢回复，关于推理过程我加了一些日志，发现两个问题 1. 使用cpu推理，是因为在llama_new_context_with_model方法中，ggml_backend_qnn_init没有被调用 在我推理的qwen2.5-1.5b大模型的时候，qnn model->n_gpu_layers=0, model->main_gpu=0，所以if (model->n_gpu_layers > 0)这个条件无法满足，当我去除这个条件时，发现程序运行出错，以下是console的部分日志 ` ......................................................................... llama_new_context_with_model: n_ctx = 32768 llama_new_context_with_model: n_batch = 2048 llama_new_context_with_model: n_ubatch = 512 llama_new_context_with_model: flash_attn = 0 llama_new_context_with_model: freq_base = 1000000.0 llama_new_context_with_model: freq_scale = 1 llama_new_context_with_model: qnn model->n_gpu_layers=0, model->main_gpu=0 ggml-qnn:[ggml_backend_qnn_init, 390]: ggml_backend_qnn_init(0, (null)) ggml-qnn:[ggml_backend_qnn_init, 393]: extend_lib_search_path is nullptr, will use /data/local/tmp/ as default ggml-qnn:[ggml_backend_qnn_init, 429]: QNN-CPU backend setenv successfully
ggml-qnn:[load_system, 751]: find a valid qnn system interface
ggml-qnn:[qnn_system_interface, 10]: initialize qnn system successfully
ggml-qnn:[load_backend, 766]: lib_path:/data/local/tmp/libQnnCpu.so
ggml-qnn:[load_backend, 788]: num_providers=1
ggml-qnn:[load_backend, 801]: QNN_API_VERSION_MAJOR=2, major=2, QNN_API_VERSION_MINOR=14, minor=14,
ggml-qnn:[load_backend, 814]: find a valid qnn interface
ggml-qnn:[qnn_init, 248]: device property is not supported
ggml-qnn:[qnn_init, 299]: create QNN device successfully
ggml-qnn:[ggml_backend_qnn_init, 449]: qnn device name QNN-CPU llama_kv_cache_init: CPU KV buffer size = 896.00 MiB llama_new_context_with_model: KV self size = 896.00 MiB, K (f16): 448.00 MiB, V (f16): 448.00 MiB llama_new_context_with_model: CPU output buffer size = 0.58 MiB Segmentation fault ` 2. 希望使用npu而不是cpu/gpu进行推理 但是如上面打印的日志，传入ggml_backend_qnn_init方法的device参数是0不是2，如何才能使用NPU呢？
是否可以给出这两个问题的排查的方向或者指导。 另外，ggml_backend_registry_init中的代码似乎没走到，这里的qnn代码有什么作用。

Hi，你好！不好意思，最近比较忙，回复比较慢：
针对第一点这个情况，upstream的backend registry最近一直在重构，所以这里一直有变动，我也在根据新的接口适配，具体可以看upstream的这个project：https://github.com/users/ggerganov/projects/12
第二点这个，现在我主要精力还是集中在让 mat_mul 能通过 test-backend-ops 测试，这个test其实和llama-cli一样也是通过registry创建的backend，所以用法应该和test-backend-ops一致，具体可以参考 @scguang301 的comment
另外如果关注 mat_mul 支持的进度，可以看我的fork的这个PR

authors: FranzKafkaYu Pateo-sunnyhuang chraac jorge-abarca myan-o scguang301 zhouwg


text:
What does FaceState mean?

Great work!
Can you elaborate what does State means here?
@unique
class FaceState(Enum):
Init = 0
State1 = 1
State2 = 2
State3 = 3
State4 = 4

@akhil-faceintel sry didn't maintain this repo for a long time.

Init: default state
State1: a 'FaceFeature' object without embedding
State2: a 'FaceFeature' object with embedding, images not saved
State3: all ready to send by kafka
State4: a finished face

Thanks for explaining the states @zhouyuchong.
I have another question regarding user_meta information. Can you please explain how you add obj_user_meta_list information in obj_meta.
What does tensor_meta has to get the face embeddings?

Thanks for the explanation @zhouyuchong.

authors: akhil-faceintel zhouyuchong

repo: zhouyuchong/face-recognition-deepstream


text:
block luncher Pro and free will not open it crash's a sec into it then crashs

running mcpe 1.9.0 latest block luncher trued beta and normal Fran Samsung galaxy Tab a 2016 android 8.1 and it crash's 2GB ram 8 core processor multi touch screen 16 by 8 screen 1920x1540 screen

a crash report a found not sure it's related
Time: 2018_05_16_09_45_16
Phone :SM-T350
Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.media.MediaPlayer.isPlaying()' on a null object reference
at com.ijoysoft.videoplayer.activity.VideoPlayActivity.onClick(Unknown Source)
at android.view.View.performClick(View.java:6308)
at android.view.View$PerformClick.run(View.java:23969)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6823)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1563)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1451)

repo: zhuowei/MCPELauncher


text:
laravel 扩展报错

\Zhuzhichao\IpLocationZh\Ip::find('110.223.0.43')
返回一个
[ErrorException]
strpos(): Empty needle

谢谢反馈，v2.2.3 已经修复了该问题。请更新一下版本。

authors: mrchenzifan zhuzhichao

repo: zhuzhichao/ip-location-zh


text:
编译失败

添加这个就报错

额，电脑没安装git？我可能还要去再改一改没有安装git场景。。。

把FluentUI中的.git文件夹删掉再试试

出现这种情况可能是第一次git初始化没有commit。或者将FluentUI中的.git文件夹删掉再尝试。

删掉了.git文件

编译过的工程，如果升级后再编译，删掉build文件夹可能也不行，需要重新克隆一份。这样试试。原因还请大家和作者指教。


text:
merge dreambooth and styledrop

Is this module included in the code? I can't seem to find it.

No, I didn't do that, I just use style adapter, no object adapter (But, the implementation is same)

authors: Laidawang zideliu

repo: zideliu/StyleDrop-PyTorch


text:
Implement a simple compilation to X64 ELF files

A currently working compilation to ELF files (targetting the amd64 instruction set) has been implemented. The compilation only works for currently supported instructions: mov and ret.
The ELF file is not meant to be executed directly, and must be linked with various object files like ctr1.o, ctri.o, crtbegin.o, crtend.o and crtn.o. Those are needed in order to initialise the C runtime.
What has been done:

Implement a library to generate ELF files easily. This can be found here.
Implement the codegen from N* to machine code.
Run the codegen from the typed AST returned by the typechecker, and write the generated ELF file to test.o.

Has to be investigated:

I don't know if the whole compiler just takes too much RAM, or if only the ELF generation does. Some profiling needs to be done to highly reduce the memory footprint (which is at about 200 MB right now, for a program as simple as true in Bash).
There are big holes in the codegen at the moment, mostly because we only try to support a minimalistic subset of the basic instruction set.
We might want later on to be able to generate executable ELF files when a _start function is present.

#13 can now be closed at least for now.

Quick update, even though the PR has already been merged.
It seems like nsc does in fact not consume much. I was trying (using time -v) to measure the memory consumed...mostly by stack when running stack exec -- nsc .... Running .stack-work/install/.../.../bin/nsc ... yields about 9MB of RAM used, which I think is still too much for what it does, but is really far better than over 200MB of RAM.

repo: zilch-lang/nsc


text:
auttu client session shared by users

Describe the bug:
When 2 users login the same attu site. One logout, another user sees the error that the connection is gone. Seems the backend cannot tell the different client connection by the session Id.
Version
v2.2.3

hey, are there any updates to this? Otherwise is it possible to include in the docs with a warning that the session is shared.
Currently, users with no admin access are able to view Milvus with admin permissions if someone logs in using admin credentials in the same attu.

hey, are there any updates to this? Otherwise is it possible to include in the docs with a warning that the session is shared.
Currently, users with no admin access are able to view Milvus with admin permissions if someone logs in using admin credentials in the same attu.

Would you like to contribute for this feature?

authors: DennisZhao168 shanghaikid zirota

repo: zilliztech/attu


text:
Only count skipped not duplicates mutations towards the total count

Duplicated mutations should not change the mutation score, and should therefore not counts towards the total count of mutations.

Coverage increased (+0.05%) to 77.158% when pulling 7ccb9f338c866c1eb4920f512f5d8ae05af39382 on only-count-skipped-not-duplicates-towards-total into adf20bc564b300dfab117edd95f56d12a8a0c81b on master.

authors: coveralls zimmski

repo: zimmski/go-mutesting


text:
Query widgets with FetchPolicy.cacheOnly don't update if contents initially not in cache

Describe the bug
If you create a Query widget with FetchPolicy.cacheOnly and that widget renders before the cache is populated with the corresponding key, the widget does not ever rerender. This does not occur when the value is already in the cache when the widget first renders.
To Reproduce
Steps to reproduce the behavior:

Create a Query widget with FetchPolicy.noCache
After the initial render of the Query widget (e.g. in initState), call client.query with the same QueryOptions

Expected behavior
The Query widget with FetchPolicy.cacheOnly should re-render whenever the cache is updated, regardless of whether the contents were in the cache at initial render.
Additional context
I think this may be related to #290.

Do you mean "Create a Query widget with ~FetchPolicy.noCach~ FetchPolicy.cacheOnly"?
I think this is probably because I'm throwing an exception if cacheOnly yields nothing, which:

prevents any kind of results from being placed on the stream blocking render
prevents query lifecycle from being updated

If I'm right, adding an optimisticResult with an OptimisticCache would be a viable workaround for now

@micimize Oops, sorry about the typo. I will try out the workaround!

I think I'm wrong, to some extent - the Exception gets caught and transformed into a GraphQLError

I think this is probably fixed in 4.0.0-beta.1 given the rebroadcasting rework. If @yunyu or anyone else still has this issue on v4 comment and I'll reopen

authors: micimize yunyu

repo: zino-app/graphql-flutter