Back
[00:16:13] <linuxcnc-build_> build #1345 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1345 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:16:13] <linuxcnc-build_> build #1342 of lucid-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1342 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:16:15] <linuxcnc-build_> build #1345 of lucid-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1345 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:16:18] <linuxcnc-build_> build #1341 of lucid-rtai-i386-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1341 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:16:21] <linuxcnc-build_> build #1346 of hardy-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1346 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:16:23] <linuxcnc-build_> build #1344 of hardy-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1344 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:16:26] <linuxcnc-build_> build #1342 of hardy-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1342 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:10] <linuxcnc-build> build #426 of precise-amd64-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/426 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:13] <linuxcnc-build> build #452 of precise-x86-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/452 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:18] <linuxcnc-build> build #1141 of precise-amd64-sim-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1141 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:19] <linuxcnc-build> build #546 of precise-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/546 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:19] <linuxcnc-build> build #1345 of precise-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1345 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:19] <linuxcnc-build> build #426 of precise-amd64-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/426 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:19] <linuxcnc-build> build #442 of precise-x86-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/442 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:25] <linuxcnc-build> build #1343 of precise-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1343 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[00:56:25] <linuxcnc-build> build #1340 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1340 blamelist: Norbert Schechner <nieson@web.de>, Chris Morley <chrisinnanaimo@hotmail.com>
[02:24:46] <alex_joni> ~/away
[02:25:04] <alex_joni> bah :)
[06:14:10] <skunkworks> logger[mah],
[06:14:10] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-09-27.html
[10:03:07] <jepler> cradek: was git down, or was the earlier problem on the buildbot side? ^^
[10:03:55] <jepler> what the heck is configs/sim/gmoccapy/gmoccapy.glade.h for?
[10:03:57] <cradek> when I looked, it was a problem local to the buildbot that I didn't understand
[10:05:47] <jepler> oh I see that commit deleted it
[10:05:55] <jepler> so I guess I don't care what it was
[10:16:06] <skunkworks> is there a way to know what branch I am running?
[10:16:27] <skunkworks> (if branch is the right word)
[10:44:00] <skunkworks> seb_kuzminsky, !
[10:48:40] <seb_kuzminsky> hi! :-)
[10:51:46] <seb_kuzminsky> jepler, cradek : i was having horrible network problems last night, is that what you were talking about?
[10:52:05] <seb_kuzminsky> skunkworks: if you're in a checked-out git repo, run "git branch" to find out what branch you're on
[10:52:49] <cradek> seb_kuzminsky: nope - I was talking about
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1343/steps/git/logs/stdio
[10:52:57] <cradek> looks like your local git repo was/is corrupt?
[10:53:10] <seb_kuzminsky> ugh
[10:56:48] <seb_kuzminsky> cradek: i think the git repo looks ok, and buildbot's running of that 'git reset' looks wrong
[10:57:00] <seb_kuzminsky> here's the previous build to the one that failed, this one worked:
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1342/steps/git/logs/stdio
[10:57:31] <seb_kuzminsky> looks like it gets a change-notification from the repo, then tries to reset to the new version before fetching
[10:58:03] <seb_kuzminsky> that fails, then it fetches, then it tries to reset to that version again and it succeeds (because it just fetched it)
[10:58:16] <seb_kuzminsky> so i think the problem in build 1343 is that the 'git fetch' didn't work
[10:58:30] <cradek> oh > command timed out: 2400 seconds without output, attempting to kill
[10:58:32] <seb_kuzminsky> which i'm happy to attribute to my super flaky network last night
[10:58:32] <cradek> I didn't see that
[10:58:43] <cradek> so it was just a network problem
[10:58:47] <seb_kuzminsky> i think so
[10:58:47] <cradek> yay
[10:59:02] <seb_kuzminsky> now, why my network glitched i don't know....
[10:59:38] <seb_kuzminsky> if this guy comes down an order of magnitude in price, i may buy his robot arm:
https://boulder.craigslist.org/ele/4091686556.html
[11:00:22] <seb_kuzminsky> it's about the same size as the one i got from mozmck, but this one appears to have functional belts still
[11:01:49] <cradek> $600 !!!
[11:01:55] <cradek> that's silly
[11:02:14] <cradek> just build an arm that's how you want it
[11:02:17] <seb_kuzminsky> it's not out of line with ebay prices for that model, but yes, it's silly
[11:02:23] <seb_kuzminsky> heh yeah
[11:02:34] <seb_kuzminsky> really i want to play with software, not build a robot
[11:02:46] <seb_kuzminsky> bbl, coffee & coconut milk
[11:02:48] <cradek> well the simulator works...
[11:02:50] <cradek> yum
[11:03:49] <skunkworks> mhaberler, so - this is what I get. (and I am running the latest branch as far as I can tell)
http://pastebin.ca/2459192
[11:05:32] <mhaberler> I did test this only with pci/5i25
[11:06:15] <jepler> to me it still looks like the output is truncated
[11:06:32] <jepler> for encoder.00 it goes on to create two more parameters compared to what it does for encoder.01
[11:06:35] <jepler> according to the log
[11:06:57] <jepler> unless it's crashing out undiagnosed, but I assume at this point hal is still working
[11:10:57] <skunkworks> it actaully creates the pins and hal is running show works and displays correctly
[11:12:00] <mhaberler> you posted a message about rsyslogd throttling the rate yesterday
[11:12:27] <mhaberler> do you still have that? we might be fixing the wrong problem here
[11:13:13] <mhaberler> something about imux
[11:13:15] <skunkworks> http://pastebin.ca/2458848
[11:13:19] <skunkworks> last line
[11:13:37] <skunkworks> that was in the syslog... Which seems to be getting everything that linuxcnc.log is getting
[11:14:27] <mhaberler> well that is it, rsyslogd gets overwhelmed and rate limiting kicks in
[11:14:28] <jepler> is this a setting that has become more obnoxious on newer ubuntu? I've never encountered this.,
[11:14:34] <jepler> or is it because dmesg is not subject to the limit?
[11:15:27] <mhaberler> the latter could well be it, dmesg doesnt go through rsyslog
[11:15:43] <mhaberler> it think it just accesses the kernel message buffer
[11:16:08] <jepler> can you make the new stuff log without going through rsyslog? if the default configuration of rsyslog is going to truncate people's logs something will have to be done
[11:16:14] <jepler> even if it's prose nobody will read about how to modify configuration files
[11:16:53] <mhaberler> that's certainly an option, I'll see what can be done here
[11:17:44] <skunkworks> http://www.rsyslog.com/tag/rate-limiting/
[11:18:44] <skunkworks> let me see if I can change the rsyslog.conf
[11:19:16] <mhaberler> the default limit is 200msgs in 5 secs
[11:19:31] <mhaberler> this explains how:
http://www.rsyslog.com/tag/rate-limiting/
[11:20:40] <mhaberler> try this (/etc/rsyslog.conf):
[11:20:41] <mhaberler> $ModLoad imuxsock # provides support for local system logging
[11:20:42] <mhaberler> $SystemLogRateLimitInterval 2
[11:20:43] <mhaberler> $SystemLogRateLimitBurst 1000
[11:20:55] <mhaberler> then
[11:20:56] <mhaberler> service rsyslog restart
[11:21:13] <mhaberler> add the two $System… lines
[11:26:08] <mhaberler> actually the increased limits could be added to src/rtapi/rsyslogd-linuxcnc.conf , but I'm unsure how to properly install that file
[11:26:35] <jepler> no rsyslog.conf.d?
[11:27:03] <mhaberler> well yes, copying to /etc/rsyslog.d ; John didnt approve ;)
[11:27:28] <jepler> oh?
[11:27:34] <jepler> well for RIP builds we wouldn't go doing it
[11:28:07] <mhaberler> it's just a note in the UnifiedBuild.txt file: sudo cp src/rtapi/rsyslogd-linuxcnc.conf /etc/rsyslog.d
[11:28:21] <mhaberler> right, RIP was the issue
[11:28:48] <mhaberler> actually there's another case or two:
[11:29:54] <mhaberler> src/rtapi/shmdrv/limits.d-linuxcnc.conf
[11:30:04] <mhaberler> and a boot option needed on some kernels:
[11:30:34] <jepler> but backing up .. is it mandatory in ubc3 that logging goes through rsyslogd instead of coming out on a terminal?
[11:31:01] <jepler> I always liked about the old sim that the information I wanted was in the terminal; dmesg (or /var/log/kern.log) was a necessary evil
[11:31:23] <cradek> in rip I'd also prefer stdout
[11:31:26] <mhaberler> it goes to syslog; if you pass --stderr to rtapi_msgd it should write to stderr too which should hit the terminal where realtime was started
[11:31:43] <jepler> what do you change in order to cause --stderr to be passed to rtapi_msgd?
[11:31:49] <skunkworks> Yay!
http://pastebin.ca/2459203
[11:31:49] <jepler> I mean, you don't directly start rtapi_msgd do you?
[11:31:50] <mhaberler> that turns on LOG_PERROR
[11:32:11] <mhaberler> no, thats from scripts/realtime
[11:32:35] <jepler> DEBUG=5 MSGD_OPTS="--stderr" realtime start >logfile 2>&1
[11:32:39] <jepler> ok, found the docs now
[11:32:40] <mhaberler> right
[11:33:11] <mhaberler> it is actually used in the hm2-idrom test
[11:33:22] <jepler> that test passes now? nice.
[11:33:53] <jepler> (for some reason I thought it was a sticking point but I don't recall the detail now)
[11:33:56] <mhaberler> well it starts realtime 15 times and each run only inspects its run's logfile
[11:34:09] <mhaberler> guessing which run was doing what was the issue
[11:34:31] <mhaberler> the pattern matching was fragile
[11:34:37] <jepler> anyway, I guess I can export MSGD_OPTS=--stderr and have what I want so that's good
[11:34:57] <mhaberler> right, that was the intent - for debugging configs or so
[11:36:01] <mhaberler> ah, good, everything there now
[11:37:06] <mhaberler> yeah John didnt like fiddling /etc unasked in a RIP install; not sure how to deal with that and the other candidates
[11:37:55] <mhaberler> in the minimum sudo make setuid should say so, or ask permission
[11:38:13] <jepler> sudo some-new-targetname
[11:38:43] <mhaberler> ok, and make setuid could check if the parts needed are in place
[11:38:53] <mhaberler> if not, output a warning
[11:39:06] <mhaberler> or suggestion to run new-target
[11:40:27] <mhaberler> I observed the vmalloc= cmdline option being needed only with a single kernel (cant remember which one, maybe raspberry), but it might imply update-grub eventually, or editing /etc/default/grub
[11:41:16] <skunkworks> looks good with all debuging enabled..
http://pastebin.ca/2459204
[11:42:53] <mhaberler> well thats almost 900 lines of startup log in 1-2secs, 1000 might be a tad low
[11:43:17] <mhaberler> I am beginning to understand why rate limiting was implemented ;)
[11:44:17] <mhaberler> ok, will add the raised limits to the rsyslog.conf fragment and add a check & target to the make setuid phase
[11:44:18] <skunkworks> I set it to 4000 before I figured out that I wasn't actually restarting the service.
[11:44:23] <skunkworks> :)
[11:44:39] <mhaberler> ah, demons not watching their configs
[11:44:46] <jepler> add it next to the bit that checks if "make setuid" is needed?
[11:44:54] <mhaberler> right
[11:45:00] <jepler> that sounds good to me
[11:45:13] <mhaberler> it needs to check if the fragment is in place, and options too
[11:46:24] <skunkworks> micges, did you see that? the reason I wasn't getting pin info was the rsyslog was rate liminting.
[11:46:47] <micges> hi all
[11:46:57] <mhaberler> hi micges!
[11:47:06] <micges> (reading back)
[11:47:21] <jepler> bbl
[11:48:51] <micges> skunkworks: I see it
[11:49:30] <micges> mhaberler: will it be fixed/improved?
[11:49:42] <mhaberler> logging?
[11:49:46] <micges> yeah
[11:49:50] <mhaberler> working on that right now
[11:49:55] <micges> ok
[11:50:11] <mhaberler> read back for a fix, rsyslog.conf needs prodding
[11:50:51] <mhaberler> make $SystemLogRateLimitBurst 5000 or so so you're sure it wont bite (rsyslogd does say so though)
[11:52:11] <cradek> have you made sure rsyslog is not fsyncing after each of those lines?
[11:54:34] <pcw_home> skunkworks: whats logged when debugging is turned off?
[11:56:20] <pcw_home> I think pre-UB3 listed the pinout regardless of debug settings, which I think is the right thing
[11:56:37] <mhaberler> it does now again
[11:56:53] <mhaberler> there was a bug in the log mask setting which I fixed yesterday
[11:58:49] <pcw_home> Thats good, its often used as a pinout reference
[12:04:46] <mhaberler> fsyncing is optional with rsyslog (I think its $MainMsgQueueSyncQueueFiles on)
[12:10:55] <cradek> ideally linuxcnc messages would go to their own file and that would not be fsynced for every line
[12:12:12] <jepler> I dunno, people who are busy writing system-crashing hal drivers might like the fsyncs
[12:12:24] <cradek> hm maybe
[12:14:15] <andypugh> I think only one person regularly writes system-crashing HAL drivers. Other devs are more competent :-)
[12:15:03] <micges> andypugh: you talking about me? ;)
[12:15:40] <andypugh> Of course not.
[12:17:55] <andypugh> I guess it is possible that everyone else regularly writes segfaults, I guess you only see your own.
[12:19:10] <jepler> unless you tell the world
[12:19:36] <skunkworks> pcw_home,
http://pastebin.ca/2459203 that is no debug in the hostmot line
[12:20:10] <pcw_home> I thought segfaults were the user error reporting scheme for unix programs
[12:21:30] <andypugh> Which reminds me, I have a segfault in the DPLL timer to track down :-)
[12:21:50] <andypugh> pcw_home: What HAL pins would you like to see from hm2dpll?
[12:22:08] <andypugh> So far I only have "phase"
[12:23:36] <pcw_home> theres the frequency setting pin, the LP filter timeconstant pin, the 4 timer phases
[12:24:22] <andypugh> What does the frequency setting pin do? Also, what are the hardware pins for?
[12:24:54] <pcw_home> the DPLL has a base frequency tha must be set to match the servo thread rate
[12:25:14] <pcw_home> (it has a small lock-in range) say 2% max
[12:25:25] <andypugh> Well, in theory it can simply be told that by HAL...
[12:25:48] <andypugh> Not HAL. By the driver, I mean.
[12:26:14] <pcw_home> probably better that its separate for now
[12:26:28] <andypugh> OK, I will do it that way for now.
[12:27:52] <pcw_home> There is some rather high magic about the DDS prescale, The trick is that for different servo thread rates and clock low rates
[12:27:54] <pcw_home> we want the DDS setting value to be about the same as the loop gain depends on the size of the DDS setting value
[12:31:08] <pcw_home> so the prescale is inversly proportional to Servo thread rate and proportional to clocklow
[12:31:10] <pcw_home> (this isbecause I didnt want to use a multiplier or barrel shifter (too big for 5I20s) to change the loop gain)
[12:33:25] <pcw_home> the I/O pins are basically for debugging, _but_ the refout and syncin pins can be used
[12:33:26] <pcw_home> to synchronize a slave FPGA config to a master (master refout --> slave syncin)
[12:34:56] <pcw_home> the phase pin could be scaled in usec of error
[12:42:16] <andypugh> I would imagine that most folk would be more interested in keeping the hardware pins for IO.
[12:44:37] <pcw_home> Yes normally there will be no hardware pins
[12:48:00] <pcw_home> if I arbitarily set prescale to 1 at the lowest clocklow (33 MHz) and the higest expected servo thread (say 10 KHz)
[12:48:02] <pcw_home> then the max prescale would be with a 100 mhz clocklow and 1 KHz servo thread (so prescale abou 32)
[12:49:06] <andypugh> I am rather assuming that I can push the driver then leave the tuning and testing to you, as I don't have any BiSS or Fanuc.
[12:49:39] <andypugh> How important do you think it is to fix the current 96-bit limit on BiSS?
[12:49:47] <andypugh> (INherited from smartserial)
[12:50:23] <pcw_home> Yeah it still will need futzing about with since i dont have much of an idea of jitter statistics and rate accuracy of the servo thread
[12:52:12] <pcw_home> I think 96 should be fine for now (the 512 hardware maxlength is just a side effect of using SRL16s if I made it 96 max it would have the same hardware resource usage)
[12:52:45] <andypugh> There is currently a friendly error message suggesting a feature request if it bothers anyone.
[12:53:31] <andypugh> I would need to make the current 3 registers in Smart Serial into a variable size array of registers.
[12:54:52] <pcw_home> It probably overkill I doubt than many encoder use even 96
[12:54:54] <pcw_home> note that the DPLL is useful for more than SSI,BISS.SPI etc
[12:54:55] <pcw_home> I intend to add the ability so sample inputs (encoder stepgen counts etc)
[12:54:57] <pcw_home> at offsets from the DPLL
[12:55:07] <pcw_home> ability to
[12:55:41] <pcw_home> so it can be used as a general jitter reduction scheme
[12:55:42] <andypugh> I have assumed that possibility.
[13:00:55] <pcw_home> If the DPLL driver only:
[13:00:57] <pcw_home> read the sync register in an available hal pin (scaled in usec of error might be nice)
[13:00:58] <pcw_home> and allowed setting the other registers directly
[13:01:00] <pcw_home> I could play around with it to learn more of its behaviour in a linuxcnc environment
[13:01:02] <pcw_home> (currently I'm using a 7I80 and a windows program at 64 Hz...)
[13:03:36] <andypugh> OK, I will do that.
[13:04:02] <pcw_home> i guess the Plimit needs to be set and reading the output of the LPF would be valuable as well (scaled in delta Hz from center maybe)
[13:05:06] <pcw_home> (LPF output is called filtered phase error in the regmap)
[13:07:56] <pcw_home> The original HM2 DPLL was made for some college project several years ago
[13:07:58] <pcw_home> (they needed a 10KHz? or so signal for a Sick scanner phase locked to a GPS 1 PPS tic)
[13:12:25] <skunkworks> pcw_home, with no debug level - it also prints the pin data (and very little else)
[13:12:44] <skunkworks> *logs the data to linuxcnc.log
[13:13:05] <pcw_home> The DPLL can also be used as just a free running timer (and generate interrupts if desired)
[13:13:07] <pcw_home> not sure how invasive supporting alternate interrupts for thread invocation is so DPLL mode
[13:13:08] <pcw_home> seemed preferable as it does not change the "linuxcnc is on charge of timing" paradigm
[13:14:49] <pcw_home> It does look like it puts a lot more in the log (all this "creating pin" stuff)
[13:15:22] <andypugh> skunkworks: You do seem to have logging turned up to "excessive"
[13:15:41] <skunkworks> well - I was trying to find the pin info... :)
[13:15:47] <andypugh> You wouldn't normally expect to need any params on the loadrt hostmot2 line
[13:16:10] <skunkworks> right
[13:17:33] <skunkworks> when the pin info wasn't showing up I increased the debug level and added the debug params to the hostmot2 line
[13:17:46] <skunkworks> (which didn't help)
[13:19:26] <pcw_home> skunkworks: is this running 12.04?
[13:20:03] <skunkworks> I think it ended up being 2 issues - an issue on mhaberler logging and dropped messages
[13:20:15] <skunkworks> pcw_home, yes
[13:20:28] <skunkworks> running ubc3 with the 7i80 stuff
[13:20:38] <pcw_home> can you try readhmid?
[13:20:54] <pcw_home> (it needs normal networking turned on_
[13:21:00] <skunkworks> how does that worik? I downloaded it and made it executable...
[13:21:03] <mhaberler> actually it was two - setlogmask() bug and rate limiting of rsyslogd; I found no trace of dropped log messages
[13:21:34] <pcw_home> It should have a better formatted pin list
[13:22:03] <pcw_home> ./readhmid but it needs some envoronment variables
[13:22:16] <pcw_home> environment
[13:22:58] <skunkworks> what do you mean by normal networking?
[13:23:20] <pcw_home> no rtnet, standard linux stack
[13:23:31] <skunkworks> ok
[13:23:43] <skunkworks> does it tell me what I have to set?
[13:24:04] <pcw_home> It should complain
[13:24:30] <skunkworks> ok
[13:24:42] <skunkworks> rebooting to use the normal e100 driver
[13:24:53] <pcw_home> but I have not tried it anywhere but on my test machine
[13:25:30] <pcw_home> (I was surprised it worked at all since it was written for windows)
[13:30:08] <skunkworks> I get no such file or directory if I do ./readhmid
[13:30:37] <mhaberler> ok, logging should be fixed in
https://github.com/mhaberler/linuxcnc/commits/ubc3-7i80-rtnet and
https://github.com/mhaberler/linuxcnc/commits/unified-build-candidate-3
[13:30:45] <pcw_home> umm is readhmid in that directory?
[13:30:56] <mhaberler> nb: ubc3-7i80-rtnet was rebased
[13:31:13] <skunkworks> no - it is on the desktop. (my linuxfoo isn't very strong)
[13:35:53] <skunkworks> when I do a sudo ./readhmid
[13:35:59] <skunkworks> I get nothing returned
[13:36:13] <skunkworks> no errors or output at all
[13:36:32] <skunkworks> (when I am in the readhmid directory with readhmid in it.
[13:38:16] <pcw_home> Hmm thats odd, thanks for trying (sudo is not needed)
[13:39:33] <pcw_home> I'll verify that thet copy is the same one i have here (though I ran it on stack Ubuntu 12.04 not Xenomai)
[13:40:54] <skunkworks> I certainly could be doind something wrong
[13:42:03] <pcw_home> run in a terminal?
[13:42:05] <pcw_home> did it segv? Not sure how it can just exit
[13:42:27] <skunkworks> run in terminal
[13:43:02] <skunkworks> when I do it without sudo - I get a cannot find file or directory - with sudo - it just returns to command prompt
[13:43:43] <skunkworks> sorry - it says .readhmid not found when running non sudo
[13:44:30] <pcw_home> ./?skunkworks
[13:44:39] <pcw_home> ./?
[13:45:28] <pcw_home> chmod +x readhmid
[13:45:28] <pcw_home> ./readhmid
[13:49:23] <skunkworks> pcw_home,
http://pastebin.ca/2459227
[13:50:16] <pcw_home> ls -l ?
[13:52:45] <skunkworks> http://pastebin.ca/2459228
[13:53:24] <pcw_home> file readhmid ?
[13:53:34] <skunkworks> yes?
[13:54:20] <skunkworks> that is the readhmid file in the readhmid directory
[13:55:15] <pcw_home> OK well must be some library differnces with xenomai
[13:55:30] <micges> skunkworks: try: sh readhmid
[13:56:35] <andypugh> And don't let anyone ever tell yout Linux isn't intuitive...
[13:56:40] <skunkworks> http://pastebin.ca/2459229
[13:56:49] <skunkworks> :)
[13:58:03] <micges> skunkworks: what do you want to do?
[13:58:30] <skunkworks> I want it to do whatever pcw_home wants it to do. :)
[13:58:57] <skunkworks> I think it is supposed to show the mesa pinouts
[13:59:13] <micges> do you have mesaflash ?
[13:59:17] <pcw_home> It shoud make a nicely formatted pinout list but I suspect there are shared libs that dont match
[13:59:43] <pcw_home> (something different about xenomai)
[13:59:57] <micges> ok, mesaflash can do that
[14:00:49] <micges> ./mesaflash --device 7i80 --verbose --hm2
[14:00:58] <skunkworks> I will give it a try - but IIRC mesaflash didn't work on 12.04
[14:01:08] <skunkworks> give me a few
[14:05:00] <andypugh> pcw_home: That pin list looked pretty normal to me
[14:05:10] <andypugh> Just buried in the other junk
[14:05:57] <andypugh> This is what mine always look like:
http://pastebin.ca/2459231
[14:17:48] <pcw_home> Yeah It was just that all the other debugging info was there
[14:25:53] <skunkworks> god I must be doing something stupid. I cannot do the ./mesaflash either - file not found
[14:26:19] <skunkworks> is it because it is in my desktop?
[14:26:38] <micges> is it 32 bit system?
[14:28:32] <skunkworks> 64
[14:29:17] <micges> can you use 32 bit?
[14:33:06] <pcw_home> Not much fun with the 7I80 unless you can use mesaflash to change the firmware
[14:33:46] <andypugh> When I get that sort of problem it is generally that I am ssh-ed into a different machine than the one I think I am :-)
[14:34:58] <pcw_home> btw micges, can you add space4 to the mesaflash memory space list?
[14:35:46] <skunkworks> well - I have other systems I can use - I have gotten mesaflash to work on 10.04 a long time ago
[14:39:34] <micges> pcw_home: sure, what it's name?
[14:40:02] <pcw_home> you are supposed to read the name :-)
[14:40:07] <skunkworks> but doesn't 'file not found' seem like something I am doing wrong?
[14:41:26] <pcw_home> cant imagine what, unless there's some shell protection from running executables in certain places
[14:42:22] <pcw_home> but this does seem like Ive seen this before (also on ubuntu 12.04)
[14:42:43] <pcw_home> bbl
[14:43:17] <cradek> is that a script
[14:43:18] <cradek> ?
[14:44:04] <cradek> if it's a script, maybe the interpreter is missing. if it's a binary, run ldd on it and see if it has the libraries it needs
[14:44:08] <micges> mesaflash is binary
[14:45:22] <cradek> ldd mesaflash
[14:46:59] <skunkworks> 'not a dynamic exicutable...'
[14:47:12] <cradek> file mesaflash
[14:48:28] <skunkworks> http://pastebin.ca/2459239
[14:48:59] <cradek> bbbbut that says it's dynamic
[14:48:59] <skunkworks> it runs just fine on my 10.04 virtual machine :)
[14:49:08] <cradek> uname -a
[14:49:55] <skunkworks> http://pastebin.ca/2459240
[14:50:25] <cradek> your x86_64 system may not be able to run i386 binaries
[14:50:41] <skunkworks> must be
[14:50:44] <cradek> strace -eopen ./mesaflash
[14:52:08] <skunkworks> http://pastebin.ca/2459241
[14:52:52] <cradek> huh
[14:53:15] <skunkworks> huh is right :)
[14:53:35] <micges> pcw_home: reading area 4 is give me parse error on 7i80
[14:53:51] <cradek> you should probably just get the source of mesaflash and build it for your system
[14:54:04] <skunkworks> I have the source...
[14:54:13] <cradek> you might be able to install a bunch of stuff to run incorrect binaries -- but why bother
[14:54:19] <cradek> ah, then build it
[14:57:19] <skunkworks> this doesn't look easy
[14:58:14] <skunkworks> http://pastebin.ca/2459243
[14:58:35] <skunkworks> there is a bat file in there - why oh why would there be a bat file?
[14:59:25] <cradek> uh, good question
[15:00:46] <skunkworks> micges, any insite on how to build that?
[15:02:53] <micges> skunkworks: give me email, I'll send you latest sources
[15:03:05] <skunkworks> samcoinc at gmail.com
[15:05:17] <micges> sended
[15:05:20] <micges> back in 10 min
[15:42:54] <micges> skunkworks: I've tried to send you many time to gmail
[15:43:28] <micges> skunkworks: I've sended on s.. at empire...
[15:43:30] <skunkworks> I got it on my other email - thank you
[15:43:37] <micges> ok
[15:43:44] <skunkworks> I will play with it
[16:20:06] <andypugh> pcw_home: The regmap for hm2dpll isn't that clear on what is read and what is write. Is ddssize a property of the dpll and read only?
[16:25:41] <skunkworks> micges: how do I go about trying to build that?
[16:26:04] <micges> go there in terminal
[16:26:07] <micges> make clean
[16:26:09] <skunkworks> sure
[16:26:10] <micges> make
[16:28:26] <skunkworks> http://pastebin.ca/2459271
[16:29:35] <cradek> libpci-dev
[16:31:28] <skunkworks> ok - got further
[16:33:07] <skunkworks> http://pastebin.ca/2459273
[16:34:52] <micges> chage line 9 in Makefile to:
[16:35:05] <micges> LIBS = lpci
[16:36:14] <skunkworks> lpci: no such file or directory
[16:37:24] <micges> hmm.. cradek help?
[16:38:27] <adb> lspci
[16:38:27] <seb_kuzminsky> should maybe be either "-lpci" or just "pci", depending on how it's used
[16:39:22] <skunkworks> hmm - I don't think I got any errors with -lpci
[16:39:37] <seb_kuzminsky> well good!
[16:39:47] <micges> thanks seb
[16:39:58] <micges> it will go to sources
[16:40:10] <micges> skunkworks: so try ./mesaflash
[16:41:05] <skunkworks> well that looks good
[16:41:07] <skunkworks> http://pastebin.ca/2459275
[16:41:17] <skunkworks> I don't have the hardware though to actually test it :)
[16:41:30] <micges> yes it is
[16:41:49] <skunkworks> yay
[16:42:43] <skunkworks> so it may work on 64bit
[19:08:01] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll 1b25235 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10(7 files)
[19:08:01] <KGB-linuxcnc> Further tidying up and introduction of the HM2DPLL module to allow pre-triggering
[19:48:06] <linuxcnc-build_> build #1346 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1346 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:48:06] <linuxcnc-build_> build #1343 of lucid-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1343 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:48:07] <linuxcnc-build_> build #1346 of lucid-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1346 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:48:08] <linuxcnc-build_> build #1342 of lucid-rtai-i386-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1342 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:48:09] <linuxcnc-build_> build #1347 of hardy-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1347 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:48:10] <linuxcnc-build_> build #1345 of hardy-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1345 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:48:10] <linuxcnc-build_> build #1343 of hardy-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1343 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:51:28] <andypugh> Oh, what have I done now?
[19:51:57] <andypugh> seb_kuzminsky: Oh bother.
[19:52:29] <andypugh> I rather thought that creating a new branch would avoid upsetting the buildbot
[19:56:16] <andypugh> OK, so, is the solution to delete that new branch?
[19:56:22] <andypugh> And if so, how?
[19:57:02] <micges> andypugh:
http://gitready.com/beginner/2009/02/02/push-and-delete-branches.html
[19:58:11] <jepler> if you want to share your work with others, it is fine to push to git.l.o. but yes, the buildbot will try to build the branch..
[20:04:31] <andypugh> the odd thng is, that it builds for me, I can't tell what the builbot is choking on (no logs)
[20:06:31] <jepler> [failed git]
[20:06:40] <jepler> this happened overnight, but I thought seb looked into it and fixed it
[20:06:52] <jepler> command timed out: 2400 seconds without output, killing pid 16928
[20:07:00] <jepler> he said something was flaky in his network, maybe it's not fixed
[20:07:27] <andypugh> Ah, so I might be blameless?
[20:08:43] <jepler> in this case I believe so
[20:08:54] <jepler> seb_kuzminsky: the git timeout problem is not yet fixed :-/
[20:10:50] <seb_kuzminsky> the network here has been all wonky
[20:11:19] <seb_kuzminsky> possibly one of the fires that makes the smoke signals that my isp uses for its back-haul got swamped by the flooding
[20:13:07] <seb_kuzminsky> linuxcnc-build: force build --branch=ssi-fanuc-biss-dpll checkin
[20:13:13] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[20:28:06] <linuxcnc-build> build #427 of precise-amd64-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/427 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:06] <linuxcnc-build> build #1346 of precise-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1346 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:06] <linuxcnc-build> build #1142 of precise-amd64-sim-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1142 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:06] <linuxcnc-build> build #453 of precise-x86-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/453 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:07] <linuxcnc-build> build #427 of precise-amd64-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/427 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:08] <linuxcnc-build> build #547 of precise-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/547 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:08] <linuxcnc-build> build #443 of precise-x86-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/443 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:09] <linuxcnc-build> build #1341 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1341 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:28:09] <linuxcnc-build> build forced [ETA 1h20m35s]
[20:28:10] <linuxcnc-build> I'll give a shout when the build finishes
[20:42:45] <andypugh> Oh I so don't "get" git
[20:50:24] <KGB-linuxcnc> 03TODO: deletor 05ssi-fanuc-biss-dpll 1b25235 06linuxcnc 04. * branch deleted
[20:51:18] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll cd0d793 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10(7 files)
[20:51:18] <KGB-linuxcnc> Further tidying up and introduction of the HM2DPLL module to allow pre-triggering
[20:59:43] <jepler> seb_kuzm1nsky: thanks for keeping us posted
[21:00:01] <jepler> I hope your world gets put back together right way up sometime soon
[21:08:11] <linuxcnc-build_> build #1347 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1347
[21:08:12] <linuxcnc-build_> build #1344 of lucid-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1344
[21:08:13] <linuxcnc-build_> build #1347 of lucid-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1347
[21:08:13] <linuxcnc-build_> build #1348 of hardy-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1348
[21:08:13] <linuxcnc-build_> build #1343 of lucid-rtai-i386-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1343
[21:08:13] <linuxcnc-build_> build #1346 of hardy-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1346
[21:08:13] <linuxcnc-build_> build #1344 of hardy-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1344
[21:48:10] <linuxcnc-build> build #428 of precise-amd64-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/428
[21:48:10] <linuxcnc-build> build #1347 of precise-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1347
[21:48:11] <linuxcnc-build> build #1143 of precise-amd64-sim-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1143
[21:48:11] <linuxcnc-build> build #454 of precise-x86-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/454
[21:48:12] <linuxcnc-build> build #428 of precise-amd64-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/428
[21:48:12] <linuxcnc-build> build #548 of precise-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/548
[21:48:13] <linuxcnc-build> build #444 of precise-x86-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/444
[21:48:14] <linuxcnc-build> build #1342 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1342
[21:54:49] <cradek> seb_kuzm1nsky: we could stretch a really long string to my house...?
[23:08:15] <linuxcnc-build> build #429 of precise-amd64-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/429 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:15] <linuxcnc-build> build #1348 of precise-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1348 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:16] <linuxcnc-build> build #1144 of precise-amd64-sim-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1144 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:17] <linuxcnc-build> build #455 of precise-x86-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/455 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:17] <linuxcnc-build> build #429 of precise-amd64-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/429 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:17] <linuxcnc-build> build #549 of precise-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/549 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:18] <linuxcnc-build> build #445 of precise-x86-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/445 blamelist: Andy Pugh <andy@bodgesoc.org>
[23:08:18] <linuxcnc-build> build #1343 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1343 blamelist: Andy Pugh <andy@bodgesoc.org>