boolnetwork / mining-scripts

Deployment guide and scripts for Bool Network
Apache License 2.0
1 stars 3 forks source link

Can't start mining node on server with SGX2 #11

Closed quangtuyen88 closed 1 week ago

quangtuyen88 commented 6 months ago
curl is already the newest version (7.68.0-1ubuntu2.21).
0 upgraded, 0 newly installed, 0 to remove and 54 not upgraded.
83d719e77deaca1470f6baf62a4d774303c899db69020f9c70ee1dfc08c7ce9e
37b63212f4c46fd4074b51575668158d93192c861904eedb2c31a7d2ce756532
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
stack backtrace:
thread '<unnamed>' panicked at 'thread 'the nested signal is too deep to handle<unnamed>', ' panicked at 'src/signal/do_sigreturn.rsthe nested signal is too deep to handle:', 143src/signal/do_sigreturn.rs::1439:
9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>thread '' panicked at '<unnamed>the nested signal is too deep to handle', ' panicked at 'thread 'src/signal/do_sigreturn.rsthe nested signal is too deep to handle<unnamed>:' panicked at '', 143the nested signal is too deep to handle:src/signal/do_sigreturn.rs', 9:src/signal/do_sigreturn.rs
:143143::99

thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>thread '' panicked at 'thread 'the nested signal is too deep to handle<unnamed><unnamed>', ' panicked at 'src/signal/do_sigreturn.rsthread 'the nested signal is too deep to handle' panicked at ':', src/signal/do_sigreturn.rs143<unnamed>the nested signal is too deep to handle::143:', 9' panicked at '9

src/signal/do_sigreturn.rsthe nested signal is too deep to handlethread ':', 143<unnamed>src/signal/do_sigreturn.rs:' panicked at ':9the nested signal is too deep to handle143',
:src/signal/do_sigreturn.rs9thread ':<unnamed>
thread 'thread '143<unnamed><unnamed>' panicked at '' panicked at '' panicked at 'the nested signal is too deep to handle:', the nested signal is too deep to handlethe nested signal is too deep to handlesrc/signal/do_sigreturn.rs:', 9143', :src/signal/do_sigreturn.rs9

src/signal/do_sigreturn.rs:thread '143<unnamed>:' panicked at ':the nested signal is too deep to handle9143',
src/signal/do_sigreturn.rs::143:99

thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:thread '9
<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
thread '<unnamed>' panicked at 'the nested signal is too deep to handle', src/signal/do_sigreturn.rs:143:9
bnk-watcher version 0.6.6-unknown
thread 'main' panicked at 'failed to spawn thread: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ctrlc-3.4.1/src/lib.rs:150:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
             at library/core/src/panicking.rs:142
   2: occlum_libos_core_rs::signal::do_sigreturn::handle_signal
   3: occlum_libos_core_rs::signal::do_sigreturn::force_signal
   4: occlum_libos_core_rs::exception::do_handle_exception
   5: occlum_libos_core_rs::syscall::do_syscall
   6: occlum_syscall
   7: <unknown>
note: Some details are omitted, call backtrace::enable_backtrace() with 'PrintFormat::Full' for a verbose backtrace.
stack backtrace:
fatal runtime error:  failed to initiate panic, error  5
 [ERROR] occlum-pal: Failed to enter the enclave to execute a LibOS thread (host tid = 544) with error code 0x1006: Unknown SGX error (line 21, file src/ocalls/spawn.c)
[ERROR] occlum-pal: Failed to enter the enclave to execute a LibOS thread (host tid = 462) with error code 0x1006: Unknown SGX error (line 21, file src/ocalls/spawn.c)
/opt/occlum/build/bin/occlum: line 455:   459 Illegal instruction     (core dumped) RUST_BACKTRACE=1 "$instance_dir/build/bin/occlum-run" "$@"

Got above err and my server suppor sgx2

 cpuid -1 | grep SGX
      SGX: Software Guard Extensions supported = true
      SGX_LC: SGX launch config supported      = true
   Software Guard Extensions (SGX) capability (0x12/0):
      SGX1 supported                           = true
      SGX2 supported                           = true
      SGX ENCLV E*VIRTCHILD, ESETCONTEXT       = true
      SGX ENCLS ETRACKC, ERDINFO, ELDBC, ELDUC = true
   SGX attributes: ECREATE SECS.ATTRIBUTES (0x12/1):
   SGX Enclave Page Cache (EPC) enumeration (0x12/0x2):
   SGX Enclave Page Cache (EPC) enumeration (0x12/0x3):
   SGX Enclave Page Cache (EPC) enumeration (0x12/0x4):
Kayryu commented 5 months ago

I don't have any additional details about your device, but we encountered a similar issue on a dual-CPU server. Our resolution involved specifying the CPU via --cpuset-cpus 0 during the Docker service startup