**** BEGIN LOGGING AT Sun Nov 15 02:59:56 2020
Nov 15 03:09:06 <Grommish> Interesting...  the build system uses $(TMP_DIR)/$(TMPDIR) as $(TOP_DIR)/tmp..  Why is it writing to tmp to disk?  Is there any reason I shoudln't just symlink ./tmp to /tmp?
Nov 15 03:09:48 <Grommish> I am cringing at all the cycles this ssd has gone thru with tmp being io'd like that
Nov 15 03:22:16 <Grommish> at least it's using the system ram now.. wonder if it's faster in the build though
Nov 15 10:31:59 <rsalvaterra> dangole: I'm going to break zram. :P
Nov 15 10:32:13 <rsalvaterra> https://lore.kernel.org/linux-block/20201115101514.954-1-rsalvaterra@gmail.com/
Nov 15 11:12:25 <ReDaLeRt> Hello.
Nov 15 11:12:38 <ReDaLeRt> I'm using a Ea7500 v1 with these settings:
Nov 15 11:13:28 <ReDaLeRt> https://pastebin.com/Q2vCcswH
Nov 15 11:13:52 <ReDaLeRt> But I can't get the TX rate above 400 Mbps. Just the RX is 866Mbps.
Nov 15 11:14:23 <ReDaLeRt> I'm close to the router and the 5GHz band channel selected is empty (apart from my one router)
Nov 15 11:15:11 <ReDaLeRt> On the status page, the client get its TX is limited to 40 MHz, but the RX gets 80 MHz.
Nov 15 11:15:29 <PaulFertser> ReDaLeRt: the rate control algorithms are monitoring the results all the time and choose the best possible option. I suggest you to check the link with "iw dev wlan0 station dump" at the moment when the link is fully loaded (that is, when you're running the speed test in the direction you want).
Nov 15 11:15:40 <PaulFertser> ReDaLeRt: that would show you what specific MCS and other link parameters are used.
Nov 15 11:21:03 <ReDaLeRt95> well, everytime the router reboots, I get a mad TX rate of 24mbps:
Nov 15 11:21:21 <ReDaLeRt95> https://pastebin.com/LmYqX5Np
Nov 15 11:21:43 <ReDaLeRt95> Just after many hours the TX rate "corrects" to 400 mbps under load.
Nov 15 11:22:02 <ReDaLeRt95> I'm now getting:
Nov 15 11:22:03 <ReDaLeRt95> 866.7 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 2, Short GI24.0 Mbit/s, 20 MHz
Nov 15 11:22:21 <PaulFertser> ReDaLeRt95: but not before? So if you push some load through it, it still stays at 24 Mb/s, do I get it right?
Nov 15 11:22:35 <ReDaLeRt95> yes, it stays at 24mbps under logs.
Nov 15 11:22:39 <ReDaLeRt95> *under load
Nov 15 11:22:50 <PaulFertser> And takes hours to change? Now that's odd.
Nov 15 11:22:58 <ReDaLeRt95> Yup.
Nov 15 11:22:58 <PaulFertser> Is that the Tx rate on the router itself?
Nov 15 11:23:07 <ReDaLeRt95> yes, on the status page
Nov 15 11:23:35 <PaulFertser> For the reference, MCS explained https://en.wikipedia.org/wiki/802.11ac#Data_rates_and_speed
Nov 15 11:24:05 <PaulFertser> So MCS 9 is the maximum, and apparently your client chooses it.
Nov 15 11:24:29 <ReDaLeRt95> this is weird:
Nov 15 11:24:30 <ReDaLeRt95>       tx bitrate:     24.0 MBit/s        tx duration:    87357367 us        rx bitrate:     866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2        rx duration:    0 us
Nov 15 11:24:57 <ReDaLeRt95> why the tx duration is that higher?
Nov 15 11:25:00 <PaulFertser> ath10k is not known to misbehave like that, this disbalance is rather odd.
Nov 15 11:26:12 <rsalvaterra> PaulFertser: I have the vague idea that ath10k hardware doesn't report the TX rate.
Nov 15 11:26:43 <PaulFertser> rsalvaterra: but then it wouldn't correlate to real throughput values.
Nov 15 11:26:54 <rsalvaterra> PaulFertser: True, that.
Nov 15 11:26:56 <PaulFertser> ReDaLeRt95: do I get it right that throughput testing confirms those rates?
Nov 15 11:27:12 <ReDaLeRt95> yes, both speedtest.net and iperf3
Nov 15 11:27:26 <PaulFertser> ReDaLeRt95: is that the same with different clients or do you have just one 802.11ac to test with?
Nov 15 11:27:30 <ReDaLeRt95> https://forum.openwrt.org/t/linksys-ea7500-v1-and-openwrt/58205/45
Nov 15 11:27:45 <ReDaLeRt95> with an intel 8265 and a samsung J7
Nov 15 11:28:26 <ReDaLeRt95> if I load it with 64 iperf3 streams, I get the 400 mbps 40 MHz full bandwith, at the same time...
Nov 15 11:29:00 <rsalvaterra> ReDaLeRt95: Which firmware are you using?
Nov 15 11:29:18 <ReDaLeRt95> yesterday snapshot
Nov 15 11:29:38 <rsalvaterra> No, I mean which ath10k firmware variant.
Nov 15 11:29:47 <ReDaLeRt95> SNAPSHOT, r14935-95b0751d0f
Nov 15 11:30:01 <ReDaLeRt95> 8064
Nov 15 11:30:14 <rsalvaterra> ReDaLeRt95: opkg list-installed grep ath10k
Nov 15 11:30:22 <rsalvaterra> | grep
Nov 15 11:30:35 <ReDaLeRt95> ath10k-firmware-qca99x0-ct - 2020-07-02-1kmod-ath10k-ct - 5.4.75+2020-06-30-edfbf916-1
Nov 15 11:30:47 <ReDaLeRt95> ath10k-firmware-qca99x0-ct - 2020-07-02-1kmod-ath10k-ct - 5.4.75+2020-06-30-edfbf916-1
Nov 15 11:30:52 <ReDaLeRt95> (sorry)
Nov 15 11:31:31 <rsalvaterra> Hm. You're also using the ath10k-ct driver, correct?
Nov 15 11:31:49 <ReDaLeRt95> kmod-ath10k-ct - 5.4.75+2020-06-30-edfbf916-1
Nov 15 11:32:11 <ReDaLeRt95> It seems to.
Nov 15 11:32:47 <rsalvaterra> Ok. The first thing I'd try would be to use the -htt variant.
Nov 15 11:34:06 <ReDaLeRt95> ath10k-firmware-qca99x0-ct-full-htt
Nov 15 11:34:07 <ReDaLeRt95> or
Nov 15 11:34:13 <ReDaLeRt95> ath10k-firmware-qca99x0-ct-htt
Nov 15 11:34:13 <ReDaLeRt95> ?
Nov 15 11:34:36 <rsalvaterra> ath10k-firmware-qca99x0-ct-htt
Nov 15 11:35:20 <ReDaLeRt95> Do i need to remove the ct only version after installing the ct-htt?
Nov 15 11:37:03 <rsalvaterra> ReDaLeRt95: I'd advise you to build an image with the image builder. I personally haven't used opkg in years, so I don't remember the restrictions.
Nov 15 11:37:45 <ReDaLeRt95> do you mean compiling the openwrt source code and using the menuconfig to replace those packadges?
Nov 15 11:38:01 <PaulFertser> Probably they conflict already so opkg will remove the other version automatically.
Nov 15 11:38:34 <ReDaLeRt> OK. (changed to another PC :))
Nov 15 11:39:16 <rsalvaterra> ReDaLeRt: You could build from scratch, yes. But the image builder is a great compromise for most people. https://openwrt.org/docs/guide-user/additional-software/imagebuilder
Nov 15 11:39:53 <rsalvaterra> ReDaLeRt: And you're Portuguese too, I see. ;)
Nov 15 11:40:02 <ReDaLeRt> Sim. :P
Nov 15 11:40:32 <rsalvaterra> Keep it English here, though. :)
Nov 15 11:41:38 <ReDaLeRt> the pain is that taking almost an hour, even with parallel compiling.
Nov 15 11:42:37 <rsalvaterra> ReDaLeRt: Don't complain. A full build from scratch takes about 4 hours on my system (but I'm crazy enough to use computers until they break, so I'm using a system from 2006).
Nov 15 11:42:38 <PaulFertser> Firmware can be installed even manually, that's all just files in /lib/firmware
Nov 15 11:43:06 <PaulFertser> rsalvaterra: don't you fix them after they break and continue using? ;)
Nov 15 11:43:26 <rsalvaterra> PaulFertser: Bah… :P
Nov 15 11:43:32 <PaulFertser> rsalvaterra: my laptop has literally welded plastic and long screws holding it together
Nov 15 11:44:19 <rsalvaterra> PaulFertser: I'm not punishing laptops with OpenWrt builds… That's a workstation job. ;)
Nov 15 11:44:51 <DonkeyHotei> i build on my laptop with 8 gigs ram
Nov 15 11:44:53 <PaulFertser> 3d printing filament plus SMD soldering hot air gun can do wonders (after few hours of training to weld that way)
Nov 15 11:45:21 <rsalvaterra> PaulFertser: I don't have the equipment for that… yet…
Nov 15 11:45:51 <rsalvaterra> DonkeyHotei: my build machine has 4 GiB of RAM, of which 3.2 are actually available. :)
Nov 15 11:46:09 <PaulFertser> rsalvaterra: I have some cheap luckey soldering/rework station for years, it's OK. Got ts100 soldering iron recently and that's much better though.
Nov 15 11:46:27 <dangole> ReDaLeRt: just use the ImageBuilder, that should take a few second and doesn't involve any compiling
Nov 15 11:46:34 <ReDaLeRt> My PC is not that newer, is from 2011, but with an intel 2500k overlocked to 4.3 GHz, and 16 Gb of RAM.
Nov 15 11:47:13 <dangole> ReDaLeRt: i think you are building from source, as you have mentioned menuconfig before. ImageBuilder doesn't have menuconfig
Nov 15 11:47:28 <ReDaLeRt> yup, compiling it from the github source code.
Nov 15 11:47:54 <dangole> ReDaLeRt: my host similar, i5 M560 made in 2011, 8GB of RAM
Nov 15 11:47:55 <rsalvaterra> PaulFertser: I'll get there, eventually… but what I need first is a flash reader/programmer and a SOP8 clip. I still hope I can teach my TL-SG2008 v1 a few new tricks (and replace that awful VxWorks with OpenWrt)…
Nov 15 11:48:27 <dangole> ReDaLeRt: just download ImageBuilder for your target and that can assemble an image (ie. kernel+squashfs) within seconds with exactly the packages you like
Nov 15 11:48:57 <rsalvaterra> ReDaLeRt: If you're compiling from the source, you just have to select the desired firmware variant in the Firmware menu.
Nov 15 11:49:10 <PaulFertser> rsalvaterra: I use my TUMPA (full) for flash programming, it's much better in all regards (and can do much more too) than all those ch341 boards.
Nov 15 11:49:28 <ReDaLeRt> rsalvaterra, I did just that.
Nov 15 11:50:04 <dangole> ReDaLeRt, rsalvaterra: but compiling from source takes a long time and much more error-prone than using ImageBuilder. As you have suggested before as well, ImageBuilder should be the way to go in such case.
Nov 15 11:50:26 <rsalvaterra> PaulFertser: I've seen some cheap TL866 II Plus programmers on AliExpress… any opinions?
Nov 15 11:51:29 <rsalvaterra> dangole: I fully agree, if ReDaLeRt doesn't have a lot of experience building from source.
Nov 15 11:51:30 <PaulFertser> rsalvaterra: not support by flashrom afaik?
Nov 15 11:51:38 <PaulFertser> rsalvaterra: not supported -> crap.
Nov 15 11:51:52 <rsalvaterra> PaulFertser: True. I'd need (ARGHHH!) Windows.
Nov 15 11:52:19 <PaulFertser> rsalvaterra: ft2232h-based devices just work
Nov 15 11:52:20 <dangole> rsalvaterra: what he wants is to swap on package from default build against something else. no changes to any sources made. hence just waste of time and kWh to compile from source.
Nov 15 11:54:20 <rsalvaterra> dangole: Yeah, the image builder is the way to go, definitely.
Nov 15 11:54:27 <PaulFertser> dangole: and the fastest way would be to just opkg install it
Nov 15 11:54:32 <ReDaLeRt> I'm not used to use the imagebuilder. I felt quite lost following its usage instructions... -.-'
Nov 15 11:54:37 <PaulFertser> Or even manually copy to /lib/firmware
Nov 15 11:54:48 <zorun> ReDaLeRt: download, untar, "make help"
Nov 15 11:54:57 <ReDaLeRt95> # opkg install ath10k-firmware-qca99x0-ct-httInstalling ath10k-firmware-qca99x0-ct-htt (2020-07-02-1) to root...Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/ath10k-firmware-qca99x0-ct-htt_2020-07-02-1_arm_cortex-a15_neon-vfpv4.ipkCollected errors: * check_data_file_clashes: Package
Nov 15 11:54:57 <ReDaLeRt95> ath10k-firmware-qca99x0-ct-htt wants to install file /lib/firmware/ath10k/QCA99X0/hw2.0/board-2.bin        But that file is already provided by package  * ath10k-firmware-qca99x0-ct * check_data_file_clashes: Package ath10k-firmware-qca99x0-ct-htt wants to install file /lib/firmware/ath10k/QCA99X0/hw2.0/board.bin        But that file is already
Nov 15 11:54:58 <ReDaLeRt95> provided by package  * ath10k-firmware-qca99x0-ct * opkg_install_cmd: Cannot install package ath10k-firmware-qca99x0-ct-htt.
Nov 15 11:55:13 <PaulFertser> ReDaLeRt95: opkg remove the other first
Nov 15 11:56:49 <ReDaLeRt> removed it and rebooted the router. Let's see.
Nov 15 11:57:09 <PaulFertser> ReDaLeRt95: after installing the -htt one I hope? :)
Nov 15 11:57:10 <rsalvaterra> dangole: Something completely different, have you tried any mklibs builds lately (after your update)? I tried one a couple of days ago and haven't noticed any size difference whatsoever.
Nov 15 11:57:12 <ReDaLeRt> (rebooted with the newer installed)
Nov 15 11:57:54 <rsalvaterra> (I remember mklibs made quite a difference in 19.07.)
Nov 15 12:00:14 <ReDaLeRt> well, I get the same result.
Nov 15 12:00:15 <dangole> rsalvaterra: haven't tried mklibs in a long while. is there newer upstream available by now with upstream Python 3 support?
Nov 15 12:00:15 <ReDaLeRt> :(
Nov 15 12:00:56 <rsalvaterra> dangole: Not really, I'm using our heavily patched version. :/
Nov 15 12:01:10 <ReDaLeRt96> 866.7 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 2, Short GI24.0 Mbit/s, 20 MHz
Nov 15 12:01:12 <ReDaLeRt96> -.-'
Nov 15 12:02:00 <PaulFertser> In other words, the client does the right thing and chooses maximum, but the AP for whatever reason is stuck with something really weird and slow?
Nov 15 12:02:13 <ReDaLeRt> Correct.
Nov 15 12:03:46 <PaulFertser> ReDaLeRt: you can try non-ct firmware then
Nov 15 12:04:30 <rsalvaterra> ReDaLeRt96: Well… ath10k is not exactly the greatest hardware (from first-hand experience, I have both QCA9880 wave 1 and QCA9886 wave 2).
Nov 15 12:04:53 <ReDaLeRt96> the intel one:
Nov 15 12:04:54 <ReDaLeRt96> 866.7 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 2, Short GI24.0 Mbit/s, 20 MHz
Nov 15 12:05:03 <ReDaLeRt96> the samsung:
Nov 15 12:05:04 <ReDaLeRt96> 433.3 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 1, Short GI200.0 Mbit/s, 40 MHz, VHT-MCS 9, VHT-NSS 1, Short GI
Nov 15 12:05:08 <ReDaLeRt96> -.-'
Nov 15 12:05:16 <ReDaLeRt96> both underload at the same time.
Nov 15 12:05:30 <PaulFertser> ReDaLeRt: https://github.com/greearb/ath10k-ct/issues/139 might be related etc. Try non-ct firmware.
Nov 15 12:06:50 <rsalvaterra> ReDaLeRt96: Beware: with non-ct firmware you may have issues with WPA3 (with QCA9880, WPA3 is only stable with -ct firmware).
Nov 15 12:07:14 <PaulFertser> Why stupid android devices do not support wpa3?
Nov 15 12:07:45 <rsalvaterra> PaulFertser: Because stupid Google is stupid. Surprisingly, it does support OWE (Android 10+).
Nov 15 12:07:53 <dangole> PaulFertser: because they are stuck on Google-patched wpa_supplicant from 10 years ago...?
Nov 15 12:08:06 <rsalvaterra> dangole: Yeah, that too. :P
Nov 15 12:08:25 <PaulFertser> Too bad so many people insist on using android.
Nov 15 12:08:48 <rsalvaterra> And also using wpa_supplicant for hostap, which is borderline nuts.
Nov 15 12:09:10 <rsalvaterra> PaulFertser: What's the alternative? Smoke signals?
Nov 15 12:09:44 <PaulFertser> rsalvaterra: dumb featurephone + netbook or something similar that runs proper OS.
Nov 15 12:10:31 <rsalvaterra> PaulFertser: I have an Eee PC 901… :P
Nov 15 12:11:37 <rsalvaterra> PaulFertser: Unfortunately, I do like Android's convenience. I use LineageOS, though. OEM Android is a cancer.
Nov 15 12:13:32 <ReDaLeRt> Now, it reports TX @ 6mbps for both clients, but I get the 400mbps upstream performance from the router.
Nov 15 12:13:56 <rsalvaterra> ReDaLeRt: Yeah, that's what I said about not reporting the TX rate.
Nov 15 12:14:06 <rsalvaterra> It's always stuck at 6 Mb/s.
Nov 15 12:14:19 <ReDaLeRt> but, still, caps at 40 MHz bandwidth...
Nov 15 12:14:23 <ReDaLeRt> on TX
Nov 15 12:21:24 <ReDaLeRt> Any guesses? :S
Nov 15 12:22:48 <rsalvaterra> ReDaLeRt: At this point, not really, no… :/
Nov 15 12:25:01 <ReDaLeRt> There is no way to create a package with the newest CT driver?
Nov 15 12:25:05 <ReDaLeRt> https://www.candelatech.com/ath10k-10.4.php
Nov 15 12:25:30 <PaulFertser> ReDaLeRt: just download and overwrite the existing files
Nov 15 12:26:23 <ReDaLeRt> I don't even see any driver there for the QCA9990
Nov 15 12:26:24 <ReDaLeRt> :S
Nov 15 12:28:01 <ReDaLeRt> well, why openwrt reports QCA9990 when this router has Atheros QCA9983 and Atheros QCA9982?
Nov 15 12:28:13 <PaulFertser> Reports where?
Nov 15 12:28:26 <ReDaLeRt> on the wireless configuration page
Nov 15 12:28:29 <rsalvaterra> There's still this pending series from stintel… https://patchwork.ozlabs.org/project/openwrt/list/?series=199172
Nov 15 12:28:36 <PaulFertser> I'd trust dmesg and PCI IDs.
Nov 15 12:28:40 <jow> LuCI, which draws the info from libiwinfo
Nov 15 12:29:10 <PaulFertser> iwinfo has its own list of PCI IDs with names.
Nov 15 12:29:20 <jow> which uses https://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=hardware.txt
Nov 15 12:41:23 <svanheule[m]> ReDaLeRt: the QCA9982 has the exact same PCI vendor, product and subsystem IDs as the QCA9990. The only way to see the difference is by checking the number of available antennas.
Nov 15 13:40:28 <nick[m]> nbd blogic I saw u published usteer. could we maybe work together. I did this dawn stuff. I don't see any reason maintaining two projects that have the same goal.
Nov 15 14:52:24 <ReDaLeRt> https://bugs.openwrt.org/index.php?do=details&task_id=3405
Nov 15 16:43:30 <jow> nbd: your recent buildroot symvers handling changes appear to break compilation of out-of-tree kmods
Nov 15 16:43:39 <jow> see e.g. https://downloads.openwrt.org/snapshots/faillogs/x86_64/base/cryptodev-linux/compile.txt
Nov 15 17:28:43 <nbd> jow: ah, it's probably just an mkdir call missing in the sdk
Nov 15 17:29:13 <nbd> will fix it, sorry about the mess
Nov 15 17:36:41 <jow> np
Nov 15 17:46:06 <eduardas>  hello, this might sound like a stupid question, but does it ever make sense to have more than one watchdog timer enabled on an embedded Linux system?
Nov 15 17:46:18 <eduardas> i.e. if I'm using an external watchdog IC, does it still make sense to use the one on the SoC?
Nov 15 18:11:23 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Nov 15 18:14:23 <jow> eduardas: interesting question
Nov 15 18:14:46 <jow> eduardas: considering the /dev/watchdog api, I can't even imagine how multiple WDs would work with it
Nov 15 18:24:19 <karlp> well, you can have a watchdog that attempts to do a "lighter" or faster action?
Nov 15 18:24:33 <eduardas> jow: why not? separate device files get created for different WDTs so the separation is pretty clear when it comes to userspace
Nov 15 18:24:56 <karlp> ie, try and do something stmarter than the OOMkiller for isntance,
Nov 15 18:25:11 <karlp> perhaps try more graceful shutdowns
Nov 15 18:25:20 <eduardas> jow: unless there is some limitation at the kernel level I am not aware of
Nov 15 18:25:37 <karlp> the watchdog governor framework might be interesting too, you cna get "pre-timeout" actions?
Nov 15 18:27:27 <eduardas> karlp: thanks for pointing that out...was not even aware pretimeout actions were a thing
Nov 15 18:30:43 <jow> eduardas: yes, you're right. I misremembered
Nov 15 18:41:46 <xdarklight> Hauke: if you have any idea on what might cause this then please let me know: https://github.com/openwrt/openwrt/pull/3085#issuecomment-727281848
Nov 15 18:42:01 <xdarklight> (internal GPHY with FE firmware)
Nov 15 18:55:33 <rsalvaterra> dedeckeh: Thanks for letting me know the pain of rebasing patches. :P
Nov 15 18:57:18 <rsalvaterra> Seemed like a trivial conflict, just keep my changes and continue… and quilt just says "f**k you, I'm not applying this". :P
Nov 15 19:15:00 <Hauke> xdarklight: not really, this is probably signaled by the PHY
Nov 15 19:16:17 <xdarklight> Hauke: yep, that's why I'm surprised about it. the GPHY firmware is the same, the PHY driver is the same so I don't see any reason why it would be different with the DSA driver
Nov 15 19:17:20 <Hauke> me too
Nov 15 19:17:43 <Hauke> it could be that the swconfig driver did not handle the phy event
Nov 15 19:19:36 <xdarklight> I'll see if I can find my O2 6431 somewhere which uses 4x internal GPHY with FE firmware to see if I can somehow reproduce it
Nov 15 19:57:19 <rsalvaterra> I rebased and resent my dropbear series. Would someone please take a look?
Nov 15 20:08:51 <dangole> ping grift
Nov 15 20:13:50 <dangole> ping olmari
Nov 15 20:15:16 <olmari> lul... err... pong... haven't done anything yet, exept taken sauna ;P
Nov 15 20:16:45 <dangole> olmari: wow, sauna... i miss that... had access to a nice sauna back in Leipzig on one of the trailerparks...
Nov 15 20:18:12 <dangole> olmari: also spend some time trying to get OpenWrt PPC (mpc8540) to boot in QEMU, no luck yet, no serial output what-so-ever, probably i have to append DTS which matches the machine QEMU emulates...
Nov 15 20:20:04 <dangole> olmari: so if you can still try installing current master with procd-ujail on wdr4900 that'd be great help
Nov 15 20:21:46 <Grommish> https://forum.openwrt.org/t/openwrt-tmp-dir-directed-to-disk-topdir-tmp/79346   Anyone has insight?
Nov 15 20:22:18 <olmari> dangole: yeah... intentions still exists
Nov 15 21:20:27 <karlp> eduardas: last I checked, of the common owrt targetrs, ath79 wdt (at least) didn't have support for any of the governor  hooks, so ymmv
**** ENDING LOGGING AT Mon Nov 16 02:59:56 2020