**** BEGIN LOGGING AT Fri Jan 28 02:59:57 2022
Jan 28 03:04:45 <set_> Has anyone cross-compiled the Native_SDK any time recently?
Jan 28 03:45:20 <set_> Anyway...no issue. I will keep on trying here.
Jan 28 03:50:29 <set_> Dang it.
Jan 28 03:50:40 <set_> 10 minutes!
Jan 28 03:51:01 <set_> Does someone know how to handle changing the user in bash on a line?
Jan 28 03:51:37 <set_> for instance, my old user on the host is /home/MonTay/ and I need it to be, of course, /home/debian/.
Jan 28 03:57:00 <SJFriedl> What do you mean change the user? change the home directory for a given user?
Jan 28 04:01:26 <set_> Oh.
Jan 28 04:02:12 <set_> ...I have 1*(n) lines of source all w/ /home/MonTay/Dir/Dir/Dir/etc/ and I need to change them to /home/debian/Dir/Dir/Dir/etc/.
Jan 28 04:02:35 <set_> The file contains umpteen lines of the incorrect username.
Jan 28 04:03:14 <SJFriedl> You have a single file that contains a ton of lines like this?
Jan 28 04:03:20 <set_> Yes.
Jan 28 04:03:56 <set_> Silly? Yes.
Jan 28 04:03:58 <SJFriedl> use vi and do a search & replace right in the editor?
Jan 28 04:04:14 <SJFriedl> or is this an operation you have to do repeatedly so want to automate?
Jan 28 04:04:32 <set_> I can and I have tried. There are so many lines. I would rather automate them.
Jan 28 04:04:52 <set_> I found another way but it is "cheating."
Jan 28 04:05:03 <SJFriedl> So many lines - I don't get it. Editors support whole-file search and replace in a single operation.
Jan 28 04:05:11 <SJFriedl> "another way"? Is this a one time thing?
Jan 28 04:05:11 <set_> I added a user, switch the files to the ...?
Jan 28 04:05:20 <set_> Oh.
Jan 28 04:05:28 <set_> You can do that in nano?
Jan 28 04:05:42 <set_> I use nano right now!
Jan 28 04:05:51 <set_> I will go and search.
Jan 28 04:05:57 <SJFriedl> I have no idea, I don't use nano. I use vi. But you can do this on the command line.
Jan 28 04:06:22 <set_> Okay. Off to read up. Thank you for saying it is possible.
Jan 28 04:07:14 <SJFriedl> sed 's|^/home/MonTay/|/home/debian/|' < oldfile > newfile
Jan 28 04:07:20 <SJFriedl> at the command line
Jan 28 04:08:24 <set_> Hmm.
Jan 28 04:08:26 <set_> Nice.
Jan 28 04:08:26 <SJFriedl> the sed command takes a search/replace pattern: s/OLD/NEW/
Jan 28 04:08:32 <set_> Nice!
Jan 28 04:08:35 <set_> I shall try it.
Jan 28 04:08:37 <SJFriedl> though I'm using | instead of / because there's a / in the actual text.
Jan 28 04:08:41 <SJFriedl> the ^ means match start of line
Jan 28 04:09:31 <set_> caret!
Jan 28 04:10:06 <set_> You are smarter than words. I must have passed this up in sed class. Ha. Thank you.
Jan 28 04:10:21 <SJFriedl> standard regular expressions
Jan 28 04:10:30 <set_> Aw.
Jan 28 04:11:03 <set_> So, when there is a "/" in the command, use "|" instead?
Jan 28 04:11:38 <SJFriedl> You can use either one; but if you use s/OLD/NEW/ but the pattern contains a /, there's a lot of escaping.
Jan 28 04:11:52 <set_> I changed my username, copied everything I needed to copy, and then I am going to try in the new username. Oops.
Jan 28 04:11:52 <set_> Oh.
Jan 28 04:11:56 <set_> That makes sense.
Jan 28 04:12:10 <SJFriedl> sed 's/^\/home\/MonTay\//\/home\/debian\//'
Jan 28 04:12:15 <set_> I am going to try your way soon. Ha.
Jan 28 04:12:16 <SJFriedl> that feels clearer
Jan 28 04:12:19 <SJFriedl> :-)
Jan 28 04:12:21 <set_> I understood.
Jan 28 04:12:48 <set_> SJFriedl: Do you remember the atari game Wavy Navy?
Jan 28 04:13:00 <SJFriedl> never been a gamer.
Jan 28 04:13:04 <set_> Me neither.
Jan 28 04:13:10 <set_> I just remember it.
Jan 28 04:13:31 <SJFriedl> have never paid attention to them one way or the other, so wouldn't remember a name.
Jan 28 04:13:40 <set_> Okay. No issue.
Jan 28 04:14:03 <set_> My cp -r * ../NewUsername/ is taking forever.
Jan 28 04:14:06 <set_> Oops.
Jan 28 04:14:42 <SJFriedl> Not a bad idea to add -v to that cmdline so you can keep an eye on what it's doing.
Jan 28 04:15:07 <SJFriedl> some Linux distributions add -v automatically (via shell aliases)
Jan 28 04:15:17 <set_> Hmm.
Jan 28 04:15:38 <set_> What does the -v do?
Jan 28 04:15:42 <set_> Oh!
Jan 28 04:15:44 <SJFriedl> verbose
Jan 28 04:15:49 <set_> Right.
Jan 28 04:16:16 <set_> Like when tar'ing a file w/ -xvf
Jan 28 04:16:25 <SJFriedl> v for verbose is common
Jan 28 04:16:45 <set_> Right. I have noticed that idea to be completely true.
Jan 28 04:16:53 <set_> -v = verbose
Jan 28 04:17:09 <set_> && -v == verbose
Jan 28 04:17:14 <SJFriedl> but it's not universal - sometimes it means "tell me your version number"
Jan 28 04:17:30 <set_> Aw. Right.
Jan 28 04:17:33 <set_> That it true.
Jan 28 04:21:39 <set_> Okay. I tried it and I think it worked.
Jan 28 04:23:45 <set_> the error is telling me my files are different...blah. Anyway, it is past 10:00. I should get some rest.
Jan 28 06:06:08 <Trinath> HI
Jan 28 06:07:23 <Trinath> i have a question regarding beagle board x15 pcie
Jan 28 06:08:50 <Trinath> i am using beagle board x15 pcie as an endpoint
Jan 28 06:09:16 <Trinath> i configured pci-epf-test driver
Jan 28 06:10:21 <Trinath> and followed the procedure mentioned in the below link for testing my endpoint
Jan 28 06:10:22 <Trinath> https://mjmwired.net/kernel/Documentation/PCI/endpoint/pci-test-howto.txt
Jan 28 06:10:45 <Trinath> everything is working fine
Jan 28 06:11:10 <Trinath> all the tests are passed
Jan 28 06:13:25 <Trinath> Now i restarted my Root complex board (LS1043ARDB), then the LTSSM_EN bit of register PCIECTRL_TI_CONF_DEVICE_CMD is being cleared. When i re-enabled it again, BARs are not being assigned properly.
Jan 28 06:14:33 <Trinath> Some of the registers (which are cleared by fundamental reset) are also being cleared on root complex restart
Jan 28 06:17:17 <Trinath> How may i reconfigure again
Jan 28 06:17:42 <Trinath> when link fails
Jan 28 06:23:01 <Trinath> Note : LTSSM_EN bit of register PCIECTRL_TI_CONF_DEVICE_CMD in beagle board x15
Jan 28 10:14:58 <set_> Rise and shine!
Jan 28 10:18:45 <set_> Does Native_SDK have a reasonable cross-compile idea or does native compiling suit it better?
Jan 28 10:24:07 <set_> The reason I am asking is b/c of the sftp to the BBB or BBBW in this instance has naming concerns that are not solved easily.
Jan 28 10:27:06 <set_> Anyway...I will keep trying. I even started a thread of a post on their forums regarding my ideas/errors and more.
Jan 28 10:28:25 <set_> Oh!
Jan 28 10:28:36 <set_> Look what I found: https://powervr-graphics.github.io/ .
Jan 28 10:28:43 <set_> Okay. Let me try this idea.
Jan 28 10:42:46 <set_> it seems wget does not work w/ that download. Hmm...off to try another resource.
Jan 28 13:07:53 <Guest49> hi anyone here?
Jan 28 13:09:45 <Guest49> just got beagle bone black, total noob on this, having issues with it connecting on hdmi got a philips curved monitor, tux logo appears in cornere then hdmi drops out any suggestions please
Jan 28 14:43:55 <jkridner> do you have a serial log?
Jan 28 14:44:06 <jkridner> or maybe output of dmesg?
Jan 28 15:22:50 <zmatt> set_: "wget does not work with that download" ?
Jan 28 15:25:50 <zmatt> set_: if you're getting some sort of certificate error, it's a known issue caused by TLS libraries mishandling the expiration of a certain root certificate.  two workarounds are given here: https://pastebin.com/uXrzuPTq
Jan 28 15:34:46 <rcn-ee> it's going to be funner... https://www.bleepingcomputer.com/news/security/lets-encrypt-is-revoking-lots-of-ssl-certificates-in-two-days/
Jan 28 15:37:24 <zmatt> wow, there are actually people using TLS-ALPN-01 challenge based validation? :D
Jan 28 15:38:43 <zmatt> this sounds like it'll probably be a non-issue, and will at worst be a transient interruption for a small number of sites whose administrators don't read their email
Jan 28 15:50:04 <zmatt> and at least some tools will automatically renew the certificate anyway
Jan 28 17:51:49 <jfsimon1981> Hi, do you have any hint about this issue (kernel panic) ?
Jan 28 17:51:51 <jfsimon1981> Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa3021b2
Jan 28 17:52:15 <jfsimon1981> With a lot of info coming afterwards
Jan 28 17:52:18 <jfsimon1981> pgd = a36d7267
Jan 28 17:52:22 <zmatt> don't paste into chat
Jan 28 17:52:28 <zmatt> use a paste service like pastebin.com
Jan 28 17:53:08 <zmatt> that line itself is unfortunately not informative, it just means it got a fault on accessing something
Jan 28 17:53:31 <jfsimon1981> https://pastebin.com/849j3PbK
Jan 28 17:53:47 <jfsimon1981> ok
Jan 28 17:54:21 <jfsimon1981> I have a program running with PMW output, analog input read, etc...
Jan 28 17:57:16 <zmatt> looks like the eqep kernel driver crashed
Jan 28 17:57:58 <zmatt> which iirc is a non-mainline driver maintained out-of-tree, so my guess would be it's simply a driver bug
Jan 28 17:58:52 <zmatt> presumably something to do with power management, i.e. it tried to access PWMSS while access to PWMSS was not enabled
Jan 28 17:58:57 <jfsimon1981> that makes sense
Jan 28 17:59:30 <zmatt> it actually looks like it interrupted some runtime power management code, so it's probably a race condition of sorts
Jan 28 17:59:45 <jfsimon1981> I messed with analog read on this build and read a block device at iio:device0
Jan 28 17:59:54 <zmatt> that's probably not related
Jan 28 18:00:35 <jfsimon1981> ah
Jan 28 18:01:25 <zmatt> are you using eqep ?
Jan 28 18:01:43 <zmatt> I would assume so, given that it's evidently producing interrupts
Jan 28 18:02:16 <jfsimon1981> not sure what this is
Jan 28 18:02:26 <zmatt> although it's a bit weird that it would not be enabled.. generally it should be enabled continuously
Jan 28 18:02:32 <zmatt> hmm
Jan 28 18:03:02 <jfsimon1981> i'm not aware using it, the program makes use of ADC input an0 and pwm modules
Jan 28 18:03:13 <zmatt> curious
Jan 28 18:05:31 <zmatt> ohh, eqep seems to be constantly producing interrupts
Jan 28 18:06:14 <zmatt> based on: grep eqep /proc/interrupts
Jan 28 18:07:18 <jfsimon1981> ok
Jan 28 18:07:24 <zmatt> hold on, but I have pwmss force-enabled right now... let's see if pwmss otherwise gets power-managed
Jan 28 18:07:25 <jfsimon1981> i don't see it
Jan 28 18:07:52 <zmatt> you're not seeing the counters increase?  what if you enable a pwm output?
Jan 28 18:08:12 <jfsimon1981> ah
Jan 28 18:08:29 <jfsimon1981> i change the pwm duty cycle all the time on this program
Jan 28 18:08:59 <jfsimon1981> only I thing I changed is i disable the pwm (0 > enable) when not in use
Jan 28 18:09:00 <zmatt> you're seeing eqep's interrupt counters increase when you have a pwm output enabled?
Jan 28 18:09:14 <jfsimon1981> how can i check this ?
Jan 28 18:09:38 <zmatt> by enabling a pwm output and using the command I just gave, grep eqep /proc/interrupts
Jan 28 18:10:00 <zmatt> and see if one or more of the counters in the second column are slowly increasing
Jan 28 18:11:20 <zmatt> what exactly did you mean by "i don't see it" earlier?
Jan 28 18:11:24 <zmatt> maybe I misinterpreted you
Jan 28 18:12:50 <zmatt> if eqep's interrupt counters only increase if you have pwm outputs enabled then I understand what's going on
Jan 28 18:12:58 <SJFriedl> I know I've been able to disable the BeagleBone bluetooth radio in the past but cannot for the life of me find it. Something about uEnv.txt maybe? Google has failed me.
Jan 28 18:13:03 <SJFriedl> BBBW
Jan 28 18:13:35 <zmatt> SJFriedl: you can disable individual functions using rfkill
Jan 28 18:13:50 <SJFriedl> will that disable the actual radio emissions?
Jan 28 18:14:01 <zmatt> yes, that's why rfkill is called rfkill
Jan 28 18:14:07 <SJFriedl> excellent, thank you. This is new to me.
Jan 28 18:14:50 <jfsimon1981> ok, well it does not seem to change
Jan 28 18:14:53 <jfsimon1981> 138:          0      INTC  79 Level     eqep_interrupt
Jan 28 18:14:53 <jfsimon1981> 140:          6      INTC  88 Level     eqep_interrupt
Jan 28 18:14:53 <jfsimon1981> 142:          0      INTC  89 Level     eqep_interrupt
Jan 28 18:15:26 <zmatt> jfsimon1981: regardless of whether any pwm outputs are enabled?
Jan 28 18:15:58 <zmatt> (with non-zero duty cycle, just in case)
Jan 28 18:17:31 <jfsimon1981> trying
Jan 28 18:18:12 <zmatt> jfsimon1981: I just tested it here, if I enable a pwm output I see the interrupt counter of the eqep unit in the same pwmss slowly increase
Jan 28 18:18:23 <zmatt> that's absolutely a bug in the eqep driver
Jan 28 18:18:44 <jfsimon1981> ok i don't quite understand this at the moment
Jan 28 18:19:52 <zmatt> so, the eqep driver is evidently not keeping the eqep device enabled, yet it does have an interrupt handler enabled which moreover gets periodic interrupts whenever the eqep module happens to be enabled anyway
Jan 28 18:20:34 <zmatt> the three submodules (ecap, eqep, ehrpwm) of a pwmss module are however not individually power-managed, only the subsystem as a whole is
Jan 28 18:21:14 <zmatt> so what's happening is that if the driver for any of the three submodules requests the module to be enabled, the whole pwmss is enabled and subsequently all three submodules
Jan 28 18:22:48 <zmatt> e.g. enabling a pwm output causes the corresponding driver (ecap or ehrpwm, depending on what pwm output you're using) to enable the pwmss to be able to operate the pwm output
Jan 28 18:23:22 <zmatt> and as a side-effect, the eqep module in the pwmss is also enabled, causing its periodic interrupts to resume
Jan 28 18:24:00 <jfsimon1981> i see a number increasing indeed
Jan 28 18:24:23 <jfsimon1981> not sure this is what you meant
Jan 28 18:24:27 <jfsimon1981> 140:        101      INTC  88 Level     eqep_interrupt
Jan 28 18:24:36 <jfsimon1981> the 101 gets increased
Jan 28 18:24:39 <zmatt> that's showing that the eqep driver is receiving interrupts yes
Jan 28 18:25:08 <zmatt> this is bogus since it's not keeping the eqep module enabled
Jan 28 18:25:20 <zmatt> the eqep module is merely being enabled by accident as side-effect of the pwm output
Jan 28 18:25:41 <zmatt> consequently, if the pwm output is disabled again, the eqep module also gets disabled again
Jan 28 18:25:44 <jfsimon1981> it increases only when pwm is enabled.
Jan 28 18:26:33 <zmatt> if the eqep interrupt by pure accident happens to trigger right at the moment eqep gets disabled by the kernel, the interrupt handler will try to access eqep while it's disabled, resulting in a bus error and kernel panic
Jan 28 18:26:43 <zmatt> this is straight up a bug in the eqep kernel driver
Jan 28 18:27:29 <zmatt> it looks like the eqep driver is compiled into the kernel rather than being built as module, so unfortunately you can't simply blacklist the driver
Jan 28 18:27:50 <SJFriedl> how the heck have I missed rfkill all my life? Thanks zmatt
Jan 28 18:28:05 <zmatt> SJFriedl: it *should* be persistent across reboot
Jan 28 18:28:16 <SJFriedl> To my delight, it was. Thank you.
Jan 28 18:28:35 <zmatt> jfsimon1981: however, the eqep modules can be easily disabled using an overlay
Jan 28 18:28:47 <jfsimon1981> thanks Matt, either i'll be able to deal with this or i'll design the hardware externally to make use of PWM, which i definitely require for this purpoe.
Jan 28 18:28:55 <jfsimon1981> Ah ah
Jan 28 18:29:59 <zmatt> or you can force-enable pwmss manually
Jan 28 18:30:12 <zmatt> or just never disable a pwm output when enabled
Jan 28 18:32:14 <zmatt> jfsimon1981: https://pastebin.com/H7FiWVV1   this force-enables all three pwmss instances (you'll see all three eqep interrupt counters increase regardless of whether or not a pwm output is enabled)
Jan 28 18:32:43 <jfsimon1981> thank you
Jan 28 18:33:10 <zmatt> or you can disable the buggy eqep kernel driver by using the uio/eqep[0-2].dtbo overlays from my overlay-utils project
Jan 28 18:33:37 <zmatt> (you could also combine them into one overlay to reduce the number of overlays enabled)
Jan 28 18:35:33 <zmatt> jfsimon1981: pretty unlucky to get that kernel panic though!  it looks like the interrupt only happens once per second, and to get the kernel panic requires that interrupt to happen within a time window that's probably a small fraction of a microsecond
Jan 28 18:36:16 <jfsimon1981> this program works at about 150 Hz, not sure that's related, but it has a short loop
Jan 28 18:36:38 <jfsimon1981> Ok running this pastbin instructions of yours, at the moment the kernel did'nt panic ...
Jan 28 18:36:49 <zmatt> what would matter is how often you're disabling a pwm output
Jan 28 18:38:24 <jfsimon1981> oddly the last code never disabled it but set the duty very low.
Jan 28 18:38:49 <jfsimon1981> Seems to work
Jan 28 18:38:56 <jfsimon1981> Thanks for this
Jan 28 18:39:16 <zmatt> it's possible the pwm driver disables the output if the duty cycle is zero (when rounded to the resolution of the output)
Jan 28 18:39:27 <zmatt> not sure, I'd need to check the driver
Jan 28 18:39:52 <jfsimon1981> too complicated this beagle, has a lot features.
Jan 28 18:40:29 <jfsimon1981> Works stable at the moment.
Jan 28 18:41:56 <zmatt> oh as for what eqep does: it can do quadrature decoding and pulse frequency measurement, typically used for things like measuring motor speed
Jan 28 18:42:13 <jfsimon1981> ok
Jan 28 18:42:58 <jfsimon1981> back the full working code, see if it get running smooth now
Jan 28 18:45:58 <jfsimon1981> i'd call that luck it triggered this bug, better sort it now than when the device is running in the field which it would be in a few weeks
Jan 28 18:46:10 <zmatt> fair!
Jan 28 18:47:11 <zmatt> if you're not using eqep, disabling it is probably better than the force-enable workaround... better if the buggy kernel driver doesn't get used at all
Jan 28 18:49:21 <zmatt> "oddly the last code never disabled it but set the duty very low" => as far as I can tell this should not implicitly disable the pwm module hence should not be able to trigger the kernel panic
Jan 28 18:50:38 <jfsimon1981> just loading one of those ?
Jan 28 18:50:40 <jfsimon1981> bone_eqep0-00A0.dtbo  [... eqep1 ... eqep2 ... eqep2b]
Jan 28 18:50:52 <zmatt> ??
Jan 28 18:51:14 <jfsimon1981> did you mean i should load in uEnv.txt
Jan 28 18:51:23 <jfsimon1981> to enable
Jan 28 18:51:29 <zmatt> those overlays would actually *enable* the eqep modules, which is pointless since you already have them enabled
Jan 28 18:52:01 <jfsimon1981> ok
Jan 28 18:52:41 <zmatt> I was specifically referring to overlays in my overlay-utils project that reconfigure the eqep modules for use via uio (which, if you don't use these, is effectively equivalent to disabling the eqep modules)
Jan 28 18:54:29 <jfsimon1981> ok
Jan 28 18:54:33 <zmatt> https://github.com/mvduin/overlay-utils  ... if you clone this and run make, it'll build these (eqep0.dtbo, eqep1.dtbo, eqep2.dtbo) in the uio/ subdirectory
Jan 28 18:55:18 <jfsimon1981> ok
Jan 28 18:57:21 <zmatt> jfsimon1981: or you could save this as "disable-eqeps.dtsi": https://pastebin.com/1tKb9heD   and then run "make disable-eqeps.dtbo"
Jan 28 18:57:52 <zmatt> to create an overlay that truly disables the eqep modules (and does nothing else)
Jan 28 18:59:56 <jfsimon1981> Cloned and built dtbo and dtsi
Jan 28 19:00:19 <jfsimon1981> i'll be back in a moment
Jan 28 19:37:26 <jfsimon1981> Running on disable_eqeps.dtbo and commented out the workaround (48300000.epwmss ...).
Jan 28 19:53:49 <jfsimon1981> cat /proc/interrupts | grep eqep
Jan 28 19:54:05 <jfsimon1981> No results returned. Looks worked well.
Jan 28 22:01:06 <jfsimon1981> Supply down 360 -> 240 mA throttling the frequency
Jan 28 22:01:10 <jfsimon1981> sudo cpufreq-set -d 300 -u 1000
Jan 28 22:01:29 <jfsimon1981> However cannot get it back up (will only work at 300 MHz from this point on)
Jan 28 22:24:15 <jfsimon1981> Apparently the watchdog got turned on automatically by a cat on the device
Jan 28 22:24:23 <jfsimon1981> Rebooted on me
Jan 28 22:29:42 <jfsimon1981> Once you cat on :dev/watchdog0 it stars running and needs update. awesome
Jan 28 22:31:02 <zmatt> jfsimon1981: fortunately only root can open the watchdog device
Jan 28 22:31:29 <zmatt> normally I'd expect systemd to have opened it though
Jan 28 22:32:35 <zmatt> hmm, maybe that's not enabled by default
Jan 28 22:34:27 <zmatt> ah that requires e.g. RuntimeWatchdogSec or RebootWatchdogSec to be configured in /etc/systemd/system.conf
Jan 28 22:34:37 <hnv> I was about to ask if it's enabled by default (and reset by systemd)... (Also I was initially thinking of cats and dogs)
Jan 28 22:35:30 <hnv> (* not a Dog, a Cat triggering something...)
Jan 28 22:36:30 <zmatt> jfsimon1981: what cpufreq governor are you using?
Jan 28 22:38:35 <jfsimon1981> no idea
Jan 28 22:39:51 <zmatt> then why are you setting the min/max frequency for that unknown governor to use? :D
Jan 28 22:40:05 <zmatt> 300-1000 is the default anyway
Jan 28 22:40:53 <zmatt> if I select the ondemand or conservative governor I can see it's dynamically switching between frequencies
Jan 28 22:41:00 <jfsimon1981> i set 300-1000 but it seems stuck at 300
Jan 28 22:41:16 <zmatt> again, which governor? check with cpufreq-info
Jan 28 22:41:21 <jfsimon1981> ok
Jan 28 22:42:12 <jfsimon1981> i see
Jan 28 22:42:31 <zmatt> powersave = always min frequency, performance = always max frequency
Jan 28 22:42:56 <jfsimon1981> yep current policy 300-300 MHz
Jan 28 22:43:17 <jfsimon1981> not sure how I set this but that's fixed 300 MHz now.
Jan 28 22:43:34 <zmatt> ondemand seems to be min freq when idle, max freq when not idle... so cpufreq-info will always see it at 1 GHz (since running cpufreq-info means the cpu isn't idle) but you'll see the 300 MHz statistic increasing in between calls to cpufreq-info
Jan 28 22:43:50 <jfsimon1981> indeed  i'll set powersave something like this. That's a low consumption application i'm working on
Jan 28 22:44:42 <zmatt> if you select the powersave governor then it'll be stuck at 300 MHz regardless of the max frequency configured
Jan 28 22:46:22 <jfsimon1981> ok
Jan 28 22:46:44 <zmatt> "conservative" may be the governor you're looking for
Jan 28 22:49:03 <zmatt> and you're correct, "cpufreq-set -d 300 -u 1000" forces the system to lowest frequency, this is because you didn't include any units and the default unit is kHz
Jan 28 22:49:29 <jfsimon1981> set in range 300-720 Mhz
Jan 28 22:49:38 <zmatt> "cpufreq-set -d 300MHz -u 1GHz"  would work ... though like I said
Jan 28 22:49:47 <zmatt> the full range is already the default
Jan 28 22:51:13 <zmatt> so the only reason to set the change is to set a lower max than 1GHz or higher min than 300MHz
Jan 28 22:51:25 <zmatt> *to set the range
Jan 28 22:51:40 <jfsimon1981> i set -u 720MHz
Jan 28 22:51:57 <jfsimon1981> conservative
Jan 28 22:52:01 <jfsimon1981> for the moment
Jan 28 22:53:21 <jfsimon1981> good shape
Jan 28 22:53:48 <jfsimon1981> watchdog enabled and solved the random crash, and added a kernel panic auto reboot.
Jan 28 22:54:00 <zmatt> also keep in mind that setting a lower max frequency may not always work out to lower overall power consumption for a given workload, since lower frequency means that workload takes more time to execute, hence there's less cpu idle time.  it'll depend on how much the power consumption varies between 720 MHz and 1 GHz, and how effective powersaving during cpuidle is
Jan 28 22:54:02 <jfsimon1981> This device should do good
Jan 28 22:54:26 <jfsimon1981> right, i did'nt measure it all
Jan 28 22:54:33 <zmatt> like I said, for watchdog: set the RuntimeWatchdogSec parameter in /etc/systemd/system.conf
Jan 28 22:54:51 <zmatt> to make systemd enable the hardware watchdog and periodically ping it
Jan 28 22:55:02 <jfsimon1981> the application runs 1/3 which seems fine though i'll need test all of this
Jan 28 22:56:46 <jfsimon1981> if you just cat the /dev/watchdog it starts
Jan 28 22:56:57 <jfsimon1981> the default period is 60 sec
Jan 28 22:57:29 <zmatt> I wouldn't suggest messing with the watchdog device directly
Jan 28 22:57:58 <zmatt> leave it to systemd, or something like watchdogd on non-systemd systems
Jan 28 22:59:15 <zmatt> if you want your application to be restarted when it crashes or freezes, you can arrange that in a systemd service for
Jan 28 22:59:18 <zmatt> *service file
Jan 28 23:00:46 <zmatt> (you can even configure it so that if your application keeps crashing at startup, systemd will give up restarting your application after a few attempts and reboot the system instead)
Jan 28 23:01:47 <jfsimon1981> ok
Jan 28 23:01:58 <jfsimon1981> quite powerful
Jan 28 23:02:07 <zmatt> yup, lots of options
Jan 28 23:03:28 <zmatt> to detect services that are frozen (but not properly crashed) systemd supports "service watchdogs" .. which means your servics needs to periodically notify systemd that it's alive or systemd will restart the service after a timeout
Jan 28 23:04:40 <jfsimon1981> ah ah
Jan 28 23:06:55 <jfsimon1981> well the program seems to be working, so I can get back to work on the electronics quite soon
Jan 28 23:07:01 <jfsimon1981> tomorrow
Jan 29 01:06:57 <set_> @zmatt: Thank you. i will review that idea in a bit.
Jan 29 01:09:00 <set_> bbl!
Jan 29 01:14:12 <set_> phew. Back. What a ride!
Jan 29 01:22:03 <set_> @zmatt: I am pretty sure my error(s), many-many-many error(s), are not specifically direceted at me via output b/c of the TLS libraries.
Jan 29 01:22:14 <set_> But...if they are due to TLS libs, blah.
Jan 29 01:22:27 <set_> I would not know how to handle putting a driver. ha.
Jan 29 01:22:48 <set_> Golf humor.
Jan 29 01:22:50 <set_> Sorry.
Jan 29 01:23:19 <set_> Anyway, back to the old BBB and trying to replicate something I cannot do so far.
Jan 29 01:25:39 <set_> Native_SDK is a vast lib. w/ many different confurations that need to take place at different intervals. So, it is a bit too in depth for me to handle, esp. when an error shows me this: https://pastebin.com/YaZnqxuU !
Jan 29 01:26:15 <set_> If you are bored or happy to pick and choose, jump on in!
Jan 29 01:34:12 <set_> Would I need to reorganize the source or just use ld <someFile> ?
**** ENDING LOGGING AT Sat Jan 29 02:59:57 2022