Back
[06:59:53] <micges-dev> logger[mah]: hi
[06:59:53] <logger[mah]> micges-dev: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-07-06.html
[09:14:10] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis b48b4b0 06linuxcnc 44 commits pushed, 1024 files changed, 03522(+), 041757(-)
[09:23:30] <linuxcnc-build> build #25 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/25 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:25:22] <linuxcnc-build> build #1417 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1417 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:26:39] <linuxcnc-build> build #2216 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2216 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:29:13] <linuxcnc-build> build #2213 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2213 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:51:44] <linuxcnc-build> build #2218 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2218 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[09:52:50] <jepler> uh oh, I'll look at that after breakfast.
[10:14:09] <micges-dev> pcw_home: mesaflash root access fix also fixed your epp errors while ethernet access
[10:22:35] <pcw_home> Great, I'll try it on Monday
[10:34:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis bed2021 06linuxcnc 26 commits pushed, 102 files changed, 038(+), 046(-)
[10:35:04] <jepler> linuxcnc-build: I hope you like this iteration better!
[10:35:04] <linuxcnc-build> What you say!
[10:49:31] <linuxcnc-build> build #26 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/26 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[11:13:14] <linuxcnc-build> build #2219 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2219 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[11:33:16] <jepler> [524127.795838] rtapi: Unknown symbol parport_register_device (err 0)
[11:33:17] <jepler> well that's weird
[11:35:25] <jepler> so before now, nothing in linuxcnc used the parport until you actually loaded a driver that did
[11:35:29] <jepler> now, just loading rtapi.ko does
[11:36:17] <jepler> .. and that vm doesn't have a parport, so linux hasn't loaded the parport module
[11:47:20] <jepler> so I guess I'll have to put that code back as inlines
[11:47:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 3bb842c 06linuxcnc 10src/Makefile 10src/hal/hal_parport.h 03src/rtapi/rtapi_parport.h rtapi: Move parport up from hal_ to rtapi_ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3bb842c
[11:47:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 8f2d71c 06linuxcnc 10docs/man/man3/hal_parport.3hal 03docs/man/man3/rtapi_parport.3rtapi rtapi: document rtapi_parport * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8f2d71c
[11:47:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis f9126d3 06linuxcnc 10src/rtapi/Submakefile 10src/rtapi/rtapi_parport.h 03src/rtapi/uspace_rtapi_parport.cc uspace: implement rtapi_parport * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f9126d3
[11:47:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 922a311 06linuxcnc 10(9 files in 3 dirs) hal_parport: Build for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=922a311
[11:47:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis e725a49 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Allow the upper-bound value to be parenthesized * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e725a49
[11:47:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 66ec54d 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Report the "corrupt" array type information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=66ec54d
[11:47:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis cb43827 06linuxcnc 10src/rtapi/uspace_common.h uspace: implement rtapi_delay_max for hm2_7i43 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cb43827
[11:47:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 1acb245 06linuxcnc 10src/Makefile 10src/hal/drivers/mesa-hostmot2/hm2_7i43.c 10src/hal/drivers/mesa-hostmot2/hm2_7i90.c hostmot2: port 7i43 (tested) and 7i90 (untested) to uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1acb245
[11:47:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 92903c4 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_7i43.c hm2_7i43: Automatically fall back to byte transfers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=92903c4
[12:18:20] <CaptHindsight> I put together a new test system yesterday. The integrated NIC is a Realtek RTL8111FR. As soon you plug in the network cable or the kernel loads the NIC crashes the network. It's entered Bizaroland
[12:20:41] <jepler> pcw, micges: so far I've learned that you can use iptables to restrict packets by uid
[12:20:44] <jepler> iptables -A OUTPUT -m owner --uid-owner root -j ACCEPT
[12:21:41] <jepler> I think that this rule (suitably specialized to the right interface) would allow rtapi_app to send packets to a 7i80, but restrict a non-sudo'd user
[12:21:44] <jepler> sudude
[12:23:47] <jepler> disturbingly, --uid-owner is listed in the iptables(8) manpage on debian wheezy, but not on debian testing
[14:03:58] <skunkworks> jepler: git pull gives me nothing.. is that correct?
[14:07:36] <CaptHindsight> putting a switch between the NIC and the rest of the network fixed it, I have to track this down
[14:08:17] <skunkworks> that is odd
[14:08:18] <CaptHindsight> which version of Mint are people trying? the ones compatible with ubuntu repos or debian?
[14:10:52] <micges-dev> jepler: thanks for lurking in iptables, I hope ubuntu iptables has also --uid-owner
[14:18:28] <jepler> skunkworks: I've stopped updating rtos-uspace-hm2-eth, I'm just updating rtos-uspace-apis. after rtos-uspace-apis is merged to master, I hope micges will take up the ethernet work again.
[14:18:42] <skunkworks> ok
[14:18:54] <jepler> skunkworks: I don't think anything I've been fixing has been relevant to hm2-eth
[14:29:06] <jepler> I need to do something about the use of tsc in hal_parport. that doesn't work when tsc is not constant and when the cpu_khz constant is not available
[14:33:49] <cradek> is that only needed for doublestep?
[14:36:41] <skunkworks> I use it on the emco config to send the clock signal
[14:45:07] <jepler> cradek: yes
[14:46:29] <jepler> I suppose I could use rtapi_get_time as rtapi_get_clocks, just like for non-x86
[14:49:13] <cradek> is software stepping going to actually work with -rt? if not, then doublesetup isn't needed.
[14:49:43] <cradek> hmm, it's becoming evident that I forgot to eat lunch. bbl.
[14:51:22] <jepler> on my test machine, one call to clock_gettime is about 600ns
[14:52:12] <jepler> huh, on another machine (debian non-rt kernel) it's 25us
[14:57:28] <jepler> er, I meant, 25ns
[15:11:48] <cradek> > Ubuntu used to offer -rt kernels, but no longer appears to do so.
[15:11:50] <cradek> I wonder why this
[15:23:09] <jepler> I don't understand the history.
https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel implies there might be some PPAs, but one is 404'd and one is restricted
[17:26:49] <skunkworks> cradek: I had wrote the latest iso on wlo to a usb drive - when it gets to the point of 'mounting' the cdrom it fails. I went back to a previous iso and it seems to work
[19:28:15] <skunkworks> and it almost seeems like the previous iso has better latency
[19:33:12] <skunkworks> but I thought they had the same kernel
[21:51:17] <skunkworks> logger[psha]_:
[21:51:17] <logger[psha]_> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-07.html
[22:45:15] <cradek> yeah I haven't changed the kernel. I'm really surprised it changed.