Back
[01:42:49] <KGB-linuxcnc> 03kinsamanka 05unified-build-candidate-3 8a239f9 06linuxcnc 10src/ 10(5 files in 2 dirs) * RPi SPI Driver initial commit
[01:42:49] <KGB-linuxcnc> 03mail17 05unified-build-candidate-3 a324838 06linuxcnc * Merge pull request #2 from kinsamanka/hal_spi
[01:42:53] <KGB-linuxcnc> 03git 05unified-build-candidate-3 eb4f416 06linuxcnc 10src/ 10rtapi/rtapi.h 10rtapi/rtapi_common.c * rtapi: add rtapi_shmem_exists() acessor
[01:43:00] <KGB-linuxcnc> 03git 05unified-build-candidate-3 4894a2a 06linuxcnc 10src/rtapi/shmdrv/shmdrvapi.c * shmdrv API: correct sign of return value on mmap() failure
[01:43:07] <KGB-linuxcnc> 03git 05unified-build-candidate-3 9df4259 06linuxcnc 10src/rtapi/shmdrv/shmdrv.c * shmdrv: IOC_SHM_ATTACH return full status of existing segment
[01:43:14] <KGB-linuxcnc> 03git 05unified-build-candidate-3 ad21610 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem_getptr(): fail with -ENOENT if shm segment not mapped
[01:43:20] <KGB-linuxcnc> 03git 05unified-build-candidate-3 1f3be77 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem_new_inst: return -EEXIST on mapping a shm segment again
[01:43:28] <KGB-linuxcnc> 03git 05unified-build-candidate-3 96ac7fd 06linuxcnc 10src/ 10rtapi/rtapi_kdetect.c 10rtapi/rtapi_kdetect.h * kdetect: sync with syndrome used in rtapi_compat.c
[01:43:35] <KGB-linuxcnc> 03charles 05unified-build-candidate-3 8e0a1ad 06linuxcnc 10configs/ 10ARM/BeagleBone/BeBoPr-Bridge/BeBoPr-Bridge.hal 10ARM/BeagleBone/BeBoPr/BeBoPr.hal * configs/BeagleBone : Fix path to ReadTemp.py
[01:43:47] <KGB-linuxcnc> 03charles 05unified-build-candidate-3 0c29b4c 06linuxcnc 10configs/ 10(6 files in 4 dirs) * configs/BeagleBone : Update path to pru_generic.bin
[01:43:54] <KGB-linuxcnc> 03charles 05unified-build-candidate-3 58b054e 06linuxcnc 10scripts/latency-test
[01:43:57] <KGB-linuxcnc> scripts/latency-test : Remove base thread by default
[01:43:59] <KGB-linuxcnc> The defualt 25 uS base thread will crash low performance systems
[01:44:01] <KGB-linuxcnc> that have greater than 25 uS interrupt latency.
[01:44:04] <KGB-linuxcnc> Signed-off-by: Charles Steinkuehler <charles@steinkuehler.net>
[01:44:21] <KGB-linuxcnc> 03charles 05unified-build-candidate-3 7b1ee82 06linuxcnc 10configs/ 10ARM/BeagleBone/BeBoPr-Bridge/BeBoPr-Bridge.hal 10ARM/BeagleBone/BeBoPr-Bridge/ReadTemp.py 10ARM/BeagleBone/BeBoPr/ReadTemp.py * configs/BeagleBone : ReadTemp.py
[01:44:28] <KGB-linuxcnc> 03john 05unified-build-candidate-3 80abd59 06linuxcnc 10docs/src/common/UnifiedBuild.txt * UnifiedBuild.txt: add notes about UB build and run-time system changes
[01:44:36] <KGB-linuxcnc> 03git 05unified-build-candidate-3 844e7c1 06linuxcnc 10debian/control.in 10docs/man/man9/motion.9 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/resolver.c * Merge remote-tracking branch 'origin/master' into unified-build-candidate-3
[01:44:45] <KGB-linuxcnc> 03git 05unified-build-candidate-3 391385c 06linuxcnc
[01:44:47] <KGB-linuxcnc> Merge remote-tracking branch 'github/unified-build-candidate-2' into ub-doc-update
[01:44:56] <KGB-linuxcnc> 03git 05unified-build-candidate-3 166412a 06linuxcnc 10docs/src/common/UnifiedBuild.txt * docs/UnifiedBuild: integrate comments from Kent
[01:45:03] <KGB-linuxcnc> 03git 05unified-build-candidate-3 b80a373 06linuxcnc 10docs/ 10src/Master_Integrator.txt 10src/Submakefile 10src/index.tmpl * docs/UnifiedBuild: integrate into docs build
[01:45:10] <KGB-linuxcnc> 03john 05unified-build-candidate-3 ff159d8 06linuxcnc 10src/configure.in * configure.in: Don't do MULTILIB_HACK on non-Precise hosts
[01:45:17] <KGB-linuxcnc> 03john 05unified-build-candidate-3 aa04069 06linuxcnc 10src/rtapi/Submakefile * rtapi/Submakefile: fix race condition creating links for parallel build
[01:45:24] <KGB-linuxcnc> 03john 05unified-build-candidate-3 d3b7969 06linuxcnc 10src/ 10Makefile 10Makefile.inc.in * Makefile, Makefile.inc: fix EMC2_RTLIB_DIR installation location
[01:45:31] <KGB-linuxcnc> 03git 05unified-build-candidate-3 a5bce14 06linuxcnc 10docs/src/common/UnifiedBuild.txt * docs/UnifiedBuild: touchups
[01:45:37] <KGB-linuxcnc> 03TODO: deletor 05unified-build-candidate-1 dd3f7a5 06linuxcnc 04. * branch deleted
[01:45:43] <KGB-linuxcnc> 03TODO: deletor 05unified-build-candidate-2 ec43a02 06linuxcnc 04. * branch deleted
[01:55:43] <linuxcnc-build> build #1300 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1300 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP Orcullo
[01:55:43] <linuxcnc-build> <kinsamanka@gmail.com>, John Morris <john@zultron.com>
[01:56:00] <linuxcnc-build> build #1296 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1296 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP
[01:56:01] <linuxcnc-build> Orcullo <kinsamanka@gmail.com>, John Morris <john@zultron.com>
[01:56:23] <linuxcnc-build> build #1298 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1298 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP Orcullo
[01:56:23] <linuxcnc-build> <kinsamanka@gmail.com>, John Morris <john@zultron.com>
[02:04:07] <linuxcnc-build> build #1296 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1296 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>, John Morris
[02:04:08] <linuxcnc-build> <john@zultron.com>
[02:04:17] <linuxcnc-build> build #1299 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1299 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>, John Morris
[02:04:17] <linuxcnc-build> <john@zultron.com>
[02:06:58] <linuxcnc-build> build #1299 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1299 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>,
[02:06:59] <linuxcnc-build> John Morris <john@zultron.com>
[02:31:35] <linuxcnc-build> build #1294 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1294 blamelist: Michael Haberler <mail17@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <git@mah.priv.at>, GP Orcullo <kinsamanka@gmail.com>, John Morris <john@zultron.com>
[07:22:11] <jepler> hm well the latency-test change that charles made wasn't quite what I suggested on the list :-/
[08:06:42] <alex_joni> 'lo
[08:08:37] <mhaberler> what you'd suggest?
[08:09:52] <alex_joni> hey mhaberler
[08:10:05] <mhaberler> servus!
[08:10:18] <alex_joni> so.. I got a BBB
[08:10:35] <alex_joni> what can I do with it (regarding lcnc) atm?
[08:10:37] <mhaberler> and you have read Charles' blog..
[08:10:48] <alex_joni> I'm aware of machinekit or what it's called
[08:10:49] <alex_joni> yeah
[08:10:55] <alex_joni> was wondering shield-wise
[08:11:01] <mhaberler> oh
[08:11:11] <alex_joni> saw references to BeBoPr - but no idea where to get one from
[08:11:23] <mhaberler> talk to Bas Laarhoven
[08:11:24] <alex_joni> and was wondering if there isn't a simpler shield that emulates a parport
[08:11:26] <mhaberler> he makes them
[08:11:45] <mhaberler> no, but maybe Steve Stallings is on that case, or Jon Elson
[08:11:59] <mhaberler> that be pretty easy, just get the breakout cape
[08:13:04] <mhaberler> and wire a db25; there are no buffer drivers between pins and cpu though, so caveat
[08:13:41] <alex_joni> hummm.. might be place for a new shield then :)
[08:22:23] <archivist> alex_joni, two versions of it while you are designing it, one where the optos are built into the drives and one with the optos on board
[08:23:10] <mhaberler> right, that be a useful cape
[08:24:38] <cradek> on low-power parport connected hardware I wonder if optos really help with real problems, or just cause pain but are there because people expect them
[08:25:39] <archivist> my drivers have built in opto I need a buffer from the parport to drive the optos
[08:26:32] <cradek> yeah that's the typical problem
[08:26:47] <cradek> also, optos can be slow
[08:36:06] <alex_joni> I agree buffers would be more useful
[08:36:21] <alex_joni> most likely socketed buffers acting as fuses :D
[08:36:48] <cradek> well I'm asking, not suggesting
[08:36:59] <skunkworks> heh - all my printer port interfaces that I have put together all have buffers.. (no optos)
[08:37:00] <cradek> I think people expect "quality" parport-connected stuff to have optos
[08:37:14] <skunkworks> buffers/inverters.
[08:37:22] <cradek> I wonder if it's driven by that or by real engineering
[08:37:24] <skunkworks> I have yet to take out a printer port.. have tried though
[08:37:45] <archivist> I use an open collector buffer either 74xx or a ULN200x
[08:38:42] <skunkworks> I don't thinnk the emco lathe has optos...
[08:39:56] <archivist> my starturn...does not either, uses the ULN for level shifting to the 12v levels of the starturn drivers
[08:40:51] <archivist> with the uln one could use it safely as a relay driver too if space for diodes added
[08:50:21] <skunkworks> I think optos mask poor grounding
[08:51:54] <archivist> dunno, there are some seriously spiky noise producers, separate grounds and optos can help
[08:52:28] <skunkworks> sure
[09:07:09] <pcw_home> Decent step drives are almost always isolated does seem a bit
[09:07:10] <pcw_home> silly to isolate the other end (and use OPTOs as line drivers, a job they are ill suited to)
[09:17:08] <jepler> mhaberler: I thought a configure-time switch to make latency-test have its current behavior on desktop platforms and some other behavior (maybe no-base-period) on everything else
[09:17:35] <jepler> eh it doesn't matter, except that probably stepconf should invoke latency-test with a base period
[09:17:58] <mhaberler> that thing is tcl, right?
[09:18:09] <jepler> it's a shell script that creates a tcl script or something awful like that
[09:18:19] <mhaberler> gawd
[09:33:52] <pcw_home> Is there any advantage of high base rates for gathering peak latency data?
[09:33:54] <pcw_home> (other than being faster at acquiring that data)
[09:34:57] <jepler> pcw_home: I think if you're going to be running two threads you should take your measurements under a like situation
[09:36:58] <pcw_home> Yeah, though in practice, unless you actually do the I/O you really have no reliable figure of what the actual latency will be
[09:38:43] <pcw_home> PC/SOC I/O can be blocked by bus masters/DMA etc
[09:43:12] <jepler> that is quite true
[09:45:42] <pcw_home> That was my disappointing finding on the Atoms (great latency on the test, poor latency if measured in physical I/o pin jitter)
[09:49:10] <pcw_home> On the other hand, for servo thread only systems especially if data sampling/output can be run by hardware timer,
[09:49:11] <pcw_home> jitter is relatively unimportant as long as you can get what you need done in the time available after a worst case
[09:49:13] <pcw_home> latency spike
[10:09:37] <kwallace> What might a real latency test look like? I suspect and external oscillator to trigger an input then an oscilloscope to see how long it takes to get a response?
[10:11:04] <skunkworks> couldn't you do that on the printer port (out to in?) for testing printer port latency...
[10:16:53] <pcw_home> Thats what I did (toggle an output bit)
[10:20:20] <skunkworks> The absolute maximum latency on this laptop after running for a few days was 25us. not bad for a laptop
[10:23:02] <kwallace> Should the LinuxCNC PC be both the timing reference and the UUT?
[10:52:35] <jepler> ideally it wouldn't be, but without depending on specific hardware being present it's hard to do otherwise
[10:56:09] <kwallace> It is the specific hardware I am curious about.
[10:58:46] <jepler> well if you want to assume mesa, you could set up stepgen to essentially be a timestamp counter
[11:27:17] <awallin> does an ubuntu "lowlatency" kernel count as a preempt-rt kernel?
[11:52:44] <awallin> well that was fun. the -lowlatency kernel completely messed up my graphics settings...
[11:59:30] <CaptHindsight> https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
[12:00:35] <CaptHindsight> looks like -lowlatency kernel just has some config tweaks
[12:01:04] <awallin> hm yeah, but it did not like my 30" 2560x1600 screen+NVIDIA at all
[12:01:45] <CaptHindsight> they probably broke kernel mode settings
[12:03:16] <CaptHindsight> awallin: did you ever more from national instruments about where they post the source for the new ZYNQ boards?
[12:03:33] <awallin> and when I booted back to my -generic kernel I had no launcher&compiz running
[12:04:02] <awallin> CaptHindsight: I just noticed they started marketing cRIO with somve variant of preempt-rt, don't know more than that
[12:04:11] <CaptHindsight> I'm just assuming you're the same awallin that I saw on their forums
[12:04:44] <awallin> maybe :)
[12:07:36] <CaptHindsight> they look interesting but I don't expect them to be low cost
[12:08:47] <awallin> ARM+FPGA combo is doable open-source also given enough time & effort...
[12:09:28] <awallin> I've been using these at work
http://www.ohwr.org/projects/spec/wiki they are open hardware, also sort of interesting..
[12:09:31] <CaptHindsight> plus the xilinx tools for ZYNQ pretty much encourage the use of Linux
[12:11:26] <awallin> any idea what bus/protocol they use between the ARM and the FPGA on NI hardware?
[12:11:42] <CaptHindsight> the ARM cores are in the FPGA
[12:11:49] <CaptHindsight> dual arm9
[12:11:58] <awallin> really?
[12:12:15] <CaptHindsight> http://www.xilinx.com/content/xilinx/en/products/silicon-devices/soc/zynq-7000.html
[12:12:32] <awallin> oh on zynq, ok
[12:12:52] <awallin> but older/existing cRIO etc hardware does have ARM+FPGA chips?
[12:13:13] <CaptHindsight> yes, for that new cRIO, not sure on the older stuff
[12:13:52] <awallin> we should ask olimex to make an olinuxino with zynq
[12:14:26] <CaptHindsight> probably outside of his price target
[12:14:27] <pcw_home> Look at the parallela for a inexpensive ZYNQ platform
[12:15:07] <pcw_home> with 16X 1 GFLOP PRUs!
[12:15:24] <awallin> eh, ev-kit is 1300euros...
[12:15:57] <CaptHindsight> I might make some ZYNQ boards later this year, maybe I'll float some open kitchen sink design around China
[12:16:41] <CaptHindsight> $99 Parallella board
http://www.parallella.org/
[12:17:10] <awallin> so the idea is to leave part of the FPGA free for user applications? and the rest is used for the ARM core?
[12:18:02] <CaptHindsight> Vivado and the SDK make it really easy to design custom peripherals and write the drivers and bootloader
[12:19:24] <CaptHindsight> yeah, they leave free gates for you to add your own IP, say hardware for video edge detect or similar
[12:20:02] <awallin> if they can sell it for $99 the zynq chip can't be that expensive?
[12:20:18] <pcw_home> I think they got a specail deal
[12:20:30] <pcw_home> the parst cost is more than that
[12:20:41] <pcw_home> parts
[12:20:49] <CaptHindsight> the only negative thing with the tools IMHO so far is the reliance on code sorcery vs crosstool
[12:22:01] <CaptHindsight> pcw_home: I read on one of the forums about the prices starting ~$40 ea
[12:22:12] <pcw_home> Kind of like the core generator, I purged all core generator created objects early on..
[12:22:34] <pcw_home> Yes they are getting more reasonable
[12:23:21] <awallin> anyway a xilinx fpga connected somehow to one of these cheap ARM boards (beagle, olimex, etc) would be interesting
[12:24:00] <CaptHindsight> cubieboard
[12:24:08] <mhaberler> awallin: ah, here you are. please pastebin src/config.log and the output of make (eg make |& tee /tmp/log)
[12:24:14] <pcw_home> I have a Cubieboard one now
[12:25:35] <CaptHindsight> http://cubieboard.org/2013/06/19/cubieboard2-is-here/ with the Allwinner A20 dual A7 core SOC
[12:25:43] <mhaberler> awallin: what ubuntu distro?
[12:25:53] <pcw_home> Which reminds me I need to order some of the those
[12:26:02] <awallin> mhaberler: I am on ubuntu 13.04
[12:26:12] <awallin> mhaberler: config.log
http://pastebin.ca/2443024
[12:32:39] <mhaberler> that looks fine
[12:33:54] <mhaberler> very strange; sure you did the '. scripts/rip-environment' ? could you pastebin the output of 'find rtlib libexec' please?
[12:34:02] <awallin> maybe make &> mylog.log
[12:34:16] <mhaberler> I use this: make |& tee /tmp/log
[12:34:38] <mhaberler> no, the make runs fine
[12:35:40] <awallin> hmh, now it works.. very strange
[12:36:16] <awallin> find doesn't find rtlib or libexec
[12:36:24] <mhaberler> cd linuxcnc
[12:36:27] <mhaberler> ls
[12:36:38] <mhaberler> this should list among others rtlib and libexec
[12:36:58] <mhaberler> looks like an environment funny to me
[12:37:12] <awallin> rtlib/posix has a lot of .so files
[12:37:16] <mhaberler> right
[12:37:33] <mhaberler> libexec must have rtapi_app-posix or so
[12:37:40] <awallin> yes
[12:37:48] <mhaberler> that build is fine
[12:37:51] <awallin> and I also have rtapi_app_rt-preempt in red
[12:38:06] <mhaberler> right, you get that for free ;) bonus thread model
[12:39:01] <mhaberler> if you're curious you could try with this kernel:
http://static.mah.priv.at/public/rt-preempt/
[12:40:26] <awallin> I get the error I reported with "make -j4" (I am impatient, no reason why compiles shouldn't use all cores) "make" by itself seems to produce an ok build
[12:40:39] <mhaberler> aha. parallel make
[12:40:48] <mhaberler> seems not all deps are worked out
[12:41:17] <mhaberler> thanks - pretty sure this was it; this needs work
[12:42:09] <CaptHindsight> pcw_home: Parallella-16 with GPIO and Zynq7020 is $199
[12:42:20] <CaptHindsight> http://shop.adapteva.com/collections/parallella/products/parallella-16
[12:42:40] <awallin> mhaberler: some linker problems at the end here
http://pastebin.ca/2443030 (output of make -j4)
[12:44:00] <mhaberler> yes, thats a consequence of the -j4; there seem to be missing deps for parallel make to work
[12:44:00] <pcw_home> 7020 is way too big for anything we do
[12:44:33] <mhaberler> please dont use the -j flag until further notice
[12:44:46] <awallin> :P
[12:45:41] <awallin> mhaberler: for testing preempt-rt, do I need all those debs: firmware-image, headers, image, libc?
[12:46:37] <mhaberler> you likely need image libc; suggest firmware
[12:46:50] <mhaberler> do you have an r8168 net i/f?
[12:47:31] <mhaberler> if so, fetch the
http://static.mah.priv.at/public/rt-preempt/r8168-8.035.00-3.10.4.tgz file ***before you reboot*** (and not into /tmp ;)
[12:47:59] <mhaberler> see also
http://static.mah.priv.at/public/rt-preempt/README
[12:48:04] <mhaberler> bb in an hour
[12:48:05] <awallin> rtl8168e/8111e says dmesg | grep eth0
[12:52:28] <mhaberler> in that case the preempt kernel likely comes up with a broken network i/f ; blacklist the r8169 driver (which very likely is loaded, see lsmod), and build the one from the r8168 tar archive
[12:53:22] <mhaberler> that should get the i/f working. unfortunately this is an issue unresolved for the better part of a decade now, and affects all torvalds kernels and derived up to at least 3.10
[12:54:27] <mhaberler> there are lots of r8168 driver archives out there; the one I referred to does work with the 3.10-4 kernel
[12:54:47] <mhaberler> bbl
[19:11:48] <KimK> memleak, CaptHindsight: Any news on the status of RTAI kernels for 12.04? Not rushing you, just looking ahead.
[19:13:19] <CaptHindsight> KimK: what kernel version is that again?
[19:14:53] <KimK> (Well, OK, maybe rushing you a little. I just noticed that the FreeCAD daily PPA guys have stopped supporting 10.04 a few weeks ago. I *thought* it had been a while since an update, lol.)
[19:15:24] <CaptHindsight> the v3.5 debs should work
[19:17:43] <CaptHindsight> or the v3.4 debs
[19:18:10] <CaptHindsight> http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[19:18:18] <KimK> CaptHindsight: Well, I had in mind the 64-bit to help in testing/debugging 64-bit Mesa stuff, but I'm not absolutely stuck on the idea. (Besides, I think people are snickering, lol.) Wait, what? Oh, these are the "Seb's debs"?
[19:19:15] <CaptHindsight> yeah, based on the new RTAI work by memleak and shabbyx
[19:22:19] <KimK> I tried installing the "Seb's debs" on my unit 2, but the grub menu doesn't show them (although, strangely, they do appear in the terminal upon "sudo update-grub"). I never tried to do anything about this, I was hoping that after a while, things would get straightened out automagically(?)
[19:23:27] <CaptHindsight> for now you'll have to compile 64bit RTAI kernels from source
[19:23:28] <KimK> So I've been using 12.04 Ubuntu since then on unit 2. But eventually I'll need to run hostmot2 on unit 2, so RTAI would be nice.
[19:25:09] <KimK> Unit 1 continues to run Xenomai, but I have done very little testing with hostmot2 on it.
[19:25:20] <CaptHindsight> https://github.com/ShabbyX/RTAI/blob/master/README.INSTALL is a howto for building the kernels, but it doesn't cover making .debs
[19:28:26] <KimK> OK, thanks, I'll take a look. I should be able to build RTAI-64 and add it to the list of kernel choices, right? So if it doesn't work out well (for whatever reason), I can just not choose it, and continue as before?
[19:28:40] <CaptHindsight> yes
[19:30:13] <KimK> OK, I'll look at it, thanks very much. In fact, unit 2 is here, I'll go and look at it right now.
[19:34:06] <KimK_2> I'm here, looking at it now...
[19:37:13] <CaptHindsight> dos KimK's
[19:52:21] <KimK_2> Ha, si! I'm looking at kernel.org, so I want the 3.4.60 longterm? (I don't see a 3.5 anything, but their recommended one is the 3.11 mainline (if you go by the big button). Are the 32 and 64 bit versions both in the tar file? Or selected a build option?
[20:03:27] <CaptHindsight> http://imagebin.org/269800
[20:05:45] <CaptHindsight> KimK_2: just to be safe I'd follow the howto exactly as is the first time
[20:06:31] <CaptHindsight> the 3.4 is more recent than the 3.5
[20:12:52] <KimK_2> Oh, you mean use the same version ShabbyX did, even though he talks about changing the version number to whatever version was used?
[20:25:18] <CaptHindsight> yes, then it's easier to check if have any problems