Define collector component and remove global references

What does this PR do?
This PR defines the component interface for the collector and uses it where applicable. The implementation will be moved into comp/collector in a followup PR.
This PR also removes all global usage of the collector.
You may choose to review this PR in 2 parts:

Define and use the component interface https://github.com/DataDog/datadog-agent/pull/22533/commits/79447a95d7446cf03a64b3abfadfbb3379bb8c1a
Remove global references to the collector https://github.com/DataDog/datadog-agent/pull/22533/commits/9617492055035a6b4e134c694e85bc9f19ce7767

This PR also clarifies the conditions where it is expected to have a nil collector vs a non-nil collector by using Optional in the relevant places (such as subcommands)

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Test the agent diagnose command still works and runs check diagnosis
Test that core checks still work
Test that python checks still work
Test JMX subcommand still works
Test agent gui subcommand still works
Test agent status and the collector section still shows up

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge

/merge -c

/merge


sapience: side quest rng bugged

DR: https://www.youtube.com/watch?v=NuXn-rX5Hgs

And the quest with the chest in Sadism Village still couldn't be completed, the npc just keep repeating his line with the laugh. (djigallag / dmitriy)

it's still bugged

confirmed by keshafilm, it works when not quicksaving/quickloading


[release/3.2.x] [CHERRY PICK] Add gfx950 target definition

This PR brings in required LLVM bumps and additional targets for gfx950 support.

https://github.com/triton-lang/triton/pull/5040
https://github.com/triton-lang/triton/pull/5064
https://github.com/triton-lang/triton/pull/5180
https://github.com/triton-lang/triton/pull/5242
https://github.com/triton-lang/triton/pull/5392

Reverts:

#5347
#5191

@atalman, @bertmaher


Improve theme preference discoverability and behaviour

Fix #34

default to light theme
update webview on config change
add a command to update the theme
add a button to switch theme in the editor menu

https://user-images.githubusercontent.com/17577332/164325072-83be61cc-f2cd-4acf-9412-d15b3914cd4d.mp4

Looks good!
Can we remove https://github.com/excalidraw/excalidraw-vscode/pull/37/files#diff-0e96fc4c0e4b663545725cc50af120099cb873ea9e3f16eee74d074e39be13feR53-R59 ?

Looks good!
Can we remove https://github.com/excalidraw/excalidraw-vscode/pull/37/files#diff-0e96fc4c0e4b663545725cc50af120099cb873ea9e3f16eee74d074e39be13feR53-R59 ?

Not sure of what you are talking about, the github redirection is not very explicit.

Sorry, It thought it was a permalink: https://github.com/excalidraw/excalidraw-vscode/blob/c357605e73dbc020cc1c4742a6229373582c9505/extension/package.json#L53-L59


fixed missing word in CONTRIBUTING.md

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "patch-2" git@github.com:YannRobert/distribution.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

This will update the existing PR, so DO NOT open a new one.

LGTM!


Configuration cache should report problems on configuration-time usages of APIs which mutate the file system

While the goal of configuration cache is to simulate the behavior of a build that had a configuration phase, it might be hard to impossible to also simulate the configuration phase side effects on the file system in builds running from the cache. Builds should normally move the side effects to the execution phase.
Gradle should report configuration cache problems on using the APIs that mutate the file system, as it does not aim to replicate that when running the build from cache.
Some of the APIs, beside mutating the file system, also return a value representing the result, which the configuration logic may use. This is also problematic because such an input depends not just on the state of the file system (which can be compared to the snapshot) but on the result of running a mutating operation. For example, renaming a file may fail (and return false) on numerous reasons, so caching its false value would require replicating the attempt and ensuring that it still fails (but it may now fail for another reason!).
The known examples of such APIs are:
In java.io.File:

[ ] mkdir
[ ] mkdirs
[ ] delete
[ ] renameTo

Groovy extensions for File (in ResourceGroovyMethods):

[ ] deleteDir

In Kotlin Standard Library:

[ ] File.deleteRecursively

For the record: we could imagine an alternative involving recording of the sequence of the mutating operations and "replaying" them when the build runs from the configuration cache. There are several problems with this approach:

If some external changes in the file system changed the state of the file system in a way that the mutating operations would behave differently, we would anyway have to run a full configuration phase, as the results returned from the mutating operations would be different.

If the operations were performed partially at that point, we would have to somehow revert them.
Or we would have to check if all the results would be the same before trying to replicate the operations.

The operations themselves might be cross-interfering, and checking if they would behave the same would require a model of the file system.

Overall, replicating side effects seem not to go well with the design of configuration cache, so doing that is not the approach that looks feasible as of now.


License update - Use secure url

Coverage remained the same at 100.0% when pulling 52d9df52654d2811afc2c5da9a0a838c0fd15cfb on hazendaz:license-update into 85a28585710db1457422a1b35a3dc9bb07920b76 on mybatis:master.


Custom CSS font size

In the how to page of the docs, it has an example for updating font size:
html {
  --font-size: 0.75rem;
  --font-size-sm: 0.7rem;
  --font-size-lg: 0.9rem;
}

but it doesn't seem to have any effect. The CSS variables are not overridden.
I had to change it to:
:root {
  --font-size: 0.75rem;
  --font-size-sm: 0.7rem;
  --font-size-lg: 0.9rem;
}

to make it work although I am not sure what other implications this change may bring to other parts of the app.

:root should be correct, updated the docs.


Share Take-aways and learnings from Agile Unconference

Description
After attending the Agile Open Canada 2024 Unconference, Kavi will share her takeaways with Jess about what she learned.
Acceptance Criteria

[ ] A document/template of choice is prepared to demonstrate the learnings

[ ] If a document is created, then share with her

[ ] Not to take longer than a couple hours
[ ] Set up a meeting with Jess in her calendar

[ ] Update the meeting with an agenda to help keep meeting on track

[ ] Create a GH ticket
[ ] Update the ticket with content

Dependencies
Blocked by:

[ ] Attending the event

Definition of Ready

[ ] Acceptance criteria are included
[ ] Wireframes are included (if applicable)
[ ] Design / Solution is accepted by Product Owner (if applicable)
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done
In progress

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] UI meets accessibility requirements
[ ] Unit tests are written
[ ] Work is traceable in GitHub
[ ] PR linked to ticket number
[ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to

PO Review

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Reviewed and approved by Product Owner

@JLWade  I updated the ticket with content and it is ready to be reviewed by you - if everything seems fine, I can move it to "in progress" after.

perfect! thanks Kavi!

great presentation - moving to done


Configure istio ingress to replace nginx ingress

Details
Implement istio to allow ingress to the cluster and eventually phase out using nginx ingress. Some caveats may be oauth2 and keycloak integration not readily available in istio natively and may require further investigation - might run istio on a subdomain as a proof of concept before migrating completely across.

#74 Adds istio-operator and initial istio 1.6.5 deployment into the GitOps workflow, however, is not a full migration as of yet.

One possible alternative to run oauth2 is using https://github.com/istio-ecosystem/authservice If this doesn't work a EnvoyFilter can be created, however, would require custom LUA scripting as described in the following article: https://medium.com/plangrid-technology/custom-user-authentication-in-istio-67c90458b093

https://istio.io/latest/blog/2019/app-identity-and-access-adapter/

Completed - Currently using Istio + DEX + oauth2-proxy.


Send store.finalized block hash to EL

Explicitly states that store's finalized checkpoint must be used to obtain finalized_block_hash that is sent to EL. Apparently, all CL clients are already following this logic.
@hwwhww we would need to create tests checking that store.finalized used instead of head_state.finalized to obtain finalized_block_hash. These values can't diverge according to current specification, as tips with finalized checkpoint not matching to the store's one are filtered out and not eligible for the head. Not sure if we can implement such tests without changing the fork choice spec.

@mkalinin

we would need to create tests checking that store.finalized used instead of head_state.finalized to obtain finalized_block_hash. These values can't diverge according to current specification, as tips with finalized checkpoint not matching to the store's one are filtered out and not eligible for the head. Not sure if we can implement such tests without changing the fork choice spec.

To provide test vectors, we need a new test format to mock notify_forkchoice_updated. I think it may be something like #2639 proposed, but probably in a simpler form. What do you think?

I pushed basic unit tests (https://github.com/ethereum/consensus-specs/pull/3105/commits/270d930a22305db451adc93390f053b565f2341a) to verify code logic of this PR.

To provide test vectors, we need a new test format to mock notify_forkchoice_updated. I think it may be something like #2639 proposed, but probably in a simpler form. What do you think?

Do you think that by mocking notify_forkchoice_updated we can bypass the requirement of store.finalized and  head_state.finalized to diverge? Or you think this requirement is not needed to be satisfied to write tests covering proposed change?


Ability to append a LiPD object

After the object has been created, add more datasets through the load function . Right now, overwrites existing dataset.

The current behaviour is to add more datasets. Could you show an example where it overwrites ?

Got it from the latest push.


feat(frontend): [WIP] frontend iota tangle connection example

🍰 Pullrequest
iota library is connected in the frontend.
I call the test node client from iota that @einhornimmond also uses.
the data is retrieved ...
https://github.com/gradido/gradido/assets/1324583/dd72774a-76bf-47fd-b47b-8bafda92fb57

Integration of

{ converter } from<EMAIL_ADDRESS>{ Bip32Path, Bip39, Blake2b } from<EMAIL_ADDRESS>https://github.com/gradido/gradido/assets/1324583/ddb95f51-4274-4377-8e19-36a09867a933

Creating an iota address:
public and private key

https://github.com/gradido/gradido/assets/1324583/e7b5ac73-cd30-42d4-9675-e1eabb047db9


[#957] feat(tez): Tez examples integration test

What changes were proposed in this pull request?
Add integration test for tez
Why are the changes needed?
To construct tez test pipeline, we need integration test.
How was this patch tested?
integration test.

This PR is not ready to review. The integration test will fail until some issue is solved.
These issue are below:

to add...

Codecov Report

Merging #982 (351dea9) into master (1159271) will increase coverage by 1.19%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #982      +/-   ##
============================================
+ Coverage     53.44%   54.63%   +1.19%
  Complexity     2513     2513
============================================
  Files           376      356      -20
  Lines         20521    18161    -2360
  Branches       1764     1764
============================================
- Hits          10967     9922    -1045
+ Misses         8866     7621    -1245
+ Partials        688      618      -70

see 21 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


KAFKA-725: Return OffsetOutOfRange error from ReplicaManager when non-follower attempts reading an offset that's above high watermark.

This should make Log.read act the same when startOffset is larger than maxOffset as it would if startOffset was larger than logEndOffset. The current behavior can result in an IllegalArgumentException from LogSegment if a consumer attempts to fetch an offset above the high watermark which is present in the leader's log. It seems more correct if Log.read presents the view of the log to consumers as if it simply ended at maxOffset (high watermark).
I've tried to describe an example scenario of this happening here https://issues.apache.org/jira/browse/KAFKA-725?focusedCommentId=15221673&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15221673
I'm not sure I understand why ReplicaManager sets maxOffset to the high watermark, and not high watermark + 1. Isn't the high watermark the last committed message, and readable by consumers?
Tests passed for me locally on second try, seems like it just hit a flaky test.

Took another look, I think I misunderstood the high watermark. It's the first offset past the most recently committed offset, not the most recently committed offset. I've reverted the changes except throwing OffsetOutOfRange when requesting a message past maxOffset.

@becketqin The check has been moved to ReplicaManager.readFromLocalLog.

Test passed locally, failure seems unrelated

Thanks for the patch! And the failures have been fixed in a previous commit. LGTM except a minor comment about unit test cleaning.

@guozhangwang Yes, it passed on first try this time :) I moved the common properties out of the test methods.

LGTM! Merged to trunk.

How can i  resolve this problem before redeploy kafka cluster. Thank you.


Bug fix: Add matching case for unmarshalling nil uuid column

Schemagen generates structs as [16]byte for uuid and timeuuid columns.
when a time/uuid column has nil value, the switch case will not match with *[]byte and returns the following error:
can not unmarshal X timeuuid into *[16]uint8
to solve this we can change Schemagen, or add the case here. personally I belive changing Schemagen has more cost and mapping UUIDs to [16]byte is better than mapping to []byte.

@sylwiaszunejko @dkropachev
I'm sorry for mentioning you, since this is causing a lot of problems for us, I wanted to get your opinion on it sooner.
Thanks.

@sylwiaszunejko @dkropachev I'm sorry for mentioning you, since this is causing a lot of problems for us, I wanted to get your opinion on it sooner. Thanks.

@izenhaim , thanks for you contribution, my bad we have not picked it up yearlier.

Glad to be of help!
will you release a version as well?

We should have a test for it (to all marshaling cases, I assume)

We should have a test for it (to all marshaling cases, I assume)

https://github.com/scylladb/gocql/issues/237

Glad to be of help! will you release a version as well?

Releasing it take a one week, meanwhile you can use fixed version as the following:
replace github.com/gocql/gocql => github.com/scylladb/gocql v1.14.3-0.20240820095829-00277be38708


Failed to spawn the python child process: The system cannot find the file specified.

Still not able to provide a minimal reproducer, but I'm putting this here in case it helps other folks.
I'm trying to replace pip with uv pip on my CI and I've been mostly successful, with the exception on Windows. There I'm getting an error like this:
> pytest tests
(uv internal error) Failed to spawn the python child process: The system cannot find the file specified.

this is despite pytest being present, as can be seen with a uv pip freeze right before.
See https://github.com/kedro-org/kedro-plugins/actions/runs/8052616036/job/21993159176 for an example of this.
The way I fixed it is by replacing pytest with python -m pytest.
I added a type ${Python_ROOT_DIR}\\Scripts\\pytest to understand what's there, see https://github.com/kedro-org/kedro-plugins/actions/runs/8053504403/job/21996069725?pr=569
I'm using uv==0.1.11, released minutes ago.
I'm unfamiliar with how scripts are created on Windows, is uv doing anything special here?

I think the issue is related to https://github.com/astral-sh/uv/issues/1779
The VIRTUAL_ENV=<global_python> hack doesn't work on Windows because the Python executable is in a different location than what's expected by uv. We're working on a proper support for global installation.
For now, you can work around it by creating a virtual env instead of pointing VIRTUAL_ENV to the global python path.

I'm still getting this error with the newest version of uv.

Do you mean 0.1.11 or the main branch?

Do you mean 0.1.11 or the main branch?

yes

Do you mean 0.1.11 or the main branch?

0.1.11

Charlie's changes have not been released yet. Please create a new issue if you're still experience issues with the new version that we release soon and include more details: What commands did you run? What's your operating system? What package do you use, etc.


Create dependency from multicontact library

In GitLab by @proyan on Jan 31, 2019, 13:33
I propose to create a dependency with the multicontact library available here https://gepgitlab.laas.fr/loco-3d/multicontact-api. This will enable us to use the same contactphase definition that is being used for the centroidal problem.

In GitLab by @proyan on Jan 31, 2019, 13:43
Although one problem would be that the package is still using Pinocchio1.0
Could you please let us know if you are moving the package to Pinocchio2.0 @jcarpent

In GitLab by @proyan on Jan 31, 2019, 13:54
Never mind. It was just a namespace issue. Solved via https://gepgitlab.laas.fr/loco-3d/multicontact-api/merge_requests/1

In GitLab by @proyan on Jan 31, 2019, 13:54
closed

In GitLab by @proyan on Jan 31, 2019, 14:39
reopened

In GitLab by @nmansard on Feb 1, 2019, 09:47
Excellent, I plus it.

In GitLab by @cmastalli on Feb 2, 2019, 08:10
I'm not sure about it. It's like asking to include a package for kkt dynamics.
In contrast, contact phase definition isn't bit deal to do it. Adding dependencies that aren't strictly necessary isn't good software practice.
You might want to explain why it's needed this, rather than having our internal definitions.

In GitLab by @nmansard on Feb 2, 2019, 11:16
I agree we should discuss it. The MCAPI is there to represent locomotion problem. It is now the standard API for loco3d problems (contact planning, centroidal optimization). It is only an API with a simple struct to store the sequence of contact, nothing bad. And it will be needed to connect with TimeOpt that we need to do.
We might have it as a conditional dependency that is very simple to do in python:
try: import multicontact_api
assert: print('You don't have multicontact_api, install it with apt get ...'
:)

In GitLab by @proyan on Feb 4, 2019, 13:38
I'll close this issue. Thanks for the discussion.

In GitLab by @proyan on Feb 4, 2019, 13:38
closed


Adding autoload file in composer.json messes up Font Icons and voyager-loader image

Version information

Laravel: v7.22.4
Voyager: v1.4.2
PHP: 7.2
Database: Mysql 14.14

Description
Adding autoload file in composer.json messes up Font Icons and voyager-loader image
Steps To Reproduce
Steps to reproduce the behavior:

Add helpers file under autoload in composer.json
 "autoload": {      "psr-4": {          "App\\": "app/"      },      "classmap": [          "database/seeds",          "database/factories"      ],     "files": [          "app/helpers.php     ]  },
Successfully run composer dump-autoload. No errors.
Refresh admin page. All menu icons and voyager-loader icon not loading. Fonts could not be loaded properly.

Expected behavior
Additional autoload files should not affect asset paths.

I cannot think of  a reason why autoload would interfere with loading assets unless you have something in your helpers file that conflicts with Voyager helpers.
Try removing everything from your helpers file, if that does not work try with:

Create new Laravel project
Install Voyager
Change composer and add an empy helpers file

Can you still reproduce the problem with these steps?

Closed for inactivity


Load search parameters doesn't clear parameters

I picked up your latest changes from Issue #9 fixes, but I don't think they fixed the issue I was seeing. Here are some screenshots of the search box after I assigned new values to it. This shows the old boxes weren't cleared out. (Example: Author)

Hm, strange. Could you please step through the code here: https://github.com/dnauck/angular-advanced-searchbox/blob/master/src/angular-advanced-searchbox.js#L55
What does it do in your case?


[Enh]: Pass through the Arrow PyCapsule Interface

We would like to learn about your use case. For example, if this feature is needed  to adopt Narwhals in an open source project, could you please enter the link to it below?
The Arrow PyCapsule Protocol makes it possible to share Arrow data between libraries without requiring a dependency on pyarrow. Many of the DataFrame libraries that narwhals wraps already support it (See https://github.com/apache/arrow/issues/39195 for ecosystem summary), so my thinking is that it wouldn't be too much work to support the protocol on the Narwhals DataFrame itself.
Please describe the purpose of the new feature or describe the problem to solve.
Vega-Altair recently adopted Narwhals as a way to support polars without a pyarrow dependency, and I'm looking at how I could do the same in VegaFusion. The next VegaFusion release is going to support ingesting DataFrames that support the PyCapsule Interface (WIP by @kylebarron in https://github.com/vega/vegafusion/pull/501), so it would be nice to be able to pass the Narwhals DataFrame directly to VegaFusion and process it using this protocol.
Suggest a solution if possible.
No response
If you have tried alternatives, please describe them below.
No response
Additional information that may help us understand your needs.
No response

thanks @jonmmease for the request! yup, definitely interested in this!

Done, thanks for the suggestion! This should allow you to support older versions of pandas/Polars which didn't yet support the interface but which did support converting to PyArrow. So, PyArrow is only used as a fallback: if the library supports the PyCapsule Interface natively without requiring PyArrow, then that will be used directly 😇

Awesome, thanks for the remarkably fast turnaround on this!


Vendor saltpack

Notable changes:

Hardcodes field order for encryption, so that fixes to the codec
library won't change it.
Make receiver shuffling unbiased, even on go <1.10.
Bump CurrentVersion to Version2 (although keybase already always uses
Version2).

Done! Here's my script:
Encryption:
(With Keybase.app running...)
> rm /tmp/*.saltpack
> keybase version
Client:  1.0.45-20180320080023+a0ec69f18a
Service: 1.0.45-20180320080023+a0ec69f18a
> keybase encrypt -m "pre-vendor message" -o /tmp/pre-vendor.saltpack oconnor663

(Quit Keybase.app.)
> pwd
/Users/akalin-keybase/go/src/github.com/keybase/client/go
> go install ./keybase
> env KEYBASE_RUN_MODE=prod ~/go/bin/keybase service start &

(Restart Keybase.app to get kbfs back up; existing service process isn't replaced.)
> env KEYBASE_RUN_MODE=prod ~/go/bin/keybase version
Client:  1.0.45
Service: 1.0.45
> env KEYBASE_RUN_MODE=prod ~/go/bin/keybase encrypt -m "post-vendor message" -o /tmp/post-vendor.saltpack oconnor663

Decryption:
> env KEYBASE_RUN_MODE=prod ~/go/bin/keybase decrypt -i /tmp/pre-vendor.saltpack
Message authored by akalin
pre-vendor message⏎

(Quit Keybase.app, kill service process, and restart Keybase.app.)
> keybase version
Client:  1.0.45-20180320080023+a0ec69f18a
Service: 1.0.45-20180320080023+a0ec69f18a
> keybase decrypt -i /tmp/post-vendor.saltpack
Message authored by akalin
post-vendor message⏎


Convert from scrolling to flipping

Have the text for one page along with previous/next buttons rather than scrolling. All chapters must start on a new page.

Have the text for one page along with previous/next buttons rather than scrolling. All chapters must start on a new page.

https://stackoverflow.com/questions/3403789/work-out-how-many-characters-can-fit-into-div-with-javascript


Debugging question (quick)

I get the following report from gdb but everything seems good, Is it a file permissions issue?
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
sleep_until (t=)
at /home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/common/pico_time/time.c:398
398	/home/earle/Arduino/hardware/pico/rp2040/pico-sdk/src/common/pico_time/time.c: No such file or directory.
As you know, however, from my browser the file exists.

It looks like you're trying to debug a program that was built on someone elses PC.

Unfortunately color in the terminal doesn't copy over to the issues page and color has meaning. In this case the color was green and I agree with you, I think it's a link to Earle's github repository.
BTW by any chance do you know of any /dev/ttyACM0 contention issues using picoprobe (cmsis-dap) for upload and debugging? I think I'm seeing one. Upload via serial-monitor opens /dev/ttyACM0 and after the upload performs a commanded reset init resulting in a halt. When debug starts, it can't get the /dev/ttyACM0 resource I think because the upload thread still owns the device.

I'm not sure what you're asking, but picoprobe is designed to use SWD for programming and debugging, not UART. /dev/ttyACM0 is the Linux-side driver of the USB-UART connection exposed by picoprobe, see Chapter 4 and Appendix A of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf and is used to see the output from the printf functions in your code.
If you've got questions about the Arduino environment, I'm afraid the Raspberry Pi GitHub repos aren't the right place to be asking those.

I thank you for your advice and understand your position. I have read the pdf and complied with the instructions. My model says that there are two serial paths and that SWD is the second serial path (between 2 picos) and that has to go through the USB-UART connection to get there. I know it sounds like an arduino-ide problem but there is a software chain openocd, serial-monitor, cortex-debug and gdb that actually does the work. That suite is board specific. In that chain there IS a contention issue between the serial monitor with the verify/UPLOAD process taking access first and then the debug process getting locked out of the serial resource. I've been redirected here with the explanation that the board vendor may have code for openocd to work with their boards (pico-tools).
I just duplicated the problem in 2 terminals
T1:
$ !1984
openocd -s /home/penta/.arduino15/packages/rp2040/hardware/rp2040/3.6.2/lib/ -f picoprobe_cmsis_dap.tcl
Open On-Chip Debugger 0.12.0-g4d87f6d (2023-11-27-12:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E661640843626C27
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
T2:
openocd -s /home/penta/.arduino15/packages/rp2040/hardware/rp2040/3.6.2/lib/ -f picoprobe_cmsis_dap.tcl
Open On-Chip Debugger 0.12.0-g4d87f6d (2023-11-27-12:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Error: couldn't bind tcl to socket on port 6666: Address already in use
What did I expect? A shared resource not exclusive access.
I appreciate your help. I hope I've clarified the issue.

I still think you're misunderstanding things - picoprobe offers multiple USB endpoints over just the one USB cable https://github.com/raspberrypi/picoprobe/blob/master/src/usb_descriptors.c#L132
The CMSIS-DAP endpoints bridge to the SWD connection on the picoprobe, and this is what you talk to with openocd.
The CDC-ACM endpoint bridges to the UART connection on the picoprobe, and this is what appears as /dev/ttyACM0 on Linux, which you talk to with minicom.
So I would indeed expect that trying to run two copies of openocd at the same time will fail.

Please ask questions in the forum https://forums.raspberrypi.com/viewforum.php?f=145


Add the cubed-sphere domain decomposition

Once the Grid, Projection and MeshGenerator classes have been added for the Cubed-Sphere grid it will be necessary to add the domain decomposition.

This has been done for cell centers

This was done for cell-centered grid.

@danholdaway, @MarekWlasak can this issue be closed now?

It will work also for the nodes of the dual of the cubed-sphere mesh.  So far, unless LFRic changes its mind to give us horizontally staggered winds we are all done.  I think that there may be some more work for fv3 as I think that the winds are staggered, but I am not sure.  First fv3 needs to create its own atlas projection to utilize what we have done.  @danholdaway what do you think about this? There may be some extra tuning of the cubed-sphere decomposition for when we need to link it to LFRic's tangent linear model, but that will happen in a few month's time.

So in summary I think it should be closed (for now)


Implement new CI trigger to alleviate API rate issues

To be filled in later...

TESTNOW

TESTNOW

TESTNOW

TESTNOW

TESTNOW

TESTNOW

"ci" failure was an internal Jenkins issue.  Rerunning with TESTNOW.

TESTNOW


Cannot send less than 1 credit via Send Credits screen

The Issue
If you enter 0.9, an address and click send, nothing happens.
System Configuration

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

This is still broken.

Not happening anymore - most likely a snackbar issue.


Update postCreateCommand

The original command had a couple issues:

It's pwsh not powershell
You need to use -c to specify a script in PowerShell
since $PSVersionTable is not escaped, bash will first evaluate it (which will evaluate it to empty string).

Also echo is more of a bash-ism so I took that out.
I do want to ask a greater question... Is there a reason the CMD in the container isn't used for the postCreateCommand?

I do want to ask a greater question... Is there a reason the CMD in the container isn't used for the postCreateCommand?

@TylerLeonhardt The CMD in many customer created containers will start up the application they will actually be developing which is not desirable during development.  As a result, the container is started with sleep infinity - though you can set "overrideCommand":false to disable this behavior when needed.  In either case,  postCreateCommand is an exec on the existing container for this reason and uses the default shell as a result.

Thanks for the context @Chuxel!


ci: Increase number of build slaves to 7

Since builds have drastically increased in time, we end up timing out CI
if we have a larger number of tests to build.  Try bumping up the number
of slaves to 7 and see if that helps.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

I do not think this is a good idea, this will  limit PR that can run at the same time. The PRs that timeout because of changes to boards and samples will continue to be a problem and they are the minority, I guess we need a better strategy for those instead of 7 minions for each PR.


Fix possible ring broken

/* cmd_id could be different in async case */
if (cmd->cmd_id != ent->hdr.cmd_id) {
ent->hdr.cmd_id = cmd->cmd_id;
}
There is no place changing and shouldn't change the cmd_id, or
this could cause the ring broken.
The old code changing the entry's cmd_id is to deal with the
async type IOs. Which will always update the first entry from the
tail, but the first entry from the tail maybe not belonged
to the current cmd, so it in order to simplify the code here just
used a trick.
If the runner has bug like handle the completion more than once,
the TCMU will find cmd_id in idr more than once too, the ring
should be flaged as broken.
Maybe there has other bugs could cause the ring broken too.

I am not sure what the bug is.
Are you saying the bug is that runner/userspace will complete a command twice. The first completion will free up the cmd_id in the kernel and later completions will hit the kernel broken code because cmd_id is not found?
If that is the bug, I did not get how these patches fix a double completion. Could you give me a little more details on how that is happening?
If that is the bug, and these patches are just meant to guard against that type of bug, then I understand the patchset.

/* cmd_id could be different in async case */
-	if (cmd->cmd_id != ent->hdr.cmd_id) {
-		ent->hdr.cmd_id = cmd->cmd_id;

These code were changing the entries' cmd_id here, this will happen when the second or later cmds completed faster and early than the first one from the  ring tail.
Multiple completions will change the entries in tail more than once too.

I'm not very sure wether there have other bugs or issues like multi completions could cause the broken because of these code.

The broken case1:
_____________
|   entry0 CMD0  |  <----- cmd_tail<-mb
||
|   entry1 CMD1  |
||
|   entry2 CMD2  |
|_____________|
For example, when the CMD0 will take 5s to complete, and the CMD2 just takes about 0.5s. The CMD0, CMD1 and CMD2 are all handled async.
Then the entry0->cmd_id = cmd2, and the at this time the entry2->cmd_id = cmd2 too.
If just after the CMD2 is completed and UPDATE the mb->cmd_tail and also complete the se_cmd in kernel. And then the runner crash or rebooted manually, what will happen ?
After the runner is restarted and it will begin to handle the ring from entry1 in tail, when the CMD2 is handled again, in kernel the cmd in idr has already gone. Which will lead the ring broken.

The following code still has other problem:
/* cmd_id could be different in async case */
-	if (cmd->cmd_id != ent->hdr.cmd_id) {
-		ent->hdr.cmd_id = cmd->cmd_id;

Such as:
____________
|   entry0 CMD0   |  -> data Page0 ->cmd_id = cmd0                 <----- cmd_tail<-mb
|------------------|
|   entry1 CMD1  |  -> data Page1 ->cmd_id = cmd1
|------------------|
|   entry2 CMD2  |  -> data Page2  ->cmd_id = cmd2
|------------------|
For example, when the CMD0 and CMD1 will take 5s to complete, and the CMD2 just takes about 0.5s. The CMD0, CMD1 and CMD2 are all handled in async already.
After 0.5s, the CMD2 is completed and then the entry0->cmd_id = cmd2, and in kernel the CMD0->data Page0 will be released, but the runner's tcmulib_cmd0 will be still referencing to Page0 . What will happen when Page0 is allocated to other new CMDs, for example CMD3.
That's to say tcmulib_cmd0->data and CMD3->data are sharing the same Page0 memory.
  ____________
 |   entry0 CMD1   |  -> data Page1 ->cmd_id = cmd1                 <----- cmd_tail<-mb
 |------------------|
 |   entry1 CMD2  |  -> data Page2 ->cmd_id = cmd2
 |------------------|
 |   entry2 CMD3  |  -> data Page0  ->cmd_id = cmd3
 |------------------|

 tcmulib_cmd0->data Page0

Due to lack of threading on github, let's take the issues separately.
For the second data page issue, did you mean entry memory instead?
I am not sure how we will hit a issue with the data page if data page means pages in the tcmu_cmd->dbi to page mapping. The kernel will be passed cmd_id cmd2. tcmu_handle_completions will do a idr_remove(cmd2) and get the kernel tcmu_cmd for cmd2. That tcmu_cmd's dbi will point to data page 2, so it will be freed.
I maybe can see how we can hit the issue for the entry memory though. On the completion side, we are serialized by the tcmur_device->lock in tcmur_command_complete . But is there a race with the completion path and  tcmulib_get_next_command?
Could tcmulib_command_complete be setting cmd_id
        /* cmd_id could be different in async case */
        if (cmd->cmd_id != ent->hdr.cmd_id) {
                ent->hdr.cmd_id = cmd->cmd_id;
        }

while tcmulib_get_next_command is still accessing an entry at the same place in the mb ring. For the current code and your patch do we need to grab the  tcmur_device->lock when calling tcmulib_get_next_command?

For the first restart problem, I got you and I see how the patch fixes the problem.
For restart though, do we want to be processing commands sitting in the ring when runner starts up? For HA, I do not think we do, because runner might start up minutes or hours later and new commands could have executed through other paths. If we start executing old commands from the ring we might overwrite new data.
If we did a tape device we definitely do not want to, but we can ignore that for now since no one is doing tape.
For normal old non-HA and disks I am not sure. It would depend on the implementation.
Is the restart case the only time we know we will hit the issue? If so, let's just fix restartup completely. I think we would want to add some code to invalidate the ring. The kernel would fail the commands if they have not already timed out. The initiator side scsi and transport, and if used multipth layers, then handle retrying if needed or just dropping if it already did so. We then do not have to guess about if the command is retryable or what the user wanted. We just rely on how they configured the initiator side.

For the multi completions case:
For restart though, do we want to be processing commands sitting
in the ring when runner starts up?

IMO, yes, we could support dynamic upgrading for tcmu-runner without stopping the IOs, and the restart will only just 1~3 seconds.
 For HA, I do not think we do, because runner might start up minutes or hours later and new commands could have executed through other paths. If we start executing old commands from the ring we might overwrite new data.

Yes, for HA case, I agree with you. But we need one way to drop or discard the old SCSI cmds in ring.
For this I think we could add one kflags when the SCSI cmds in ring are timedout, then when the runner read the SCSI cmds it will try to check the timeout kflags, if it's set, just skip it with updating the ring tail. While if the cmd_time_out = 0, we could create and fire one check thread in kernel when userspace is opening it, if the ring has old entries which are more than 30s old, we also could set the timeout kflags as above.
For normal old non-HA and disks I am not sure. It would depend on the implementation.

Yes, for non-HA case, I think we could also just create and fire one check thread as above.
Is the restart case the only time we know we will hit the issue?

For now, the restart is the only one I can make sure that it will hit.
 I think we would want to add some code to invalidate the ring.

Yes, agree and some thing as I said above.

For the data PageX case, sorry for confused.
As we can see that the struct entr{} is:
struct tcmu_cmd_entry      {
    struct tcmu_cmd_entry_hdr hdr;

    union {
            struct {
                    __u32 iov_cnt;
                    __u32 iov_bidi_cnt;
                    __u32 iov_dif_cnt;
                    __u64 cdb_off;
                    __u64 __pad1;
                    __u64 __pad2;
                    struct iovec iov[0];
            } req;
            struct {
                    __u8 scsi_status;
                    __u8 __pad1;
                    __u16 __pad2;
                    __u32 __pad3;
                    char sense_buffer[TCMU_SENSE_BUFFERSIZE];
            } rsp;
    };

} __packed;

For the data PageX case, sorry for confused:
As we can see the entry struct:

Sorry for clicking the close button by mistake, reopen it again.

For the get_next_command race you are right. It should not happen.

tcmu/runner restart, we have 2 cases: clean restart and restart after a crash.

clean restart should be easy. We can add a configfs file that indicates all new IO should be failed with SAM_STAT_BUSY to have the initiator side retry. Userspace then fails IO in the ring with the same code, and waits on outstanding IO and exits when complete. On restart it unsets the file, and IO starts again like normal.

For crash based restart, I think you want the same configfs file. On restart if there are commands in the ring, set the configfs file to make sure new IOs are not coming in, loop over the ring and fail all commands with the same code as #1. If the command timed out in the kernel, it is just dropped by tcmu already. If the command had not timedout, tcmu returns the command to lio. If the iscsi session has dropped or the SCSI EH code is running, the the command is dropped or the abort/reset code decides what to do based on that state. If the session is up and the SCSI EH has not run, then the command is retried by the initiator. When runner has looped over the ring unset the configfs file to allow new IO.

@mikechristie
Sorry for late, just came back from my business travel.
For the 3 and 4 sound nice and agree.
These should be another new issue apart from this one, it's about supporting the runner restarting without stopping the service.
And let's fix it in another PR ?
Thanks,

@mikechristie
How about this PR ? These days we have reproduced this bug twice based the 693 kernel and nick's target kernel.
Nov 10 15:43:45 sds-3-94 kernel: ring broken, not handling completions
Nov 10 15:43:45 sds-3-94 kernel: cmd_id not found, ring is broken

For the configfs we discussed above, I will add them later in another PRs, but not now, because we are busy to do the test about the tcmu and iscsi gateway.
@zhuozh will paste the bug's reproduce step later.
Thanks,

@mikechristie Hi, how is this PR going?
I am testing HA with gateway tools,
If tcmu-runner is pkilled and restarted, It will run into the ring buffer broken issue.(iscsi_trx is stucked in transport_generic_free_cmd) , initiator retry login also fails.
I'd like to post the log here:

[root@sds-3-94 rpmbuild]# ps -aux |grep iscsi
root     445286  0.0  0.0      0     0 ?        S    15:11   0:00 [iscsi_np]
root     445287  0.0  0.0      0     0 ?        S    15:11   0:01 [iscsi_np]
root     447348  0.3  0.0      0     0 ?        D    15:22   0:04 [iscsi_trx]
root     452207  0.0  0.0 112648   976 pts/1    S+   15:49   0:00 grep --color=auto iscsi
[root@sds-3-94 rpmbuild]# cat /proc/447348/stack
[] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
[] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
[] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
[] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
[] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0xffffffffffffffff
[root@sds-3-94 rpmbuild]# cat /proc/447348/stack
[] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
[] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
[] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
[] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
[] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0xffffffffffffffff
[root@sds-3-94 rpmbuild]# cat /proc/447348/stack
[] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
[] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
[] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
[] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
[] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0xffffffffffffffff
[root@sds-3-94 rpmbuild]# cat /proc/447348/stack
[] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
[] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
[] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
[] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
[] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0xffffffffffffffff
[root@sds-3-94 rpmbuild]# journalctl -r
-- Logs begin at Tue 2017-11-07 12:48:09 CST, end at Fri 2017-11-10 15:49:53 CST. --
Nov 10 15:49:53 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:53 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:53 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:53 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:49:38 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:38 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:38 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:38 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:49:23 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:23 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:23 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:23 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:49:08 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:08 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:08 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:08 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:53 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:53 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:53 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:53 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:38 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:38 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:38 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:38 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:23 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:23 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:23 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:23 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:07 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:07 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:07 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:07 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:52 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:52 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:52 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:52 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:37 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:37 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:37 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:37 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:22 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:22 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:22 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:22 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:07 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:07 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:07 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:07 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:46:52 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:46:52 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:46:52 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:46:52 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:46:37 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:46:37] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:46:37 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:46:37] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:46:36 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:46:36] "GET /api/config HTTP/1.1" 200 -
Nov 10 15:46:09 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:46:09 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:46:09 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:46:09 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:52 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:52 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:52 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:52 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:35 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:35 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:35 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:35 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:18 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:18 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:18 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:18 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:01 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:01 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:01 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:01 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:45 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:45] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:45 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:45] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:44 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:44] "GET /api/config HTTP/1.1" 200 -
Nov 10 15:44:44 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:44:44 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:44:44 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:44:44 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:44:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:44:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:44:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:44:32 sds-3-94 kernel:  [] ? manage_workers.isra.24+0x2a0/0x2a0
Nov 10 15:44:32 sds-3-94 kernel:  [] worker_thread+0x126/0x3c0
Nov 10 15:44:32 sds-3-94 kernel:  [] process_one_work+0x17a/0x440
Nov 10 15:45:01 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:01 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:01 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:45 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:45] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:45 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:45] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:44 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:44] "GET /api/config HTTP/1.1" 200 -
Nov 10 15:44:44 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:44:44 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:44:44 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:44:44 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:44:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
-- Logs begin at Tue 2017-11-07 12:48:09 CST, end at Fri 2017-11-10 15:49:53 CST. --
Nov 10 15:49:53 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:53 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:53 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:53 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:49:38 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:38 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:38 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:38 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:49:23 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:23 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:23 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:23 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:49:08 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:49:08 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:49:08 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:49:08 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:53 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:53 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:53 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:53 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:38 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:38 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:38 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:38 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:23 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:23 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:23 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:23 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:48:07 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:48:07 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:48:07 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:48:07 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:52 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:52 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:52 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:52 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:37 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:37 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:37 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:37 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:22 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:22 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:22 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:22 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:47:07 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:47:07 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:47:07 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:47:07 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:46:52 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:46:52 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:46:52 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:46:52 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:46:37 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:46:37] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:46:37 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:46:37] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:46:36 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:46:36] "GET /api/config HTTP/1.1" 200 -
Nov 10 15:46:09 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:46:09 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:46:09 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:46:09 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:52 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:52 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:52 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:52 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:35 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:35 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:35 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:35 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:18 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:18 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:18 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:18 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:45:01 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:45:01 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:45:01 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:45:01 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:45 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:45] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:45 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:45] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:44 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:44] "GET /api/config HTTP/1.1" 200 -
Nov 10 15:44:44 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:44:44 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:44:44 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:44:44 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:44:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:44:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:44:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:44:32 sds-3-94 kernel:  [] ? manage_workers.isra.24+0x2a0/0x2a0
Nov 10 15:44:32 sds-3-94 kernel:  [] worker_thread+0x126/0x3c0
Nov 10 15:44:32 sds-3-94 kernel:  [] process_one_work+0x17a/0x440
Nov 10 15:44:32 sds-3-94 kernel:  [] ? iscsi_target_restore_sock_callbacks+0xc0/0xc0 [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel:  [] iscsi_target_do_login_rx+0x270/0x380 [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel:  [] iscsi_target_do_login+0x315/0x600 [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel:  [] iscsi_target_check_for_existing_instances+0x35/0x40 [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel:  [] iscsi_check_for_session_reinstatement+0x213/0x280 [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel:  [] iscsit_stop_session+0x1c8/0x1e0 [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:44:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:44:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:44:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:44:32 sds-3-94 kernel: Call Trace:
Nov 10 15:44:32 sds-3-94 kernel:  7fffffffffffffff ffff880076460560 ffff88103ccf8fd0<PHONE_NUMBER>000000
Nov 10 15:44:32 sds-3-94 kernel:  ffff88103bb1ffd8 ffff88103bb1ffd8 ffff88103ccf8fd0 ffff880076460568
Nov 10 15:44:32 sds-3-94 kernel:  ffff88103bb1fb40<PHONE_NUMBER>000046 ffff88103ccf8fd0 ffff88103bb1ffd8
Nov 10 15:44:32 sds-3-94 kernel: Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
Nov 10 15:44:32 sds-3-94 kernel: kworker/21:1    D<PHONE_NUMBER>000000     0   440      2 0x00000000
Nov 10 15:44:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:44:32 sds-3-94 kernel: INFO: task kworker/21:1:440 blocked for more than 120 seconds.
Nov 10 15:44:27 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:44:27 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:44:27 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:44:27 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:10 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:44:10 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:44:10 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:44:10 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:44:05 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:05] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:05 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:05] "GET /api/_ping HTTP/1.1" 200 -
Nov 10 15:44:04 sds-3-94 rbd-target-api[445134]: <IP_ADDRESS> - - [10/Nov/2017 15:44:04] "GET /api/config HTTP/1.1" 200 -
Nov 10 15:43:45 sds-3-94 polkitd[57937]: Unregistered Authentication Agent for unix-process:451342:26973820 (system bus name :1.587, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF
Nov 10 15:43:45 sds-3-94 systemd[1]: Started LIO Userspace-passthrough daemon.
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: 2017-11-10 15:43:45.606 451348 [WARN] tcmu_rbd_detect_device_class:247 rbd/rbd.block0: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: tcmu_rbd_detect_device_class:247 rbd/rbd.block0: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: 2017-11-10 15:43:45.592 451348 [WARN] tcmu_rbd_detect_device_class:247 rbd/rbd.block5: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: tcmu_rbd_detect_device_class:247 rbd/rbd.block5: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: 2017-11-10 15:43:45.576 451348 [WARN] tcmu_rbd_detect_device_class:247 rbd/rbd.block4: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: tcmu_rbd_detect_device_class:247 rbd/rbd.block4: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: 2017-11-10 15:43:45.560 451348 [WARN] tcmu_rbd_detect_device_class:247 rbd/rbd.block3: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: tcmu_rbd_detect_device_class:247 rbd/rbd.block3: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: 2017-11-10 15:43:45.546 451348 [WARN] tcmu_rbd_detect_device_class:247 rbd/rbd.block2: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: tcmu_rbd_detect_device_class:247 rbd/rbd.block2: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 kernel: ring broken, not handling completions
Nov 10 15:43:45 sds-3-94 kernel: cmd_id not found, ring is broken
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: 2017-11-10 15:43:45.527 451348 [WARN] tcmu_rbd_detect_device_class:247 rbd/rbd.block1: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 tcmu-runner[451348]: tcmu_rbd_detect_device_class:247 rbd/rbd.block1: Could not locate crush rule key
Nov 10 15:43:45 sds-3-94 kernel: tcmu daemon: command reply support 1.
Nov 10 15:43:45 sds-3-94 systemd[1]: Starting LIO Userspace-passthrough daemon...
Nov 10 15:43:45 sds-3-94 polkitd[57937]: Registered Authentication Agent for unix-process:451342:26973820 (system bus name :1.587 [/usr/bin/pkttyagent --notify-fd 7 --fallback], object path /org/freedesktop/Pol
Nov 10 15:43:29 sds-3-94 polkitd[57937]: Unregistered Authentication Agent for unix-process:451329:26972265 (system bus name :1.586, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF
Nov 10 15:43:29 sds-3-94 polkitd[57937]: Registered Authentication Agent for unix-process:451329:26972265 (system bus name :1.586 [/usr/bin/pkttyagent --notify-fd 7 --fallback], object path /org/freedesktop/Pol
Nov 10 15:43:23 sds-3-94 systemd[1]: tcmu-runner.service failed.
Nov 10 15:43:23 sds-3-94 systemd[1]: Unit tcmu-runner.service entered failed state.
Nov 10 15:43:23 sds-3-94 systemd[1]: Stopped LIO Userspace-passthrough daemon.
Nov 10 15:43:23 sds-3-94 systemd[1]: tcmu-runner.service: main process exited, code=killed, status=9/KILL
Nov 10 15:43:23 sds-3-94 systemd[1]: tcmu-runner.service stop-sigterm timed out. Killing.
Nov 10 15:43:11 sds-3-94 polkitd[57937]: Unregistered Authentication Agent for unix-process:451316:26969893 (system bus name :1.585, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF
Nov 10 15:43:06 sds-3-94 polkitd[57937]: Registered Authentication Agent for unix-process:451316:26969893 (system bus name :1.585 [/usr/bin/pkttyagent --notify-fd 7 --fallback], object path /org/freedesktop/Pol
Nov 10 15:43:04 sds-3-94 polkitd[57937]: Unregistered Authentication Agent for unix-process:451310:26969608 (system bus name :1.584, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF
Nov 10 15:43:03 sds-3-94 polkitd[57937]: Registered Authentication Agent for unix-process:451310:26969608 (system bus name :1.584 [/usr/bin/pkttyagent --notify-fd 7 --fallback], object path /org/freedesktop/Pol
Nov 10 15:43:02 sds-3-94 polkitd[57937]: Unregistered Authentication Agent for unix-process:451302:26966254 (system bus name :1.583, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF
Nov 10 15:42:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:42:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] ? do_exit+0x6bb/0xa40
Nov 10 15:42:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:42:32 sds-3-94 kernel:  [] ? iscsi_target_tx_thread+0x230/0x230 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:42:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:42:32 sds-3-94 kernel:  [] ? __schedule+0x39d/0x8b0
Nov 10 15:42:32 sds-3-94 kernel:  [] ? finish_task_switch+0x12c/0x160
Nov 10 15:42:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:42:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:42:32 sds-3-94 kernel: Call Trace:
Nov 10 15:42:32 sds-3-94 kernel:  7fffffffffffffff ffff880eba326770 ffff881f24ff0fd0<PHONE_NUMBER>000001
Nov 10 15:42:32 sds-3-94 kernel:  ffff882028a0ffd8 ffff882028a0ffd8 ffff881f24ff0fd0 ffff880eba326778
Nov 10 15:42:32 sds-3-94 kernel:  ffff882028a0fc80<PHONE_NUMBER>000046 ffff881f24ff0fd0 ffff882028a0ffd8
Nov 10 15:42:32 sds-3-94 kernel: iscsi_trx       D<PHONE_NUMBER>000001     0 447348      2 0x00000080
Nov 10 15:42:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:42:32 sds-3-94 kernel: INFO: task iscsi_trx:447348 blocked for more than 120 seconds.
Nov 10 15:42:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:42:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:42:32 sds-3-94 kernel:  [] ? manage_workers.isra.24+0x2a0/0x2a0
Nov 10 15:42:32 sds-3-94 kernel:  [] worker_thread+0x126/0x3c0
Nov 10 15:42:32 sds-3-94 kernel:  [] process_one_work+0x17a/0x440
Nov 10 15:42:32 sds-3-94 kernel:  [] target_tmr_work+0x12a/0x140 [target_core_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] core_tmr_abort_task+0x10e/0x190 [target_core_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] transport_wait_for_tasks+0x53/0x90 [target_core_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] __transport_wait_for_tasks+0xbc/0x1d0 [target_core_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:42:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:42:32 sds-3-94 kernel:  [] ? console_unlock+0x265/0x4b0
Nov 10 15:42:32 sds-3-94 kernel:  [] ? wake_up_klogd+0x32/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] ? irq_work_queue+0x63/0x80
Nov 10 15:42:32 sds-3-94 kernel:  [] ? msg_print_text+0xea/0x1d0
Nov 10 15:42:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:42:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:42:32 sds-3-94 kernel: Call Trace:
Nov 10 15:42:32 sds-3-94 kernel:  7fffffffffffffff ffff880eba3267f8 ffff880035c88fd0 ffff880f46158050
Nov 10 15:42:32 sds-3-94 kernel:  ffff88103ca83fd8 ffff88103ca83fd8 ffff880035c88fd0 ffff880eba326800
Nov 10 15:42:32 sds-3-94 kernel:  ffff88103ca83bf0<PHONE_NUMBER>000046 ffff880035c88fd0 ffff88103ca83fd8
Nov 10 15:42:32 sds-3-94 kernel: Workqueue: tmr-user target_tmr_work [target_core_mod]
Nov 10 15:42:32 sds-3-94 kernel: kworker/u65:5   D ffff880f46158050     0   552      2 0x00000000
Nov 10 15:42:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:42:32 sds-3-94 kernel: INFO: task kworker/u65:5:552 blocked for more than 120 seconds.
Nov 10 15:42:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:42:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:42:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:42:32 sds-3-94 kernel:  [] ? manage_workers.isra.24+0x2a0/0x2a0
Nov 10 15:42:32 sds-3-94 kernel:  [] worker_thread+0x126/0x3c0
Nov 10 15:42:32 sds-3-94 kernel:  [] process_one_work+0x17a/0x440
Nov 10 15:42:32 sds-3-94 kernel:  [] ? iscsi_target_restore_sock_callbacks+0xc0/0xc0 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsi_target_do_login_rx+0x270/0x380 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsi_target_do_login+0x315/0x600 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsi_target_check_for_existing_instances+0x35/0x40 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsi_check_for_session_reinstatement+0x213/0x280 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] iscsit_stop_session+0x1c8/0x1e0 [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:42:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:42:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:42:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:42:32 sds-3-94 kernel: Call Trace:
Nov 10 15:42:32 sds-3-94 kernel:  7fffffffffffffff ffff880076460560 ffff88103ccf8fd0<PHONE_NUMBER>000000
Nov 10 15:42:32 sds-3-94 kernel:  ffff88103bb1ffd8 ffff88103bb1ffd8 ffff88103ccf8fd0 ffff880076460568
Nov 10 15:42:32 sds-3-94 kernel:  ffff88103bb1fb40<PHONE_NUMBER>000046 ffff88103ccf8fd0 ffff88103bb1ffd8
Nov 10 15:42:32 sds-3-94 kernel: Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
Nov 10 15:42:32 sds-3-94 kernel: kworker/21:1    D<PHONE_NUMBER>000000     0   440      2 0x00000000
Nov 10 15:42:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:42:32 sds-3-94 kernel: INFO: task kworker/21:1:440 blocked for more than 120 seconds.
Nov 10 15:42:29 sds-3-94 polkitd[57937]: Registered Authentication Agent for unix-process:451302:26966254 (system bus name :1.583 [/usr/bin/pkttyagent --notify-fd 7 --fallback], object path /org/freedesktop/Pol
Nov 10 15:42:11 sds-3-94 polkitd[57937]: Unregistered Authentication Agent for unix-process:451289:26962628 (system bus name :1.582, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF
Nov 10 15:41:53 sds-3-94 systemd[1]: Stopping LIO Userspace-passthrough daemon...
Nov 10 15:41:53 sds-3-94 polkitd[57937]: Registered Authentication Agent for unix-process:451289:26962628 (system bus name :1.582 [/usr/bin/pkttyagent --notify-fd 7 --fallback], object path /org/freedesktop/Pol
Nov 10 15:41:14 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:41:14 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:41:14 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:41:14 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:40:57 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:40:57 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:40:57 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:40:57 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:40:40 sds-3-94 kernel: iSCSI Login negotiation failed.
Nov 10 15:40:40 sds-3-94 kernel: tx_data returned -32, expecting 48.
Nov 10 15:40:40 sds-3-94 kernel: Unexpected ret: -104 send data 48
Nov 10 15:40:40 sds-3-94 kernel: iSCSI Login timeout on Network Portal <IP_ADDRESS>:3260
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] ? do_exit+0x6bb/0xa40
Nov 10 15:40:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:40:32 sds-3-94 kernel:  [] ? iscsi_target_tx_thread+0x230/0x230 [iscsi_target_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:40:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:40:32 sds-3-94 kernel:  [] ? __schedule+0x39d/0x8b0
Nov 10 15:40:32 sds-3-94 kernel:  [] ? finish_task_switch+0x12c/0x160
Nov 10 15:40:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:40:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:40:32 sds-3-94 kernel: Call Trace:
Nov 10 15:40:32 sds-3-94 kernel:  7fffffffffffffff ffff880eba326770 ffff881f24ff0fd0<PHONE_NUMBER>000001
Nov 10 15:40:32 sds-3-94 kernel:  ffff882028a0ffd8 ffff882028a0ffd8 ffff881f24ff0fd0 ffff880eba326778
Nov 10 15:40:32 sds-3-94 kernel:  ffff882028a0fc80<PHONE_NUMBER>000046 ffff881f24ff0fd0 ffff882028a0ffd8
Nov 10 15:40:32 sds-3-94 kernel: iscsi_trx       D<PHONE_NUMBER>000001     0 447348      2 0x00000080
Nov 10 15:40:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:40:32 sds-3-94 kernel: INFO: task iscsi_trx:447348 blocked for more than 120 seconds.
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:40:32 sds-3-94 kernel:  [] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:40:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:40:32 sds-3-94 kernel:  [] ? __schedule+0x39d/0x8b0
Nov 10 15:40:32 sds-3-94 kernel:  [] ? finish_task_switch+0x12c/0x160
Nov 10 15:40:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:40:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:40:32 sds-3-94 kernel: Call Trace:
Nov 10 15:40:32 sds-3-94 kernel:  7fffffffffffffff ffff880eba326770 ffff881f24ff0fd0<PHONE_NUMBER>000001
Nov 10 15:40:32 sds-3-94 kernel:  ffff882028a0ffd8 ffff882028a0ffd8 ffff881f24ff0fd0 ffff880eba326778
Nov 10 15:40:32 sds-3-94 kernel:  ffff882028a0fc80<PHONE_NUMBER>000046 ffff881f24ff0fd0 ffff882028a0ffd8
Nov 10 15:40:32 sds-3-94 kernel: iscsi_trx       D<PHONE_NUMBER>000001     0 447348      2 0x00000080
Nov 10 15:40:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:40:32 sds-3-94 kernel: INFO: task iscsi_trx:447348 blocked for more than 120 seconds.
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] kthread+0xcf/0xe0
Nov 10 15:40:32 sds-3-94 kernel:  [] ? manage_workers.isra.24+0x2a0/0x2a0
Nov 10 15:40:32 sds-3-94 kernel:  [] worker_thread+0x126/0x3c0
Nov 10 15:40:32 sds-3-94 kernel:  [] process_one_work+0x17a/0x440
Nov 10 15:40:32 sds-3-94 kernel:  [] target_tmr_work+0x12a/0x140 [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] core_tmr_abort_task+0x10e/0x190 [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] transport_wait_for_tasks+0x53/0x90 [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] __transport_wait_for_tasks+0xbc/0x1d0 [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel:  [] ? wake_up_state+0x20/0x20
Nov 10 15:40:32 sds-3-94 kernel:  [] wait_for_completion+0xfd/0x140
Nov 10 15:40:32 sds-3-94 kernel:  [] ? console_unlock+0x265/0x4b0
Nov 10 15:40:32 sds-3-94 kernel:  [] ? wake_up_klogd+0x32/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] ? irq_work_queue+0x63/0x80
Nov 10 15:40:32 sds-3-94 kernel:  [] ? msg_print_text+0xea/0x1d0
Nov 10 15:40:32 sds-3-94 kernel:  [] schedule_timeout+0x239/0x2c0
Nov 10 15:40:32 sds-3-94 kernel:  [] schedule+0x29/0x70
Nov 10 15:40:32 sds-3-94 kernel: Call Trace:
Nov 10 15:40:32 sds-3-94 kernel:  7fffffffffffffff ffff880eba3267f8 ffff880035c88fd0 ffff880f46158050
Nov 10 15:40:32 sds-3-94 kernel:  ffff88103ca83fd8 ffff88103ca83fd8 ffff880035c88fd0 ffff880eba326800
Nov 10 15:40:32 sds-3-94 kernel:  ffff88103ca83bf0<PHONE_NUMBER>000046 ffff880035c88fd0 ffff88103ca83fd8
Nov 10 15:40:32 sds-3-94 kernel: Workqueue: tmr-user target_tmr_work [target_core_mod]
Nov 10 15:40:32 sds-3-94 kernel: kworker/u65:5   D ffff880f46158050     0   552      2 0x00000000
Nov 10 15:40:32 sds-3-94 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Nov 10 15:40:32 sds-3-94 kernel: INFO: task kworker/u65:5:552 blocked for more than 120 seconds.
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
Nov 10 15:40:32 sds-3-94 kernel:  [] ret_from_fork+0x58/0x90
Nov 10 15:40:32 sds-3-94 kernel:  [] ? insert_kthread_work+0x40/0x40
[root@sds-3-94 rpmbuild]# cat /proc/447348/stack
[] transport_generic_free_cmd+0xa2/0x160 [target_core_mod]
[] iscsit_free_cmd+0x82/0x140 [iscsi_target_mod]
[] iscsit_close_connection+0x4c6/0x8a0 [iscsi_target_mod]
[] iscsit_take_action_for_connection_exit+0x8b/0x120 [iscsi_target_mod]
[] iscsi_target_rx_thread+0xe3/0xf0 [iscsi_target_mod]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0xffffffffffffffff
[root@sds-3-94 rpmbuild]#

I think this was fixed with the reset ring feature. Closing for now.


Width not divisible by two error on timelapse

I get this error from ffmpeg on generating a timelapse with my asi224mc as it has an odd number of pixels. There are a number of possible fixes, see: https://stackoverflow.com/questions/60788967/ffmpeg-width-not-divisible-by-2-375x500-error In my case I added -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2" to the arguments to ffmpeg in the script and this worked fine.
-Mark

I used to have this error when I was resizing images while I was building the prototype for allsky with my ASI224MC. I fixed it by chopping 2 columns of pixels with image magick.
See this line https://github.com/thomasjacquin/allsky/blob/master/scripts/saveImageNight.sh#L62
The chop option does all the work.
I haven't had that issue during timelapse generation with ASI224mc though. Are you using full frame images?

Good point @thomasjacquin. I guess trimming the full frame images would also do the trick, but I hadn't got to the optimisation stage of the build yet so was still working with full frame images.
Whilst there are lots of fixes, they're not immediately obvious to someone who's run into this bug when they're building the project with a sensor which has an odd number of pixels. Added the pad argument to ffmpeg would avoid the problem for those who would run into it, while not impacting everyone else except a slight performance hit.
-Mark

Good point @thomasjacquin. I guess trimming the full frame images would also do the trick, but I hadn't got to the optimisation stage of the build yet so was still working with full frame images.
Whilst there are lots of fixes, they're not immediately obvious to someone who's run into this bug when they're building the project with a sensor which has an odd number of pixels. Added the pad argument to ffmpeg would avoid the problem for those who would run into it, while not impacting everyone else except a slight performance hit.
-Mark

@ennui2342, Mark, any update?

@EricClaeys Apologies, my allsky has been out of commission due to a waterlogged power supply. Once it's back up and running I'll do an upgrade and try the new parameter.
You are right in that the resolution of the 224mc is as you state and an even number. But the images generated by allsky which are used for the timelapse are 885x754 (width and height in settings are 0 for max so I'm not sure why it's smaller).

@ennui2342, sorry to hear about your power supply.  The 224MC has a native resolution of 1304x976.  You have "width" and "height" set to 0 in the WebUI, correct?
Would you please attach (don't copy/paste) your config/config.sh file?

Closing - no response from user.


Register Winnipeg, Manitoba, Canada for the Global Day of Code Retreat 2018

Looks good, welcome to GDCR18!


feat: log headers

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.00%. Comparing base (e9bdea1) to head (742bd3a).

:white_check_mark: All tests successful. No failed tests found.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
+ Coverage   94.96%   95.00%   +0.03%
==========================================
  Files           5        5
  Lines         298      300       +2
  Branches       31       31
==========================================
+ Hits          283      285       +2
  Misses         12       12
  Partials        3        3

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

This was just for debugging


Restrictive dependency versions - NumPy 1.24.4 blocked

My project wants to update to NumPy 1.24.4, however this is being blocked by datacompy dependency constraints in the pyproject.toml.
The dependency rules in datacompy for NumPy are currently numpy<=1.24.3,>=1.22.0.
From looking through NumPy release history it seems as though they restrict breaking changes to the second block in the version string (in Semantic Versioning this would be the "minor" position).
Would it be possible to update the restriction in datacompy so that it becomes numpy<1.25,>=1.22.0?

Hey @jason-vitaler Let me take a look!
Going to run edgetest against it and see if there are any issues.

Seems like the bump to Pandas 2 is causing some issues too. See the following edgetest run: https://github.com/capitalone/datacompy/actions/runs/6277350903/job/17048905414
Will get out a fix for updating everything. Looking to get up to the following upper pins:
=============  ===============  ===================  =================
Environment    Passing tests    Upgraded packages    Package version
=============  ===============  ===================  =================
core           False            fugue                0.8.6
core           False            numpy                1.26.0
core           False            ordered-set          4.1.0
core           False            pandas               2.1.1
=============  ===============  ===================  =================

That would be greatly appreciated.  Thank you!

More precisely this is a duckdb issue affecting fugue: https://github.com/duckdb/duckdb/pull/8738
I'll bump up the numpy version for now to unblock @jason-vitaler

@jason-vitaler FYI: https://pypi.org/project/datacompy/0.10.4/

Thanks @fdosani !!


[CMSIS-NN] Convert scalar constants to tensor constants

Scalar to tensor constant pass

-Pass that converts scalar constants into tensor constants for CMSIS-NN binary ops
-Updated extract_constants pass to support constants at any position in the function signature
-Modified tests for extract_constants pass corresponding to the scalar support
-Added new binary op tests to include constants

Thanks for the review @Mousius. I have updated the PR with review comments.

Thanks @ashutosh-arm! This is merged now :smile_cat:


Update README.md

Add missing '}'
What exactly does the PR do?
Add a missing '}' symbol in the Readme
Is there anything I need to consider when testing?
If related to an error, please link it:
If possible, illustrate your PR with a small demo:
I agree with the following:

[x] The code runs without problems
[x] I myself have tested it
[x] The code was written by myself personally and not copied by anyone

Wichtiger und richtiger PR. Danke dir Buddy


Streamlit-folium is extending its container way further past the bottom border of the map

The current version of streamlit-folium (0.22.1) has introduced a bug which is clearly visible from the showcase page (https://folium.streamlit.app/). Right on the bottom of the map, there is a huge blank space which extends a lot until the next element or the footer/bottom of the page.

I can see the exact same problem (the issue of the blank space after the map, which I described in my first post) present on the published version of https://folium.streamlit.app/ in my apps which are using streamlit-folium (0.22.1). However, the error you are posting is not present in my apps, therefore I think is not related. Thank you

The issue you are seeing isn't present for me?

I can scroll way past the end of the map. Reproduced using Chrome Version 128.0.6613.138 (Official Build) (arm64) and Safari Version 18.0 (196<IP_ADDRESS>.10, 19619).
With both of them I've tried to access the https://folium.streamlit.app/ clearing the cache.

I can get that to happen, but it's intermittent. I've rebooted the app to ensure its on 0.22.1, and will fix the experimental_rerun error to see if this persists. If so, then we can try and figure out what else might be causing this

What is you want from me?  That's not up for debate, it's what I am seeing.

Thanks for clarifying :)
I now agree that it's not intermittent, it's literally every other refresh for me, irrespective of having/not having cache. Unfortunately, there are no messages in the console to indicate an error.
@hansthen I don't think this is an issue with the patch you just did for Draw, but I also don't know what to look for here. Any ideas?

As it turns out, it's not the map but the code on the right side that is causing the issue. The map is only 700px tall, the right column is 2438px tall

When it doesn't show the issue, the code column is only 833px tall

@hansthen I don't think this is an issue with the patch you just did for Draw, but I also don't know what to look for here. Any ideas?

Just to be sure, I undid my changes for the Draw plugin on the latest main branch locally. Without my changes the demo app also shows this issue.
The same issue also shows up in the page for the draw plugin. There is a code block below the two columns, which makes it easier to see. The issue is still there even if there is nothing in the second column.
  with st.echo(code_location="below"):
      import folium
      import streamlit as st
      from folium.plugins import Draw

      from streamlit_folium import st_folium

      m = folium.Map(location=[39.949610, -75.150282], zoom_start=5)
      Draw(export=True).add_to(m)

      c1, c2 = st.columns(2)
      with c1:
          output = st_folium(m, width=700, height=500)

      with c2:
          pass

I don't have time right now, but I would check the setComponentHeight message sent from the streamlit-folium component in a javascript debugger.

Fixed by #237


Add transform hook for changing errors from json schema validation

Reasons for making this change
The error messages that come from the json schema spec/library (not sure where they come from) aren't very user friendly. They also clash with a pattern that the forms I work have for required validation, namely that those required errors should show up at the field level (rather than at the containing object).
One way of addressing those issues is to allow users to modify the error list sent back by the jsonschema library. Since that has all the error detail produced beyond just a message, it's easy to modify or write your own messages. This PR adds that hook.
I'm skipping updating tests and docs until I get some feedback on whether this is a good approach and something that this library should accommodate.
Thanks!
Checklist

[x] I'm updating documentation

[x] I've checked the rendering of the Markdown text I've added
[x] If I'm adding a new section, I've updated the Table of Content

[x] I'm adding or updating code

[x] I've added and/or updated tests
[x] I've updated docs if needed

[x] I'm adding a new feature

[x] I've updated the playground with an example use of the feature

This is actually smart, I like it. Sure I'd love if the jsonschema lib we used exposed a better API, but I think this nicely solves our current needs with this issue.
Could you please rebase your patch against latest master, and add a few tests and docs? Sorry for being so late to provide feedback.

Released in v0.42.0.


I am getting issues when used tabfragment inside the fragment

@venkateshcool12 can you elaborate more into what's the problem that you have with the library?


GPL-526 UI Pagination

User story
As a user I would like the libraries in the run to be ordered by most recent first as we would generally want to use ones which have most recently been created
Pagination for Plates/ Libraries/ Runs/ LibrariesList
Who are the primary contacts for this story
Steve / Harry
Acceptance criteria
To be considered successful the solution must allow:

When I go to the create run page the most recent libraries should appear first
[ ] ...

Dependencies
This story is blocked by the following dependencies:

#<issue_no.>
sanger/#<issue_no.>

Additional context
Add any other context or screenshots about the feature request here.

Coupled with https://github.com/sanger/traction-service/issues/409


Add UPS SenderId

Sender ID is a requirement to UPS

@pilhuhn @anuj1708 Quickly review?

LGTM - waiting on Travis anyway

Looking good to me too


Question: Integration with alert manager

I can think of few ways to integrate alerts manager with promplot, such that a triggered alert will also be accompanied with a relevant graph, much like grafana alerts.
Wondering if this is something that is already done? maybe with some projects using promplot?

Hi! To be honest, not sure if anyone is actively using promplot. But if this seems like something useful to you, feel free to explore!

i think alertmanager does not support this features like promplot but its good to integrate with slack which is convenient to use this tool

@jorinvo can we work how to integrate this with alertmanager? i think alertmanager does not support image attachment yet


MAINT: Clean _clean_inputs in linprog

Clean _clean_inputs(...) as listed in #9671.
This PR:
* Remove catching BaseExceptions for unspecified errors.
* Remove nested try statements
* Refactor duplicate behaviour into functions.
* Group related checks into try..except..else statements.
* Minor tweaks to documentation and error messages.

This PR does not make any changes to how bounds is handled. I've been looking to rewrite the bounds as arrays which will change that part significantly.
@mdhaber @rgommers All of the (500+) tests in test_linprog pass as well as the tests in test__linprog_clean_inputs. The tests for clean inputs could be more comprehensive, but, I'm going to trust the passing tests. Maybe reviewing the test suite should be added to #9671?
see #10083

Nice, thanks @Kai-Striega


%-I in strftime() doesn't work on Windows

Version of the custom_component

1.0.2
Describe the bug
%-I in strftime() doesn't work on Windows
Here is an example
C:\Users\admin>python
Python 3.8.7 (tags/v3.8.7:6503f05, Dec 21 2020, 17:59:51) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now().strftime('%-I')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format string
>>> datetime.datetime.now().strftime('%I')
'01'

See also http://strftime.org/ and https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior
If it is possible, can you replace it with %I ?
Otherwise you can use some tricks, like
d.strftime('%d:%%M %%p - %d %%b %%Y' % (d.hour % 12 if d.hour % 12 else 12, d.day))
Debug log

  File "C:\Users\admin\AppData\Roaming\.homeassistant\custom_components\frigate\media_source.py", line 518, in _generate_recording_title
    return dt.datetime.strptime(f"{folder['name']}.00.00", '%H.%M.%S').strftime('%-I:%M:%S %p')
ValueError: Invalid format string

HomeAssistant is supported on Windows?

HomeAssistant is supported on Windows?

For me it works, but I don't know if it is officially supported.

For me it works, but I don't know if it is officially supported.

This bug can be closed. "%-I" no longer features in this integration.


Many url(for:in:appropriateFor:create:) calls crash on Windows

This crashes on Windows:
FileManager.default.url(for: .libraryDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
Swift/ErrorType.swift:253: Fatal error: Error raised at top level: (extension in Foundation):FoundationEssentials.FileManager.(unknown context at $7ffe36188798).URLForDirectoryError.directoryUnknown
due to most locations being unimplemented. Presumably this should return some fallback location instead of crashing.
Swift version 6.1-dev (LLVM 5728735dd595a22, Swift a680211a4f8d4dc)
Target: x86_64-unknown-windows-msvc

Presumably this should return some fallback location instead of crashing.

I'm not sure I agree with this as I don't think it'd be appropriate for Foundation to decide where such a fallback location might live.
To clarify, this function doesn't crash but rather it throws an error, it looks like your application is crashing because you have a try at the top level of an executable without a do/catch block which is defined to fatal error upon a thrown error. IMO it seems reasonable that if a directory/mask is provided that doesn't exist on the current platform that this API should throw an error indicating it was unable to produce a URL, and the client can then choose a suitable fallback behavior. It's possible this could be improved by indicating which SearchPathDirectory cases are valid on certain platforms if a platform doesn't have the concept of a directory entirely, but it's also possible that a directory is applicable to a platform but it does not exist or isn't created for the specified user and therefore cannot be returned.
@jakepetroules do you think adding failure logic to your client application to determine what a suitable fallback location might be for your application would be a good solution here? Or is there anything that is requiring you to escalate this thrown error to a crash in your application?

Looks like you're right. I might've been thinking of a different function which was non-throwing and wouldn't have been able to throw an error..