#linuxcnc-devel Logs

Jun 30 2018

06:02 AM andypugh: skunkworks: Are you awake?
09:00 AM Tom_L: #valgrind must be a dead channel
09:17 AM pcw_home: halcmd: loadrt mesa_7i65 bspi_chans=hm2_7i90.0.bspi.0
09:17 AM pcw_home: *** Error in `/home/pcw/linuxcnc-dev/bin/rtapi_app': free(): corrupted unsorted chunks: 0x08823d10 ***
09:18 AM pcw_home: I get the same error with a 7I90 here (uspace) Ill try a 7I96 but it does seem this is a mesa_7i65 comp bug only so FPGA independent
12:01 PM pcw_home: Hmm, A interesting random and probably useless data point with the mesa_7I65 bug is that it seems to be OK with hm2_eth
12:04 PM andypugh: That’s odd
12:05 PM pcw_home: (also mesa_7i65 is built automatically in 2.8)
12:05 PM pcw_home: 2.8 uspace I mean
12:05 PM andypugh: I am using 2.8. Perhaps that is the difference?
12:05 PM andypugh: There was a patch that put it back in usspace.
12:06 PM pcw_home: must have been a while ago
12:08 PM pcw_home: also weird that there are different bugs with hm2_pci and hm2_7i90
12:10 PM pcw_home: (original complaint was with hm2_pci which I could duplicate) Ill have to try 2.8 uspace with a PCI card but I dont have on at home
12:10 PM pcw_home: one at home
12:11 PM pcw_home: do you have a pci card in your test computer?
12:41 PM rene-dev_: andypugh looks like you are overrunning a buffer
12:42 PM rene-dev_: I really dont like that you need to specify axis values on a trivkins machine. Im thinking of just picking them from the joint, if no axis is specified on trivkins.
12:42 PM rene-dev_: how likeley is a PR like this to be accepted?
12:43 PM rene-dev_: with stepper machines, you need to specify vel and acc 3 times for each axis. thats a bit much
12:43 PM rene-dev_: as well as the limits
12:44 PM rene-dev_: andypugh does that happen during loading only, or after a while?
01:09 PM andypugh: rene-dev_: PCW has been seeing it on driver unload some of the time with RTAI and PCI. I am seeing it on driver load with Uspace and EPP.
01:09 PM andypugh: It happens before the threads are even running, so is a problem with the init code, and so probably something in the BSPI driver setup.
01:10 PM andypugh: I haven’t looked at it yet today (it’s an evening project)
01:13 PM andypugh: pcw_mesa: Different behaviour may be because the over-run overwrites different data in different compiles.
01:13 PM rene-dev_: where is the spi? is that an spi port expander?
01:14 PM andypugh: pcw_mesa: The test PC has a 5i25. (or probably 6i25) I can try flashing a firmware with BSPI onto it.
01:14 PM andypugh: The 7i65 has SPI devices on the card (D to A and A to D I think)
01:58 PM pcw_home: Yeah A-D, D-A a little I/O and watchdog
02:14 PM rene-dev_: now im getting a core dump every time I try to use hal comp array types
02:27 PM rene-dev_: nevermind, that was just me unable to count to 4
04:07 PM andypugh: 0, 1, 2, 3
04:40 PM andypugh: Well, I tried adding some debugging prints. And I am no wiser:
04:42 PM andypugh: https://pastebin.ubuntu.com/p/bJtPsmVVNF/
04:57 PM andypugh: An alternative approach has narrowed it down, if I comment out all the hm2_tram_add_bspi_frame calls then it doesn’t crash.
06:50 PM andypugh: seb_kuzminsky: —trace-children=yes doesn’t really help
06:51 PM andypugh: Try it, just valgrind —trace-children=yes halrun
06:51 PM andypugh: It basically seems to be convinced that bash is broken, and can’t do anythind with the modules that are setuid root.