#linuxcnc-devel Logs

Aug 31 2017

01:14 PM IchGucksLive: someone able to build me a Mesa Bitfile
01:15 PM IchGucksLive: i cand downloay xilinx
01:15 PM IchGucksLive: and my DAMMBob is the other Way the standards are
01:15 PM IchGucksLive: so sTEP/Dir is oposit
01:15 PM IchGucksLive: to DMMBOB
01:16 PM IchGucksLive: pin2 is Channel 0 Step pin3 chanel 0 DIR ..pin4 is Channel 1 Step pin5 chanel 1 DIR ....
01:31 PM mozmck: I might can do it. What board is it?
01:31 PM IchGucksLive: moment pcw is on
01:32 PM mozmck: hi pcw_mesa
01:33 PM pcw_mesa: Hi mozmck
01:43 PM Tom_L: yeah the source file for that isn't in the zip that i can see
01:45 PM Tom_L: i see PIN_DMMBOB1x2_34.vhd and PIN_DMMBBOB1x2D_34.vhd
02:02 PM IchGucksLive: Gn8
03:38 PM seb_kuzminsky: dgarr, jepler: the "sched_setaffinity: Invalid argument" happens on 2.7 too
03:39 PM seb_kuzminsky: it seems to be because the uspace rtapi_app's find_rt_cpu_number() function calls sched_setaffinity with a cpu mask of all-bits-1, asking for all cpus from 0 to 1023, but the machines we're running on have fewer CPUs than that
03:40 PM seb_kuzminsky: i think this is uspace_rtapi_app's way of trying to determine the highest-numbered CPU in the system
04:44 PM andypugh: Well, PCW kindly sent a 7i43 and 7i90 so I could properly fix the thing that I tried to fix before, and now I can’t get the dev PC to boot. ANd I don’t really want to take one of the CNC machiens apart.
04:45 PM * JT-Shop emails Andy a spare PC
04:45 PM andypugh: (Actually, I can’t tell if it is booting, but there is no monitor display, though it does wake up the monitor)
04:45 PM andypugh: I just spent £100 on an old all-in-one with PCI, PCIe and Parallel ports.
04:46 PM andypugh: All-in-one means I can move it about / put it away.
04:46 PM andypugh: One of these: http://www.morgancomputers.co.uk/product_detail/18457/RM-One-310-19-All-In-One-Intel-i5-2390T-Dual-Core-2-7GHz-4GB-250GB-Computer-PC-Windows-7-Home/
04:47 PM andypugh: (but from eBay instead)
04:47 PM andypugh: I think that covers all current Mesa options.
04:50 PM suavesteve: For £100, I'd love to know who you got that off Andy, and if they have any more? Could be useful!
04:52 PM andypugh: He seems to have one left. http://www.ebay.co.uk/itm/302433564068
04:56 PM suavesteve: Looks good, thanks!
04:58 PM CaptHindsight: I never had luck with the BIOSes on many of the all-in-ones
04:59 PM CaptHindsight: maybe now just with ethernet
05:27 PM dgarr: jepler,seb_kuzminsky: maybe this fix(?): http://www.panix.com/~dgarrett/stuff/0001-uspace_rtapi_app.cc-alter-computation-of-top-cpu.patch
05:55 PM seb_kuzminsky: dgarr: i tried something similar, and it made the error message go away, but i think it violates the intent of that code
05:56 PM seb_kuzminsky: i think the goal of that function is to determine the highest-numbered cpu in the system
05:56 PM dgarr: ok,maybe jepler can look at it
05:56 PM seb_kuzminsky: and your patch finds the highest-numbered cpu in rtapi_app's original cpuset
05:59 PM seb_kuzminsky: i think it wants the same number as you get from "nproc --all" or sysconf(_SC_NPROCESSORS_CONF)
06:21 PM seb_kuzminsky: i think _SC_NPROCESSORS_CONF works on linux and freebsd, even through it's listed as "non standard" in the sysconf manpage, so maybe we should just use that
07:47 PM jepler: one way it needs to work is: say you have an 8-thread system and boot with isolcpus=7 to stop "normal" programs from running on the highest CPU
07:47 PM jepler: .. that code needs to pick CPU #7 in that case, but with the proposed change I *THINK* it would pick CPU #6, since 7 wouldn't be in the set
07:49 PM CaptHindsight: RTAI hasn't needed isolcpus set for a quite some time
07:49 PM jepler: CaptHindsight: this is for preempt-rt
07:50 PM CaptHindsight: with LCNC you're not going to be running anything other than LCNC anyway
07:54 PM CaptHindsight: I but haven't seen what preempt-rt is doing I no longer expect well written code
07:54 PM jepler: you'll have lots of other Linux processes even if you're not running any other applications
07:54 PM CaptHindsight: I'm happily surprised when it happens :)
07:54 PM CaptHindsight: all I'm saying is that what they are doing right now might not make good sense
08:02 PM jepler: It's not a discussion of the merits of RTAI vs preemt-rt but thanks
08:02 PM CaptHindsight: thats not my point
08:03 PM CaptHindsight: trying to make sense of things when there isn't sometimes
08:09 PM jepler: as for freebsd, that section of code is already not portable to freebsd, sched_xxx is nonportable and we didn't succeed in finding a portable function to do the same thing
08:10 PM jepler: get_nprocs_conf was added in 2009 to glibc, dunno if it's in all our platforms
08:10 PM jepler: oh wait that's a cygwin mailing list post
08:11 PM jepler: and yes the docs also state it's the same as related sysconf calls so it's not clear why you'd use one vs the other
08:25 PM jepler: on kernel Linux babs 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
08:25 PM jepler: .. it works just fine to sched_setaffinity to a bunch of CPU numbers that don't exist; the following sched_getaffinity call returns a "correct" mask
08:25 PM jepler: ditto Linux rat 4.9.0-3-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux
08:27 PM jepler: on this platform it fails in the way described: Linux odroid 3.8.13.26-rt31 #12 SMP PREEMPT RT Mon Sep 1 14:02:33 CDT 2014 armv7l armv7l armv7l GNU/Linux
08:28 PM jepler: I see the a failing kernel on buildbot is Linux jessie-rtpreempt-amd64 4.1.0-2-rt-amd64 #1 SMP PREEMPT RT Debian 4.1.6-1 (2015-08-23) x86_64 GNU/Linux
08:37 PM jepler: it appears to be this internal glibc test which fails the call (sched_setaffinity syscall is never actually performed): https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/sched_setaffinity.c#L59
08:39 PM jepler: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2359035ac52db69eb427c3b4b9d9297c98d2b225
08:40 PM jepler: this behavior is no longer in newer glibc versions
08:48 PM jepler: .. thanks for putting up with my free association process
08:52 PM jepler: seb_kuzminsky: I experienced that buildbot didn't build my branch on the intial push, only on the force update...
08:57 PM dgarr: b79034c tested ok on jessie 4.1.0-0.bpo.2-rt-amd64
08:57 PM jepler: thanks dg!
08:57 PM dgarr: thank you -- amazing sleuthing
08:58 PM jepler: thanks dgarr
09:00 PM jepler: afk
09:01 PM jepler: I'll just leave you with this though https://arxiv.org/abs/1708.09492 "Automatically Generating Commit Messages from Diffs using Neural Machine Translation"
09:06 PM hazzy1: looks like a fascinating paper
10:43 PM seb_kuzminsky: jepler: i see that the buildbot waterfall pages shows the update at 19:20, but not the original push at 19:17
10:50 PM jepler: seb_kuzminsky: OK for 2.7?
11:18 PM seb_kuzminsky: ok, i think it'll build new branches now
11:18 PM seb_kuzminsky: i wonder what existing features i broke while adding that one
11:19 PM seb_kuzminsky: jepler: i see that the warning is gone, in your branch
11:20 PM seb_kuzminsky: and your code looks right to me, and the comment gives me a big fuzzy feeling, so i say put it in 2.7