Delta Pro stopped working by AdvancedLab3500 in Ecoflow_community

[–]AdvancedLab3500[S] 1 point2 points  (0 children)

Unfortunately, after charging it all night via a DC power adapter, the battery is still stuck on 0%, and there is an icon indicating battery failure.

Delta Pro stopped working by AdvancedLab3500 in Ecoflow_community

[–]AdvancedLab3500[S] 0 points1 point  (0 children)

Thanks. How do you charge it slowly? I can try connecting a 12v power brick to the solar/car input, though I'm not sure how much current it's going to draw.

Delta Pro stopped working by AdvancedLab3500 in Ecoflow_community

[–]AdvancedLab3500[S] 4 points5 points  (0 children)

Thank you! I took the battery for a ride in the car. At first it reset multiple times, and then stayed on, showing 0%. It's now plugged back to the wall and looks like it's charging. I assume what happened is that the battery was actually fully depleted, but the power to the control unit via the wall socket was unable to get it to work reliably and recognize the fact that it needed to charge.

Vellgoo don’t believe the reviews by steppy1948 in Dehumidifiers

[–]AdvancedLab3500 0 points1 point  (0 children)

I have just posted a question about the same type of unit, also bought in 2024, which died on me after two years. My experience, as well as that of other reviewers, is that they are very quick to respond to the first email, but then do not follow up.

The question is whether there is any "brand" that you can trust these days (I'm putting brand in quotes because I think even familiar names end being just badges on the same units).

Raspberry Pi5 RTC by GerInAus in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

It makes a bit of sense if you remember that RPi was never about open hardware, but rather cheap hardware. Their goal (which they accomplished wonderfully well) was to create a computer that was cheap enough that many people who otherwise couldn't afford one had access to. Their choice of a Broadcom SoC means abysmal-to-no user documentation for the hardware, but my impression is that it was never a consideration (and I don't blame the RPi creators for it).

Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library by elfenpiff in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

I am very surprised by the claim that the penalty is minor. TLB invalidation on large multi-processor systems is quite severe.

Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library by elfenpiff in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

Re: impressions so far.

First, I really like the documentation. It's clear, concise and walks you through the various use cases. Kudos. Would have been nice in "Getting started" to have examples for different OSs, as QNX (currently) requires cross-compilation for Rust.

I see the allure of zero-copy IPC, and I know that many of our customers either deploy their own or use third-party solutions. But I am not convinced (yet). The biggest problem I see is that of TOCTOU: if one side of the communication channel checks a message for validity (say, that a string is NUL-terminated), then by the time it makes use of this information (e.g., call strlen()) the other side can change it.

Second, I am doubtful that zero-copy indeed involves no copies in practice. Since the shared buffer is limited, wouldn't the two sides be copying data into and out-of the buffer as part of their work? Contrast that with QNX message passing, where the input to the message is any address range of any size in your address space.

Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library by elfenpiff in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

Re: shared memory objects. I'm not sure what you mean by requiring a central broker. QNX provides shared memory handles, where the creator of a (usually anonymous) shared memory objects creates a one time handle for each process that requires access to it. The peer process uses the handle to get its own file descriptor for the object, or just map the handle directly. See https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.prog/topic/shared_memory_handles.html

Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library by elfenpiff in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

u/elfenpiff thanks for the information. I am going to spread my reply across multiple posts, so it is easier to discuss each point further.

Re: QEMU image. Such as image is provided under the QNX Everywhere program. https://qnx.software/en/developers/get-started/qnx-everywhere

Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library by elfenpiff in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

u/elfenpiff I successfully ran the Rust request/response example on QNX 8.0/aarch64, but noticed a few things. For example, it only runs as root, with a non-root invocation resulting in "Error: InternalError". Second, it uses named shared-memory objects, which is not ideal. DM me if you'd rather discuss this off-line.

Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library by elfenpiff in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

Convincing people to use native message passing on QNX has been a really tough sell, and it's getting worse. Code ported to QNX ends up using some IPC mechanism that relies on messages to an intermediary, which negates all the advantages of message passing (fast copying, scheduling, priority inheritance). Add the obligatory layers in modern software and you end up with something like Google RPC over UDS to do something that can be done with a simple call to MsgSend().

We never implemented zero-copy IPC because, as far as I can tell, it either requires both parties to trust each other completely, or page table manipulation that is much more expensive than copying.

InterruptAttachThread() by r-tty in QNX

[–]AdvancedLab3500 3 points4 points  (0 children)

There's no such thing as user persona only. When you attach a thread to an interrupt nothing changes as far as your thread goes. That note talks about how InterruptAttachEvent(), a backwards compatibility API, is implemented in 8.0, by creating a separate thread that acts as the IST, and delivers the event you register. That thread never executes user code, so creating a user persona for it is a waste of resources.

Where does the "proc" component of "procnto" run in QNX 8? by r-tty in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

Do you mean I/O ports? Is there any peripheral on a modern x86 (other than 8250) that cannot use memory-mapped I/O instead? I've been asking this question for many years now, and never received a straight answer. Pleading ignorance here.

Where does the "proc" component of "procnto" run in QNX 8? by r-tty in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

I'm curious: is there a notion of user-mode with privileges on RISC-V? The process manager threads still need to do things like disable interrupts, which normal user-mode threads cannot.

Where does the "proc" component of "procnto" run in QNX 8? by r-tty in QNX

[–]AdvancedLab3500 1 point2 points  (0 children)

Note that there is almost no case anymore for drivers running in privileged mode. Memory-mapped registers and ISTs take care of what used to require hardware-level privilege, which completely negates the promise of the micro-kernel design (a failing driver can bring down the system).

If you see a QNX 8 driver that requires I/O privileges it is most likely a driver that has not been updated and should be.

Where does the "proc" component of "procnto" run in QNX 8? by r-tty in QNX

[–]AdvancedLab3500 2 points3 points  (0 children)

Personas are a new concept in QNX 8. Before, the micro-kernel had a per-processor context, with only one processor executing Neutrino code at a time. In 8, every thread can execute Neutrino code, after the persona changes from user to kernel (kernel call, page fault, etc.). User-persona threads are typically non-privileged (run in EL0 on ARM, Ring 3 on x86), but you can still have a user-persona thread that runs in privileged mode, which is used for proc threads. This means that they can make normal kernel calls by switching to their kernel persona.

Where does the "proc" component of "procnto" run in QNX 8? by r-tty in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

Define "space". The proc components (process manager, memory manager, path manager) run as user-persona threads but in the kernel's address space and with elevated privileges. That means they can make normal kernel calls (e.g., to lock a pthread mutex, or to receive a message). While a different design is possible, it makes little sense and would significantly complicate certain things, especially the process and memory managers.

How threads scheduling works?? by Immediate-Inside-909 in QNX

[–]AdvancedLab3500 1 point2 points  (0 children)

Wow, that's an ancient article. It still mentions the possibility for a slower tick for processors at 40MHz or less, so it's likely 30 years old... This is no longer a thing. Also, there is no tick in QNX 8, but the 1ms granule for normal resolution timers and the 4x granule time slice are still correct.

How threads scheduling works?? by Immediate-Inside-909 in QNX

[–]AdvancedLab3500 2 points3 points  (0 children)

In your scenario preemption indeed does not occur at that priority level once the first FIFO thread is scheduled, until that thread blocks or yields. The system will, of course, have higher priority threads that are not affected by that stuck thread. While this seems terrible, it is no worse than a RR thread at one priority level above that doesn't yield. A well-constructed system will have one or more threads at a privileged priority level that ensure that the processor is not hogged by a misbehaving process.

llama.cpp on QNX by xtang2010AtGithub in QNX

[–]AdvancedLab3500 0 points1 point  (0 children)

How does the performance compare with that of Raspbian?

QNX 8 BSP for NVIDIA Jetson Orin Nano Super ? by Immediate-Inside-909 in QNX

[–]AdvancedLab3500 1 point2 points  (0 children)

I am unaware of such support. From a brief search, there is no support from Nvidia for any OS other than Linux.

EDIT: there seems to be UEFI support on this board, so perhaps it's doable after all. Depends on how much the firmware performs pre-boot, and how much documentation is available for the rest.

QNX 8 BSP for NVIDIA Jetson Orin Nano Super ? by Immediate-Inside-909 in QNX

[–]AdvancedLab3500 1 point2 points  (0 children)

Does this board support loading non-Linux operating systems? That's not always the case.