Back
[03:16:04] <KGB-linuxcnc> 03Chris Morley 05new_pncconf 8891b48 06linuxcnc 718 commits pushed, 10702 files changed, 03247849(+), 0419575(-)
[06:57:22] <jepler> kgb really doesn't know what to make of rebases, does it...
[06:58:44] <jepler> also, cool: cmorley knows how to rebase. I hope he knows how / learns how to squash his commits too. it needs a slogan, like "nix the wips"
[07:09:31] <skunkworks> cradek, never mind about the iso on wlo.. It must have been a bad burn or bad usb drive.. I burned it again on a different media and it mounted during install. (also latency seems much better)
[07:19:12] <skunkworks> (the machine that normally has around 10us latency was pushing 50us...)
[08:59:51] <jepler> hm, why do I bother building linuxcnc under clang scan-build if I'm just going to disbelieve most of the diagnostics?
[09:01:47] <jepler> http://emergent.unpythonic.net/files/sandbox/report-705972.html#EndPath
[09:02:42] <jepler> clang seems to think that "te_ptr" in iteration 2 is the same memory as "te" in iteration 1, but it seems to me they must be different if it's a proper linked list
[09:03:47] <jepler> http://emergent.unpythonic.net/files/sandbox/report-c92440.html#EndPath
[09:04:18] <jepler> though this one looks like it's right -- the error message was probably intended to have pin->port_num as its argument.
[09:05:28] <cradek> yep
[09:06:22] <jepler> I was interested in running scan-build on the uspace branch mostly because I wasn't sure if for kernel-based RTOSes, the existing scan-build could check kernel modules
[09:06:58] <cradek> are there few enough diagnostics that you can at least glance at them all?
[09:07:24] <jepler> 167, so not really
[09:08:08] <skunkworks> cradek, installed - it still seems to have worse latency. (>50us vs <15) I am having dad put the old hd back in and re-test latency with 10.04
[09:08:59] <jepler> ooh here are some more accurate ones
[09:09:00] <jepler> static GLfloat *feedback_buffer = NULL;
[09:09:05] <jepler> feedback_buffer = realloc( feedback_buffer, sizeof(int) * sz);
[09:09:12] <jepler> scan-build says: Result of 'malloc' is converted to a pointer of type 'GLfloat', which is incompatible with sizeof operand type 'int'
[09:16:01] <jepler> wow, a reminder that xz is much better than gz:
[09:16:03] <jepler> 5.9M linuxcnc-uspace-scan-build-diagnostics.tar.gz
[09:16:06] <jepler> 912K linuxcnc-uspace-scan-build-diagnostics.tar.xz
[09:16:12] <jepler> (both using default compression level)
[09:16:29] <jepler> anyway, if anyone cares to look at the scan-build diagnostics:
http://emergent.unpythonic.net/files/sandbox/linuxcnc-uspace-scan-build-diagnostics.tar.xz
[09:16:48] <jepler> I know buildbot runs scan-build, but I couldn't figure out where it puts its diagnostics
[09:44:58] <cradek> jepler: I think that loop doesn't free the first (last remaining) te
[09:45:38] <cradek> it only ever frees next's payload
[09:47:34] <cradek> in step 4 do you know which memory it is saying it thinks is used after free?
[09:48:05] <jepler> cradek: I *think* the first item in a list has no payload.
[09:49:09] <jepler> http://www.makelinux.net/ldd3/chp-11-sect-5
[09:50:08] <jepler> cradek: I assume the memory purportedly used in step 4 at line 184 is the line freed in step 2 at line 185 (previous loop iteration)
[09:50:31] <jepler> of course, it's entirely possible that my implementation of the list ops for userspace is wrong
[09:52:19] <jepler> I should figure out whether I can valgrind rtapi_app when it's running as root
[09:56:18] <skunkworks> jepler, the 7i80 is still running with no issues
[09:58:16] <jepler> skunkworks: cool, though you have a ways to go until you match pcw's 31 billion packet record he reported last week..
[09:58:49] <skunkworks> right.. although I bet pcw has a machine setup right now that will beat the record.. ;)
[10:01:26] <skunkworks> I don't know if I could leave it alone long enough..
[10:14:25] <jepler> to avoid the false warning at line 184, clang would have to know that x->next->prev == x
[10:14:44] <jepler> not knowing that, it can't infer that rtapi_list_del(te_ptr) changes hm2->tram_read_entries.next
[10:14:54] <jepler> your favorite static analyzer sucks
[10:22:31] <seb_kuzminsky> jepler: i hid the link to clang on the buildbot dev page:
http://buildbot.linuxcnc.org/dev.html
[10:22:42] <seb_kuzminsky> which points to
http://buildbot.linuxcnc.org/clang/
[10:22:58] <seb_kuzminsky> then in the scratch section are links to the clang results from all non-release branches
[10:33:54] <cradek> my responses to these are "that's so complicated I don't get what it's even saying, but it seems to run, so whatever" or "that sure is wrong, wonder what the author really intended, oh well it seems to run."
[10:36:20] <seb_kuzminsky> at some point i should re-figure-out how to run linuxcnc through Coverity Scan again
[10:37:37] <seb_kuzminsky> last time i did it, years(?) ago, it found lot of things that clang missed (and that never bite our users)
[10:39:08] <cradek> decade = 1;
[10:39:08] <cradek> sub_decade = 1;
[10:39:08] <cradek> actual_usec_per_div = decade * sub_decade;
[10:39:12] <cradek> uhh
[10:39:29] <cradek> oh well it seems to run
[10:45:56] <skunkworks> I wonder if there is something not quite right with the motherboard dad is using.. (here the computers seem to have similar latencys to 10.04..)
[10:46:04] <skunkworks> maybe a bios setting
[10:55:50] <jepler> seb_kuzminsky: thanks
[10:56:06] <cradek> haha,
http://buildbot.linuxcnc.org/clang/2.6-sim/v2.6.0-pre4/report-xJ2zBI.html#EndPath
[10:56:26] <jepler> looks like clang 3.5 finds ~30 more diagnostics (138 in precise-amd64-clang with unspecified clang version, 167 in mine with clang 3.5 on debian 7)
[11:02:28] <seb_kuzminsky> jepler: yeah, it keeps getting better(?) and better(?)
[11:02:31] <cradek> this is the kind where "fixing" the diagnostic would make the code worse:
http://buildbot.linuxcnc.org/clang/2.6-sim/v2.6.0-pre4/report-WnEJES.html#EndPath
[11:02:54] <seb_kuzminsky> now that we have an rtai kernel on precise and wheezy i should move the clang-rtai build to one of those buildslaves
[11:03:08] <jepler> cradek: yes indeed
[11:04:32] <seb_kuzminsky> that's an unusual idiom
[11:07:46] <jepler> well, looking at these *is* enough to irritate me about the general code quality of linuxcnc, so mission accomplished I guess
[11:10:05] <seb_kuzminsky> if we git rm emclcd and halrmt that removes like 75% of our clang warnings
[11:10:41] <cradek> and classicladder and nml will take care of the rest
[11:10:49] <seb_kuzminsky> heh
[11:11:03] <cradek> then I'll fix these three I recently wrote:
http://buildbot.linuxcnc.org/clang/2.6-sim/v2.6.0-pre4/report-qvCVR2.html#EndPath
[11:12:38] <jepler> just a heads up: I'll be busy with guests from about 9-12, and then out of town until about the 21st
[11:13:37] <jepler> so I will be unlikely to act on any further code reviews before then
[11:14:27] <jepler> or we could just go ahead and merge it <3/8 wink>
[11:15:41] <cradek> wfm
[11:17:10] <CaptHindsight> the 3.4.55 RTAI kernel and the wheezy-sim work so far on Mint-Debian-Mate, did anyone ever package linuxcnc with RTAI for wheezy?
[11:17:29] <cradek> not for that kernel
[11:17:55] <CaptHindsight> ah, then which kernel and where are the packages?
[11:19:05] <cradek> www.linuxcnc.org wheezy 2.6
[11:19:24] <cradek> the kernel's in base
[11:21:13] <seb_kuzminsky> the precise rtai debs are for 3.4.55, they'll probably work on the same kernel in wheezy
[11:21:25] <seb_kuzminsky> deb
http://linuxcnc.org precise 2.6
[11:21:56] <CaptHindsight> I was going to try those next
[11:22:07] <jepler> too many kernels
[11:24:11] <CaptHindsight> I'm just testing to see if it works. The Video drivers have issues with new hardware in Mate and Cinnamon
[11:30:21] <CaptHindsight> oh yeah, it wants libboost-python1.46.1
[12:18:05] <CaptHindsight> ok, the precise 3.4.55 RTAI and Linuxcnc work in Mint-Debian-Mate
[12:54:09] <skunkworks> this asus laptop runs 12us latency on the wheezy image
[12:54:18] <skunkworks> doesn't see the wireless though
[12:54:36] <skunkworks> and that is on battery
[12:57:09] <skunkworks> huh - seems to be an intel wireless nic
[13:10:06] <seb_kuzminsky> jthornton: i dont understand the thc change that you and marius liebenberg are talking about, but i keep hearing about velocity and acceleration control
[13:10:23] <seb_kuzminsky> can't that be handled by the limit3 component? seems silly to reimplement it in thc
[13:11:56] <seb_kuzminsky> i didnt understant marius's objection when i suggested it
[13:41:09] <CaptHindsight> well it runs, but the latency is terrible, was ~7K with the LiveCD
[13:42:51] <skunkworks> what is it now?
[14:19:22] <PCW> I agree with seb, reimplementing limit 3 in THCUD (or TCH) seems contrary to the normal hal (or unix)
[14:19:24] <PCW> "string comps together system" for THC external PID probably makes sense also
[14:19:25] <PCW> Hmm wonder if theres a way to embed a component in a component...
[14:20:20] <cradek> it seems like there's also something going on where an input goes from 0 to 100 to represent percentages or something -- that is also not the normal hal way
[14:23:00] <PCW> for most systems (with step motor on Z) the stepgen accel limit works
[14:24:09] <PCW> of course this fails on servo systems (not sure you would want a servo near a plasma torch though)
[14:43:03] <jepler> It's too bad the design of HAL didn't come up with a way to make things both components (which can be hooked together in hal) and objects (things which can be embedded by other components to perform a sub-function)
[14:47:02] <KGB-linuxcnc> 03Norbert Schechner 052.6 78df5fb 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_4 - solved screen 2 bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=78df5fb
[14:47:06] <jepler> (that is, ddt, limit3, etc could be "C" functions with extern linkage, available to any component)
[14:48:25] <seb_kuzminsky> yay, gmoccapy fix in 2.6 :-)
[14:49:31] <jepler> (but those two examples both have *state*, so now they each have a structure that is part of the API, too)
[14:51:18] <jepler> double ddt_function(struct ddt_state *st, unsigned long dt, double in);
[14:51:30] <KGB-linuxcnc> 03Norbert Schechner 05master 7b2346b 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_4 - fixed screen 2 error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b2346b
[14:51:49] <jepler> branch understand fail
[14:52:29] <seb_kuzminsky> aww, same commit in master :-/
[14:53:33] <cradek> ...
[14:56:34] <jepler> seb_kuzminsky: any thoughts to share on a timeline to merge rtos-uspace?
[15:00:29] * jepler wonders if "Niemand Sonst" = "none other"?
[15:02:13] <CaptHindsight> skunkworks: it's ~500K
[15:03:08] <skunkworks> oh - yeck
[15:04:08] <CaptHindsight> so something is missing or not setup right, plus the EFI is flaky,
[15:07:58] <cmorley> cmorley knows how to squash commits too -- and will before merging. :)
[15:08:20] <jepler> cmorley also knows how to talk about himself in the third person. excellent.
[15:08:30] <cmorley> lol
[15:21:19] <jthornton> seb_kuzminsky, I don't know what Marius is talking about
[15:34:45] <seb_kuzminsky> bummer
[15:37:51] <JT-Shop> yea, I can't understand how using the F word and the period he gets an acceleration AFAIK those two number won't vary as you cut
[16:51:56] <micges-dev> PCW: got chance to pull mesaflash repo and check ethernet comm?
[17:07:20] <CaptHindsight> hmm, increased memlock to 81920 and latency is ~23K now
[17:07:41] <CaptHindsight> also turned off kernel mode settings
[17:15:38] <PCW> micges-dev: will check right now still working on 7I90 ssremote
[17:17:13] <micges-dev> ok
[17:26:05] <PCW> OK seems good
[17:29:42] <micges-dev> thanks
[17:33:49] <PCW> Ha the 7I90 starts with ssslbp now
[17:36:46] <PCW> Card Name = 7I90 Channel = 0 Baud Rate = 2500000
[17:36:48] <PCW> RecvBuffer = HEX 00 0D 00 00 00 FF FF FF 00 FF FF FF 00 00 00 00
[17:36:50] <PCW> State = blather1
[17:36:51] <PCW> CRCErrorCount = 0
[17:36:53] <PCW> LBPDataSize = 0 RPCRecvSize = 13 RPCXmitSize = 12
[17:36:54] <PCW> MeasuredTime = 132.000 uS Response time = 24.000 uS LoopTime = 4.000 uS
[17:50:35] <micges-dev> cool
[17:51:03] <micges-dev> you had to rewrite sserial slave into fpga onboard cpu?
[17:51:14] <PCW> Yes
[17:51:54] <micges-dev> how much room it takes?
[17:51:57] <PCW> well I just wrote it from scratch sine the environment/hardware is so different
[17:52:02] <PCW> since
[17:53:04] <PCW> about 700 instructions so far
[17:53:46] <PCW> still needs:
[17:53:47] <PCW> discovery database init
[17:53:49] <PCW> watchdog
[17:53:50] <PCW> blinkylights
[17:55:52] <PCW> probably about 1K when done, more if there are more modes supported
[17:57:56] <micges-dev> nice
[18:00:40] <PCW> need to write some string macros for the database init
[18:00:41] <PCW> ldib something
[18:00:43] <PCW> stab somewhere
[18:00:44] <PCW> ldib somethingelse
[18:00:46] <PCW> stab somewhere+1 ...
[18:00:47] <PCW> gets old pretty fast
[18:10:17] <skunkworks_> ssslbp?
[18:21:06] <alex_joni> super speedy serial link bit protocol
[18:21:44] <micges-dev> heh I think too many 's'
[18:21:53] <micges-dev> smart serial little binary protocol
[18:22:16] <alex_joni> hey.. I was actually quite close
[18:22:48] <micges-dev> yeah
[18:44:16] <skunkworks_> it had 3 S's
[18:47:39] <alex_joni> super smart then
[18:48:12] <jepler> somewhat silly serial
[18:48:18] <jepler> (hi alex_joni)
[18:50:18] <jepler> ah, I meant "slightly silly".
http://en.wikipedia.org/wiki/Election_Night_Special
[22:32:46] <CaptHindsight> bad latency with Mint-debian and Mint 17 Qiana Xfce that uses the Trusty repos with the 3.4.55 RTAI and the debs for Precise
[22:33:31] <CaptHindsight> Linuxcnc debs for precise
[22:40:40] <skunkworks_> I have had pretty good luck so far with the wheezy setup. (one computer so far that doesn't play nice with the new kernel - 10.04 gives 10us vs 50+us on wheezy)
[22:59:27] <seb_kuzminsky> skunkworks_: can you try the precise rtai kernel (3.4.55-rtai-2)? as far as i know that's still the best one
[23:02:10] <skunkworks_> sure. what is on the wheezy cd?
[23:09:48] <seb_kuzminsky> something newer, probably 3.4.87-1~linuxcnc1
[23:10:09] <seb_kuzminsky> you can add precise as an apt source and manually downgrade the kernel
[23:10:43] <seb_kuzminsky> i'm wondering how its latency compares to the 2.6.32 rtai kernel in our lucid repo
[23:12:15] <CaptHindsight> 4 installs and tests today
[23:17:10] <skunkworks_> systems that run 50+us latency usually run a lot better - <20us when using 'idle=poll' in the kernel line..
[23:17:26] <skunkworks_> but it didn't seem to help the problem motherboard
[23:19:05] <skunkworks_> it even seems to help the preempt kernel
[23:19:17] <CaptHindsight> this asrock fm288m-hd+ and A6 6400K (dual core 3.9GHz) runs <7K on 10.04 with the 2.6.32 RTAI
[23:21:00] <CaptHindsight> on Ubuntu Precise 12.04 and 3.4.55 it runs about the same and if I add remove the irq balance it's down ~3K
[23:22:48] <CaptHindsight> so I'm stuck with precise or gentoo on this for now if I need fast video
[23:24:26] <CaptHindsight> if we spent enough time on Debian (learning the ins and outs) it might work well to
[23:34:41] <seb_kuzminsky> CaptHindsight: thanks for that report, it's helpful
[23:35:40] <seb_kuzminsky> the 3.4.55 and 3.4.87 rtai kernels have quite different rtai kernel patches, i'm thinking we get generally better results with the rtai kernel patch i used in the 3.4.55 kernel
[23:36:23] <CaptHindsight> I'm installing precise on it again right now (ran out of drive space)
[23:36:49] <CaptHindsight> I can try the 3.4.87 RTAI on it tomorrow
[23:38:04] <CaptHindsight> somebody else posted this board about month ago on the linuxcnc latency page
[23:38:43] <CaptHindsight> they had a different cpu, AMD A4-4000 Dual Core 3.2GHZ Max Turbo, 3.0 GHZ Base,
[23:39:25] <CaptHindsight> All Power saving features disabled in BIOS, Bios updated to VER 2.40, ISOLCPUS Enabled, IRQBalance un-installed, Disabled/Turned? Off spread spectrum, turbo core, APM, C6, cool'n'quiet, SVM, cpu throttle, suspend to RAM with latency 7966 on the 25uS thread
[23:43:03] <CaptHindsight> pretty sure that was with 12.04 + 3.4.55 RTAI