I just set up another Trixie install for a Pi2Bv1.1, so armv7, for
use with an Owon vds1022 USB oscilloscope. I have an older install
(bookworm) on a separate microSD card which works correctly, but the
card is too small (8GB) to allow useful working space. The new install
is less than a year newer than the working one.
The new install allows installation of Florentbr's software found at
GitHub but when the software is run it gets stuck in a loop and can't
connect to the 'scope:
bob@raspberrypi:~/OWON-VDS1022-1.1.5-cf19 $ sudo owon-vds-tiny
env: Linux, Java 25.0.1 arm
app dir: /opt/owon-vds-tiny
user dir: /root/.owon-vds-tiny
locale: en_US, en_US, true
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by ch.ntb.usb.LibusbJava in an unnamed module (file:/opt/owon-vds-tiny/lib/ch.ntb.usb-0.5.9.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
ch.ntb.usb.USBException: LibusbJava.usb_claim_interface: Device or resource busy
at com.owon.uppersoft.vds.core.usb.CDevice.open(CDevice.java:91)
at com.owon.uppersoft.vds.core.usb.CDevice.getDevices(CDevice.java:300)
at com.owon.uppersoft.dso.source.usb.USBSourceManager.refreshUSBPort(USBSourceManager.java:79)
at com.owon.uppersoft.dso.source.comm.detect.USBLoopChecker.checkUSBDevice(USBLoopChecker.java:74)
at com.owon.uppersoft.dso.source.comm.USBDaemonHelper.onNotConnecting(USBDaemonHelper.java:35)
at com.owon.uppersoft.vds.machine.InfiniteDaemonTiny0.onNotConnecting(InfiniteDaemonTiny0.java:37)
at com.owon.uppersoft.dso.source.comm.Flow.run(Flow.java:79)
at com.owon.uppersoft.dso.global.ControlAppsTiny$1.run(ControlAppsTiny.java:38)
that never seems to stop.
The warning prompted me to try running under sudo, but that made no difference.
On closer inspection, it's not clear the warning has any relevance to the "device or resource busy" message. Busy isn't the same as restricted.
If anybody's got a suggestion please post!
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
bob prohaska wrote:It only says it's a warning, not an error.
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning forcallers in this module
Have you done that?
On 07/12/2025 18:55, bp@www.zefox.net wrote:
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
Have you done that?
Depending on what kind of device it appears as (serial, keyboard, mass storage, network, ...) see if you can work out what other app might have grabbed it. ('sudo lsof' is handy here, if it appears as a device node that you can grep for)
It only says it's a warning, not an error.
Have you done that?
[apologies for the wide lines]
Theo <theom+news@chiark.greenend.org.uk> wrote:
Depending on what kind of device it appears as (serial, keyboard, mass storage, network, ...) see if you can work out what other app might have grabbed it. ('sudo lsof' is handy here, if it appears as a device node that
you can grep for)
Sudo lsof is loquatious, but not obviously informative. These tests were
on a Pi5 running up-to-date Bookworm, but the behavior is outwardly the
same as Trixie on Pi2.
bp@www.zefox.net wrote:OOI I discovered a weird thing
[apologies for the wide lines]
Theo <theom+news@chiark.greenend.org.uk> wrote:
Depending on what kind of device it appears as (serial, keyboard, mass
storage, network, ...) see if you can work out what other app might have >>> grabbed it. ('sudo lsof' is handy here, if it appears as a device node that
you can grep for)
Sudo lsof is loquatious, but not obviously informative. These tests were
on a Pi5 running up-to-date Bookworm, but the behavior is outwardly the
same as Trixie on Pi2.
What I'm looking for is something having grabbed the USB device. This is
hard to specify without knowing how the OWON does its USB, but for example
if it was serial I'd 'lsof | grep /dev/tty' and look for things using the /dev/ttyUSB0 or /devttyACM0 device the OWON probably uses.
Since the OWON app has failed to grab the USB you're looking for other apps that have grabbed it, ie not at the OWON app.
Theo
On 08/12/2025 13:13, Andy Burns wrote:
It only says it's a warning, not an error.
Have you done that?
True, but if you $(SEARCH_ENGINE_OF_CHOICE) for it you will find that
there is a suggestion that some things may not work in the situations
that trigger the warning.
It's surprising how often clutching at straws yields results!
bp@www.zefox.net wrote:
[apologies for the wide lines]
Theo <theom+news@chiark.greenend.org.uk> wrote:
Depending on what kind of device it appears as (serial, keyboard, mass storage, network, ...) see if you can work out what other app might have grabbed it. ('sudo lsof' is handy here, if it appears as a device node that
you can grep for)
Sudo lsof is loquatious, but not obviously informative. These tests were
on a Pi5 running up-to-date Bookworm, but the behavior is outwardly the same as Trixie on Pi2.
What I'm looking for is something having grabbed the USB device. This is
hard to specify without knowing how the OWON does its USB, but for example
if it was serial I'd 'lsof | grep /dev/tty' and look for things using the /dev/ttyUSB0 or /devttyACM0 device the OWON probably uses.
Since the OWON app has failed to grab the USB you're looking for other apps that have grabbed it, ie not at the OWON app.
Daniel James <daniel@me.invalid> wrote:
On 07/12/2025 18:55, bp@www.zefox.net wrote:
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
Have you done that?
After a fashion, yes. I tried appending
--enable-native-access=ALL-UNNAMED
on the command line, but it made no difference.
Clearly, the restriction is new(ish) and there's no obvious reason to
think that's the right place put the option. The references I found on-line to this change date from 2025, the application was last updated in 2022 IIRC.
Thanks for writing!
bob prohaska
bp@www.zefox.net wrote:
[apologies for the wide lines]
Theo <theom+news@chiark.greenend.org.uk> wrote:
Depending on what kind of device it appears as (serial, keyboard, mass
storage, network, ...) see if you can work out what other app might have >> > grabbed it. ('sudo lsof' is handy here, if it appears as a device node that
you can grep for)
Sudo lsof is loquatious, but not obviously informative. These tests were
on a Pi5 running up-to-date Bookworm, but the behavior is outwardly the
same as Trixie on Pi2.
What I'm looking for is something having grabbed the USB device. This is
hard to specify without knowing how the OWON does its USB, but for example
if it was serial I'd 'lsof | grep /dev/tty' and look for things using the /dev/ttyUSB0 or /devttyACM0 device the OWON probably uses.
Since the OWON app has failed to grab the USB you're looking for other apps that have grabbed it, ie not at the OWON app.
bp@www.zefox.net wrote:
Daniel James <daniel@me.invalid> wrote:It turns out there's a problem report that resembles mine at https://github.com/florentbr/OWON-VDS1022/issues/76
On 07/12/2025 18:55, bp@www.zefox.net wrote:
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
Have you done that?
After a fashion, yes. I tried appending
--enable-native-access=ALL-UNNAMED
on the command line, but it made no difference.
Clearly, the restriction is new(ish) and there's no obvious reason to
think that's the right place put the option. The references I found on-line >> to this change date from 2025, the application was last updated in 2022 IIRC.
Thanks for writing!
bob prohaska
but it doesn't offer an explicit resolution.
At this point I have Trixie and Bookworm installs that don't connect
and a somewhat older Bookworm install that worked out of the box. So
far, the one that works is on a 33 bit Pi2.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,090 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 158:12:01 |
| Calls: | 13,922 |
| Files: | 187,021 |
| D/L today: |
219 files (57,450K bytes) |
| Messages: | 2,457,273 |