#linuxcnc-devel Logs

May 29 2020

08:59 AM jepler: seb_kuzminsky, skunkworks have either of you experienced that the pi rt kernel from my package only boots intermittently? andypugh reported unreliable booting to me privately. I haven't see it though.
09:03 AM skunkworks: jepler: you mean - the pi never boots - or boots a different kernel? I have not experienced either
09:04 AM skunkworks: andypugh: awesome video.
09:18 AM andypugh: There are suggestions that one needs to use mkimage to get devicetree support.
09:19 AM jepler: mkimage has to do with uboot, right? pi don't use uboot as shipped.
09:20 AM andypugh: It was something that I read in passing looking for an answer to a different question.
09:22 AM jepler: the "usual" pi way is for the devicetree files to be in /boot, but I don't know how a dtoverlay= line in config.txt actually causes that devicetree file to be used by the loaded kernel
09:22 AM jepler: or, presumably, the "implied" devicetree file that the hardware itself requires
09:26 AM andypugh: Anyway, the boot is reliable but a bit wierd.
09:26 AM andypugh: https://www.youtube.com/watch?v=utdB66Qsf4U
09:26 AM andypugh: (I should have locked exposure and focus)
09:26 AM andypugh: The text that appears twice is “CPU 0 not supported”
09:27 AM jepler: > [ 1.016705] kvm [1]: Error, CPU 0 not supported!
09:28 AM andypugh: That’s the one
09:28 AM jepler: https://github.com/raspberrypi/linux/issues/2299
09:29 AM andypugh: Possibly nothing to worry about then?
09:30 AM jepler: in my estimation, no. Not sure why the message wouldn't appear with a pi upstream kernel. possibly (likely) they disabled the feature at build time.
09:32 AM jepler: it seems kvm supports ARM_CPU_PART_CORTEX_A7 and ARM_CPU_PART_CORTEX_A15 but this CPU is ARM_CPU_PART_CORTEX_A72
09:33 AM jepler: https://github.com/raspberrypi/linux/blob/e2d2941326922b63d722ebc46520c3a2287b675f/arch/arm/kvm/guest.c#L289
09:46 AM andypugh: Just disable KVM? Or is that the problem?
09:47 AM jepler: I'm trying to verify that it's disabled in the official kernels
09:47 AM jepler: but the official package doesn't seem to have the "config" (kernel configuration file) in the package like a proper debian kernel does
09:51 AM jepler: if I repeat the configuration instructions from jt, I get CONFIG_KVM disabled
09:51 AM jepler: and CONFIG_NAMESPACES becomes enabled
09:51 AM jepler: both have CONFIG_DEBUG_PREEMPT=y
09:52 AM jepler: https://gist.github.com/170856dff093c59b0bbb8a711c5490ee so I should rebuild with these changes, I think
10:04 AM skunkworks: andypugh: it also looks like you are getting the 'under sized power supply' lightning bolt
10:05 AM skunkworks: (and I get the kvm error to - with out any issues with the os it seems)
10:14 AM andypugh: I have never found a PSU that _doesn’t_ give the lightning bolt.
10:14 AM andypugh: My Pi might have the USB hardware error?
10:14 AM jepler: I have a couple of "genuine" pi foundation power supplies and they are fine
10:15 AM andypugh: https://arstechnica.com/gadgets/2019/07/raspberry-pi-4-uses-incorrect-usb-c-design-wont-work-with-some-chargers/
10:16 AM jepler: almost but not entirely sure that when powering it from the 5V converter on a Mesa 7C80 it was also fine (no lightning bolt)
10:20 AM skunkworks: I have a 4a supply plus the suppled one with the rpi4 kit. Both are fine as long as I am not trying to boot off of a usb/ssd converter
10:25 AM skunkworks: the one supplied with the rpi4 kit also fast charges my pixel too
10:26 AM skunkworks: andypugh: I think it only effect you if you are using a smart charger. I have been just using 5v supplies with the rated current.
10:41 AM pcw_home: well git bisect (of the crazy move issue ) was not fun because so many tags would not compile...
10:41 AM andypugh: git bisect skip seems to deal OK with that.
10:42 AM pcw_home: except there are 38 possibilities
10:42 AM andypugh: Bother!
10:45 AM jepler: Put the output of `git bisect log` in a paste somewhere and we'll see if we can make some sense out of it
10:49 AM pcw_home: http://freeby.mesanet.com/bisect_log
10:55 AM jepler: it's statetags
10:58 AM jepler: pcw_home: thanks for bisecting, this is a huge help
11:10 AM jepler: I've pinged zultron (john morris) on the issue
11:10 AM pcw_home: at least it shows the general area
11:18 AM pcw_home: rmu's patch with emcTaskPlanReset in emcTaskAbort does fix the issue but I don't understand enough to know whether it has any unwanted side effects
11:42 AM jepler: Someone who understands state tags would be well positioned to answer that question, I bet
11:43 AM jepler: though just knowing that the state tags tests still passed would also be a good thing to check. If they do, maybe toss it in. If it creates a state tags problem, it is probably overt, rather than racy
01:13 PM rmu|w: that is a bunch to check...
01:26 PM rmu|w: commit message of f8f9b3a35ac477cd861e5a1670f0e7afba8d3cbe is suspicious: "interp: Added a method to restore state on abort
01:26 PM rmu|w: "