Back
[00:21:35] <seb_kuzminsky> the silly deb archive structure at wlo requires me to put a copy of the hm2 firmware in each dist (hardy, lucid, precise, wheezy)
[00:21:57] <seb_kuzminsky> or i could create a horrible symlink farm
[00:22:09] <seb_kuzminsky> uh oh, skunkworks is gonna call me out for talking to myself again
[00:22:13] * seb_kuzminsky shuts up
[01:15:59] <seb_kuzminsky> whoa!
[01:16:04] <seb_kuzminsky> i must be in the future:
[01:16:06] <seb_kuzminsky> [Connecting to us.archive.ubuntu.com (2001:67c:1562::15)]
[03:00:15] <seb_kuzminsky> cradek: i just pushed hostmot2-firmware 0.8.10 (with the -all Depends fix) to wlo
[03:01:27] <seb_kuzminsky> i monkeyed around a bunch with the binary-all component, until i noticed this debian bug:
[03:01:30] <seb_kuzminsky> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264952
[03:02:19] <seb_kuzminsky> the hm2 debs now live in binary-all, where apt-ftparchive can't see them, and they're symlinked to the real arches that apt-ftparchive *can* see
[03:02:31] <seb_kuzminsky> well, it works for me, hope i didnt break it for anyone else
[03:12:31] <seb_kuzminsky> for your amusement, my soundtrack tonight has been the brett domino trio:
https://www.youtube.com/watch?v=Lsm3hoWEM14
[07:34:38] <jepler> seb_kuzminsky: sounds like a lot of work
[07:35:01] <jepler> seb_kuzminsky: if it was just a matter of space on www.l.o, I don't think we care (copies of hm2)
[08:45:51] <KGB-linuxcnc> 03John Thornton 05v2.5_branch 963a047 06linuxcnc 10docs/src/hal/basic_hal.txt Docs: fix float value with old data * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=963a047
[08:57:45] <KGB-linuxcnc> 03John Thornton 05v2.5_branch 80efa5f 06linuxcnc 10docs/man/man9/debounce.9 Docs: try to word synopsis to be a bit clearer in the description * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=80efa5f
[09:01:43] <skunkworks> this is what is in the linuxcnc sources and the sources..
http://pastebin.com/SZ5rPJH2
[09:04:48] <seb_kuzminsky> jepler: it was a hassle to figure out, but all the work is done by bash now so i dont care
[09:05:22] <seb_kuzminsky> keeping the the symlinks up to date is automatic
[09:06:24] <seb_kuzminsky> jthornton: the new debounce docs are better, thanks
[09:23:04] <linuxcnc-build> build #2210 of 1100.rip-hardy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1100.rip-hardy-i386/builds/2210 blamelist: John Thornton <jthornton@gnipsel.com>
[09:31:52] <JT-Shop> seb_kuzminsky, thanks
[09:32:22] <JT-Shop> looks like we have a new proof reader YEA!
[09:32:56] <jepler> well as I had long suspected, accesses to hal_float_t are not atomic on arm
[09:33:15] <jepler> mailing list message with more infos
[09:33:18] <cradek> oh dear
[09:33:21] <cradek> that ain't good
[09:33:29] <jepler> .. cancel my interest in ARM ports
[09:34:26] <cradek> yeah that's one sacrifice too many
[09:37:30] <linuxcnc-build> build #2212 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2212 blamelist: John Thornton <jthornton@gnipsel.com>
[09:38:45] <jepler> there are bound to be atomic 64-bit instructions on arm, so "all" you have to do is decree that all hal components are C++ programs, and make hal_double_t a class with operator= and operator double methods that do the necessary atomic access, as I proposed a thousand years ago.
http://media.unpythonic.net/emergent-files/01189609097/atomic64.h
[09:39:42] <jepler> but any way you slice it, you're likely to have to make a new, source-code-breaking requirement
[09:41:29] <cradek> you'd use c++ just so you could continue to use the = operator?
[09:42:32] <jepler> it's likely to need fewer source-level changes
[09:42:51] <cradek> sure
[09:43:10] <cradek> but you could do it in C just fine too, but with different syntax?
[09:43:27] <jepler> yeah, at every location where you read or write a hal_float_t
[09:43:46] <cradek> I bet that wouldn't be a bad thing
[09:44:10] <cradek> we've often fixed things where the component unwittingly read the pin several times, expecting it to have not changed
[09:44:31] <cradek> an explicit hal read would make that problem less easy to write
[09:44:46] <jepler> that's an interesting point
[09:44:54] <jepler> so you think it could be good for whatever type it is
[09:45:37] <cradek> it would be a pain to change (and yeah you break everyone else's code too) but when done, things would be better in several ways
[09:45:51] <jepler> we could probably find a way to make it optional at first
[09:45:59] <jepler> activate it only if something is defined when rtapi.h is included
[09:46:14] <jepler> now I'm envisoning how comp components would change
[09:46:33] <jepler> I think there we could do something much cooler actually
[09:46:44] <jepler> change function x; to function x reads in writes out;
[09:47:20] <jepler> then behind the scenes, comp ensures that all the "reads" values are read into locals and at exit all "writes" are written
[09:47:32] <jepler> and now you can document what each thread reads and writes, which is cool too
[09:51:13] <jepler> the downside would arise for, say, mux: imagine you write a mux4096 in comp. the "old way", you read one value and write one value every time. the new way, it would have to read 4096 values every time...
[09:51:48] <jepler> (ok, it has to read the 12 mux bits or one mux control u32, but either way the number of reads is greatly inflated by code which would read all the inputs at the top)
[09:52:46] <seb_kuzminsky> jepler: i like it
[09:53:45] <jepler> seb_kuzminsky: which "it"?
[10:01:48] <cradek> seb_kuzminsky: thanks for fixing the firmwares! I got updates this morning when booting last night's new cd image
[10:06:57] <cradek> skunkworks: on this morning's install, apt-get build-dep linuxcnc works fine for me with no screwing around
[10:08:39] <cradek> skunkworks:
http://linuxcnc.org/binary.hybrid.iso ec2e8151b617426df30d384440656ada
[10:09:45] <skunkworks> same thing here.. Wonder what I screwed up. I just picked the defaults going through the text installer
[10:09:59] <cradek> huh
[10:10:16] <cradek> I think the graphical and text installers should be exactly the same, but I should try both. I used the text, too
[10:10:44] <skunkworks> I will try agian for grins.
[10:13:13] <jepler> mmm did someone say grits?
[10:13:30] <cradek> I installed this time with full disk encryption on lvm for kicks, and it works fine
[10:21:42] <seb_kuzminsky> cradek: did i tell you have had trouble with, errr, one of the install images? the 'live' option at the grub menu worked fine, but both the install options had messed-up unreadable vga consoles
[10:21:54] <seb_kuzminsky> removing the "vga=788" from the kernel command line fixed it and let me install
[10:22:08] <seb_kuzminsky> it's the old dell that runs my bridgeport
[10:22:26] <cradek> hmmm
[10:22:47] <cradek> so I guess real X (live) works but not the framebuffer console
[10:22:57] <seb_kuzminsky> jepler: i like the idea of a more rigid hal api that enforces read and write atomicity
[10:23:39] <cradek> after removing vga=, you used the text mode installer successfully?
[10:24:05] <seb_kuzminsky> yes, i think it was text-mode that i used
[10:24:31] <seb_kuzminsky> i tried booting both text-mode installer and graphical installer with vga=788 removed, and both worked, whereas with vga= they both didn't work
[10:24:53] <cradek> what happened when it didn't work?
[10:25:00] <seb_kuzminsky> i think i took a picture, hold on
[10:25:41] <cradek> I guess 788 is 800x600x16
[10:25:45] <cradek> you'd think that would work on everything
[10:28:01] <jepler> cradek: sounds pretty lowest-common-denominator, that's for sure
[10:28:12] <seb_kuzminsky> my denominator is lower
[10:28:15] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/0630140014.jpg
[10:28:47] <seb_kuzminsky> the colorful confetti at top flickers as if it was writing to video memory but ithe bytes were getting misinterpreted
[10:29:14] <cradek> :-/
[10:29:25] <seb_kuzminsky> that's the grub splash in the background obviously
[10:29:38] <seb_kuzminsky> might be my kernel is lacking some video driver
[10:32:24] <cradek> the installer runs the debian kernel
[10:32:33] <cradek> er, both installers
[10:32:41] <seb_kuzminsky> oh
[10:32:45] <seb_kuzminsky> why?
[10:32:53] <cradek> happy accident?
[10:33:01] <seb_kuzminsky> it's always been strange to me that the debian install cds use a different kernel than the one they install for you
[10:33:06] <cradek> I have no idea but I decided it wasn't a thing to worry about fixing
[10:33:12] <cradek> yeah
[10:33:59] <seb_kuzminsky> i was bit and/or saved by that feature(?) a few years ago on some benighted early netbook
[10:34:29] <seb_kuzminsky> jepler: it's great that you figured out the arm atomicity thing before it bit any users
[10:35:32] <jepler> seb_kuzminsky: and all it took was a little googling
[10:35:47] <jepler> for UP systems, you're unlikely to ever notice a problem
[10:36:00] <jepler> for SMP systems it's not hard to notice the problem if you write software to look for it
[10:37:14] <seb_kuzminsky> bbl
[10:43:05] <cradek> huh, someone tried to put spam on the wiki (but failed)
[10:43:08] <cradek> the front page is not loading
[10:44:50] <linuxcnc-build> build #1416 of 4000.deb-hardy-rtai-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4000.deb-hardy-rtai-i386/builds/1416 blamelist: John Thornton <jthornton@gnipsel.com>
[10:46:04] * jthornton runs and hides
[10:48:04] <cradek> studying it before I just clean it up
[10:48:07] <cradek> please nobody touch
[10:56:41] <seb_kuzminsky> jthornton: that one's not your fault, it's something in the buildbot
[10:56:48] <seb_kuzminsky> i dont know why the previous one failed though
[10:57:01] <seb_kuzminsky> but that one also doesn't look like yours
[10:59:08] <seb_kuzminsky> hmm, that deb-hardy-rtai-i386 failure is a race condition in the new repo management code :-/
[10:59:57] <seb_kuzminsky> one buildslave puts new packages in the repo and asks the buildmaster to regenerate the index file (Release, Packages, etc), and while those files are being written another buildslave runs 'apt-get update' and get an inconsistent view of the archive
[11:00:20] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch 0000.checkin
[11:00:23] <linuxcnc-build> build forced [ETA 1h11m13s]
[11:00:24] <linuxcnc-build> I'll give a shout when the build finishes
[11:00:27] <seb_kuzminsky> i wonder how to fix that
[11:01:17] <seb_kuzminsky> i wonder if i could have apt-ftparchive generate the new index files into a temporary directory and mv them into place, that would at least make the window smaller
[11:14:51] <jepler> now's the perfect time to stop what you're doing and develop on apt-ftparchive. shaved yaks for all.
[11:17:31] <seb_kuzminsky> it's the unix way
[11:18:14] <seb_kuzminsky> i tried to shave a yak, but there was a hairy yak in the way
[11:45:47] <skunkworks> cradek, the new image install - seems to be working
[11:45:59] <skunkworks> it is currently installing all the dependanices
[11:46:11] <cradek> but it didn't fix your usb thing, right?
[11:46:22] <skunkworks> I have not tried it in that motherboard yet
[11:46:28] <cradek> ok thanks
[11:46:34] <cradek> (surely it still won't work)
[11:46:55] <skunkworks> It also pulled the mesa firmware when I did the update/upgrade
[11:47:09] <cradek> I booted the newest one live, installed git and build-deps and was able to build packages
[11:47:25] <cradek> yay, that's a good thing :-)
[11:47:29] <skunkworks> :)
[11:47:33] <seb_kuzminsky> oh good :-)
[11:47:59] <cradek> seb_kuzminsky: I listed all of them instead of using -all. should I change it back?
[11:48:24] <skunkworks> now lets see if I can get the 7i80 working with rt-preemt and jepler ethernet branch
[11:49:40] <cradek> fun!
[11:50:05] <pcw_home> I was about to try that but not sure what rt option config needs
[11:50:43] <skunkworks> I just did a search in synaptic and installed the -rt kernel. some something pae something...
[11:51:10] <seb_kuzminsky> heh, sounds like a kernel version number...
[11:51:18] <skunkworks> it seemed to install it. it deosn't set it as the default kernel - but that isn't hard to do/
[11:51:19] <seb_kuzminsky> cradek: yes, i think you should change it back to -all now
[11:51:32] <jepler> pcw_home: I have been building and doing a limited amount of testing on debian 7 amd64 with linux-image-3.2.0-rt-amd64. On 32-bit systems, linux-image-3.2.0-rt-i686-pae sounds like the right alternative
[11:51:39] <cradek> seb_kuzminsky: ok
[11:51:58] <seb_kuzminsky> skunkworks: the -rt kernel form debian is in the 3.2 series, grub wil prefer the rtai kernel from linuxcnc.org because it's 3.4.something thus obviously much better
[11:52:13] <skunkworks> ah
[11:52:26] <seb_kuzminsky> wow my typing is getting bad
[11:52:27] <skunkworks> I assume I can force it in grub..
[11:52:31] <seb_kuzminsky> skunkworks: sure
[11:52:35] <jepler> as for build requirements, if you can build regular linuxcnc I think you need one additional package, libudev-dev
[11:53:32] <jepler> pcw_home: weird thing happened to me recently: the 5i20 I have had for years spontaneously lost its eeprom settings and wouldn't work with linuxcnc. I reprogrammed it with that DOS utility you've recommended on the forum, and it works again.
[11:53:51] <jepler> I'm not sure I'd used that 5i20 for 2 years, and I also transferred it between systems at least twice since the last time I'm certain it worked
[11:54:46] <seb_kuzminsky> jepler: next time try micges-dev 's mesaflash, it runs in linux and i think there might even be debs somewhere
[11:55:02] <jepler> seb_kuzminsky: if there's a next time, I'll look
[11:55:08] <pcw_home> we have occasionally have had bad EEPROM lots (leaky)
[11:55:09] <pcw_home> its something that cannot really be tested :-)
[11:55:13] <jepler> this is not the FPGA bitstream eeprom, it's a eeprom for configuring the PCI bridge
[11:55:18] <cradek> we need to get mesaflash in our repo
[11:55:20] <seb_kuzminsky> i mean, unless you *want* to boot fmor a freedos floppy
[11:55:22] <jepler> so I dunno if mesaflash handles that
[11:55:26] <jepler> seb_kuzminsky: it boots from USB!
[11:56:04] <jepler> (I used
http://chtaube.eu/computers/freedos/bootable-usb/ )
[11:56:33] <cradek> that's pretty amazing
[11:56:38] <pcw_home> I think Michael G was considering adding EEPROM support
[11:57:23] <pcw_home> the batch files could be munged into scripts easily
[11:58:08] <jepler> yes, if it had been harder to get freedos going, I'd probably have tried my hand at that
[11:58:13] <skunkworks> I don't know what I did wrong the first time.. I did have some network issues when I initially installed the live cd to the hd..
[11:58:38] <jepler> I should port rtapi to freedos
[11:58:43] <jepler> yeah, that's it
[11:58:58] <cradek> skunkworks: I've done some work to make things right, in the situation where you install without network but then later plug it in to the network. if you're really bold that's a thing it would be useful to test too :-)
[11:59:19] <skunkworks> ok :)
[11:59:20] <pcw_home> I think Ive only seen the leaky EEPROMs on older 5I20s so I'm hoping that issue is solved
[11:59:21] <pcw_home> (we will fix the card if you like)
[11:59:52] <skunkworks> does it just stop working after a long time?
[12:00:01] <pcw_home> Yep
[12:00:05] <cradek> eek
[12:00:23] <jepler> pcw_home: I figured you'd exchange it since there are no big scorch marks on it, but I was glad to be able to fix it myself
[12:01:07] <pcw_home> it will eventually go bad again...
[12:01:26] <skunkworks> about the same amount of time?
[12:01:31] <jepler> pcw_home: before or after I run out of systems with PCI slots?
[12:01:37] <skunkworks> heh
[12:02:01] <cradek> you plan to run out?
[12:02:09] <cradek> guess you need a bigger basement
[12:02:29] <pcw_home> maybe (though there are new MBs with PCI now)
[12:03:05] <jepler> cradek: I think my oldest desktop was purchased new in 2005, so under ten years old
[12:03:20] <jepler> who would want a computer over ten years old?
[12:03:39] <cradek> ask again in 10 years
[12:05:11] <jepler> cradek: do you know about when those core2 desktops would have been purchased?
[12:05:35] <cradek> sorry, no
[12:05:41] <pcw_home> jepler: I'm still not clear on the configure option I need for preemt-rt
[12:05:59] <jepler> pcw_home: oh, when invoking configure? --enable-realtime=uspace, though --enable-simulator is accepted and now means the same thing
[12:06:08] <jepler> er, is it --with-realtime=uspace ?
[12:06:15] <seb_kuzminsky> all this talk of preempt-rt reminds me that i told jepler i'd review his branch last night
[12:06:20] <pcw_home> OK will try that
[12:06:28] <seb_kuzminsky> instead i worked on hm2 debs
[12:06:39] <seb_kuzminsky> i'll try to review it soon jeff
[12:06:55] <jepler> seb_kuzminsky: you were up until the AMs anyway, no hard feelings
[12:07:38] <seb_kuzminsky> oh good
[12:09:02] <jepler> cradek: well, the specific CPU in mine was released in 2008, but I don't recall whether when we got them they were hot s--- or old and budget CPUs
[12:09:19] <jepler> seems like they were good desktop CPUs for the day, so maybe the machines are from 2008/2009 era
[12:10:37] <jepler> OK, added improve configure --help / document how to build / kernel requirements to my list of TODOs for the next (and last?) time I rebase that branch
[12:11:35] <seb_kuzminsky> we need to figure out what this branch means for our packaging
[12:11:51] <jepler> seb_kuzminsky: yes
[12:11:52] <seb_kuzminsky> we currently build linuxcnc (rtai) and linuxcnc-sim (non-realtime)
[12:12:02] <jepler> I think that I successfully made dpkg build linuxcnc-uspace instead
[12:12:08] <jepler> it's supposed to conflict with linuxcnc-sim
[12:12:08] <seb_kuzminsky> this sort of replaces -sim
[12:12:16] <seb_kuzminsky> ... oh you did! sweet
[12:12:18] <jepler> and, yes, it would replace -sim
[12:13:38] <jepler> there's not a linux-image-rt metapackage, so I don't think there's an obvious way to recommend an appropriate -rt kernel
[12:13:53] <seb_kuzminsky> there's linux-image-rt-amd64 (on my amd64 wheezy machine)
[12:14:00] <jepler> though I could look at the dpkg architecture and either recommend linux-image-rt-amd64 or linux-image-rt-i686-pae
[12:14:05] <seb_kuzminsky> yeah
[12:16:47] <jepler> in fact, I think I can just write that statically in control.in
[12:17:04] <jepler> no, because I don't want that for the regular, rtai version
[12:19:21] <jepler> Package: linuxcnc-uspace
[12:19:25] <jepler> Recommends: linuxcnc-doc-en | linuxcnc-doc, hostmot2-firmware, linux-image-rt-amd64 [linux-amd64], linux-image-rt-686-pae [linux-i386]
[12:19:28] <jepler> I hope that's the right spelling
[12:25:30] <seb_kuzminsky> i think the linux- part of linux-{amd64,i386} is optional?
[12:25:40] <seb_kuzminsky> but otherwise it looks right
[12:50:49] <linuxcnc-build> Hey! build 0000.checkin #2214 is complete: Success [3build successful]
[12:50:49] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2214
[12:59:12] <skunkworks> master builds
[13:00:50] <memfrob> seb_kuzminsky, i heard people were having seg faults with 3.4.XX-4 RTAI kernel patches?
[13:08:55] <seb_kuzminsky> hi memfrob
[13:09:38] <seb_kuzminsky> i've built 3.4.87 with the rtai patch called hal-linux-3.4.87-x86-4.patch (md5sum b4755f26cdd06bda1e576e05b40c0713) from the tip of shabby's master (it's also the tip of his dev branch)
[13:10:39] <seb_kuzminsky> i'm using the rtai userspace from before, old-master commit a0dc5355ee
[13:11:00] <memfrob> yes userspace is not made for -4 IPIPE releases
[13:11:00] <seb_kuzminsky> with this combo we've found two machines that panic reliably, one is dgarr's and one is mine
[13:11:31] <memfrob> for you i'm working on bumping the -1 kernel patch to 3.4.96 that should remove all problems
[13:11:55] <memfrob> userspace is hard-coded to specific IPIPE kernel releases, -1, -2, -3, etc.
[13:12:03] <memfrob> if you change one thing, you have to change another.
[13:12:03] <seb_kuzminsky> here's dgarr's info:
http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-29.html#23:04:25
[13:12:19] <seb_kuzminsky> hmm, most machines run just fine with this userspace/kernel split
[13:12:32] <memfrob> not meant to though
[13:12:39] <seb_kuzminsky> ok, i guess that makes sense
[13:13:03] <memfrob> i will post kernel patch to the linuxcnc-old branch on github
[13:13:29] <seb_kuzminsky> i haven't looked at the linuxcnc-old branch at all yet
[13:14:26] <memfrob> dont worry about the branch, just the patch :)
[13:14:37] <seb_kuzminsky> back in the way back when, the 3.4.55 patch and the userspace in a0dc5355ee seemed to work well for everyone, so i think i'm going to build packages for that and worry about updating rtai versions later
[13:15:02] <seb_kuzminsky> does the kernel patch live in a secret git repo somewhere?
[13:15:21] <memfrob> dont update rtai userspace, its a big mess, kernel bumps though should not be a problem if they're done right
[13:15:22] <seb_kuzminsky> where does the adeos patch come from?
[13:15:32] <memfrob> those dont work with RTAI
[13:15:45] <memfrob> they need to be modified to handle the RTAI code
[13:15:45] <seb_kuzminsky> isn't rtai based on adeos? (for some value of "based on")
[13:15:54] <memfrob> yes but the stock patches do not work
[13:16:03] <seb_kuzminsky> ok
[13:16:32] <memfrob> http://download.gna.org/adeos/patches/
[13:17:16] <memfrob> if you use those you'll get a bunch of undefined symbols and such
[13:17:33] <skunkworks> jepler, so ./configure --enable-run-in-place --with-realtime=uspace
[13:17:35] <memfrob> i have however been able to modify those patches myself to work with RTAI but it takes a few hours.
[13:17:46] <skunkworks> (I am paraphrasing run in place
[13:18:05] <seb_kuzminsky> memfrob: thanks for the link
[13:18:14] <memfrob> ill post a kernel bump for you seb_kuzminsky really quick
[13:18:27] <memfrob> if you make a .deb with that i am almost certain it will work fine
[13:18:41] <seb_kuzminsky> ok
[13:18:42] <seb_kuzminsky> thanks
[13:20:24] <seb_kuzminsky> memfrob: here's jepler's debugging of the problem dgarr had:
http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-30.html#11:47:26
[13:21:15] <memfrob> jepler is way ahead of me
[13:22:28] <memfrob> so seb_kuzminsky i assume you've given up with getting RTAI master working with linuxcnc?
[13:23:51] <seb_kuzminsky> i wouldn't say given up... but it's on hold for now
[13:24:30] <seb_kuzminsky> i'm going back to a0dc5355ee for now, i might try to tackle something newer later, after linuxcnc 2.6 is finally released
[13:25:06] <seb_kuzminsky> if you make a kernel patch that'll work with a newer 3.4 kernel and the a0dc5355ee rtai userspace i'll give that a try
[13:25:45] <seb_kuzminsky> i send shabby some bug reports about his master branch, he said he'd try to fix it
[13:25:55] <memfrob> sounds great thanks!
[13:26:13] <seb_kuzminsky> :-)
[13:27:16] <memfrob> wow! that issue report list is building!
[13:27:24] <memfrob> last i checked it had about 4'
[13:27:38] <seb_kuzminsky> shabby's rtai issue tracker?
[13:27:41] <memfrob> yes
[13:27:54] <memfrob> all those closed ones...
[13:28:14] <memfrob> you guys have been busy
[13:28:14] <skunkworks> so - is shabby taking over for pavel?
[13:28:17] <seb_kuzminsky> yeah, it's great to see that it's getting attention
[13:28:24] <memfrob> pavel?
[13:28:30] <seb_kuzminsky> i dont know pavel... paolo?
[13:28:39] <skunkworks> yes - paolo
[13:28:48] <seb_kuzminsky> not that i know of
[13:28:55] <seb_kuzminsky> seems more like a fork than a hand-over
[13:28:59] <skunkworks> ah
[13:29:01] <memfrob> ^exactly
[13:30:07] <seb_kuzminsky> i'm really not sure how the rtai situation will play out
[13:30:17] <memfrob> none of us do :)
[13:30:42] <seb_kuzminsky> memfrob: how do you work with the kernel patch? do you have a git tree somewhere that you rebase?
[13:30:42] <memfrob> shabby and i just hack on it occasionally (more him now than me. used to be vice versa)
[13:31:39] <memfrob> how do i make kernel patches you mean?
[13:31:44] <seb_kuzminsky> yeah
[13:34:12] <memfrob> cd kernel-source && patch -p1 --fuzz=0 < ../hal-linux-XYZ-X.patch (fix conflicts) && git add -A && git diff HEAD &> new-hal-linux.patch
[13:34:31] <seb_kuzminsky> oh wow
[13:34:53] <memfrob> what?
[13:35:26] <seb_kuzminsky> i had thought it was a linux git repo with a branch of rtai commits on top, that got exported to a single patch file for inclusion in the rtai repo
[13:35:36] <memfrob> heh no
[13:35:58] <memfrob> i wish it was that easy.
[13:36:07] <seb_kuzminsky> you and me both pal ;-)
[13:36:46] <memfrob> im used to it though. i've bumped major kernel releases before without any problems
[13:37:15] <memfrob> the 3.8 patch was me. i took it from the 3.5.7 patch
[13:37:53] <memfrob> speaking of which, the 3.8.13-1 patch should work fine.
[13:38:18] <memfrob> so should any kernel release before 3.12 while keeping IPIPE release ver the same
[13:38:58] <memfrob> the issues are in newer IPIPE code, not newer upstream kernel code. you keep IPIPE the same but bump the kernel code, its pretty safe.
[13:39:09] <skunkworks> jepler,
http://electronicsam.com/images/KandT/testing/posix.png
[13:39:20] <memfrob> not 3.12.. 3.10 i meant
[13:39:32] <seb_kuzminsky> memfrob: because the rtai patch doesn't interact much with the linux kernel, it's mostly with the adeos patch?
[13:39:51] <seb_kuzminsky> skunkworks: neat!
[13:40:03] <memfrob> mostly yeah.
[13:40:29] <memfrob> rtai patch affects adeos patch at its core a little bit but most of the heavily lifting is done in adeos which then breaks things.
[13:40:49] <skunkworks> as good or better latency than the ubc rt-preempt I have played with
[13:41:14] <seb_kuzminsky> it should be the same (on the same hardware)
[13:41:52] <jepler> I think ubc was missing one element of hardening (/dev/cpu_dma_latency=0)
[13:41:54] <memfrob> a lot of what RTAI does to the adeos patch is adding in a lot of EXPORT_SYMBOL lines how bugs are logged and some extra oops functions and a few extra lines that consist of declarations, definitions, and things like that
[13:42:25] <memfrob> the scheduler isnt touched, and if it is, its pretty minor stuff
[13:43:06] <seb_kuzminsky> bbl
[13:43:11] <skunkworks> now lets see if I can talk to the mesa 7i80 card. That was pretty painless to get this far..
[13:43:30] <jepler> skunkworks, pcw_home: so at origin/jepler/rtos-uspace-apis, PCI mesa hardware should work, and I've tested it with 5i20 enough to generate some pwm. At origin/jepler/rtos-uspace-hm2-eth, functionality should be similar to the ubc-7i80 branch from micges (pci cards not working)
[13:44:12] <skunkworks> I remember ubc and mah's kernel being around 80us.. (on this hardware)
[13:46:47] <pcw_home> unlike RTAI, preemt-rt kernels are easy to build so you have the option to to make your own up-to-date kernel
[14:12:54] <skunkworks> jepler, pcw_home,
http://electronicsam.com/images/KandT/testing/mesaeth.png
[14:12:57] <skunkworks> and
[14:13:09] <skunkworks> http://electronicsam.com/images/KandT/testing/mesaethrun.png
[14:13:34] <skunkworks> I don't remember this harware working very well before..
[14:14:17] <skunkworks> amd system - onboard nic is hooked to the internet/network - pro/100 pci board hooked to the mesa card.
[14:14:36] <cradek> mmmmm
[14:14:56] <skunkworks> mmmmm?
[14:15:29] <jepler> skunkworks: it works ??!
[14:15:41] <skunkworks> jepler, unless it is smoke and mirrors...
[14:15:45] <jepler> holy cow
[14:15:45] <skunkworks> Great work!
[14:16:12] <jepler> micges-dev: ^^^ I imagine you're also excited to hear it. it's your code!
[14:18:07] <skunkworks> that is using the rt kernel from the synaptic package manager.
[14:18:11] <skunkworks> pretty painlese
[14:18:43] <micges-dev> uber cool!
[14:18:46] <mozmck> rt kernel from synaptic - built by who? debian?
[14:19:21] <cradek> yeah it's a debian kernel
[14:19:42] <mozmck> that is very neat!
[14:19:56] <cradek> absolutely terrific
[14:22:00] <skunkworks> I could see 2 livecd... 1 with rt_preempt and one with rtai...
[14:22:33] <cradek> I can see not making stupid cds anymore
[14:22:53] <cradek> (although people really seem to love them, no matter how silly I think it is)
[14:25:25] <skunkworks> *images..
[14:25:36] <cradek> yeah whatever they're called nowadays
[14:27:16] <skunkworks> *I meant images - not cd's
[14:27:20] <skunkworks> iso or whatever
[14:27:31] <skunkworks> people can do what they want with them
[14:28:32] <micges-dev> cradek: test mesaflash 3.0 deb:
http://filebin.ca/1Rxhp8K6nTT4/mesaflash_3.0.0_i386.deb
[14:29:01] <micges-dev> seb_kuzminsky: ^^
[14:35:01] <skunkworks> cradek, or are you saying - install the rtai debs - then add linuxcnc.org to your sources and get linuxcnc that way?
[14:41:22] <cradek> if we run against a debian kernel maybe we can just get linuxcnc into debian
[14:41:46] <skunkworks> well - that would be super awesome
[14:43:05] <CaptHindsight> ATT knocked out our power trenching, memfrob will try that again later
[14:50:27] <memfrob> power went out. testing 3.4.96 RTAI kernel, will post patch if it goes ok
[14:52:10] <skunkworks> no realtime delays - running for a good hour or more
[14:52:43] <jepler> skunkworks: I think the realtime delay detection may be disabled
[14:52:47] <skunkworks> I will let it run overnight - I should make the program loop
[14:52:49] * jepler puts a TODO item on his list
[14:52:58] <skunkworks> oh...
[14:53:43] <skunkworks> well - I will run the program over and over at max velocity.. following error would let me know if there was a major isse.
[14:53:46] <skunkworks> issue
[14:53:54] <jepler> that seems truthy
[14:56:43] <seb_kuzminsky> omg you guys
[14:56:56] <jepler> hi seb
[14:57:16] <seb_kuzminsky> nice work on the rt-preempt/7i80 stuff y'all
[15:03:02] <memfrob> is there anything bad about building a kernel in /home instead of /usr/src?
[15:04:30] <seb_kuzminsky> nope, it's fine
[15:04:34] <memfrob> ah kernel is done building, will reboot. if no crashes, seb_kuzminsky patch is yours
[15:04:45] <seb_kuzminsky> ok thanks!
[15:04:50] <seb_kuzminsky> he rebooted
[15:07:35] <memfrob> looks good!
[15:07:45] <jepler> "if it boots, ship it"
[15:08:29] * memfrob recompiles linuxcnc against new kernel
[15:10:43] <memfrob> good thinkin jepler ;)
[15:14:33] <memfrob> would it be possible in theory to have latency results similar to rtai or xenomai while keeping everything strictly to kernel hacks like preempt-rt?
[15:16:09] <jepler> memfrob: there's a question above my pay grade if ever there was one
[15:18:35] <memfrob> brb again
[15:38:04] <skunkworks_> after a few runs it threw a following error.. I will look at it closer tomorrow. (I might move it to the system that I know worked well before)
[15:38:22] <memfrob> all is good!
[15:38:57] <skunkworks_> It looked like the read times where causing following errors (just a few jogs - the pid error was into the .001)
[15:39:38] <skunkworks_> I might also swap the nics too - I think on the other system I was using the internal one to connect to the 7i80
[15:42:38] <skunkworks_> (and the spikes in pid error corresponded to the read times)
[15:42:48] <seb_kuzminsky> memfrob: yay!
[15:43:00] <skunkworks_> logger[psha]_:
[15:43:00] <logger[psha]_> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-02.html
[15:52:41] <seb_kuzminsky> memfrob: the last commit in the ipipe.git 3.4 branch was in 2013, how can the adeos patch be changing between shabby's old-master and master? i must be missing something here
[15:52:54] <seb_kuzminsky> http://git.xenomai.org/ipipe.git/log/?h=stable/ipipe-3.4.6
[15:54:06] <memfrob> i dont contribute to upstream ipipe only githib
[15:54:08] <memfrob> *github
[15:54:15] <memfrob> im responsible for those changes
[15:56:22] <memfrob> https://github.com/ShabbyX/RTAI/tree/linuxcnc-old/base/arch/x86/patches
[15:56:26] <memfrob> patch is up
[15:57:07] <memfrob> i used to hack at adeos ipipe a lot
[16:01:41] <seb_kuzminsky> thanks memfrob, i'll take it for a spin
[16:12:47] * jepler groans at the \n;;\n thread
[16:13:01] <jepler> I want to say: I'd accept a patch which looked for \r in the source, and berated the user for it
[16:13:27] <jepler> but not one that patches it up for the user and continues on, because the user should be punshed
[16:20:18] <memfrob> is this about rtai?
[16:21:00] <memfrob> some whitespace might have been added in the patch, i apologize.
[16:21:30] <memfrob> shabby and i tried to talk to paolo about the excessive whitespace in the tree but he denied.
[16:22:10] <jepler> memfrob: no, it's about the utility called "comp" in 2.6.
[16:22:45] <memfrob> OHH
[16:23:06] <jepler> if you feed it a file with DOS line endings it just squints at you
[16:23:14] <jepler> which is the just and right thing to do
[16:27:18] <PCW> jepler: rtos-uspace-hm2-eth seems to work fine here (running 7I76E at 2 KHz)
[16:30:08] <PCW> (preemt rt 3.12.16 kernel on Celeron J1800 dual core 2.4 GHz RTK 8111 Ethernet)
[16:50:57] <jepler> PCW: good. did you see skunkworks_ eventually got a following error, though?
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-02.html#19:35:33
[16:51:58] <PCW> You will have to widen your following error limits a bit due to the higher sampling jitter
[16:53:35] <PCW> I can fix this in hardware by sampling the stepgen feedback with the DPLL but thats for another day
[16:54:32] <jepler> I sort of want one of the ethernet cards, but I don't have any project on tap that would actually need one
[16:54:35] <jepler> oh well
[16:55:33] <PCW> i can send you a proto/blem, got a bunch around
[16:56:45] <seb_kuzminsky> jepler: you could rototill the controller for your 3d printer just because
[16:57:03] <jepler> PCW: that'd be great of you to do
[16:57:10] <jepler> seb_kuzminsky: that assumes I'll ever get back to that project
[16:58:06] <PCW> 50 pin header or DB25 type?
[16:59:12] <jepler> PCW: I guess with the 50 pin I can plug it into my old blinkenlights daughterboard
[17:03:09] <jepler> since the hm2-eth code is incompatible with the pci cards, this'll allow me to test both while I try to get it working
[17:03:16] <jepler> .. if micges doesn't beat me to it
[17:04:28] <jepler> and I have a hopefully-compatible PCI-E parport card coming tomorrow, so I can test 7i43 too
[17:04:44] <cradek> darn, I forgot to look for one for you
[17:04:46] <cradek> sorry
[17:04:50] <jepler> cradek: eh, it's OK
[17:57:31] <andypugh> Did my recent post to emc-dev about spinbutton get through? Gmail hides one’s own responses, and I used to that, but I don’t see it in gmane either
[17:58:05] <andypugh> Sorry, now I do.
[17:58:22] <andypugh> Some sort of archiving lag
[18:26:20] <seb_kuzminsky> andypugh: try running rt-preempt on your mail server
[18:26:28] <andypugh> :-)
[18:27:32] <mozmck> just kick archivist
[18:27:54] <andypugh> Though, that does remind me of a serious question. I see no plan for Xenomai, and that means no 7i80. Any ideas?
[18:28:35] <PCW> 7I80 runs fine on Preemt-RT
[18:28:36] <seb_kuzminsky> i think it's supported on rt-preempt in jepler's latest branch
[18:28:43] <seb_kuzminsky> what he said
[18:29:00] <andypugh> I think he said it _could_ be, with a driver re-write.
[18:29:16] <seb_kuzminsky> sam and peter have both already got it up and running
[18:29:39] <PCW> Just had it running 70 days 24/7 2KHz with UBC3-7I80
[18:30:04] <seb_kuzminsky> andypugh: 12:54 < skunkworks> jepler, pcw_home,
http://electronicsam.com/images/KandT/testing/mesaeth.png
[18:30:13] <seb_kuzminsky> that's earlier today ^^^
[18:30:38] <PCW> and dual core baytrail MB (J1800 about 2-3x Atom speed, same power)
[18:31:21] <andypugh> PCW: I fear UBC3 is dead in the water
[18:31:25] <PCW> now running the same with jeplers uspace
[18:31:50] <seb_kuzminsky> i'm so glad for jepler's and micges' work on that
[18:32:54] <seb_kuzminsky> andypugh: check out the branch called jepler/rtos-uspace-hm2-eth on glo
[18:33:30] <andypugh> Sorry, my psychic skills were turned off
[18:35:00] <seb_kuzminsky> it would be cool to have xenomai support, but i think we're in pretty good shape without it, once that branch gets merged
[18:35:13] <seb_kuzminsky> and it'll be very easy to review & merge, compared to ubc3-7i80
[19:12:42] <cradek> - "" | y | ye | yes | n | no)
[19:12:44] <cradek> + ("" | y | ye | yes | n | no)
[19:13:05] <cradek> jepler: are these changes on purpose? they seem to still work, but I've never seen a case written with the (
[19:34:50] <micges-dev> cradek: beta mesaflash package:
http://filebin.ca/1Rxhp8K6nTT4/mesaflash_3.0.0_i386.deb
[19:43:02] <jepler> cradek: it's permitted in posix shell, look at the production case_item_ns in
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
[19:43:12] <jepler> cradek: and it fixed my editor being bitchy about paren-matching in this case
[19:43:32] <jepler> cradek: so I could drop it, or split it to a separate commit
[19:43:37] <jepler> preference?
[20:54:26] <cradek> no strong preference
[20:55:25] <cradek> I'm offended that it was to satisfy an editor's substandard understanding of sh, but that's no reason to undo it if it's equally valid
[20:59:44] <jepler> vim certainly doesn't get it right in this case
[21:02:56] <cradek> jepler: in 39354653, the setfsuid seems like it must be important, but I don't immediately see the idea behind it. is it because rtapi_app is sometimes installed setuid now?
[21:03:47] <cradek> is it supposed to make the core dumps safer?
[21:12:43] <cradek> - chan->params->u32_param = 0xF;
[21:12:44] <cradek> + chan->params->rtapi_u32_param = 0xF;
[21:12:56] <cradek> harmless but probably not intended?
[21:13:41] <jepler> cradek: yes, that was a search-and-replace error not caught.
[21:15:00] <jepler> cradek: yes, as soon as possible in rtapi_app we want to start doing I/O as ourselves, with a few exceptions
[21:15:51] <jepler> cradek: see 94f429bf, which maybe should be squashed, for an example
[21:16:13] <jepler> same at ed77f61a
[21:16:25] <jepler> need root permissions to open device stuff
[21:17:12] <jepler> .. but setfsuid() doesn't apply to shm API calls, so I have to use a different method to ensure the shm is owned by the user (in 39354653)
[21:18:19] <jepler> I use the counted method in the pci code because I was too tired to see whether anything there was calling another place where I wanted to have root filesystem I/O
[21:20:21] <jepler> + /* UIO-pci-generic should bind to the device now. Wait to avoid races. */
[21:20:24] <jepler> wtf is that
[21:22:34] <cradek> //FIXME: Support more than one card!
[21:22:34] <cradek> hmm
[21:23:54] <jepler> I haven't understood this code well enough to know whether limitations like that are easy or hard to lift..
[21:28:28] <jepler> I don't even have /sys/bus/pci/drivers/uio_pci_generic
[21:36:13] <jepler> soooo .. it turns out there are two implementations of userspace pci
[21:36:17] <jepler> *bodypalm*
[21:37:08] <jepler> one set of APIs which use rtapi_pcidev and one set which use rtapi_pci_driver (which was possibly pci_driver upstream at machinekit)
[21:39:57] <jepler> so there are 350 lines of rtapi_pci.cc that can just be deleted :-/
[21:40:00] <jepler> and hm2 still runs
[21:40:13] <jepler> hm2-pci
[21:40:22] <jepler> so this pretty much shows that I need to beat on rtapi_pci.cc until it doesn't suck
[21:53:43] <jepler> if (mmio == NULL)
[21:53:44] <jepler> munmap(mmio, rtapi_pci_resource_len(dev,bar));
[22:12:43] <skunkworks_> how does the realtime delay work for just the servo thread? does it just get triggered if the processes within the thread take longer than the servo thread? or is it takes longer than a percentage of the servo thread?
[22:12:59] <skunkworks_> servo period
[22:14:31] <jepler> in rtai rtapi, there are two distinct checks. The first (and newest) is the return value from rt_task_wait_period(), an RTAI API. If it returns RTE_TMROVRN then we diagnose an 'unexpected realtime delay on task'
[22:14:40] <jepler> I don't know what it does inside, but I could go learn
[22:16:07] <jepler> the second, and older, is the servo one. It is just a heuristic: it measures the number of CPU cycles from the start of one call to the motion handler to the start of the next one. If the newest interval is more than 1.2x as many cycles as any of the others, then it diagnoses "Unexpected realtime delay", with information about the number of cycles
[22:16:22] <jepler> the first one is diabled for uspace because uspace doesn't use rt_task_wait_period, it uses some other call (clock_nanosleep)
[22:16:53] <jepler> and the second is disabled (A) simply because it was always disabled for sim and (B) because it gives false positives when CPU frequency scaling is enabled, which may be the case in -rt kernels I think
[22:17:13] <skunkworks_> interesting
[22:19:13] <skunkworks_> so both have to be rewritten - and it sounds like only the first one (which has to be reworked to use clock_nanosleep) is usable
[22:20:03] <jepler> yeah, some form of "unexpected realtime delay" would *cough* be nice
[22:20:38] <jepler> cradek: OK, rtapi_pci.cc pretty thoroughly reamed.
http://emergent.unpythonic.net/files/sandbox/rtapi_pci.cc if you want to review it.
[22:20:43] <jepler> 'night all
[22:20:59] <skunkworks_> night - thanks for all your work!
[22:24:49] <jepler> cradek: (I think the reaming also fixes the multi-device stuff but of course I can't test it)
[22:25:39] <jepler> compared to the previous version, 144 insertions, 506 deletions (so I deleted nearly 40% or so)
[22:26:30] <memfrob> hi seb_kuzminsky how did the patch go? get a chance to test it?
[22:42:53] <cradek> jepler: we could borrow up to all 3 5i20s from my machines
[22:43:02] <cradek> seb_kuzminsky:
http://timeguy.com/cradek-files/emc/installer-failsafe.png
[22:46:16] <cradek> fwiw, latest image will be on wlo in ~ 1hr
[22:47:11] <cradek> 0189184d4636939f7a31c3b3af8119df
[23:06:31] <skunkworks_> I have more than 1 5i25 I could test too
[23:09:08] <skunkworks_> I would have to find a motherboard with more than one pci slot
[23:09:10] <skunkworks_> ;)
