Back
[05:57:21] * jthornton hates the mailing list...
[06:17:24] <archivist> I prefer that to the forum :)
[06:55:35] <CaptHindsight> ok, now precise with 3.4.55 RTAI is acting up on this board, latency is now terrible after being tested <7K
[08:34:41] <cradek> the forum has twice as many problems: the users AND the obnoxious format
[08:38:15] <skunkworks> heh
[09:20:28] <JT-Shop> as usual I didn't type what I thought
[09:22:13] <JT-Shop> I do hate the ads that get tacked onto the mailing list and find it inefficient to scroll up and down through all the top/bottom posting quotes and personal comments to read what the poster said
[09:23:12] <seb_kuzminsky> i find it more annoying to scroll past all the anecdotes and tangents and fighting to read what the poster said...
[09:23:43] <cradek> in mutt, poking S will go past any quoted stuff to the main part of the message, no matter where it is
[09:24:00] <cradek> if your mailer sucks, you can use a different one -- unlike the forum
[09:24:57] <cradek> but yeah, the noise is the worst part, followed closely by the bad quoting hygeine
[09:25:41] <cradek> I guess the ads don't bother me unless people fail to trim them (since they're only a few lines of text, and always at the end)
[09:26:10] <seb_kuzminsky> speaking of bad hygiene, i've build a new kernel with the "known-best" 3.4.55 rtai patch
[09:26:16] <cradek> yay
[09:26:26] <seb_kuzminsky> i'm gonna build rtai-modules for it, should be ready later this morning
[09:26:29] <jepler> Hopefully sourceforge gets a femtocent everytime it attaches a blurb about some proprietary software on our mailing list about free software.
[09:26:50] <seb_kuzminsky> then i should try it on my computer that crashes with the newer kernel patches when i plug in the wifi usb dongle
[09:26:58] <seb_kuzminsky> and i'd like dgarr to try it on his misbehaving machine
[09:27:00] <cradek> seb_kuzminsky: cool, will you also rebuild wlo/wheezy/2.6?
[09:27:16] <cradek> ah yes, basic testing should come first
[09:27:30] <cradek> I'm all ready to make a new cd image, but why bother unless we know it's better
[09:27:40] <seb_kuzminsky> and if it looks like it's a good kernel i'll push it to wlo, update the buildslave, rebuild 2.6, you can make a new cd image, and then we can finally release 2.6...
[09:27:56] <JT-Shop> on the CD image can you turn off the OS updates prompt?
[09:28:07] <cradek> seb_kuzminsky: so excited
[09:28:24] * seb_kuzminsky goes squeeee
[09:28:38] <cradek> JT-Shop: good question. I am not sure if there's any auto popup thing at all, I will figure it out
[09:29:01] <cradek> I think debian doesn't do the nag-you-to-push-the-button dist upgrade
[09:29:03] <jepler> I have never seen a update prompt on debian, whether for regular updates or "we're about to destroy your life" OS updates
[09:29:19] <seb_kuzminsky> bbl
[09:29:25] <JT-Shop> in the synaptic package manager > settings > repositories > Updates tab you can turn it off
[09:29:29] <skunkworks> I have not seen it with wheezy either..
[09:29:40] <JT-Shop> I don't know if that will be used when you make the CD or not
[09:30:30] <cradek> I would like it if there was the upgrade notice, but not one that changes the sources
[09:30:38] <skunkworks> I probably won't be able to test the kernel on wonky hardware until the end of the week
[09:30:52] <JT-Shop> the next CD will not be Ubuntu?
[09:31:26] <cradek> the one I am building is based on debian wheezy, which is the parent of ubuntu
[09:31:34] <JT-Shop> ah ok
[09:31:39] <jepler> hah, in debian 7 "wheezy", synaptic settings > repositories > updates, an option has the title "Notify me of a new Ubuntu version"
[09:31:42] <jepler> oops
[09:31:57] <cradek> that's very funny
[09:33:24] <skunkworks> wheezy is more similar in look and feel to 10.04 than ubuntu 12.04/14.04 with the selected desktop
[09:33:48] <JT-Shop> that's nice, I didn't care for the 12.04 desktop when I tried it
[09:34:42] <skunkworks> http://electronicsam.com/images/KandT/testing/mesaeth.png
[09:44:45] <cradek> jepler: I set those things in synaptic but nothing happens when I reboot. there must be another xfce piece of the puzzle.
[09:45:27] <jepler> bugs.debian.org/710565
[09:45:58] <jepler> looks like gnome broke the update manager so that it doesn't work in xfce?
[09:46:30] <cradek> fff
[09:47:24] <jepler> do you still live in the fantasy land where it's possible to write an application like "show a list of available updates on the screen" that can work on more than one desktop environment?
[09:47:30] <jepler> give up and smell the coffee of the new gnome
[09:48:17] <jepler> (It's written "gnome" but a growing fraction of people pronounce it as "f--- those guys")
[09:50:56] <cradek> might work in wheezy? I installed update-notifier and am rebooting.
[09:52:34] <cradek> ugh
[09:52:36] <cradek> well it runs
[09:52:45] <cradek> but it constantly asks me for the "administrative" password
[09:52:59] <cradek> so it doesn't work with sudo
[09:54:21] <jepler> just to list the updates?
[09:54:40] <jepler> apt-get --dry-run dist-upgrade runs without root
[09:54:58] <cradek> it shows the number of available updates
[09:55:13] <cradek> when you click it to see/install them, it wants the password, and there isn't one
[09:55:18] <jepler> oh
[09:55:50] <skunkworks> there isn't one?
[09:56:42] <seb_kuzminsky> yak sighted!
[09:56:46] <seb_kuzminsky> man the harpoons!
[09:58:06] <cradek> welllll I like the ubuntu way of asking for one password at install instead of two, and then letting the install user sudo, so I did that
[09:58:27] <cradek> which works fine for everything but this, apparently
[09:58:31] <seb_kuzminsky> that's much better than making the user remember a root password they hardly ever use
[09:58:37] <skunkworks> ah
[09:58:37] <cradek> yes
[10:01:18] <cradek> synaptic works fine with my (user) password
[10:07:24] <cradek> ffff
[10:07:34] <cradek> there's gksu and gksudo; gksudo works and gksu doesn't
[10:07:42] <cradek> update-manager calls gksu
[10:08:24] <cradek> they both come from the gksu package
[10:13:08] * skunkworks finally does sudo apt-get update/upgrade
[10:28:41] <maximilian_h> hi
[10:28:56] <maximilian_h> I am trying to run a X X Y Z C gantry setup
[10:29:09] <maximilian_h> and I am running into quite a lot of problems
[10:29:20] <maximilian_h> using 2.6 pre4
[10:29:34] <maximilian_h> is anybody actually using this with a gantry ?
[10:40:48] <seb_kuzminsky> jmk speaks my language
[10:41:05] <seb_kuzminsky> maximilian_h: i've never setup or run a machine like that
[10:46:28] <maximilian_h> seb_kuzminsky: It is a samplemaking plotter for carton samples
[10:46:39] <maximilian_h> x and y is a flat table
[10:47:01] <maximilian_h> z is there for the height of the different tools
[10:47:46] <maximilian_h> and c is there because when you cut carton with any type of knife, or if you crease carton, when you need C around Z
[10:48:02] <maximilian_h> and X has a gantry setup on that machine
[10:48:47] <seb_kuzminsky> sounds like a neat machine!
[10:48:56] <maximilian_h> it is
[10:49:01] <maximilian_h> when it is working
[10:49:31] <maximilian_h> linuxcnc should be a replacement for an older msdos based controller
[10:49:46] <maximilian_h> but that gantry is giving me gray hairs
[10:55:50] <seb_kuzminsky> gantry setups are known to work in linuxcnc 2.6 (with some wrinkles that you have to know about and work around)
[10:56:12] <seb_kuzminsky> i dont know of anyone running a gantry with a rotary axis, that may uncover new issues
[10:56:44] <seb_kuzminsky> maximilian_h: there's some stuff on our wiki that may be helpful:
[10:56:44] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?FiveAxisGantry
[10:57:07] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?GantryPlasmaMachine
[10:58:43] <seb_kuzminsky> cradek, skunkworks : new linux-image and rtai-modules debs available here: deb
http://highlab.com/~seb/linuxcnc/rtai-debs (wheezy|precise) main
[10:59:36] <maximilian_h> seb_kuzminsky: thanks for these two links, I was aware of the gantry with the plasma, but the other one is new to me
[10:59:42] <seb_kuzminsky> the linux-image is 3.4.55-1linuxcnc, the rtai-modules is 3.9.260.g6394e67, these are probably downgrades for you
[10:59:52] <seb_kuzminsky> maximilian_h: i just searched for "gantry" on the wiki
[11:00:03] <seb_kuzminsky> i thought we had a page somewhere with known gantry wrinkles, but i couldnt find it
[11:00:41] <maximilian_h> my rotary axis it can jog with the right velocity
[11:01:19] <maximilian_h> but if I to a move like g90c0c3600 then it is so slow than I can hardly see it move
[11:01:59] <maximilian_h> with trivkins on a similar older machine without the gantry that worked just fine
[11:02:39] <maximilian_h> so it must be connected to either the gantry setup and/or the different joint numbers used
[11:02:46] <cradek> maximilian_h: c0c3600 does not make sense
[11:03:03] <maximilian_h> on the gantry i am using X with joints 1 and 2
[11:03:23] <maximilian_h> oh sorry, that should be g90g0c3600
[11:03:34] <maximilian_h> for 10 revolutions of the c axis
[11:04:19] <maximilian_h> when jogging that turns with the intended high velocity
[11:04:21] <cradek> you do realize F is in degrees/minute when you move only C axis, right?
[11:04:29] <cradek> if in G94 mode
[11:04:56] <cradek> this probably has nothing to do with gantry
[11:04:59] <seb_kuzminsky> for g0 that shouldnt matter
[11:05:06] <cradek> oh right
[11:05:13] <maximilian_h> I tried F5000 and F20000 too
[11:05:21] <maximilian_h> and it did not change anything
[11:05:24] <maximilian_h> yes g0
[11:05:38] <cradek> I bet this is an ini config thing then
[11:05:47] <cradek> (still not a gantry thing)
[11:05:52] <maximilian_h> I use g0c3600 or g0c36000 to calibrate the INPUT_SCALE for the C axis
[11:05:59] <maximilian_h> because of the gears used
[11:06:04] <seb_kuzminsky> have you looked at [DISPLAY]DEFAULT_ANGULAR_VELOCITY and friends in the ini file (assuming you're using the Axis gui)?
http://www.linuxcnc.org/docs/2.6/html/config/ini_config.html#sub:DISPLAY-section
[11:06:25] <maximilian_h> hang on, can I copy&paste my c axis here ?
[11:06:28] <seb_kuzminsky> hm, it says those are just for jogs, and i dont see an ini setting in [TRAJ] for angular velocity
[11:06:35] <seb_kuzminsky> maximilian_h: no! put it on pastebin
[11:07:27] <maximilian_h> hang on, I put it on pastebin
[11:07:59] <skunkworks> seb_kuzminsky, so - what exactly do I need?
[11:08:24] <skunkworks> (which debs)
[11:09:52] <skunkworks> there sure are alot in that directory ;)
[11:10:25] <maximilian_h> http://pastebin.com/bpXHsE1T
[11:10:31] <seb_kuzminsky> skunkworks: yeah, grab these:
[11:10:31] <maximilian_h> this is the pastebin
[11:10:43] <jepler> seb_kuzminsky: is there a timestamp in hostmot2?
[11:10:50] <seb_kuzminsky> rtai-modules-3.4-9-rtai-686-pae_3.9.260.g6394e67_i386.deb
[11:11:05] <seb_kuzminsky> linux-image-3.4-9-rtai-686-pae_3.4.55-1linuxcnc_i386.deb
[11:11:19] <seb_kuzminsky> that should do it to see if it runs and see what the latency numbers are
[11:11:27] <seb_kuzminsky> then also grab these if you want to build linuxcnc:
[11:11:40] <seb_kuzminsky> linux-headers-3.4-9-rtai-686-pae_3.4.55-1linuxcnc_i386.deb
[11:11:47] <seb_kuzminsky> linux-headers-3.4-9-common-rtai_3.4.55-1linuxcnc_i386.deb
[11:11:52] <seb_kuzminsky> i think that should do it
[11:12:04] <skunkworks> exactly what I needed - thanks
[11:12:13] <seb_kuzminsky> jepler: i dont know what you're asking
[11:12:29] <skunkworks> will the installed version of linuxcnc on the livecd work with the different kernel?
[11:12:35] <skunkworks> (wheezy)
[11:12:44] <cradek> nope
[11:12:46] <skunkworks> ok
[11:12:52] <jepler> seb_kuzminsky: Is there a free-running counter that counts up at a known speed?
[11:12:56] <seb_kuzminsky> ah
[11:12:58] <skunkworks> so if I want to run latency-test - I need to build rip
[11:13:01] <seb_kuzminsky> hm
[11:13:10] <seb_kuzminsky> skunkworks: you could run the rtai latency test
[11:13:14] <seb_kuzminsky> jepler: i dont know
[11:13:21] <seb_kuzminsky> PCW: do you know of one?
[11:13:23] <skunkworks> seb_kuzminsky, sure. ok.
[11:13:50] <seb_kuzminsky> maximilian_h: your C max vel is 660 degrees per minute, is that maybe the low speed you're seeing?
[11:14:11] <maximilian_h> no, I am seeing a vel of 60 in axis
[11:14:29] <maximilian_h> and I do not know where it is coming from
[11:14:58] <maximilian_h> axis as in axis, the gui
[11:15:00] <jepler> hm, there's this in regmap: 0x3300 TSCount 16 bit time stamp counter (read only)
[11:15:16] <jepler> 16 bits isn't much
[11:15:35] <seb_kuzminsky> doesn't the axis gui show vel in units/second mode, rather than units/minute?
[11:15:55] <jepler> (not if you wanted to replace rdtsc with a read of this register, when you have a pci hostmot2 board available)
[11:16:18] <maximilian_h> if it were in machine units per second
[11:16:30] <maximilian_h> then 60 degrees per second would be visible
[11:16:39] <seb_kuzminsky> maximilian_h: hmm, you're right
[11:16:44] <maximilian_h> however when I look at the machine
[11:16:58] <maximilian_h> than I can hardly see any change because it is sooo slow
[11:16:59] <seb_kuzminsky> try adding a [DISPLAY]DEFAULT_ANGULAR_VELOCITY
[11:17:21] <seb_kuzminsky> i really dont know what i'm doing here, sorry! never used or configured a rotary axis
[11:17:52] <cradek> maximilian_h: you might want to look at sim/axis/axis_9axis.ini as an example of correct configuration
[11:18:05] <maximilian_h> I just know that on a similar machine without the gantry these settings do work for a rotary axis
[11:18:07] <cradek> maximilian_h: there are a lot of velocity and acceleration settings :-/
[11:18:44] <maximilian_h> yes, there are. I do want my autoengineer button to automagically setup everything ;)
[11:19:23] <maximilian_h> bbl
[11:20:22] <cradek> seb_kuzminsky: it boots and runs on this laptop, and my nonfree-firmwared wifi works
[11:22:11] <cradek> it bothers me that uname -a doesn't tell me the difference between these various kernels
[11:24:29] <seb_kuzminsky> yes that bothers me too
[11:25:26] <cradek> I guess it'll be ok if we can settle on one
[11:25:33] <seb_kuzminsky> hm, on my stock wheezy machine i get this uname: Linux bifrost 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
[11:25:45] <seb_kuzminsky> for this kernel package: ii linux-image-3.2.0-4-amd64 3.2.57-3+deb7u2
[11:25:48] <cradek> interesting
[11:26:21] <cradek> (I'm building linuxcnc against it now)
[11:26:22] <seb_kuzminsky> what does uname say with these rtai kernels?
[11:27:00] <cradek> ... #1 SMP Tue Jul 8 07:38:06 UTC 2014 i686 GNU/Linux
[11:27:11] <cradek> (weird)
[11:27:33] <seb_kuzminsky> yeah
[11:27:47] <seb_kuzminsky> i guess i'm doing something wrong with the packaging, but i'm not sure what
[11:28:35] <skunkworks> seb_kuzminsky, awesome ascii art!
[11:28:56] <skunkworks> I use a similar setup for offsetting Z based on spindle temp.. works great
[11:29:52] <seb_kuzminsky> cradek: i've added it to my kernel todo list
[11:30:07] <cradek> thanks
[11:30:13] <seb_kuzminsky> skunkworks: i'm only moonlighting as a hacker until my ascii art career takes off
[11:30:18] <cradek> it's minor
[11:30:37] <cradek> the timestamp does tell us the difference, but it's stupider
[11:30:44] <cradek> I didn't even notice it as important information
[11:30:57] <skunkworks> well - sorry to tell you this.. I don't think you are ready to do ascii art full time...
[11:31:10] <seb_kuzminsky> aww, guess i'll keep hacking then
[11:31:37] <seb_kuzminsky> you guys remember aalib? it was an ascii art backend for some graphics abstraction layer back in the 90s
[11:31:45] <seb_kuzminsky> you could run text-mode screen savers and things
[11:31:52] <cradek> oh sure
[11:32:24] <seb_kuzminsky> aw yea, "apt-get install bb" and prepare to be amazed
[11:32:29] <cradek> also svgalib (why start X when you just want to view an image or something)
[11:33:06] <cradek> seb_kuzminsky: linuxcnc etc runs on your .55
[11:33:18] <seb_kuzminsky> i wrote a crappy soundcard oscilloscope app for svgalib back in like 1998
[11:33:21] <seb_kuzminsky> cradek: yay
[11:33:39] <seb_kuzminsky> if it also doesnt hork up when i plug in my wifi i say let's ship it
[11:33:48] <cradek> fuck yeah
[11:33:51] <seb_kuzminsky> i guess we should ask dgarr to try it too
[11:33:57] <cradek> oh that too :-)
[11:34:18] <cradek> email him?
[11:34:25] <seb_kuzminsky> this search for a working rtai has been demoralizing - i'm now using a revision that's not in shabby's repo any more :-/
[11:34:48] <jepler> working on kernel/rtai is easily the most demoralizing part of a new port
[11:34:55] <cradek> the sun'll come up tomorrow, bet your bottom dollar
[11:35:07] <cradek> (-rt is a nice promising thing)
[11:35:18] <seb_kuzminsky> yes
[11:35:32] <seb_kuzminsky> that's a breath of fresh air after this dank dungeon
[11:35:45] <seb_kuzminsky> i'll mail dgarr
[11:35:50] <jepler> that's why I squashed all the uspace stuff to a single commit with the message "gmoppaco 1_5_37" and pushed it all to the 2.6 branch last night.
[11:36:11] <seb_kuzminsky> also push it to 2.5 and master and all other branches you can find
[11:36:21] <jepler> uhhh I Figured I'd merge 2.6 to 2.5
[11:36:41] * seb_kuzminsky goes to $DAYJOB
[11:36:46] <jepler> see ya
[11:36:57] <seb_kuzminsky> laters
[11:37:32] <skunkworks> you guyzz
[11:38:28] <cradek> yeah, be nice
[12:38:36] <seb_kuzminsky> http://lwn.net/Articles/604695/rss
[13:04:01] <skunkworks> depressing
[13:07:55] <CaptHindsight> is there an open version of QNX? (ducks)
[13:50:10] <jepler> too bad we don't have a briefcase of hundred dollar bills to send 'em
[13:50:19] <jepler> (rt-preempt guy, not qnx)
[13:53:38] <CaptHindsight> xenomai seems to be in most commercial products
[13:54:07] <pcw_home> or rtlinux
[13:55:17] <CaptHindsight> http://www.sysgo.com/ uses xenomai
[13:58:28] <pcw_home> labview uses preemt-rt AFAIK
[13:58:49] <skunkworks> labfiew is linux?
[13:59:18] <pcw_home> labview remote CPU/FPGA - Zynq pods are
[13:59:40] <skunkworks> heh
[13:59:48] <skunkworks> neat
[14:01:49] <CaptHindsight> none of their profits must make it back to the _rt devs
[16:33:25] <dgarr> seb_kuzminsky:
http://www.panix.com/~dgarrett/stuff/07jul14.txt (amd machine, similar Oops)
[16:35:21] <cradek> jepler's suggestion was that we fix rtai to not break on this hardware
[16:35:38] <cradek> it's not a kernel version problem
[16:35:57] <seb_kuzminsky> dgarr: thanks for that
[16:36:16] <seb_kuzminsky> dgarr: can you confirm/deny that the old 3.4.55 kernel worked on that hardware (it had a different version of the rtai patch)
[16:37:01] <dgarr> what i remember is thre 3.4.55 kernel i tried earlier the ps/2 mouse did not work and i stopped at that
[16:37:09] <seb_kuzminsky> hmm
[16:37:36] <seb_kuzminsky> ok, last night i built new kernel debs with the 3.4.55 kernel and the old rtai patch, but a new kernel config that should have working ps/2
[16:37:57] <seb_kuzminsky> i sent you the link, can you try it if possible & report back?
[16:38:06] <seb_kuzminsky> i have high hopes
[16:38:18] <dgarr> i am reporting based on that link
[16:38:34] <dgarr> please make sure my log info confirms i am doing it correctly
[16:38:41] <seb_kuzminsky> the installed linux-image version in the page you just linked above says 3.4.87
[16:40:51] <dgarr> so i need to download a deb instead of using synaptic?
[16:41:17] <cradek> the problem may be that it's actually a downgrade in version number
[16:41:29] <seb_kuzminsky> i think you can do it with synaptic, but you need to add that "deb
http://highlab.com..." line to your sources.list
[16:41:39] <cradek> I used apt-get to install it, after fixing sources.list, and uninstalling the old one
[16:42:02] <cradek> I rebooted to a non-rtai kernel and uninstalled all the rtai kernel packages and rtai-modules
[16:42:04] <seb_kuzminsky> cradek: that's how i usually do it too
[16:42:10] <dgarr> i have deb
http://highlab.com/~seb/linuxcnc/rtai-debs wheezy main
[16:42:17] <seb_kuzminsky> that's good
[16:42:40] <seb_kuzminsky> what kernels do you have installed? look in /boot or "dpkg -l 'linux-image*' | grep ^ii"
[16:43:40] <dgarr> i just reloaded in synaptic, it only shows 87
[16:43:53] <seb_kuzminsky> ok, cool
[16:44:20] <seb_kuzminsky> in a terminal, run 'apt-get update'
[16:44:22] <dgarr> am i supposed to install the 3.4.96 ones? i can try that with the debs
[16:44:39] <seb_kuzminsky> you see the .96 ones?
[16:45:18] <seb_kuzminsky> they shouldn't be available any more, i removed them when they crashed my problematic test machine
[16:45:43] <seb_kuzminsky> you should see linux-image-3.4-9-rtai-686-pae with version 3.4.55-1linuxcnc
[16:45:48] <seb_kuzminsky> that's the one i'd like you to test
[16:46:02] <dgarr> i've done the apt-get update several times 96 doesn't appear, i am using /etc/apt/sources.list.d/linuxcnc.list
[16:46:14] <seb_kuzminsky> after the 'apt-get update', try 'apt-cache policy linux-image-3.4-9-rtai-686-pae'
[16:46:22] <seb_kuzminsky> you should see 3.4.87 and 3.4.55
[16:46:34] <seb_kuzminsky> with the 3.4.87 one marked as installed
[16:47:04] <seb_kuzminsky> then say "apt-get install linux-image-3.4-9-rtai-686-pae=3.4.55-1linuxcnc"
[16:47:18] <seb_kuzminsky> it'll complain about downgrading the package and about uninstalling the running kernel, but i think it should work
[16:48:32] <dgarr> apt-cache policy shows 3.4.55-1linuxcnc 0 -- i guess i don't know how to install it
[16:48:50] <seb_kuzminsky> dgarr: the "apt-get install" line above should do it ^^^^^
[16:50:21] <dgarr> ok that started, will i need any other updates like headers to build linuxcnc?
[16:50:57] <seb_kuzminsky> yes, although you can crash the machine by just running the rtai latency test, right?
[16:53:19] <dgarr> i wouldn't call it a crash but /usr/realtime*/testsuite/kern/latency/run hasn't worked yet with 3.4.x kernels seems a good indicator of linuxcnc problem
[16:53:34] <dgarr> i'll reboot that machine and try the testsuite latency
[16:53:38] <seb_kuzminsky> thank you
[16:57:33] <seb_kuzminsky> hmm, my kernel config changes didn't work in the 3.4.55 image :-(
[16:58:58] <seb_kuzminsky> because i'm an idiot, hold on
[17:00:00] <seb_kuzminsky> but it should still be good enough to test dgarr's machine
[17:00:11] <seb_kuzminsky> welcome back!
[17:00:56] <dgarr> http://www.panix.com/~dgarrett/stuff/07jul14_b.txt
[17:01:31] <seb_kuzminsky> ok, that's not bad
[17:01:36] <seb_kuzminsky> you need the new rtai-modules deb too
[17:02:06] <seb_kuzminsky> apt-get install rtai-modules-3.4-9-rtai-686-pae=3.9.260.g6394e67
[17:02:22] <cradek> it would be nice if you could use depends to tie those versions together
[17:02:26] <seb_kuzminsky> (this will all be easier when/if we find a version that works)
[17:02:33] <cradek> heh yeah
[17:02:42] <seb_kuzminsky> cradek: yeah...
[17:03:47] <seb_kuzminsky> once we have something that's not patently ridiculous, fixing annoyances like that will be fun and easy
[17:03:53] * seb_kuzminsky is whistling past the graveyard
[17:04:24] <cradek> haha
[17:04:28] <dgarr> i did the apt-get install rtai-modules... and it says: rtai-modules-3.4-9-rtai-686-pae is already the newest version
[17:04:34] <seb_kuzminsky> hrm
[17:04:43] * seb_kuzminsky sighs
[17:04:50] <seb_kuzminsky> i might have reused the version number by mistake
[17:04:53] <seb_kuzminsky> try this:
[17:05:03] <seb_kuzminsky> dpkg --purge rtai-modules-3.4-9-rtai-686-pae
[17:05:05] <seb_kuzminsky> apt-get clean
[17:05:11] <seb_kuzminsky> then the apt-get install again...
[17:05:57] <seb_kuzminsky> ah, or 'apt-get install --reinstall rtai-modules-3.4-9-rtai-686-pae'
[17:07:18] <dgarr> tried both ways , still Invalid module format is a reboot required?
[17:07:25] <seb_kuzminsky> no
[17:07:30] <seb_kuzminsky> hm
[17:07:43] <seb_kuzminsky> i probably messed up the rtai package somehow
[17:07:48] <seb_kuzminsky> sorry to have you waste your time
[17:07:53] <seb_kuzminsky> hold on
[17:08:43] <dgarr> this is all very confusing to me with versions and dash numbers, i would be most comfortable with installing directly from a list of debs
[17:09:09] <seb_kuzminsky> yes, it's a mess, sorry
[17:10:05] <seb_kuzminsky> the versions of rtai that i'm trying to package all have different kinds of problems, so i'm having to jump around in their git tree to try to find something that works, and that makes for non-intuitive version numbers
[17:10:31] <seb_kuzminsky> once we find something that's good i'll remove all the broken ones we've tried and it'll be much more straight-forward frmo there
[17:10:55] <seb_kuzminsky> your testing work is helping make that happen
[17:11:51] <dgarr> not complaining -- just not familiar with all the apt commands
[17:20:51] <jepler> hm, I seem to be hitting a bug. I wonder if it's uspace or hm2_eth.
[17:21:03] <jepler> pin 7 is listed as a GPIO, and I've set its .is_output to true
[17:21:24] <jepler> setting .out to 1 or 0 doesn't change the attached blinkenlight, but setting .invert_output to 1 or 0 does
[17:22:01] <micges-dev> what board what bitfile?
[17:22:54] <jepler> micges-dev: 7i80, whatever bitfile was on it when shipped
[17:23:21] <micges-dev> check sticker on board
[17:23:28] <jepler> I see that the invert is actually separate from the gpio output
[17:24:13] <jepler> no sticker seems to identify the firmware.
[17:26:19] <jepler> setting .pwmgen.00.enable to 1/0 changes the state of pins 1 and 47
[17:26:29] <jepler> that is, P1-1 and P1-47
[17:28:41] <skunkworks_> you would have to use mesaflash to check the firmware
[17:29:14] <jepler> besides the enable outputs of pwmgen toggling, I also don't see any LEDs with the pwm value
[17:30:38] <micges-dev> jepler: please clone latest mesaflash:
https://github.com/micges/mesaflash
[17:31:21] <micges-dev> then try: ./mesaflash --device 7i80 --addr n.n.n.n --readhmid
[17:32:59] <skunkworks_> jepler: you probably want to set the gpio as open collector..
[17:33:14] <jepler> how delightful, it segfaults
[17:33:30] <jepler> more later
[17:37:33] <PCW> yeah the readhmid option is still buggy
[17:37:58] <skunkworks_> I have only been running stepgens in 7i80 - I surely can test some i/o
[17:38:37] <PCW> I know sserial works
[17:39:39] <skunkworks_> jepler: if you just have an led plugged in - it will be lit...
[17:40:17] <skunkworks_> setting the gpio to open collector makes it act correctly
[17:42:11] <jepler> skunkworks_: this is one of those 7i31 daughterboards with a pile of LEDs
[17:42:27] <jepler> the LEDs will toggle on/off if I change the .invert_output of the (should be) GPIO
[17:43:58] <micges-dev> PCW: on which board and firmware --readhmid can't handle it? should works with all boards from about 2 months
[17:44:30] <micges-dev> PCW: I've tested all my boards then
[17:45:01] <jepler> Program received signal SIGSEGV, Segmentation fault.
[17:45:09] <jepler> #1 0x000000000040d606 in pin_get_pin_name (pin=0x646c88) at hostmot2.c:476
[17:45:12] <jepler> 476 sprintf(buff, "%s", pin_names[i].name[(pin->sec_pin & 0x0F) - 1]);
[17:45:15] <jepler> (gdb) p *pin
[17:45:18] <jepler> $4 = {sec_pin = 0 '\000', sec_tag = 0 '\000', sec_chan = 0 '\000', gtag = 3 '\003'}
[17:45:59] <jepler> it looks like to me it's trying to read name[-1], since pin->sec_pin is 0 here
[17:46:09] <jepler> micges-dev: this is a 64-bit machine, it could be related
[17:46:13] <micges-dev> jepler: hold on
[17:46:56] <jepler> this happens just as it starts to print "IO Connections for P2"
[17:47:01] <micges-dev> jepler: sorry my bad, I left last few commits locally
[17:47:10] <micges-dev> try pull again now
[17:47:26] <jepler> now it finishes
[17:47:44] <micges-dev> good
[17:48:22] <jepler> it has PWM & MuxQ on P1, GPIO on P2, sserial on P3
[17:50:12] <jepler> so .. whatever firmware that is
[17:50:20] <micges-dev> jepler: what firmware version in ./mesaflash --device 7i80 --addr n.n.n.n --verbose ?
[17:51:05] <jepler> LBP16 protocol version 3
[17:51:07] <jepler> board firmware version 14
[17:51:48] <PCW> svsss6_8
[17:52:11] <jepler> thread order is pet / read / write -- is that OK?
[17:52:42] <jepler> period is 1ms
[17:52:45] <PCW> hmm GPIO works for me (just tested with 7I76E)
[17:52:52] <seb_kuzminsky> dgarr: ok, i rebuilt the rtai-modules package against the new kernel headers
[17:53:14] <seb_kuzminsky> try it now: sudo apt-get update && apt-get install --reinstall rtai-modules-3.4-9-rtai-686-pae
[17:53:47] <micges-dev> jepler: I wonder if 64 bits aren't a problem
[17:53:54] <jepler> I've got a ribbon cable from 7i80 P2 to Mesa 7i31. I haven't touched voltage jumpers.
[17:54:09] <jepler> interactively, this changes an LED status (of LED identified "IO0")
[17:54:10] <jepler> halcmd: setp hm2_7i80.0.gpio.024.is_output 1
[17:54:11] <jepler> halcmd: setp hm2_7i80.0.gpio.024.invert_output 1
[17:54:12] <jepler> halcmd: setp hm2_7i80.0.gpio.024.invert_output 0
[17:54:23] <jepler> but this doesn't:
[17:54:24] <jepler> halcmd: setp hm2_7i80.0.gpio.024.out 1
[17:54:26] <jepler> halcmd: setp hm2_7i80.0.gpio.024.out 0
[17:54:54] <jepler> is_opendrain also has no discernable effect
[17:55:22] <jepler> PCW: running ubc3 hm2-eth or usapce hm2-eth?
[17:57:55] <PCW> I am running uspace-hm2-eth
[18:05:19] <jepler> I'll troubleshoot further later. time to make dinner.
[18:06:16] <dgarr> seb_kuzminsky: --still rtai_hal.ko: Invalid module format
[18:09:23] <seb_kuzminsky> hm, it works on my machine
[18:09:49] <seb_kuzminsky> what does 'uname -a' and 'dpkg -s rtai-modules-3.4-9-rtai-686-rtai | grep Vers' say
[18:09:52] <seb_kuzminsky> ?
[18:10:27] <dgarr> ii linux-image-3.4-9-rtai-686-pae 3.4.55-1linuxcnc
[18:10:28] <dgarr> ii rtai-modules-3.4-9-rtai-686-pae 3.9.260.g6394e67
[18:10:28] <dgarr> uname -a: Linux shop-debian 3.4-9-rtai-686-pae #1 SMP Tue Jul 8 07:38:06 UTC 2014 i686 GNU/Linux
[18:10:57] <seb_kuzminsky> hmm, the kernel looks right
[18:11:25] <seb_kuzminsky> do you get this:
[18:11:26] <seb_kuzminsky> 0 16:52:57 seb@debian-7-i386 /usr/realtime-3.4-9-rtai-686-pae/modules> md5sum rtai_hal.ko
[18:11:29] <seb_kuzminsky> 4b1180b9ddd696e1fd8548dabfbc8690 rtai_hal.ko
[18:12:29] <dgarr> c89e22f73998f1280715219afbc4d0fb rtai_hal.ko
[18:12:34] <seb_kuzminsky> that's the problem
[18:13:02] <seb_kuzminsky> try: apt-get clean
[18:13:04] <seb_kuzminsky> apt-get update
[18:13:12] <seb_kuzminsky> apt-get install --reinstall rtai-modules-3.4-9-rtai-686-pae
[18:13:34] <seb_kuzminsky> i bet there was a cached copy of the old rtai-modules somewhere, those commands should clear it out and get the new one
[18:13:41] <seb_kuzminsky> no reboot needed, try the rtai latency test
[18:13:52] * seb_kuzminsky starts biting his nails
[18:15:29] <PCW> jepler works for me (toggling bit 24 on a 7I80hd-16 with setp the .out pin true/false)
[18:16:15] <dgarr> the md5sum not changed (still c89e...fb), still invalid module format
[18:17:56] <seb_kuzminsky> bizarre
[18:18:32] <dgarr> ok i just downloaded the deb and used dpkg to install it and the testsuite latency test works
[18:18:51] <dgarr> this is why i thing working from debs is easier than apt -stuff
[18:19:45] <seb_kuzminsky> oh!
[18:19:47] <seb_kuzminsky> wow
[18:19:55] <seb_kuzminsky> and it didnt crash or anything? that's new right?
[18:20:39] <seb_kuzminsky> your machine can run the 3.4.55-1linuxcnc ltency test, whereas it couldnt run the 3.4.87 or the 3.4.96 ones without crashing?
[18:20:41] <dgarr> this is first time testsuite latency test works
[18:20:48] <seb_kuzminsky> hahahahahahahahHAHAHAHAHAHAHAHAHAHAHAH
[18:21:04] <seb_kuzminsky> http://www.troll.me/2014/07/08/i-would-be-so-happy/if-dgarrs-machine-doesn/
[18:21:13] <seb_kuzminsky> yay
[18:21:24] <seb_kuzminsky> i feel like i should smoke a cigarette
[18:22:46] <micges-dev> PCW: if it's hm2_eth problem I feel 64 bits are the root of it
[18:23:15] <PCW> maybe pretty sure I'm running 32 bits
[18:23:27] <dgarr> so the testsuite latency started, i try linuxcnc ../configs/sim/axis/axis.ini and get
[18:23:28] <dgarr> Error: could not insert module /data/git_debian_rtai/emc2-dev/rtlib/rtapi.ko: Invalid module format
[18:23:57] <seb_kuzminsky> you'll have to use your wget-fu (or apt) to get the matching linux-headers, and recompile linuxcnc, and then i bet it'll work
[18:24:23] <seb_kuzminsky> btw i checked the web server logs and i never saw you download rtai-modules via apt-get, so i dont think the 'apt-get install --reinstall' did what i hoped it would
[18:24:28] <seb_kuzminsky> i saw you get it with wget though
[18:24:37] <seb_kuzminsky> you are 184.101.147.237, right?
[18:24:57] <dgarr> ..237 yes
[18:25:50] <PCW> micges-dev, I duplicated the external hardware (7I80HD-16) and config and its OK for me
[18:26:27] <seb_kuzminsky> dgarr: so i saw you 'apt-get update' but not 'apt-get install'
[18:26:33] <seb_kuzminsky> oh well, shrug
[18:26:41] <micges-dev> PCW: duplicated from jepler's setup?
[18:26:58] <cradek> yayyy
[18:27:28] <seb_kuzminsky> i'll try it on my troubled machine at home tonight, and we'll keep our eyes open for new failures with this kernel, but i got a good feeling about this
[18:27:52] <seb_kuzminsky> and cradek, i think i fixed the uname bug you reported
[18:27:57] <cradek> that's terrific
[18:28:04] <cradek> let me know when I can rebuild the live image
[18:28:12] <cradek> that sure makes it easy for me to test hardware I see laying around
[18:28:19] <seb_kuzminsky> building a new one one, it only takes ~ 1e20 hours
[18:28:21] <jepler> if I don't turn up something here, I'll get a 32-bit install and see if that "fixes" it
[18:28:38] <PCW> micges-dev: same hardware and config (different OS though)
[18:28:46] <micges-dev> ok
[18:28:57] <cradek> jepler: oh I see you have a new problem - hmm
[18:29:52] <jepler> cradek: it's nothing to do with the rtai stuff
[18:30:17] <micges-dev> PCW: --readhmid was detecting latest pins configuration properly from about may, only up to now mf had problem with pins with sec_tag == 0
[18:30:28] <PCW> I guess it could be some weird hal file issue
[18:30:30] <PCW> I used hm2-servo.hal and a ini file with just num-encoders=6 (and the appropriate ethernet foo)
[18:30:30] <micges-dev> PCW: already fixed in repo
[18:31:05] <cradek> jepler: oh good
[18:31:05] <jepler> I'm just halrun'ing a simple hal file
[18:31:06] <jepler> loadrt hm2_eth config="num_encoders=0 num_pwmgens=0 num_stepgens=0" board_ip=192.168.1.121 board_mac=00:60:1b;11:80:37
[18:31:17] <jepler> and add some functions to threads, then drop into interactive halcmd to do tsuff
[18:31:22] <jepler> s/tsuff/stuff/
[18:31:28] <PCW> OK thats it first "none" secondary function = BLAMMO
[18:32:11] <PCW> let me try that
[18:33:22] <jepler> the mesaflash problem is resolved for me with micges's earlier push
[18:38:27] <skunkworks_> cradek: makes it easy for me to test hardware also :)
[18:39:45] <micges-dev> PCW: did you update any zip file with bitfiles with ICAP support?
[18:42:39] <PCW> Yes I did but had a (unrelated) mistake so they are all bad... rebuilding today
[18:43:01] <PCW> takes about a day to make all
[18:43:09] <micges-dev> eww
[18:43:31] <micges-dev> you didn't setup buildbot to test them all ;)
[18:44:02] <PCW> wrong stride1 (I really need to put that in the pinout file)
[18:44:29] <seb_kuzminsky> PCW: once all the current fires are put out and 2.6 is out the door, we should think about the hm2-buildbot again
[18:45:09] <PCW> yeah once 2.6 is just a memory...
[18:45:37] <seb_kuzminsky> cradek: 0 17:27:07 seb@debian-7-i386 /home/seb> uname -a
[18:45:38] <seb_kuzminsky> Linux debian-7-i386 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-0linuxcnc i686 GNU/Linux
[18:45:50] <cradek> that's a beautiful work of art
[18:46:05] <seb_kuzminsky> (i made this one a downgrade deliberately for once, i'll rebuild it with an upgradeable version number and we're off to the races)
[18:46:24] <cradek> eh, just delete the others
[18:46:34] <cradek> push it to wlo, build 2.6, bang, done
[18:46:39] <seb_kuzminsky> heh
[18:46:51] <seb_kuzminsky> heh oh wait he's right, we're there!
[18:46:58] <seb_kuzminsky> bbl
[18:47:07] <PCW> jepler: so I tried with config="num_encoders=0 num_pwmgens=0 num_stepgens=0" and its still OK
[18:47:07] <cradek> (?)
[18:47:55] <PCW> so may be a 64 bit issue
[19:03:02] <seb_kuzminsky> skunkworks_: my notes say usb is broken on a machine of yours, with the rtai kernels (don't know what version
[19:03:32] <seb_kuzminsky> would you try 3.4.55-1linuxcnc and see if it's fixed?
[19:04:02] <micges-dev> skunkworks_: on what system you have usb broken?
[19:27:36] <cradek> I don't approve of skunkworks_ not being here and testing right away
[19:28:56] <jepler> So when I command gpio 24 to be a true output, I get 83 c2 00 10 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
[19:29:06] <jepler> (dunno if I wrote the right number of 00s)
[19:29:47] <jepler> since I know at address 0x1000 is where GPIOs start, according to 7i80hdman.pdf
[19:46:03] <PCW> that looks right C283 is write 3 doublewords to hm2space and inc the address after each one
[19:47:09] <PCW> well lsB first
[19:48:27] <skunkworks_> seb_kuzminsky: what ever rtai that is on the wheezy livecd.
[19:48:41] <skunkworks_> when I get a chance I will test the your new kernel
[19:48:48] <skunkworks_> old kernel - or whatever ;)
[19:49:15] <skunkworks_> it is a GA-j1800-mumblemumble
[19:49:21] <cradek> skunkworks_: had you previously run 3.4.55 on it successfully?
[19:57:28] <PCW> actually should be
[19:57:29] <PCW> 83 c2 00 10 00 00 00 00 01 00 00 00 00 00 00 00
[19:58:07] <jepler> I probably transcribed it wrong, it's not cut and pasted
[20:01:24] <PCW> same hardware/config works here so a bit mysterious
[20:02:28] <jepler> I'm trying to read the "alt source reg"
[20:02:38] <jepler> 83 42 00 12
[20:02:42] <jepler> it reads back all ffs
[20:02:44] <PCW> not readable
[20:02:48] <jepler> oh
[20:02:50] <jepler> OK
[20:02:54] <PCW> the ddr register is though
[20:03:41] <PCW> @ 0x110X
[20:04:19] <PCW> and theres always the cookie at 0x0100
[20:04:57] <jepler> I can read that
[20:10:16] <PCW> so 83 42 0011
[20:10:18] <PCW> will read all three DDR registers (which should be 24 bits of right aligned 0s and startup or wd bite)
[20:11:02] <PCW> (well 3 32 bit words each with 24 bits of 0's)
[20:12:15] <CaptHindsight> where is the new 3.4.87 rtai kernel posted?
[20:13:38] <cradek> the new one is a rebuilt 3.4.55
[20:14:22] <cradek> the older 87 with known problems is at www.linuxcnc.org wheezy base
[20:14:36] <CaptHindsight> thanks
[20:18:43] <jepler> somehow the I/O pins are numbered wrong
[20:19:13] <jepler> 024.is_output / invert_output and 000.out all affect the same LED
[20:19:25] <jepler> 024.out doesn't seem to affect anything
[20:27:06] <jepler> 024.out seems to control a pin on port p3
[20:29:03] <jepler> 20:09:18.764255 IP rat.local.53803 > 192.168.1.121.27181: UDP, length 20
[20:29:04] <jepler> 0x0000: 4500 0030 e68b 4000 4011 d066 c0a8 0101
[20:29:05] <jepler> 0x0010: c0a8 0179 d22b 6a2d 001c 83f8 83c2 0010
[20:29:06] <jepler> 0x0020: 0000 0000 0200 0000 0200 0000 0000 0000
[20:29:40] <jepler> looks like linuxcnc is transmitting the wrong packet
[20:31:40] <jepler> (that's with gpio 001 and 025.out set to true according to hal)
[20:31:48] <seb_kuzminsky> CaptHindsight: get version 3.4.55-0linuxcnc from here:
[20:31:51] <seb_kuzminsky> deb
http://highlab.com/~seb/linuxcnc/rtai-debs precise main
[20:32:09] <seb_kuzminsky> (typing this via wifi from the machine that crashed with 3.4.87 and 3.4.96)
[20:32:21] <seb_kuzminsky> so: so far so good, let's see what skunkworks says
[20:32:38] <CaptHindsight> I was just looking at that repo, thanks
[20:33:29] <cradek> oh it fixes yours too - yay
[20:42:58] <jepler> yay, found the error
[20:43:46] <jepler> lbp16_cmd_addr *packet; ... write_packet_ptr += sizeof(packet);
[20:43:51] <jepler> lbp16_cmd_addr is 4 bytes
[20:44:08] <jepler> but a pointer-to-lpb16_cmd_addr is 8 bytes on x86_64
[20:45:44] <jepler> yay, fixed the pwmgen problem too
[20:45:51] <jepler> now it's perfect
[20:56:50] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/rtos-uspace-hm2-eth fcefbfb 06linuxcnc 10(6 files in 2 dirs) Add support for mesanet ethernet UDP boards 7i80 and 7i76E * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fcefbfb
[20:56:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-hm2-eth c7ac7d6 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_test.c hm2_test: Don't crash on test case 12 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c7ac7d6
[20:56:50] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/rtos-uspace-hm2-eth 6278896 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add more data to debug output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6278896
[20:56:52] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/rtos-uspace-hm2-eth 717f816 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add retry with timeout to enqueue_read() to make sure that all requested data will be readed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=717f816
[20:56:56] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/rtos-uspace-hm2-eth 2698a02 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: read watchdog with same packet like rest of data from board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2698a02
[20:57:02] <KGB-linuxcnc> 03Michael Geszkiewicz 05jepler/rtos-uspace-hm2-eth 1bfa4a3 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: enable debug logging in enqueue_write function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1bfa4a3
[20:57:06] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-hm2-eth 20f546d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: fix 64-bit build error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=20f546d
[20:57:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-hm2-eth 17de976 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2-eth: take the size of the structure, not size of address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17de976
[21:00:58] <skunkworks_> jepler: nice!
[21:12:48] <dgarr> i think the reason apt-get install --reinstall mishaps were caused because i had multiple lines that could find rtai-modules-3.4-9-rtai-686-pae
[21:16:18] <dgarr> apt-cache policy rtai-modules-3.4-9-rtai-686-pae shows two places for 3.9.260.g6394e67:
[21:16:44] <dgarr> 1) 500
http://linuxcnc.org/ wheezy/base i386 Packages 2)500
http://highlab.com/~seb/linuxcnc/rtai-debs/ wheezy/main i386 Packages
[21:18:48] <dgarr> i got linux-headers from debs and built linuxcnc 2.6 without errors but it will not run, at insmod rtai_hal machine becomes unresponsive
[21:22:08] <cradek> yuck
[21:26:30] <dgarr> some notes:
http://www.panix.com/~dgarrett/stuff/07jul14_b.txt i'm not sure this old amd machine is worth the trouble
[21:27:06] <cradek> it may represent many others
[21:29:26] <cradek> I don't think I see anything you did wrong... what a weird hang.
[21:32:44] <dgarr> i just repeated insmod ../rtai_hal.ko, it didn't hang right way, top wouldn't start; rmmod rtai_hal, top works -- it is weird
[21:33:07] <cradek> no oopses in dmesg?
[21:38:34] <dgarr> nil no clues in dmesg
[21:38:46] <seb_kuzminsky> dgarr: did you make clean? it might not notice the new kernel headers right?
[21:38:59] <dgarr> yes clean
[21:42:24] <seb_kuzminsky> well shit
[21:43:33] <cradek> (new live image boots and runs in qemu, rtai latency test works)
[21:43:48] <seb_kuzminsky> with 3.4.55-0linuxcnc?
[21:44:24] <cradek> I think it's called 3.4.55-1linuxcnc
[21:45:07] <seb_kuzminsky> that one's no good, i goofed the kernel config
[21:45:18] <cradek> doh
[21:45:32] <cradek> that's what apt gave me when I pointed to your highlab repo
[21:45:33] <seb_kuzminsky> let me build a -2linuxcnc nice and fresh, hold on a few hours
[21:45:39] <seb_kuzminsky> yes...
[21:45:43] * seb_kuzminsky hides in shame
[21:45:47] <cradek> haha
[21:45:51] <cradek> this is getting silly
[21:45:55] <dgarr> latest test: hang didn't occur with: realtime start returned (no hang), but now realtime stop seems to hang trying to rmmod rtai_sched
[21:46:11] <seb_kuzminsky> that's crazy
[21:46:17] <seb_kuzminsky> how does memtest86 run on that machine?
[21:46:52] <cradek> does memtest86 use pae? that's another very big difference between these and the lucid kernel
[21:47:44] <dgarr> i don't know , will try and report back, I ran this machine yesterday (cutting) for more than 8 hours using vmlinuz-2.6.32-122-rtai
[21:47:44] <seb_kuzminsky> i have a non-pae kernel too, but i haven't been testing it
[21:47:59] <seb_kuzminsky> ok, that's a pretty good indication that the hardware is sound...
[21:48:28] <cradek> dgarr: does it have more than 2G of ram?
[21:59:53] <cradek> seb_kuzminsky: when I downgrade from 1linuxcnc to 0linuxcnc, do I need to do anything about the rtai-modules?
[22:00:22] <cradek> heh it suggests debian-kernel-handbook
[22:01:28] <cradek> aha this one has the fixed uname
[22:01:30] <cradek> awesome
[22:02:01] <cradek> yeah it won't run with these modules
[22:02:48] <dgarr> 1.5 G ram i think
[22:03:38] <cradek> hm neither of the rtai-modules packages available on highlab work for me with 3.4.55-0linuxcnc
[22:04:11] <cradek> I tried 3.9.246.g75d and 3.9.260.g639 (the one dgarr has)
[22:04:35] <cradek> both say rtai_hal: disagrees about version of symbol module_layout
[22:04:51] <cradek> ... when I try to start testsuite/kern/latency
[22:55:56] <skunkworks__> so I was going to test the debs but they seem to be missing now here
http://highlab.com/~seb/linuxcnc/rtai-debs/dists/
[23:21:02] <cradek> hmm yes they are.
[23:21:28] <cradek> he started a new one building and may have removed all the broken ones so it's sane when done.
[23:23:11] <skunkworks_> sounds good - I will test tomorrow
[23:23:15] <skunkworks_> night
