Yes, 1.16.3 is also what I run for observations (a compile from March 11).
xsnrg post=70059 wrote: That might be advisable. I reverted to a copy of the build I had from March 19, and it worked great for the rest of the night last night.
running `git diff c882e29822f6b692a6d6db2e48e99cab88ac31a5 .` it looks like the previous version of the Camera SDK was 1.16.3. The EAF and EFW were updated on the 19th.
I think we can leave those alone and only change the camera version. Thoughts?
Just tried it with my laptop and the ASI183MC. Did crash, too:
knro post=70056 wrote: does ./asi_camera_test causes a crash as well?
..... Please input the <width height bin format> with one space, ie. 640 480 2 0. Leave w/h to zero to use maximum. 0 0 1 2 set image format 5496 3672 1 2 success, Will capture now a 100ms image. Image successfully captured. Writing image to image.raw file... asi_camera_test: ./os/threads_posix.h:46: usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0' failed. Aborted (core dumped)
I can confirm that, same here. Reducing the FOV of my ASI183 to 3672x3672 prevents it from crashing! But already at 4000 it starts crashing again, so no workable solution.
seescho post=70012 wrote: So, reduzing the picture size a bit let the crash dissapeare
256MB should be enough for the ASI183MC, no? Nevertheless, I tried with both 512 and 1024, no change there. Crashes with both. It does take a while though: The image is downloaded and displayed, and only some 3s later I get the crash message which states
pawel-soja post=69992 wrote: In original library (1.17), there are probably larger double buffers used for communication with the camera.
The usbfs_memory_mb value should be at least '6 x Resolution'. For now, these are guesses, I need to analyze the library more.
Anyway, to rule out a memory problem, I suggest temporarily increasing the usbfs_memory_mb value and testing indi with different ZWO libraries.
Child process 14326 died 2021-04-13T13:52:57: Driver indi_asi_ccd: stderr EOF
In my experience it is enough to keep the current nightly/devel of indi, and only downgrade the version of libasi. Haven't yet tested my filter wheel, though - will do later today.
Just for confirmation:
With latest, you refer to 1.17, yes? So that one fixes the original issue in this thread, but causes crashes for some?
Addendum: I had not checked the syslog so far. It actually says
Apr 12 11:27:52 woodstock.pitnet kernel: usb 2-1: Process 28984 (indi_asi_ccd) called USBDEVFS_CLEAR_HALT for active endpoint 0x81 Apr 12 11:27:53 woodstock.pitnet kernel: indi_asi_ccd: segfault at 35 ip 00007fb5551d4646 sp 00007fb53e442b90 error 4 in libusb-1.0.so.0.3.0[7fb5551ca000+e000]
Ah, it's in 99-indi_auxiliary.rules now. Was wondering, too. But I had checked that the setting was at 256, so that was/is not the issue.
xsnrg post=69941 wrote:This is true, but it still exists. It was just moved to INDIlib, and should have the same effect. This change has been working for me now for some time. Jasem moved it there because many devices require it, so indilib is a good central place to manage it.
jpaana post=69937 wrote: Libasi package also contains the udev rule file, which has that usbfs 256MB memory line in the old version, but not in new one.
I still suspect changes in the SDK/driver from ZWO as having some differences to figure out.
Addition: If I downgrade only libasi, in my case to 1.9.0-21_gd9a5e309 from March 11, everything runs fine. That is the old SDK, 184.108.40.206. So it obviously is an issue of the ZWO SDK?
So this is the EQMOD driver yes?
This is only for building the unit test. For normal operation, gmock is not needed. I have neither gmock nor gtest installed, and it builds fine.
If I read the CMakeLists.txt right, that one isn't correct. It tries to find both GTest and GMock, but if GTest is found it wants to build the tests, even if GMock wasn't found.
For a quick solution you could edit CMakeLists.txt, line 146, and set INDI_BUILD_UNITTESTS to FALSE...
(in my case the packages would be called gmock and gtest, but that won't help you, as it's openSUSE....)
I can at least confirm that, while the ASI183MC is crashing the driver every time, the 290MMmini works without issues...
pawel-soja post=69903 wrote: This can actually be a problem for a specific camera.
No idea. I started kstars from the terminal, and got messages about the xml device file,
Dispatch command error(-1): Device ZWO CCD ASI183MC Pro not found <setTextVector device="ZWO CCD ASI183MC Pro" name="DRIVER_INFO" state="Idle" timeout="60" timestamp="2021-04-11T09:39:07"> <oneText name="DRIVER_NAME"> ZWO CCD </oneText> <oneText name="DRIVER_EXEC"> indi_asi_ccd </oneText> <oneText name="DRIVER_VERSION"> 1.9 </oneText> <oneText name="DRIVER_INTERFACE"> 2 </oneText> </setTextVector>
2021-04-11T09:45:29: Driver indi_asi_ccd: stderr EOF Child process 17789 died
Thread 4 "indi_asi_ccd" received signal SIG33, Real-time event 33. [Switching to Thread 0x7ffff55ad640 (LWP 18722)] 0x00007ffff6ef9a9a in __futex_abstimed_wait_common64 ( futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74 Downloading source file /usr/src/debug/glibc-2.33-4.1.x86_64/nptl/../sysdeps/nptl/futex-internal.c... 74 err = INTERNAL_SYSCALL_CANCEL (futex_time64, futex_word, op, expected, (gdb) bt #0 0x00007ffff6ef9a9a in __futex_abstimed_wait_common64 ( futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74 #1 0x00007ffff6ef9aff in __GI___futex_abstimed_wait_cancelable64 ( futex_word=futex_word@entry=0x5555555ade98, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123 #2 0x00007ffff6ef3260 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555555a2860, cond=0x5555555ade70) at pthread_cond_wait.c:504 #3 __pthread_cond_wait (cond=0x5555555ade70, mutex=0x5555555a2860) at pthread_cond_wait.c:619 #4 0x00007ffff6da50e0 in __gthread_cond_wait (__mutex=<optimized out>, __cond=0x5555555ade70) at /usr/src/debug/gcc11-11.0.0+git183291-1.4.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux/bits/gthr-default.h:865 #5 std::__condvar::wait (__m=..., this=0x5555555ade70) at /usr/src/debug/gcc11-11.0.0+git183291-1.4.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/std_mutex.h:155 #6 std::condition_variable::wait (this=this@entry=0x5555555ade70, __lock=...) at ../../../../../libstdc++-v3/src/c++11/condition_variable.cc:41 #7 0x00007ffff7e4dfa7 in std::_V2::condition_variable_any::wait<std::unique_lock<std::recursive_mutex> > (this=this@entry=0x5555555ade70, __lock=...) at /usr/include/c++/10/condition_variable:321 #8 0x00007ffff7e4d768 in std::_V2::condition_variable_any::wait<std::unique_lock<std::recursive_mutex>, INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()>::<lambda()> > (__p=..., __lock=..., this=0x5555555ade70) at /usr/include/c++/10/condition_variable:330 #9 operator() (__closure=0x555555597b28) at /home/pit/Sources/indi/libs/indibase/thread/indisinglethreadpool.cpp:31 #10 std::__invoke_impl<void, INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > (__f=...) at /usr/include/c++/10/bits/invoke.h:60 #11 std::__invoke<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > (__fn=...) at /usr/include/c++/10/bits/invoke.h:95 #12 std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > >::_M_invoke<0> (this=0x555555597b28) at /usr/include/c++/10/thread:264 #13 std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > >::operator() (this=0x555555597b28) at /usr/include/c++/10/thread:271 #14 std::thread::_State_impl<std::thread::_Invoker<std::tuple<INDI::SingleThreadPoolPrivate::SingleThreadPoolPrivate()::<lambda()> > > >::_M_run(void) ( this=0x555555597b20) at /usr/include/c++/10/thread:215 #15 0x00007ffff6daade4 in std::execute_native_thread_routine ( __p=0x555555597b20) at ../../../../../libstdc++-v3/src/c++11/thread.cc:82 #16 0x00007ffff6eed299 in start_thread (arg=0x7ffff55ad640) at pthread_create.c:473 #17 0x00007ffff6a9a3b3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Is there any news on this? I just tried to connect my camera (ASI183MC) locally to the laptop, and trying to take an image crashes the indi driver. Streaming works on the first try (I can even select sub-fields etc), but a restart (also from within the stream window to change exposure) will crash it....
This is with libindi-1.9.0-92_gbd9110b4. No issues with the previous one I had installed (libindi-1.9.0-21_gd9a5e309 as of March 11)