Back
[03:47:52] <seb_kuzminsky> the buildbot debs are signed by the buildmaster now, i added a blurb about it to
http://buildbot.linuxcnc.org/
[07:00:56] <jepler> seb_kuzminsky: yay, signed repository
[07:57:47] <micges-dev> jepler: can you make small test with your 5i20 under hm2_eth uspace branch?
[07:59:08] <micges-dev> jepler: test with this patch:
http://pastebin.com/xkmKcsmd
[08:09:12] <jepler> micges-dev: will do
[08:09:14] <jepler> .. building now
[08:09:18] <jepler> patch applied by hand
[08:11:23] <jepler> micges-dev: 5i20 does load, makes nasty crash at unload
[08:12:54] <micges-dev> yes, hm2->watchdog.status_reg is overwritten, can you narrow it down? my gdb is too slow
[08:14:14] <micges-dev> hm2->watchdog.status_reg is malloced and after pointer is trashed
[08:14:57] <jepler> I can't do much right now. I'll look at it tonight, my time.
[08:17:04] <jepler> (remote machine was booted in rtai, so now it's looking pretty wedged; can't do anything more until I go home and reboot it)
[08:17:53] <micges-dev> oh I see
[08:18:17] <micges-dev> jepler: thanks!
[08:29:29] <jepler> (what a luxury to be able to run a debugger on "realtime" code)
[08:41:55] <jepler> micges-dev: I have some useful debugging information from valgrind
[08:42:30] <jepler> http://pastebin.com/311e3GSp
[08:44:22] <jepler> but perhaps this only confirms what you said already: that status_reg is "overwritten"
[08:46:02] <jepler> micges-dev: OK, I can tell you sort of what's going on...
[08:46:05] <jepler> in watchdog.c, we have:
[08:46:08] <jepler> r = hm2_register_tram_read_region(hm2, hm2->watchdog.status_addr, (hm2->watchdog.num_instances * sizeof(rtapi_u32)), &hm2->watchdog.status_reg);
[08:46:11] <jepler> ...
[08:46:15] <jepler> hm2->watchdog.status_reg = (rtapi_u32 *)rtapi_kmalloc(hm2->watchdog.num_instances * sizeof(rtapi_u32), RTAPI_GFP_KERNEL);
[08:47:01] <jepler> hm2_register_tram_read_region stores &hm2->watchdog.status_reg and later when hm2_allocate_tram_regions is called it writes hm2->watchdog.status_reg, overwriting the kmalloc'd pointer
[08:52:20] <jepler> so you need to fix the memory allocation of status_reg and figure out a correct way to get it its initial value of "0"
[08:53:10] <jepler> .. it's uninitialized, as shown by this valgrind diagnostic:
[08:53:10] <jepler> ==32730== Thread 2:
[08:53:10] <jepler> ==32730== Conditional jump or move depends on uninitialised value(s)
[08:53:11] <jepler> ==32730== at 0x67AAE4C: hm2_watchdog_process_tram_read (watchdog.c:105)
[08:53:14] <jepler> bbl
[09:11:44] <seb_kuzminsky> cradek: thanks for the updated live/install image
[09:20:28] <micges-dev> jepler: thanks I fixed it
[09:25:37] <seb_kuzminsky> i wonder what Churms, Cecil was really asking...
[09:30:10] <cradek> hm, there's already a new ubuntu lts after precise
[09:30:35] <cradek> I would rather see people use wheezy than precise
[09:30:54] <cradek> I wonder if anyone cares about my feelings
[09:31:43] <archivist> I hate names because there is no relation to version number
[09:33:42] <jepler> I, too, would rather see people using Debian
[09:33:58] <jepler> they'll be at least 2 years behind Ubuntu in switching away from X, for example
[09:35:52] <cradek> while booted live, I added the checkmarks in front of the buildbot-rt sources in synaptic, poked upgrade, and 2.7.0~whatever installs and runs
[09:36:12] <jepler> cradek: oh, there's a way to ship sources.list entries "turned off"?
[09:36:24] <jepler> "#deb" or is it something more sophisticated?
[09:36:31] <jepler> .. you'll include the buildbot's key on the media too?
[09:36:32] <cradek> yes, and I have both 2.6 and master from buildbot in there, that way
[09:36:38] <cradek> yes the keys are all there
[09:36:45] <jepler> that's all awesome
[09:36:46] <cradek> it's exactly #deb
[09:36:49] <cradek> yeah
[09:37:26] <cradek> should we boldly recommend wheezy on the
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise page that a lot of folks seem to be using?
[09:41:09] <jepler> fine by me
[09:42:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth f396a90 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Allow debugging rtapi_app as root * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f396a90
[09:43:07] <jepler> cradek, seb_kuzminsky: remote: git_buildbot: ERROR: Could not connect to buildbot.linuxcnc.org:5133: Connection was refused by other side: 61: Connection refused.
[09:45:39] <jepler> What other libraries deserve a mention here? gtk?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
[09:45:41] <cradek> jepler: that's one for seb
[09:58:16] <micges-dev> jepler: this bug I introduced with watchdog changes in hm2_eth, I wonder why noone hit it while using 7i80...
[10:02:49] <jepler> oops, I pushed that last thing to a wrong branch anyway
[10:03:15] <KGB-linuxcnc> 03Jeff Epler 05master 59f18d0 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Allow debugging rtapi_app as root * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=59f18d0
[10:22:57] <jepler> oh it's been nice to get back to developing on linuxcnc
[10:30:18] <cradek> me too
[10:30:49] <cradek> I'm doing metawork, but it feels important and useful
[10:48:55] <jepler> you're making it so regular people can install the software
[10:49:01] <jepler> for certain definitions of regular
[10:50:44] <seb_kuzminsky> jepler: that's probably the super flaky internet at my house :-(
[10:51:26] <Roguish> cradek: fyi. yesterday i attempted the 'wheezy' install you referenced a bit ago. hm2_pci is broken. i tried all three branches. same results.
[10:52:31] <Roguish> i would like to do it again if possible. i see you guys are making progress leaps and bounds. thanks!!!
[10:52:56] <seb_kuzminsky> Roguish: how did hm2_pci fail for you?
[10:53:40] <Roguish> if i recall correctly, the .....ko was not found or something to that affect.
[10:53:54] <seb_kuzminsky> hrm
[10:54:07] <Roguish> sorry i do not recall more.
[10:54:08] <cradek> Roguish: it would be great if you could try again, and share what you typed and what you saw
[10:54:28] <seb_kuzminsky> i run hm2_pci (5i22) on a wheezy install off an older version of cradek's image
[10:54:34] <seb_kuzminsky> works for me ;-)
[10:54:42] <cradek> I also use it with my 5i25
[10:54:49] <jepler> I used an older version of the image with a 5i20
[10:54:57] <Roguish> ok. i would like to help.
[10:55:09] <Roguish> i too use a 5i20
[10:55:18] <jepler> I didn't run a mill, just a .hal script that did a basic "load and look if pins exist"
[10:55:31] <seb_kuzminsky> i bet we can make that work, and maybe discover where things went wrong for you so we can fix it for everyone in the future
[10:57:44] <jepler> though .. I'm not 100% sure I did it with the packaged version of 2.6
[10:58:36] <seb_kuzminsky> the packaged versions were incompatible with the installer image for a while, when i was trying to get the rtai kernel under control
[10:58:41] <seb_kuzminsky> should be good now though
[10:59:23] <Roguish> right now i am in the middle of the 'Debian Wheezy Linux-RT compile LinuxCNC'. when i do the 'dpkg-checkbuilddeps' i get 'error: cannot read debian/control: No such file or directory'
[10:59:44] <seb_kuzminsky> linux-image-3.4-9-rtai-686-pae version 3.4.55-3linuxcnc for the win (despite the ridiculous mouthful of a specifier)
[10:59:57] <seb_kuzminsky> Roguish: you skipped a step i think
[11:00:02] <seb_kuzminsky> cd debian; ./configure -a
[11:00:03] <cradek> Roguish: so you're not using the new image?
[11:00:04] <Roguish> ??
[11:00:17] <cradek> Roguish: if you're following some instructions, link us to them
[11:00:17] <jepler> these instructions are out of date and should be deleted.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC
[11:00:36] <Roguish> DOH !!!
[11:00:54] <jepler> it's not your fault
[11:01:15] <seb_kuzminsky> heh: (a different 'I' from the 'I' in the main text)
[11:01:25] <Roguish> jepler cited the instruction i am trying.
[11:01:38] <jepler> Roguish: you should install from one of cradek's "hybrid.iso" images. it includes a (we think) working linuxcnc preinstalled.
[11:01:49] <seb_kuzminsky> probably a bunch of the wiki needs to be re-evaluated... :-/
[11:02:03] <Roguish> point me to them and I will give it a shot.
[11:02:16] <cradek> Roguish: this morning's announcement on emc-users:
http://article.gmane.org/gmane.linux.distributions.emc.user/52401
[11:02:33] <Roguish> will check email and read it.
[11:02:42] <cradek> Roguish: thanks!
[11:02:47] <archivist> how about move stuff from wiki to the docs while fixing
[11:02:54] <seb_kuzminsky> archivist: +1
[11:03:20] <seb_kuzminsky> some stuff should move to the git docs, some should stay on the wiki, and some should be deleted
[11:03:21] <archivist> wikis get stale I think
[11:03:27] <cradek> we will have to update
http://linuxcnc.org/index.php/english/download
[11:03:32] <cradek> soon, but probably not today
[11:04:29] <Roguish> it will take a bit, but i will get to it today. juggling a lot right now. installing SolidEdge for a possible job at Stanford Linear Accelerator (SLAC) on their new FEL project.
[11:05:11] <seb_kuzminsky> i used to live near slac, but i never visited
[11:05:16] <seb_kuzminsky> seems like a neat facility
[11:06:26] <cradek> I deleted that wiki page. it didn't have any instructions that should be followed today.
[11:06:38] <seb_kuzminsky> thanks
[11:07:16] <Roguish> i'm up in Walnut Creek, so the commute will be hell. but the job is really cool.
[11:07:27] <seb_kuzminsky> wow cradek, zsync is cool
[11:08:10] <cradek> seb_kuzminsky: yeah, it's pretty magical
[11:08:52] <cradek> even for the first download it's nice, because it makes sure you get the file correctly
[11:09:58] <jepler> OK, I basically deleted
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC and started over
[11:10:24] <cradek> thanks
[11:10:30] <cradek> that's better than my outright deletion
[11:10:48] <cradek> your last link didn't link
[11:10:52] <jepler> oops
[11:11:27] <cradek> there are no links to that page, so we could rename it to be more appropriate
[11:11:34] <jepler> what should it be called?
[11:11:47] <jepler> I have published some links to it in e-mail though
[11:11:49] <cradek> it could be DebianWheezy
[11:11:51] <cradek> oh ok
[11:12:08] <cradek> the _ are disturbing
[11:12:23] <jepler> Someone_else's_Style
[11:12:32] <jepler> OffendedByWikiNames
[11:12:39] <jepler> of course, "Uspace" isn't a very good WikiName either
[11:12:48] <cradek> WikiNamesWereNIH
[11:18:09] <cradek> there
[11:18:16] <cradek> I renamed it and made a redirect from the old name
[11:18:27] <jepler> OK, thanks
[11:19:49] <jepler> cradek: OH, I see you were renaming the long page name
[11:19:54] <jepler> I though you were talking about "Uspace"
[11:19:59] <seb_kuzminsky> i'm unconvinced that wheezy > precise for most users
[11:20:25] <jepler> I'm unconvinced precise > win8 for most users
[11:20:32] <seb_kuzminsky> well yeah
[11:20:41] <cradek> I'm unconvinced you're both not trolling
[11:20:44] <seb_kuzminsky> heh
[11:20:52] <seb_kuzminsky> i'm serious
[11:21:11] <cradek> do you mean aside from wheezy being easire to install right now, or even including that?
[11:21:14] <cradek> easier
[11:21:56] <cradek> I have to admit I haven't used precise much
[11:22:17] <jepler> I get a rash when I look at the precise default desktop environment
[11:22:23] <Connor> You all thinking of doing a image of Debian Wheezy vs Ubuntu ?
[11:22:25] <jepler> I also become prone to exaggerating
[11:22:28] <cradek> I don't have any interest in ubuntu anymore, because I'm tired of undoing their breakage
[11:22:40] <cradek> Connor:
http://article.gmane.org/gmane.linux.distributions.emc.user/52401
[11:22:43] <jepler> Connor: there are current images of Wheezy (cradek's put a great deal of work in)
[11:22:44] <mozmck> the name "wheezy" certainly sounds worse than "precise" for machining...
[11:23:11] <jepler> We should take care to call it Debian 7.5 then.
[11:23:31] <cradek> but 7.5 < 10.04
[11:23:38] <cradek> sorry, now I'm doing it
[11:23:48] <Connor> Cool
[11:23:52] <jepler> it's hard to do this conversation without hyperbole
[11:25:38] <Connor> It's SO hard to keep up these days...
[11:25:54] <cradek> 100% seriously now, I don't pretend to be able to guess what's best for "most" users, or for even any user other than me, but I think wheezy is among the good choices and that's where I chose to put in the work to make it as easy as possible for folks.
[11:27:07] <cradek> some of the things where I think ubuntu made a better choice for our users than debian by default (nonfree firmwares, sudo from the primary installed user, update manager that pops up) I retrofitted those choices into my cd
[11:27:14] <Connor> I don't see anything wrong with it.. your basically just going 1 level up on the distribution chain.. since Ubuntu is built on-top of Debian..
[11:28:33] <cradek> if there are more of those concrete things, let me know what you think they are
[11:31:04] <micges-dev> jepler: can I apply fix on top of jepler/hm2_eth branch?
[11:31:13] <jepler> micges-dev: yes
[11:31:46] <jepler> micges-dev: I can test on 7i43 and 5i20 later, with your fix
[11:31:58] <micges-dev> ok
[11:32:09] <jepler> seb_kuzminsky: I assume you'll want a change to review hm2_eth before it's pushed...
[11:32:35] <micges-dev> jepler: I tested it with 5i25, works ok
[11:33:18] <seb_kuzminsky> cradek: i like that you retrofitted those good things onto you wheezy image. it's working really well for me
[11:38:06] <jepler> I feel like I don't think about my linux like "typical users" do, so it's a hard question to try to answer
[11:38:33] <jepler> For example, I'd rather my desktop looked something like Linux circa 2002 than like an ipad
[11:38:55] <jepler> argh I couldn't even stop that coming out without sarcasm
[11:40:14] <seb_kuzminsky> haha
[11:42:54] <jepler> cradek: does hybrid.iso prompt the user before using proprietary drivers or firmware?
[11:44:04] <seb_kuzminsky> i dont remember getting prompted, but the one i tried was many days ago
[11:44:25] <cradek> jepler: nope
[11:44:42] <jepler> cradek: that's a pity
[11:45:14] <jepler> I badmouthed ubuntu about that back in 2010 (when they'd put nvidia behind a "non-free driver" icon, but not [yet?] firmwares)
[11:46:00] <cradek> jepler: :-/ it makes my wifi work.
[11:47:17] <jepler> cradek: I know; I use a laptop that requires non-free firmware
[11:48:14] <cradek> it won't do nvidia or other lkms things, but does have the linux-firmwares-all (however it's spelled) from non-free
[11:51:14] <Roguish> ok. made the boot usb drive with the hybrid. ready to rebuild.
[11:52:58] <Roguish> opinion on Ubuntu, et.al.. Ubuntu is too bloated. I much prefer a simple, stripped down OS for running machines. I do not see the need for all the office type stuff, games, and media junk. KISS please. just my opine.
[11:54:03] <Roguish> signing off to reboot and rebuild. back in a while.................
[12:08:25] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth ae7166a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c hm2_pci: fix pci driver after tram changes that allows send/receive ethernet data in one packet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ae7166a
[12:08:25] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth 800a4b6 06linuxcnc 10src/hal/drivers/mesa-hostmot2/watchdog.c hostomot2: fix memory corruption in watchdog introduced in 2a4997813d6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=800a4b6
[12:08:48] <cradek> yay!
[12:11:52] <seb_kuzminsky> awesome
[12:12:00] <seb_kuzminsky> the 2.7 features are piling up, better get 2.6 out!
[12:12:19] <cradek> you know it's time
[12:12:29] <seb_kuzminsky> yeah
[12:12:41] <seb_kuzminsky> getting the rtai kernel sorted out was the last blocker on my list
[12:12:56] <cradek> is it suitably sorted?
[12:13:04] <seb_kuzminsky> if the kernel switch for pre5 works i think it's done
[12:13:16] <seb_kuzminsky> i wonder how that will go for people
[12:13:17] <cradek> well it works
[12:13:38] <seb_kuzminsky> i think i'll have some time this weekend
[12:13:44] <seb_kuzminsky> to make the 2.6.0 release
[12:13:54] <jepler> micges-dev: how do you feel if I use rebase to make the history pretty?
[12:14:32] <jepler> (of hm2-eth)
[12:14:54] <jepler> so far I worked to preserve your history and then make fixes on top of it, but it'd be nicer to merge a branch with no "introduce bug, then fix bug" history..
[12:16:01] <micges-dev> sure, just leave note about wd buffers
[12:17:50] <jepler> It looks like changes are needed in 7i43 and 7i90 drivers too
[12:18:03] <jepler> I can test 7i43
[12:18:13] <micges-dev> right I forgot
[12:18:19] <micges-dev> I can test 7i90
[12:18:22] <jepler> OK
[12:19:11] <jepler> hmm
[12:20:06] <jepler> so basically, queue_write is the same as write, except if the size is -1?
[12:20:16] <jepler> and the same for read?
[12:20:31] <micges-dev> yes
[12:20:47] <jepler> and anybody who doesn't care about queueing can just return when size is -1
[12:21:11] <micges-dev> yes
[12:26:18] <jepler> then what about this?
http://emergent.unpythonic.net/files/sandbox/0001-hostmot2-Provide-implementation-of-queue_-read-write.patch
[12:26:31] <jepler> now _pci, _7i43 and _7i90 shouldn't require any changes
[12:27:38] <seb_kuzminsky> looks good to me
[12:28:27] <jepler> the watchdog change is an incompatible change, right?
[12:28:50] <jepler> (it removes a hal function)
[12:29:36] <micges-dev> ahh clever
[12:30:08] <jepler> I can't tell you how pleased I am when someone calls me clever.
[12:31:19] <seb_kuzminsky> deleting thousands of lines of cruft: also clever ;-)
[12:31:30] <micges-dev> :
[12:31:31] <micges-dev> :)\
[12:31:46] <seb_kuzminsky> it's a mutant smiley
[12:32:00] <micges-dev> wd change doesn't remove hal function
[12:32:25] <jepler> I am confused, then
[12:32:29] <jepler> but that's OK
[12:32:31] <jepler> bbl, lunchtime
[12:38:16] <micges-dev> it just reads wd status along with tram read, not directly from board, so if tram is one eth packet and wd read was another eth packet then we reduce reading from board to one packet per servo cycle
[12:39:11] <Roguish> ok, back. now running on an installed hybrid iso
[12:39:40] <seb_kuzminsky> sweet
[12:39:46] <Roguish> ran ok on the live version. tried the 5i20 and it started up without errror.
[12:39:52] <seb_kuzminsky> aww yiss
[12:40:06] <seb_kuzminsky> great, thanks for trying that
[12:40:26] <Roguish> restarted and did the graphical install. tried the 5i20 again and started up without error. yeah baby !!!!!
[12:44:06] <Roguish> oh, yeah. it's on a new intel D2500HN with 4 gig ram and a 128 gig SSD.
[12:44:43] <seb_kuzminsky> how's your latency?
[13:09:46] <cradek> andypugh: about the tool table: I think you're conflating two things. the packing lets you have arbitrary P numbers. the prepped-pocket hal pin should show that arbitrary P number.
[13:13:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth 93fc025 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c hostmot2: Provide implementation of queue_{read,write} * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=93fc025
[13:14:15] <andypugh> cradek:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_find.cc;hb=59f18d06ac980b906c9dd786fa3f387b88bc41eb#l708
[13:14:27] <andypugh> It returns the index in the array where the tool number is found
[13:16:28] <cradek> yeah ... that's how it knows which index to load. but that's not really related to what I'm saying. I think the bug is that the hal pin, and only the hal pin, should show the P number from the tool table when you prep a tool. there is nothing wrong with anything else, even though the array indexes are called "pockets" in the code
[13:16:46] <andypugh> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/tool_parse.cc;hb=59f18d06ac980b906c9dd786fa3f387b88bc41eb#l95
[13:16:56] <cradek> those internal indexes are only sometimes really pockets, and who cares about that
[13:16:59] <andypugh> The tool array does not actually contain the P-numbe
[13:17:09] <cradek> no, but the fms array does
[13:17:34] <cradek> nothing needs it but iocontrol, so it's fine that it's only in there
[13:18:19] <cradek> without looking at the code, can you describe the bug you see externally? is it that the hal prep pin shows the wrong pocket number?
[13:18:53] <cradek> (if nonrandom)
[13:19:09] <andypugh> iocontrol.0.tool-prep-pocket always shows the tool number if nonrandom, not the pocket number.
[13:19:32] <cradek> actually I think it shows the internal index
[13:19:50] <cradek> but ok, then I think I'm thinking about it the right way
[13:20:02] <cradek> if nonrandom, it should just look it up in fms
[13:21:43] <andypugh> fms?
[13:22:00] <cradek> fms is an array in iocontrol that remembers the P number from the tool table if nonrandom
[13:22:15] <cradek> it is packed the same way the tool array is
[13:22:46] <andypugh> I have a tool table with 5 tools. Tool 1 has 11 in the pocket column, and so on. If I set “random” then I get 11 on the HAL pin for T1. If random_toolchanger isn’t set, then I get 1.
[13:24:20] <andypugh> fms is only consulted for random
[13:24:52] <cradek> fms is used when nonrandom
[13:25:00] <andypugh> Sorry, reading the code wrong
[13:26:25] <cradek> *(iocontrol_data->tool_prep_pocket) = p;
[13:26:38] <cradek> unless I'm missing something, I think you get the internal index number, not the T number
[13:26:57] <cradek> so if T1 is your first line you'd get 1, but if it's the third line you'd get 3
[13:27:59] <cradek> the only trick to fixing it (making it not a one line change) is how we read it back in from the hal pin: emcioStatus.tool.pocketPrepped = *(iocontrol_data->tool_prep_pocket);
[13:28:02] <andypugh> Yes, I guess that fits observations. It certainly isn’t the “pocket” column entry
[13:28:25] <cradek> ok cool
[13:28:43] <cradek> return 11; //change finished
[13:28:46] <cradek> oh this code
[13:28:50] <andypugh> Not that cool, it _should_ be the pocket column, shouldn’t it?
[13:29:23] <cradek> (cool = oh good I think I understand the problem) yes, I think it should be the P number from the tool table
[13:30:11] <cradek> adding to iocontrol_data a (non hal pin) tool_prep_index and then manipulating it alongside tool_prep_pocket seems like an easy fix
[13:30:36] <andypugh> I only noticed because I started to create a remapped code (initially M10) to return the posket number, then fond that even calling the tool_get_pocket code returned the Tool Number.
[13:31:13] <andypugh> (I didnt
[13:31:44] <andypugh> I didn’t notice that it actually returned the table row, I did notice that it wasn’t the pocket number.
[13:32:35] <andypugh> Arguably this indicates that nobody has ever needed nonrandom pockets, or it would have been mentioned.
[13:32:46] <cradek> I bet you are right about that
[13:33:05] <cradek> but that would also mean we can fix it and nobody will complain
[13:33:22] <cradek> those internal index numbers can't have been useful to anyone
[13:34:15] <cradek> ffffff we have two copies of iocontrol.cc
[13:36:30] <andypugh> Adding an index to iocontrol might not fix
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_find.cc;hb=59f18d06ac980b906c9dd786fa3f387b88bc41eb#l708
[13:37:18] <cradek> that means find the internal index that contains that requested T number
[13:37:32] <cradek> it will still work the same
[13:38:05] <andypugh> I think that is what is called by the python interface, which certainly looks like it would want to return an actual pocket.
[13:38:30] <cradek> ok the bug report just got bigger :-/
[13:39:39] <cradek> I'm working on fixing the hal pin thing
[13:39:40] <cradek> fwiw
[13:40:40] <andypugh> Packing the tools tightly means that we allow arbitrarily large pocket numbers, I guess. But then we don’t seem to be making the number available anywhere, so it seems moot.
[13:41:08] <cradek> well that's the bug, IMO
[13:42:12] <andypugh> I found this initially with the G43.2 remap example, I spent ages trying to figure out why I couldn’t set a pocket number from the remap, then realised that it was just the same without the remap.
[13:46:55] <cradek> http://pastie.org/9412832
[13:48:01] * cradek cringes and starts the runtests
[13:49:19] <andypugh> I will try to give it a run-through after dark, bit at the moment I have old motorbikes to rebuild :-)
[13:49:36] <cradek> that sounds like a lot more fun
[13:49:48] <cradek> I did test it in sim/axis...
[13:50:25] <cradek> but you'll still get internal pockets inside the interpreter remap stuff -- not sure what can be done about that
[13:50:39] <cradek> add the fms entries to the array, I guess, but ick
[13:51:06] <cradek> but I think this incomplete fix is worthwhile either way
[13:51:11] <andypugh> If I ever shift tool data out of NML and into something sensible, then this can all be tidied up
[13:51:27] <cradek> yes I'd love it if you could nuke this garbage
[13:51:36] <andypugh> You don’t need data for anything but the currently loaded tool in realtime....
[13:51:58] <andypugh> (for values of “currently loaded” that may include readahead)
[13:52:56] <andypugh> It does feel like one approach might be to delete the tool array then see what breaks.
[13:54:24] <andypugh> Right! to the Bat Cave!
[14:04:32] <skunkworks_> http://www.youtube.com/watch?v=VSaDPc1Cs5U
[14:08:44] <Tom_itx> andypugh, what about prefetch changers?
[14:17:53] <cradek> seb_kuzminsky: 2.6?
http://pastie.org/9412832 Runtest: 141 tests run, 141 successful, 0 failed + 0 expected
[15:05:56] <micges-dev> jepler: 7i90 works
[15:06:24] <jepler> micges-dev: good
[15:06:31] <jepler> with my most recent push?
[15:06:38] <micges-dev> yes
[15:27:26] <seb_kuzminsky> cradek: i thought params were out of fashion?
[15:29:13] <seb_kuzminsky> i think i'll skip the oportunity to chat with steve blackmore about how i'm wasting everyone's time
[15:32:22] <cradek> seb_kuzminsky: well it's no use to the user, but it was nice to see for my testing. it wouldn't have to be a param at all, except I wanted it in a structure that's all hal stuff. I'm actually a bit ashamed.
[15:52:54] <seb_kuzminsky> cradek, andypugh: we have two version of io now for some reason, this ontroduces (another?) incompatibility between them
[15:53:41] <seb_kuzminsky> this does make io behave like io.1 says it should, so that's good
[15:54:32] <seb_kuzminsky> if andypugh approves, push to 2.6 please
[15:55:04] <jepler> seb_kuzminsky: "iocontrol-v2" was a mah
[15:55:34] <jepler> assuming that's what you are referring to
[15:55:52] <seb_kuzminsky> yeah
[15:55:58] <cradek> yeah I know we have two. I don't know what to do about it.
[15:56:10] <seb_kuzminsky> jepler: while you have your flensing knife out...
[15:57:40] <jepler> does v2 actually fix some bug?
[15:58:44] <seb_kuzminsky> it implements part of a new tool change protocol
[15:58:47] <seb_kuzminsky> i think
[15:58:55] <memfrob> whats the linuxcnc branch to use for best preempt_rt performance?
[15:59:14] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolchangerProtocolProposal
[15:59:17] <seb_kuzminsky> memfrob: master
[15:59:25] <jepler> rt-preempt support is fully merged into master branch.
[15:59:57] <jepler> there's still a "2.6-ish" version of the branch, rat/jepler/rtos-uspace-for-2.6
[16:00:04] <jepler> err that's not right
[16:00:10] <memfrob> will use master thanks
[16:00:49] <jepler> origin/jepler/rtos-uspace-for-2.6
[16:01:05] <jepler> and if you're a hm2-eth early-adoper you need origin/jepler/hm2-eth or origin/jepler/hm2-eth-for-2.6.
[16:01:14] <jepler> but all the 2.6-ish branches are not anticipated to be updated further
[16:03:01] <memfrob> how stable is 3.4.55 kernel with that old RTAI checkout? are there any actual bugs?
[16:03:58] <seb_kuzminsky> there are zero stability bugs that i know about
[16:04:23] <seb_kuzminsky> there's an issue with some usb controllers refusing to initialize
[16:04:52] <jepler> there's at least one computer that rtai 3.4.55 refuses to run on, citing some erratum on the timer chip; where rtai 3.3 worked.
[16:05:55] <seb_kuzminsky> oh, is this dgarr's machine?
[16:05:58] <jepler> yeah
[16:06:04] <seb_kuzminsky> crap, i forgot about that one
[16:07:01] <seb_kuzminsky> my notes say dgarr's machine failed with 3.4.87 but worked with 3.4.55
[16:07:10] <seb_kuzminsky> did i understand wrong? or write it down wrong?
[16:08:13] * cradek is not as smart as seb
[16:08:25] <jepler> seb_kuzminsky: I'm not sure
[16:08:47] <jepler> seb_kuzminsky: I thought that dgarr was trying out uspace in master branch because his new computer still didn't work
[16:09:04] <jepler> dgarr: if you read this, let us know what the score is
[16:09:13] <seb_kuzminsky> i thought he was doing that because he's a badass early adopter developer
[16:09:44] <cradek> adopteveloper
[16:10:02] <jepler> develadopter
[16:10:05] <jepler> devdopter
[16:10:27] <cradek> velocidopter
[16:10:28] * seb_kuzminsky is a helicopter
[16:13:27] <jepler> an interesting item that was in ubc3 was a pair of rtapi calls to get the nominal time this thread invocation was supposed to start, and to get the actual time it started
[16:13:52] <jepler> thinking about adding that, but I'm not sure how to do it in rtai (I haven't peeked to see whether they have an implementation)
[16:15:04] <jepler> origin/jepler/rtos-master-v0-linux_rt:src/rtapi/rtapi.h: extern long long int rtapi_get_nominal_time(void);
[16:15:11] <jepler> hmm either this was my addition, or it went by the wayside
[16:15:25] <jepler> either way, there was no rtai implementation
[16:16:14] <jepler> oh, yeah, that was my own addition. heh.
[16:16:33] <seb_kuzminsky> would you use it to keep track of jitter during runtime?
[16:19:59] <jepler> It's probably a better way of tracking jitter than subtracting 'last time' from 'now'
[16:20:31] <jepler> for instance, if you ask for 1ms and get 1ms + 10us consistently, you'll think your max latency is really 10us
[16:20:40] <jepler> but .. it's unbounded, because each invocation becomes later-er
[16:24:26] <jepler> how confusing, RTAI uses the typedef RTIME for both timer tick counts and for nanoseconds
[16:27:40] <PCW> Yeah the lateness (relative to the minimum or perhaps average) is what I think of as latency
[16:27:42] <PCW> (so the mirror image histogram looks wrong to me)
[16:28:29] <jepler> yup
[16:32:16] <PCW> you should never have an early thread activation
[16:32:23] <jepler> yup again
[16:33:23] <jepler> though the mirror-image graphs do mean something
[16:33:48] <jepler> if you generate a square wave and plot its "time high" as a histogram, that's what you'd se
[16:33:51] <jepler> e
[16:33:52] <jepler> isn't it?
[16:34:55] <PCW> Yes
[16:36:15] <jepler> bbl
[16:55:59] <dgarr> seb_kuzminsky: i never got the amd machine ro run rtai3.4.55 so i have retired that machine. last tests:
http://www.panix.com/~dgarrett/stuff/09jul14_a.txt
[16:56:07] <dgarr> i got an hp machine on ebay that will run rtai3.4.55 but runs as well or better with rt-preempt
[16:56:32] <dgarr> the amd machine has run rtai 2.6.122 for years
[17:03:08] <seb_kuzminsky> dgarr: thanks for that report
[17:05:47] <seb_kuzminsky> oh yeah, that's right - it would hang strangely at certain times
[17:06:47] <memfrob> in short, how does the preempt_rt code in ubc3 differ from master?
[17:11:20] <memfrob> also that kernel doesnt look like 3.4.55.. 3.4-9-rtai-686-pae in kern.log
[17:12:06] <seb_kuzminsky> memfrob: that's how the debian kernel packaging infrastructure (that i'm using now) names packages
[17:12:38] <seb_kuzminsky> the "3.4" means it's a 3.4.x kernel, then the "-9" means it's version 9 of the abi for the 3.4 kernels
[17:12:48] <memfrob> oh..
[17:12:55] <memfrob> well thats confusing
[17:13:04] <seb_kuzminsky> (the abi changes when you got to a new 3.4.x version, or when you change config variables that monkey with internal apis)
[17:13:36] <seb_kuzminsky> then the "-rtai" specifies the featureset (think "out-of-tree feature patch")
[17:13:53] <seb_kuzminsky> then the "-686-pae" specifies the config (pretty much)
[17:14:15] <seb_kuzminsky> then you have to look at the version of the .deb, which in this case is "3.4.55-3linuxcnc", which might be the info you're looking for ;-)
[17:15:33] <memfrob> i guess `uname -r` output in dmesg wasn't cute enough for the debian devs
[17:41:31] <jepler> memfrob: the new "uspace" code for RT-PREEMPT kernels is a new implementation, but I made it while reading the "ubc3" code.
[17:42:14] <jepler> memfrob: I didn't really keep track of specific ways it differs, but for instance I had no interest in supporting additional userspace RTOSes like xenomai or lxrt (rtai)
[17:42:48] <jepler> memfrob: I also took the approach that (A) I didn't want to introduce ifdefs into components where I could avoid it and (B) I wanted all new identifiers to be prefixed by rtapi_
[17:48:14] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-v2 bf7c06b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: Introduce queue_{read,write} methods * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf7c06b
[17:48:15] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-v2 f415df4 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hostmot2: move watchdog I/O to the read function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f415df4
[17:48:15] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/hm2-eth-v2 d95d654 06linuxcnc 10(5 files in 3 dirs) hm2_eth: New driver for Mesa 7I80 ethernet cards * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d95d654
[17:48:55] <jepler> micges-dev, seb_kuzminsky, PCW: I've rebased the history of the hm2_eth driver, preserving the old branch in case you want to look at what I changed
[17:49:42] <jepler> .. I did change a few things: changed some error returns from -1 to -errno; deleted some unused code; reverted the no longer needed hm2_test changes
[17:50:01] <jepler> at each ref, 7i43 and 5i20 pass a basic "does it load" test, and at the tip, 7i80 works too
[17:50:08] <jepler> and the idrom tests also still pass at each step
[17:50:12] <seb_kuzminsky> sweet
[17:51:32] <jepler> I think I got just about the right split of functionality; the last commit is the biggest, but it's not very splittable: you either have a working driver or you don't.
[17:52:24] <jepler> oh and there's a lost change to uspace_rtapi_app.cc; I had mistakenly pushed that change to jepler/hm2-eth. so I just dropped it in the rebase.
[17:52:47] <jepler> before merging to master I'll rebase it onto the tip of master to avoid a conflict in src/Makefile
[17:55:15] <jepler> seb_kuzminsky: how much review do you want to do before this is pushed to master? those first two commits potentially affect all hm2 hardware.
[17:57:29] <micges-dev> jepler: great
[17:59:34] <PCW> Thats wonderful
[18:00:37] <jepler> PCW: after you sent me a card I had to take an active interest!
[18:01:01] <PCW> its a trick...
[18:01:11] <jepler> I know
[18:03:06] <PCW> dont you have a parallela card? now linuxcnc should run on it ( well +- )
[18:03:32] <jepler> I do own two
[18:03:46] <jepler> should get one back out
[18:04:01] <jepler> and then check if the fpga is big enough to hold hm2 :-P
[18:04:11] <PCW> its huge
[18:05:35] <PCW> and just think its got 16X 1GHz PRUs with FP
[18:06:19] <jepler> that's gotta be good for something
[18:06:46] <jepler> hm, three problems. I stole the power supply for the beaglebone that is my mp3 player; I stole the ethernet cable for my 7i80; and now the board itself has wandered off
[18:07:40] <jepler> but good news! I found a 20GB, 2.5", PATA hard disk and a Windows XP Pro install media + product key
[18:08:36] <PCW> Ethernet cables are like pens you need enough to saturate space
[18:09:31] <jepler> time to drink a homebrew then think about dinner
[18:09:40] <jepler> if you were here I'd share, promise.
[18:11:59] <PCW> You say that...
[18:31:40] <andypugh> I think that mah might have decided that iocontrolV2 was a dead end. Perhaps I could ask him.
[18:31:55] <andypugh> There is also a demo that does all of iocontrol in HAL.
[18:32:05] <andypugh> (which isn’t at all a bad idea)
[18:49:01] <seb_kuzminsky> andypugh: yeah, io's not that useful probably
[18:49:32] <seb_kuzminsky> jepler: i'll read through it tonight and get back to you
[18:49:37] <seb_kuzminsky> thanks for all that work, it's really great
[18:50:26] <andypugh> It hard-codes a lot of stuff that might be better configurable. If you could loadusr a suitable tool-handler for your application that things would be rather neater. And the other stuff in there is even more basic. The missing link is HAL components being able to field NML messages.
[18:51:24] <PCW> the same thing could probably be said for motion
[18:54:40] <seb_kuzminsky> i think we're talking about different things
[18:55:00] <seb_kuzminsky> i think the hal pins that io has are useful for connecting to hal components that move tools around in the real world
[18:55:13] <seb_kuzminsky> i dont think it's useful for io to be a separate thread from task
[18:55:48] <seb_kuzminsky> but i bet andypugh has thought about this much more deeply than i, so i'm ready to be convinced i'm wrong
[18:57:01] <andypugh> Are we talking about the things that iocontrol.cc does, or have I got the wrong end of the stick?
[18:58:59] <seb_kuzminsky> that's what i think we're talking about
[18:59:39] <seb_kuzminsky> io (iocontrol.cc) gets nml messages from task, and turns those nml messages into hal-pin state machine transitions
[19:00:12] <seb_kuzminsky> the hal-pin state transitions talk to a part of the machine that changes which tool is where (in the real world)
[19:00:38] <seb_kuzminsky> some hal pin state transitions cause io to send nml messages back to task
[19:01:03] <seb_kuzminsky> all that software is good and useful, but it'd be simpler (and not less useful) if it just lived inside task, i think
[19:01:34] <andypugh> I think it would be useful to consider allowing alternative code to handle the tool requests. Maybe a scheme like the kins modules.
[19:02:46] <andypugh> coolant-mist and coolant flood certainly could be handled by task. There really is no debate about what those G-codes do.
[19:02:47] <seb_kuzminsky> the part of the tool request that io does just manipulates linuxcnc data structures, all the interesting hardware-dependent parts are done on the other side of a well-defined "hal pin interface"
[19:03:08] <seb_kuzminsky> what functionality am i not thinking about?
[19:03:14] <seb_kuzminsky> (err, bus change, bbl)
[19:03:21] <seb_kuzminsky> i'll read back
[19:04:47] <andypugh> The data structure itself is a bit limiting. Motion needs certain information, and that is well-defined, but there are many other things that a tool table might want to hold, and many things that a tool-handler might want to do with the data.
[19:20:06] <jepler> whee, got the parallela booted again
[19:20:07] <jepler> Linux linaro-nano 3.12.0-g0bc9c3a-dirty #6 SMP PREEMPT Wed Jan 29 10:25:25 CET 2014 armv7l armv7l armv7l GNU/Linux
[19:20:19] <jepler> too bad they didn't see fit to provide a preempt-rt kernel, just a preempt kernel :-P
[19:21:57] <CaptHindsight> jepler: that one of the few ARM boards I didn't get, how well is it made and how is the layout?
[19:22:50] <jepler> CaptHindsight: this iteration of the board has a heat problem. the I/O connectors are inconvenient for hobbyists (high-density and on the bottom).
[19:23:05] <andypugh> Night all
[19:23:26] <jepler> CaptHindsight: in the current iteration they say they can cool the board entirely passively, but my board needs a fan
[19:23:45] <jepler> it has ethernet, which is nice, but besides that only two USB "B" connectors and the inconvenient high-density connectors
[19:24:36] <jepler> oh and it has ttl-level serial on standard headers
[19:24:53] <jepler> only micro sdhc, no e-mmc
[19:26:31] <jepler> bbl
[19:46:21] <jepler> obviously the gimmick of the 16 CPUs is unique
[19:50:21] <jepler> wow that's terrible
[19:50:25] <jepler> WARNING: The following packages cannot be authenticated!
[19:50:32] <jepler> [list of 101 packages that come from ubuntu.com]
[19:50:35] <jepler> Authentication warning overridden.
[19:50:47] <jepler> ^^^ default behavior of apt on this device with linaro (ubuntu) 14.04
[19:51:03] <Tom_itx> :)
[19:53:52] <jepler> I should obviously have splurged on a better SD card for this thing, apt-get takes its sweet time installing packages
[19:54:35] <Tom_itx> i got a SD the other day windows wouldn't handle
[19:54:43] <Tom_itx> my android liked it just fine
[19:54:45] <jepler> huh
[19:54:55] <Tom_itx> 64Gb
[19:55:15] <Tom_itx> but i'm still running xp
[19:55:22] <jepler> I don't need huge capacity, but faster write speeds would be nice
[19:55:38] <Tom_itx> it's a fairly quick card
[19:55:38] <jepler> I think it'd be faster if I could just network boot it and run root-on-nfs
[19:55:50] <jepler> I think this one claims "class 4"; I know it goes up to 10
[19:56:02] <jepler> but I don't know how useful that is in, vs just marketing bs
[19:57:00] <micges-dev> skunkworks: when you get a chance try latest jepler/hm2-eth branch, there was few important bugs fixed
[19:57:06] <PCW> one nice thing about the cubie is that is has a sata connector
[19:58:54] <jepler> this thing looked interesting, but you're stuck with e-mmc or micro sd for storage (or usb)
http://hardkernel.com/main/products/prdt_info.php
[19:59:15] <jepler> it has only a little I/O, and all at 1.8V, so it doesn't sound convenient to interface to anything (does have SPI, though)
[19:59:19] <Tom_itx> these were class 10 iirc
[19:59:44] <PCW> I haven't seen any odd behaviour with either ubc3-7i80 or uspace-hm2-eth
[20:01:45] <jepler> PCW: just for grins somebody should dig out a USB ethernet adapter and try using it with 7i80
[20:01:56] <micges-dev> I wonder why wd memory corruption error shows up while using hm2_pci and not while 7i80 testing
[20:02:19] <PCW> I have one on my test machine, just need to swap ports
[20:04:27] <skunkworks> micges-dev: will do
[20:04:51] <micges-dev> thanks
[20:05:15] <skunkworks> micges-dev: Should I test pci also on that branch?
[20:05:49] <micges-dev> yes
[20:06:01] <micges-dev> what pci cards do you have?
[20:07:06] <PCW> Ha! USB ethernet is working at 1 KHz (not sure for how long)
[20:07:14] <jepler> skunkworks: yes, pci and epp mesa cards (in addition to the ethernet cards) should work with branch origin/jepler/hm2-eth-v2
[20:07:30] <jepler> PCW: shiver me timbers, now linuxcnc works over usb
[20:07:48] <jepler> they asked us for it for years, and we said it wouldn^Wcouldn't be done
[20:08:53] <skunkworks> usb ethernet?
[20:10:25] <jepler> skunkworks: usb anything realtime
[20:10:31] <CaptHindsight> the ubc3-7i80 runs on the cubie2 with debian and preempt_RT, we have to try the new master
[20:11:09] <jepler> CaptHindsight: I'm interested to hear the result
[20:11:14] <CaptHindsight> hm2-eth for the cubie2 might be worth looking at
[20:11:25] <micges-dev> CaptHindsight: what version of preempt-rt kernel ?
[20:11:32] <jepler> origin/jepler/hm2-eth-v2 doesn't include the commits that "port" to arm, so you will want to try that merged with or rebased onto master
[20:11:56] <memfrob> 3.4.94
[20:11:57] <skunkworks> I was wondering what usb ethernet was.. Usb to ethernet adaptor?
[20:12:07] <PCW> yes
[20:12:53] <PCW> still running at 1 KHz (survived unplugging /replugging mouse)
[20:17:28] <skunkworks> so pcw would have to create some sort of board for the odroid..
[20:18:04] <skunkworks> I suppose the 7i80 would work.. (with a wireless usb nic..)
[20:19:11] <jepler> skunkworks: he has a product that talks SPI .. that plus a level-translator for the odroid's 1.8v I/Os would seem to be the easiest path
[20:19:19] <jepler> (except that you'd need a new hal driver for hm2_spi)
[20:19:23] <PCW> USB/Ethernet works at 2 KHz!
[20:19:31] <jepler> PCW: no f---ing way
[20:19:41] <PCW> way
[20:20:26] <PCW> wonder what the usb adapter does... may lookup the chip
[20:22:21] <PCW> hm2_spi should be similar to hm2_eth if the interface uses DMA
[20:22:53] <jepler> I only know that SPI is a bullet-point on that particular board
[20:24:21] <PCW> The cubie shoud do 50 mb/s SPI to/from our FPGA card (it can do 100 mb/s but i woudl need to do more work on the FPGA code to get that fast)
[20:26:09] <CaptHindsight> banana pi is supposed to be $30 with the R pi pinout and form factor but uses the A20 like the cubie2
[20:27:04] <CaptHindsight> so far people have been paying $50 to get the first ones
[20:28:00] <CaptHindsight> http://www.bananapi.org/p/product.html SPI is on the GPIO header
[20:28:30] <PCW> still ticking at 2 KHz
[20:28:48] <CaptHindsight> Gigabit Ethernet is on the Die
[20:29:53] <jepler> based on my experience with the arm chromebook, it's clear that arms are plenty powerful enough for everyday computing
[20:30:13] <jepler> but based on my experience with beaglebone, these corner-cutting boards are too slow for anything
[20:30:14] <CaptHindsight> https://www.kickstarter.com/projects/1575992013/logi-fpga-development-board-for-raspberry-pi-beagl might actually be useful soon
[20:30:24] <jepler> I don't know how to square the two, except to assume some form of "you get what you pay for"
[20:32:15] <PCW> 2 Khz still ticking along
[20:33:02] <jepler> I was going to tell how long linuxcnc took to build on the parallela vs the chromebook, except "make -j2" hit the OOM killer on the parallela
[20:33:02] <CaptHindsight> A20 + FPGA should be plenty fast enough for Linuxcnc
[20:33:09] <jepler> .. after 7.5 minutes
[20:34:04] <CaptHindsight> running LXDE with linuxcnc <70MB total memory is used
[20:34:51] <CaptHindsight> sorry ~90MB
[20:35:20] <jepler> some of the invocations of g++ while building linuxcnc seem to take over a half gig of memory
[20:35:29] <jepler> boost::python is a memory-hogging piece of crud at compile-time
[20:37:44] <jepler> chromebook built linuxcnc from clean in 5:34 real, 8:53 user + 47 system
[20:38:52] <CaptHindsight> jepler: ARM Chromebook?
[20:39:12] <jepler> CaptHindsight:
http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook
[20:39:18] <jepler> CPU: Samsung Exynos 5 Dual (5250) (Cortex A15; 1.7GHz dual core cpu)
[20:39:24] <jepler> 2GB RAM, etc
[20:39:25] <CaptHindsight> ok, yeah that one :)
[20:40:28] <jepler> It's a great travel machine, even more now that I can develop linuxcnc on it
[20:40:28] <CaptHindsight> Samsung is picky about who they sell those ARM parts to, so no lower cost boards
[20:40:53] <jepler> 6-thread Intel desktop: 2m1s real, 17:51 user + 0:44 system -- but that was building the docs too
[20:42:00] <jepler> wow, real 29s, user 4m38 + sys 16s when not building docs
[20:42:06] <mozmck> jepler: regarding the atomic problem on ARM, MH posted about it on the Xenomai list - did you see that and the response?
[20:42:19] <jepler> mozmck: no, I don't actively follow the xenomai list
[20:43:12] <mozmck> http://www.xenomai.org/pipermail/xenomai/2014-July/031210.html
[20:43:35] <mozmck> Don't know how helpful that is, but thought you might be interested.
[20:44:34] <jepler> It's interesting to see him link to the same stackoverflow I had mentioned on July 2.
[20:45:37] <mozmck> His email was a day after yours - so I think someone told him about it.
[20:46:04] <jepler> yeah
[20:46:42] <jepler> if someone comes up with a cool solution for machinkit, I hope they'll mention it to us
[20:49:44] <jepler> so bored waiting for parallela to build linuxcnc
[20:50:12] <PCW> you need parallel parallela's
[20:50:24] <jepler> so far at about 25 minutes CPU time / 20 minutes wall time
[20:50:48] <jepler> including the failed-partway-through build
[20:51:16] <jepler> anyway, if you spend your time building software, this parallela board does not seem like a good one.
[20:53:17] <jepler> lots of single files take 1 minute CPU time to compile, the interpreter in particular
[20:54:33] <PCW> probably woudl be faster with NFS
[20:54:57] <jepler> this is mostly sitting at 100% CPU
[20:55:15] <jepler> I think that the micro sd was a factor for installing packages, but not at the moment
[20:55:22] <PCW> dual core 666 MHz I think
[20:57:28] <PCW> bbl
[20:57:29] <PCW> USB-->Enet @ 2 KHZ _still_ running!
[20:57:30] <jepler> yeah, but too little ram to actually build in parallel
[21:11:51] <mozmck> AMD 8-core: real 0m55.608s user 5m33.707s sys 0m47.493s I think that is with docs - I just did make -j9
[21:12:46] <jepler> looks like this'll be north of 50 minutes CPU time
[21:12:59] <jepler> that's assuming it's almost done..
[21:13:17] <mozmck> I'm not sure how to read the "time" output - do you add the 3 together?
[21:13:25] <jepler> mozmck: the first is the wall time
[21:13:35] <mozmck> what is wall time?
[21:13:38] <jepler> mozmck: the second two added together are the CPU time, with the last one being the kernel CPU time
[21:13:48] <jepler> wall time is the time you'd measure on a clock
[21:13:56] <jepler> or a stopwatch
[21:14:03] <jepler> but it's wall time as in wall clock
[21:14:12] <mozmck> Oh, so the actual time the command took.
[21:14:28] <jepler> right
[21:14:40] <jepler> and user+sys are in CPU time
[21:14:40] <mozmck> so what does the CPU time even mean then?
[21:15:12] <jepler> that's amount of time it was actually executing on a CPU
[21:15:19] <jepler> with 8 CPUs it could be up to 8 CPU seconds per wall second
[21:15:48] <mozmck> I see - interesting. Looks like it's pretty fast anyhow.
[21:15:56] <jepler> but it is usually lower than that, for instance because make doesn't always run 8 things at once, because other programs use some of the CPU, and because sometimes a CPU is idle while waiting to read from disk, or whatever
[21:16:54] <jepler> in this case, your usre+sys CPU time is about 6.9x your wall time, so your average CPU usage was 690% out of a maximum 800%
[21:17:58] <mozmck> makes sense - does not sound too bad on the usage. I do have 20Gb ram but I'm running VBox with WinXP and several other programs as well.
[21:21:11] <mozmck> I wonder if it would be faster to set up a cross-compiler for that?
[21:21:18] <jepler> quite possibly
[21:25:57] <jepler> 56 minutes wall time to build linuxcnc on the parallela
[21:27:30] <jepler> .. and it doesn't work. hmm, what's up?
[21:27:38] <jepler> it appears the realtime threads did not start
[21:32:05] <jepler> well .. some debugging to do
[21:34:15] <skunkworks> PCW: what kind of read/write times are you getting with the usb?
[21:43:50] <pcw_home> 700 max (so about 280 usec) on read
[21:44:12] <pcw_home> not much worse than direct
[21:44:39] <pcw_home> I didn't check write times yet
[21:54:14] <skunkworks> neat
[21:55:07] <skunkworks> Btw - after doing everthing I could to rsync over ssh - I got a bit over 1GB/min
[22:03:45] <jepler> 133Mb/s ? could be worse, though it's true you might hope for better if it's GbE
[22:03:54] <jepler> ssh encryption is not free compared to the speed of gigabit nics
[22:05:41] <jepler> ugh, figured out my problem: apparently, if you set a scheduling priority via pthread_attr_setschedparam, every pthread call including pthread_attr_setschedparam and pthread_create return success, but the thread exits without ever calling its function
[22:19:41] <KGB-linuxcnc> 03Jeff Epler 05master 9007e24 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Raise RLIMIT_RTPRIO or fail at hardening * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9007e24
[22:19:41] <KGB-linuxcnc> 03Jeff Epler 05master 30000be 06linuxcnc 10debian/control.in 10scripts/latency-test latency-test: use awk for calculations * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=30000be
[22:22:16] <jepler> now linuxcnc master branch works on two ARM systems
[22:22:47] <jepler> . slowly running the testsuite
[22:29:15] <skunkworks> well - the sending side was an atom based supermicro motherboard.. Not the most powerful.
[22:29:24] <skunkworks> jepler: neat!
[22:33:19] <jepler> sigh, milltask taking 20% CPU on parallela
[22:39:08] <jepler> anyway, on parallela running linaro 14.01 (which I incorrectly called 14.04 earlier):
[22:39:11] <jepler> Runtest: 142 tests run, 142 successful, 0 failed + 0 expected
[22:40:31] <jepler> but it has about 300ms worth of latency with its "PREEMPT" (not "PREEMPT-RT") kernel
[22:41:23] <seb_kuzminsky> buildbot maintenance...
[22:41:30] <seb_kuzminsky> out of disk again