profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jbliesener/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jorg Neves Bliesener jbliesener Brasilia, Brazil

jbliesener/FlightSimSwitches 9

Library for easy handling of Switches and Buttons in X-Plane with PJRC's Teensy

jbliesener/FlightSimOutputs 3

Library to support Midwest737Simulation's digital output card.

jbliesener/3DsMax-XplnObj 0

This plug-in is for 3DsMax that allows you to import or export x-plane's obj format

jbliesener/Arduino 0

ESP8266 core for Arduino

jbliesener/chrome 0

Docker Automated Build Repository for siomiz/chrome -- Google Chrome via VNC (or via Chrome Remote Desktop)

jbliesener/chrome2 0

Chrome VNC 800x600

jbliesener/conan-3dsmax-sdk-recipes 0

Contains scripts for generating conan recipes for 3DsMax's SDK

jbliesener/cores 0

Teensy Core Libraries for Arduino

jbliesener/crossbuild 0

Docker container for cross-building X-Plane plugins

issue commentzrepl/zrepl

zrepl killed by kernel OOM

I was doing this in order to see if it gets killed at a particular step:

watch -n1 'ps -Af | grep "zfs " | grep -v "grep " >> zfsprocs.log'

It does seem to be coinciding with zfs destroy on the recipient. Maybe the situation could be alleviated by destroying fewer snapshots (or even a single one) at a time? I guess the buik destroy can create additional pressure.

MAFLO321

comment created time in 12 hours

push eventPaulStoffregen/cores

PaulStoffregen

commit sha c84bb2fc56b7d60af82cd92ec84f4e9e51fd6ab1

Fix compiler warnings

view details

push time in 15 hours

push eventPaulStoffregen/cores

PaulStoffregen

commit sha eb0e021f56fe296c570e9883526db094d0a03c05

Enable fault handlers on Teensy 4

view details

push time in 16 hours

push eventPaulStoffregen/cores

Frank

commit sha 303a50219ddd5d3c4ec87389984c7ee83380c00a

rmv printing of "Hello World" text from crash report

view details

Paul Stoffregen

commit sha 44960b6f9fac5fbd6a01042cbcf631a64bc5f37d

Merge pull request #575 from FrankBoesing/patch-7 rmv printing of "Hello World" text from crash report

view details

push time in 18 hours

push eventPaulStoffregen/cores

Mike S

commit sha 5af9d01bfda415259ce207dbab9f81f7695cd09c

Added Sysclock setting to Crash Report

view details

Paul Stoffregen

commit sha 23f84924bcc284d06765575739a0f4bc38fcd515

Merge pull request #574 from mjs513/master Added Sysclock setting to Crash Report

view details

push time in 18 hours

PR merged PaulStoffregen/cores

Added Sysclock setting to Crash Report

Good Morning Paul Made 1 slight addition to the crash report. I added printing the System clock to report. Only affects crashreport.cpp.

Unless you want to crash the panic temp from shut down to cool down. I can't see me making any other changes.

Let us know when you want to freeze changes to crash reporting.

Thanks Mike

+3 -3

0 comment

1 changed file

mjs513

pr closed time in 18 hours

issue commentgephi/gephi

Gephi wont start in Debian 10.

My path to success:

  1. Check all the java versions available: sudo update-alternatives --config java. Not mandatory but then you go straight to the java versions properly.
  2. Launch Gephi with every java version: ./bin/gephi --jdkhome /usr/lib/jvm/{JAVA-VERSION}. This is faster than updating the gephi.conffile

Best!

chomwitt

comment created time in 20 hours

issue commentzrepl/zrepl

zrepl killed by kernel OOM

@problame No no, just added and enabled a 7GB swap file (:

MAFLO321

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

Work is happening right now on better fault handling and crash reporting. So if you wait a while, we may have 1.54-beta11 with that work included.

deadeert

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

no worries, whenever is fine

deadeert

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

Expect some delays because I’m currently out of the office, but will give a try most probably begin of July.

deadeert

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

Hey, Sorry for the delay. will give a try as soon as I can. thanks for the support.

deadeert

comment created time in a day

issue commentgephi/gephi

link error in ubuntu 20.04

I also ran into that same error. I think this is because of JDK 11.

Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed! 

Apparently JDK 8 is fine, though if you run it from the command line, there will be some GTK warnings similar to here, which ironically are solved by JDK 11. And I think that makes the Gephi looks a bit ugly but still usable.

Btw, for the current workaround, you don't need to uninstall JDK 11, just install JDK 8 and point it to the correct jdkhome either with:

./bin/gephi --jdkhome /usr/lib/jvm/java-8-openjdk-amd64/

or in the etc/gephi.config file

jdkhome="/usr/lib/jvm/java-8-openjdk-amd64/"

this worked after a whole day of trials thanks a lot!

jeremy-rutman

comment created time in a day

issue commentzrepl/zrepl

zrepl killed by kernel OOM

. Adding virtual memory it goes for longer but eventually the same thing.

@3nprob what do you mean by 'adding virtual memory'? Are you using resource limits?

MAFLO321

comment created time in 2 days

issue commentzrepl/zrepl

zrepl killed by kernel OOM

I'm not sure exactly what's going on here and it's years since I worked with Go slices, but this line stands out a bit to me in this context - will this not create a new references allocation with each call? https://github.com/zrepl/zrepl/blob/3b5a1a8b9a14c167d1af3ab7af115d5f9ffe9c2f/rpc/dataconn/base2bufpool/base2bufpool.go#L32

I'm not really into go but what I found on the go wiki to this: https://github.com/golang/go/wiki/SliceTricks#pop


If this help's, I could provide coredumps generated by gcore {PID} of a zrepl instance in multiple memory usage states (8%, 14%, ..., 57% of 4 GB host memory) (as you might guess they are quit big (1.4 GB - 2.9 GB). Therefore, please ask, and I will send you a private link via mail)

MAFLO321

comment created time in 2 days

PR opened PaulStoffregen/cores

Added Sysclock setting to Crash Report

Good Morning Paul Made 1 slight addition to the crash report. I added printing the System clock to report. Only affects crashreport.cpp.

Unless you want to crash the panic temp from shut down to cool down. I can't see me making any other changes.

Let us know when you want to freeze changes to crash reporting.

Thanks Mike

+3 -3

0 comment

1 changed file

pr created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Tim - see my response in https://forum.pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1?p=281920&viewfull=1#post281920

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Okay - saw both githubs same 4 hrs old.

It is against first plan to restart - shutdown seems safe path. In your test case of a heating lamp dropping speed wouldn't help - in the real world it might be a fan or airflow failure causing over temp.

Only issue is that the crash data won't survive is power shutdown happens for system restart.

But an ill behaving Teensy in any oddly controlling of critical stuff could wake up and half baked and do bad stuff without supervision.

Also not sure what the Teensy state of I/O is in that 8 second time period? No interrupts or programmatic response can happen - what is the state of the outputs? Are they maintained as last set? Assuming a proper design would fail safe if the Teensy went off/poof ... what is it

Would be nice to commandeer 11 DWORDS of EEPROM for more permanent recall.

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Tim: the shutdown on panic alarm. Yes it us. For testing I made set him temp to 50 and panic temp to 55 and ran over clicked at >800

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Mike: is this code in the current PJRC github as last merged?

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

@PaulStoffregen and @Defragster Between sleep cycles and doing this response - I must be crazy. In response

Looks like we still need checking to only start the 8 seconds when temperature is safe.

Right now on panic alarm there is no reboot. The T4.1 shuts down on panic alarm with the following messages:

Reboot was caused by temperature sensor Panic Temp Exceeded Shutting Down Can be caused by Overclocking w/o Heatsink or other unknown reason

If you still want it to restart as opposed to shutdown let me know. I did mention this up on the thread as well. Tim seemed to agree:

Shutdown seems right.

As I said I am leery of continuing to reboot when the cause for the panic temp is unknown. Before the merge tempmon would shutdown the T4 if the panic temp was reached. Agree more than likely its due to overclocking but ....

mjs513

comment created time in 2 days

issue commentzrepl/zrepl

zrepl killed by kernel OOM

Getting this consistently as well. Receiver end on a single encrypted pull job eventually gets killed.

I'll see if I can gather more useful info. In either case, by looking at is as it's running, it seems memory usage of zrepl is building up incrementally with each STEP.

MAFLO321

comment created time in 2 days

issue commentzrepl/zrepl

strconv.ParseInt: value out of range

@pcd1193182 I think I find you on IRC to send the output on the first two as the output is quite huge. As for the last two:

#  zfs send -nv -Lce -i tank/foo@zrepl_20210309_052222_000 tank/foo@zrepl_20210309_053722_000

send from tank/foo@zrepl_20210309_052222_000 to tank/foo@zrepl_20210309_053722_000 estimated size is 50.7M
total estimated size is 50.7M

(on recipient)

# zfs get -o value receive_resume_token $recvfs
VALUE
1-13f18c2996-140-789c636064000310a501c49c50360710a715e5e7a69766a6304081fb43adb9fc074adb15806c762475f94959a9c9250c0ca6507518f26969c5a9250c7000926743924faa2c492d06d2474ab1eb2fc987b8a239725a31fb8f3f9d0148f29c60f9bcc4dc54068682a2ccbce4d4f8e2e214fdf49cd2e292d422dd94c4924487aaa2d4829c78230323430363038b78034b037323a37803030324f7703320c221393fb7a028b5b8383f1b222601752f4cbe28b11c26c5000003a93139
genofire

comment created time in 2 days

issue commentzrepl/zrepl

notify mechanism when something goes wrong

I found the hook system for snapshot jobs a good solution, is possible to implement also in push jobs? https://zrepl.github.io/configuration/snapshotting.html#pre-and-post-snapshot-hooks? I use zrepl to snapshot the customer server periodically and then like every night send a replication to a central server. Thank you

almoondsllc

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

The only thing I'm wondering is startup.c might have is in https://forum.pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1?p=281851&viewfull=1#post281851

Though of course without the call to CrashReport - then there would be 'fast' repeated reboot. Unless there was a 'weak' call the user could add to sketch to replace the default wait for reaction of their choosing.

That "weak void userCrashReport() { // on prior Crash wait 8 secs }" then enter setup() Sketch "void userCrashReport()" - could wait for Serial - or other - and then stream the output to a place of their choosing - that might solve KurtE's issue where it could go to elsewhere. Not a simple as "if ( CrashReport ) {" - but that would still work, and pasting a template copy of userCrashReport() could give more control?

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Figured not ... doing a flush() that waits forever would be bad.

perhaps auto clear is weak - better to see it twice and then have it clear()'d, than to not get to see it at all if the user codes it wrong - they still can if they do a clear() with a ready stream. Given how easy it is to call Serial.print(CrashReport); it wasn't much harder to overtly call .clear() when the user so chooses confirming the Report was seen ... as the user sees fit to code it.

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

No, there is no API to query buffer status. But the API does have a flush() function which waits (or is supposed to wait) until all data is actually transmitted.

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Can p.print tell when the data actually gets 'stream'ed?

Right now it does the clear() no verification Serial or whatever the output device was receptive.

mjs513

comment created time in 2 days