Back
[00:00:04] <jmkasunich> when you run the drive in vel loop mode, what does it use for velocity feedback?
[00:00:13] <jmkasunich> (if not the encoder)
[00:00:18] <petev> it uses the encoders, but does the calcs internal
[00:00:34] <petev> you can't get vel on the external encoder interface as far as I can tell
[00:00:40] <petev> you can get it on an analog out pin
[00:00:45] <jmkasunich> thats totally irrelevant to my point
[00:01:04] <petev> I guess I'm missing your point
[00:01:08] <jmkasunich> I said "your drives have vel loops in the drive, using encoder for vel fb, don't they?"
[00:01:39] <petev> not exactly sure what you're asking, they use a position encoder for feedback in all modes
[00:01:45] <jmkasunich> the mazak drives don't see the encoder signals, so their velocity loops use armature voltage (counter-emf) as the velocity feedback
[00:01:48] <petev> and the drive calcs the vel from the position
[00:01:59] <petev> I see
[00:02:09] <jmkasunich> right, and then it uses the calced vel for feedback
[00:02:19] <petev> yes, internally
[00:02:36] <petev> it has another encoder out interface that the external controller uses
[00:03:01] <petev> but that's the same info as on the encoder in, with a possible scaling
[00:03:47] <jmkasunich> this conversation has gotten out in left field
[00:03:54] <jmkasunich> you said: from the numbers I'm getting now, I'm wondering if the Mazak drives weren't in torque mode?
[00:04:01] <petev> yes
[00:04:17] <petev> the new numbers are much less than what the mazak is using
[00:04:33] <petev> and I think they were that high to overcome the loss from the low pass filter
[00:04:37] <jmkasunich> and I mentioned what I knew about the mazak drives, and that the AB drives can actually close the vel loop with real vel feedback from the encoders
[00:04:53] <jmkasunich> if you go higher it gets unstable?
[00:05:09] <petev> more P and it will oscillate
[00:05:15] <petev> more D and it's way over damped
[00:05:17] <jmkasunich> tried any I?
[00:05:33] <petev> ideal D is less than one for nice damping
[00:05:45] <petev> yes, I have I about 150 now, P at 200
[00:05:51] <petev> more I and I see overshoot
[00:06:00] <petev> but this may be it winding up
[00:06:16] <petev> I think it could still use more I if I enable the limitter
[00:06:27] <petev> as it seems to take too long to make the final pos correction
[00:06:31] <jmkasunich> cradek: "num_online_cpus()" ?
[00:06:36] <jmkasunich> maybe that is the key
[00:06:48] <petev> but all this is still in tenths, so it's very good now
[00:07:13] <petev> and the step response to the same step is down to about 20 msec from 50-60
[00:07:51] <petev> and it does home without problem now too
[00:08:41] <petev> when the pid output was oscillating really badly the drive could never match the correct vel and would often give a vel following fault as well
[00:09:10] <jmkasunich> there's a reason why I always do things from the bottom up
[00:09:27] <petev> point taken
[00:09:40] <petev> at least it's behaving like I would expect now
[00:10:12] <jmkasunich> cradek: num_online_cpus is a normal linux kernel thing (not rtai), added in kernel 2.6
[00:10:29] <jmkasunich> so, if 2.6, call num_online_cpus, if > 0, set code to run on 1, else run on 0
[00:10:37] <jmkasunich> seem reasonable?
[00:10:48] <petev> does linux have processor affinity for SMP?
[00:11:14] <jmkasunich> it can
[00:11:30] <jmkasunich> I think its a kernel option, cradek knows more than I, he must have stepped away
[00:11:32] <petev> are you seeing issues when you let the scheduler decide?
[00:11:38] <jmkasunich> no
[00:11:50] <petev> just trying to improve RT response?
[00:12:01] <jmkasunich> rtapi (our wrapper layer) alway runs RT code on CPU 0, for portability on uni and smp
[00:12:31] <jmkasunich> but cradek found (I think) that linux can be told to run the users stuff on 0, leaving 1 free, but not vice-versa
[00:12:37] <petev> why not let the scheduler decide, or does the RT scheduler have to knowledge of the other tasks?
[00:12:44] <jmkasunich> so for best smp perfomance, we should run RT on cpu 1
[00:12:48] <petev> oh, that would be nice
[00:12:54] <petev> on core dedicated to RT
[00:13:14] <jmkasunich> yep
[00:13:24] <jmkasunich> cradek got good latency numbers that way
[00:13:35] <jmkasunich> I saw a very strange result on my core duo system
[00:13:44] <petev> yes, I bet they were pretty good
[00:13:52] <petev> no crusty linux driver ISRs in the way
[00:14:08] <jmkasunich> latency dropped a lot, when I ran an endless loop in userspace
[00:14:27] <jmkasunich> from 16uS to less than 4uS
[00:14:46] <petev> 16 isn't bad, 4 is pretty good
[00:15:02] <jmkasunich> while true ; do echo "foo" >/dev/null ; done is all it takes to make it work better
[00:15:10] <jmkasunich> not what I would have expected at all
[00:15:21] <jmkasunich> I even niced that shell down to 19, and it still works
[00:15:23] <petev> that does seem a bit strange
[00:15:39] <petev> you would think the idle task would just run with the same results
[00:15:58] <petev> what does the idle task do in linux?
[00:16:00] <jmkasunich> my speculation is that the idle task puts the CPU into a halt or power-saving state, and it takes time to come out of that
[00:16:08] <jmkasunich> I have no idea what it really does
[00:16:10] <petev> maybe it is doing things that require interrupts
[00:16:18] <petev> could be
[00:16:33] <jmkasunich> I didn't see that behavior on my single-processor amd system
[00:16:49] <jmkasunich> dunno if cradek tried it on (any of) his
[00:16:50] <petev> I think the init code sequence becomes the idle task if I rememer correctly
[00:17:21] <petev> maybe the duo core takes longer to get in and out of low power modes
[00:17:29] <jmkasunich> maybe
[00:17:48] <jmkasunich> but even without that endless loop, the core duo beats the amd
[00:18:19] <jmkasunich> the amd has ovl max latency of about 35uS, the core has 16uS with no endless loop, 4uS with the loop
[00:22:18] <petev> I got the wifi adabter working last night and that really helped progress
[00:22:32] <petev> the native linux driver didn't work, but the ndiswrapper works fine
[00:32:37] <skunkworks> I used fwcutter. ndiswrapper I could not get to work
[00:33:18] <petev> which adapter? I was using a Netgear WG111v2 with realtek
[00:33:36] <petev> the native driver would not work, although it could see the AP
[00:33:45] <petev> the ndis wrapper worked flawlessly
[00:34:20] <skunkworks> it is a buffalo with broadcom 43xx chipset
[00:46:50] <jmkasunich> cradek: there you go... RT on the last CPU, at least for kernel 2.6
[00:47:16] <jmkasunich> the CPU number used for RT is now printed as part of the /proc/rtapi data too
[01:06:07] <cradek> jmkasunich: cool
[01:07:02] <jmkasunich> can you try it on an smp machine?
[01:07:32] <cradek> yes
[01:08:25] <jmkasunich> the kernel's smp support is wild... they have hooks for hotplugging cpus, and for having 4 sockets, with 0, 1, and 3 installed, etc
[01:08:39] <cradek> RT task CPU = 1
[01:08:46] <jmkasunich> ;-)
[01:09:36] <cradek> you tried it on UP?
[01:09:39] <jmkasunich> yes
[01:09:46] <jmkasunich> RT task CPU = 0
[01:09:47] <cradek> uh-oh, my keyboard problem didn't go away with a different keyboard, that's not good
[01:10:29] <cradek> at least it's rare
[01:10:37] <jmkasunich> what is the problem?
[01:10:56] <cradek> sometimes it will register a keypress a hundred times instead of one
[01:11:09] <cradek> too fast for auto repeat
[01:11:11] <jmkasunich> you aren't running a vm are you?
[01:11:14] <cradek> no
[01:11:17] <jmkasunich> ok
[01:11:24] <jmkasunich> I've seen something similar on a vm
[01:11:29] <cradek> strange
[01:11:33] <jmkasunich> where it sees the press, but not the release
[01:11:41] <cradek> I don't think this is that, because they enter way too fast
[01:11:45] <jmkasunich> ok
[01:12:26] <jmkasunich> its a fixed number, they don't just keep going and going until you hit the key again?
[01:12:41] <cradek> I'm not sure about the number or what stops it
[01:13:01] <cradek> it's pretty rare
[01:13:12] <cradek> guess I can go back to my better keyboard then :-)
[01:13:18] <jmkasunich> heh
[01:13:36] <petev> BTW, how exactly does emc combine FE and MIN_FE? I thought the FE ramp was either added to MIN_FE, or max(FE * vel, MIN_FE) was used
[01:13:50] <jmkasunich> FE is at max velocity
[01:14:03] <jmkasunich> it ramps down toward zero at zero vel, but with a floor of MIN_FE
[01:14:25] <jmkasunich> so the faster you go, the wider the allowable FE band is
[01:14:38] <jmkasunich> but its never smaller than +/- MIN_FE
[01:14:52] <petev> hmm, I caught some traces when the tuning was bad that generated a FE, but the pid error was only about 60% of what MIN_FE was set too
[01:15:16] <jmkasunich> seems unlikely to me
[01:15:22] <petev> I took MIN_FE out, and FE seemed to be more like a constant value and I could not get the same behavior
[01:15:31] <jmkasunich> you double checked the numbers, and scope scaling, etc?
[01:15:40] <petev> yes
[01:15:47] <petev> I had MIN_FE at 0.001
[01:15:57] <jmkasunich> there is a hal param for the (velocity-dependent) limit, you could scope that as well as the actual FE (another param)
[01:16:10] <jmkasunich> with the offsets and scales the same, it will be very clear what is going on
[01:16:14] <petev> but I was seeing a FE get triggered with it at about 600u
[01:16:25] <jmkasunich> either the limit is lower than you expect, or the FE is higher
[01:17:00] <petev> maybe there was something funny in the scope setup, but the offsets were 0 and I thought the pos were not moved
[01:17:32] <petev> I had the gain up pretty good, so I was looking with a couple of divs
[01:17:55] <petev> but maybe I missed the zero line from the pos slider
[01:20:08] <cradek> jmkasunich: is there a thing in emcStatus that tells the number of axes? joints?
[01:20:21] <cradek> (I didn't carefully read all the stuff you did today)
[01:21:08] <jmkasunich> IIRC there are globals in the RT for both num_axes (maybe max_axes) and num_joints
[01:21:21] <jmkasunich> only max (or num)_axes in Status, nothing for joints
[01:21:34] <cradek> ok well axes is what's important at the level I'm considering
[01:21:47] <cradek> it would be nice if we did something smart when gcode moves axes that are undefined
[01:21:53] <cradek> (I'm not sure what that smart thing is)
[01:21:56] <jmkasunich> well, I can't guarantee that the axes entry in status is axes and not joints
[01:22:43] <cradek> ok I understand
[01:22:54] <cradek> brb
[01:23:02] <jmkasunich> it should be of course
[01:23:10] <jmkasunich> and I'm not averse to figuring it out and fixing it
[01:23:52] <jmkasunich> but what worries me is that for all I know some code up there in user space thinks its joints
[01:24:26] <jmkasunich> I believe I've now separated axes from joints throughout the rt code
[01:24:31] <jmkasunich> but userspace is still a horrible mess
[01:25:52] <cradek> assuming all that is right (ahem) what should emc do when you move an undefined axis in gcode?
[01:26:10] <jmkasunich> error out and stop the program?
[01:26:17] <jmkasunich> ideally, during the preview ;-)
[01:26:52] <cradek> AXIS would be able to error when loading the program, the others would error at runtime or if you do the "check" or whatever it's called
[01:27:28] <cradek> there would be a canon call GET_EXTERNAL_NUMBER_OF_AXES_AND_TELL_ME_WHAT_IT_IS
[01:27:40] <jmkasunich> lol
[01:27:42] <cradek> (the implementation reads emcStatus->something)
[01:27:53] <jmkasunich> and a complementary one for joints
[01:27:56] <cradek> the interp would call that when it starts, and remember the value
[01:28:05] <cradek> no, the interp doesn't care two whits about joints
[01:28:09] <jmkasunich> even if not needed now, so people will realize that there are two things
[01:28:52] <cradek> IMO gcode shouldn't be concerned and shouldn't know about joints
[01:28:57] <jmkasunich> ok
[01:29:14] <jmkasunich> I'm just very sensitive to places that misuse one for the other
[01:29:24] <cradek> sure
[01:29:34] <jmkasunich> and providing only one, is a sure-fire way to make people pick that one instead of thinking about which one is appropriate
[01:29:45] <cradek> but I'd be more sensitive about someone suggesting a special gcode that only moves a joint
[01:30:03] <jmkasunich> you are right, at the interp level it does make sense to have only axes
[01:30:07] <cradek> should be ignorant of joints on the "top" side of kins
[01:30:48] <cradek> well wait, this is already doomed
[01:31:10] <cradek> my lathe could very likely be XZC. what NUMBER_OF_AXES is that?
[01:31:22] <jmkasunich> 3
[01:31:26] <cradek> clearly it's 3, but that's not the information we need
[01:31:39] <jmkasunich> you want a mask, not a number
[01:31:51] <jmkasunich> in cartesean space, there are always 6, some of which aren't usec
[01:31:53] <jmkasunich> used
[01:32:02] <jmkasunich> joints otoh are a number, and there are no gaps
[01:32:10] <jmkasunich> a variable number
[01:32:50] <jmkasunich> like I said, axis/joint is really fscked up
[01:32:58] <cradek> sure
[01:33:09] <jmkasunich> num_axes should always be 6 imo
[01:33:21] <jmkasunich> with some mask that decides which ones can move
[01:33:26] <jmkasunich> (and be displayed, etc)
[01:33:37] <cradek> and what they're called
[01:33:43] <cradek> and whether they're rotary or linear
[01:33:57] <jmkasunich> no, they're always x,y,z (lin) and A,B,C (rot)
[01:34:24] <cradek> nah, I want X Y X' Y' sometimes, and they're all linear
[01:34:28] <jmkasunich> but Y, A, and B might be masked off
[01:34:32] <cradek> ideally I could call them UV in the interpreter
[01:34:39] <jmkasunich> does G-code understand X'?
[01:34:44] <cradek> no
[01:35:03] <cradek> but I could write U=>A V=>B W=>C pretty quick
[01:35:21] <jmkasunich> I think as long as you are using EMO_Pose structs to pass around poses, you need to stick with xyzabc
[01:35:21] <cradek> XYUV all linear is a commonly desired setup
[01:35:44] <jmkasunich> I know, foamcutters and wire edm
[01:35:49] <cradek> what they're called in the program is irrelevant - I'm talking about gcode -> output joints in general
[01:36:08] <cradek> my only point is you don't want to assume 3 linear, 3 rotary
[01:36:18] <jmkasunich> for joints, I agree
[01:36:24] <jmkasunich> for axes, I disagree
[01:37:04] <cradek> I can also easily imagine a XYZWA knee mill
[01:38:05] <jmkasunich> I understand the desire to do that
[01:38:17] <jmkasunich> but a "pose" is supposed to define the position of the tool in some (workpiece) coordinate system
[01:38:41] <tomp> the idea that a tool has a tip rather than an edge
[01:38:48] <jmkasunich> ZW is redundant, there are many ZW pairs that lead to the same tool position (relative to the work)
[01:38:54] <cradek> I understand 'pose' in the ngc sense is 3 linear, 3 rotary - but I'd rather think of it as a more generic 6-space
[01:39:10] <cradek> that's true about redundancy
[01:39:19] <cradek> (I'd be tempted to handle ZW in kins)
[01:39:26] <jmkasunich> but poses (and axes) are NOT generic
[01:39:55] <jmkasunich> a collection of joint values is generic, and can represent lots of different things for differnt machines
[01:40:28] <jmkasunich> but a pose is a description of things in real 3D space, space where mathematical relations should hold
[01:40:38] <jmkasunich> like the calculation of a hypotenuse
[01:40:48] <jmkasunich> how can you do that in xyzw?
[01:40:53] <jmkasunich> or xyuv?
[01:41:11] <cradek> or XYAB
[01:41:16] <jmkasunich> right
[01:41:24] <cradek> but XYAB is a 'pose'
[01:41:34] <cradek> I'm not understanding what makes it special
[01:42:02] <cradek> you can't even hypot from XYZA to XYZ(A+dA)
[01:42:08] <jmkasunich> I've been thinking of everything as xyzabc, where all 6 are present, and all 6 have their traditional meaning... all the rules (right hand rule, hypotenuse, etc) hold true, etc
[01:42:23] <jmkasunich> if you are doing XYA, its really XYzAbc
[01:42:35] <jmkasunich> z,b, and c are still present, but always zero
[01:42:39] <jmkasunich> the math always works on all 6
[01:43:10] <tomp> i think xyuvz is a pose. the tool is a length not a tip, it defines one pose of the line segment tool in cartesian space
[01:44:06] <jmkasunich> xyuvz isn't completely defined
[01:44:15] <jmkasunich> xyz defines one end of the line segment
[01:44:30] <tomp> uv is related to xy by kins
[01:44:31] <jmkasunich> uv is not enough to define the other
[01:45:06] <jmkasunich> the other end is offset laterally by uv, but at what height? 1" below the xyz point? 10" below? above?
[01:45:38] <tomp> i dont want to push for it now but i dont want it dissalowed either ( Z defines the height, i t was xyuvz )
[01:45:53] <jmkasunich> the height of which end?
[01:45:57] <tomp> uv
[01:46:05] <tomp> signed from xy plane
[01:46:05] <jmkasunich> then what is the height of the other end?
[01:46:10] <tomp> 0
[01:46:54] <tomp> just dont make it impossible in the future by decisions now
[01:46:55] <jmkasunich> so more accurately it would be xy0uvw
[01:47:32] <tomp> ? why w instead of z , why the parallel axis without the primary
[01:47:48] <tomp> (w is the axis parallel to z traditionally)
[01:48:04] <jmkasunich> it could be z or w, but I think of xyz as a point, and uvw as another point, in this case the two ends of the line segment
[01:48:34] <jmkasunich> its really xyuvw, but z is always zero
[01:48:42] <tomp> ok, i just hope it wont be dissallowed by decisions now
[01:49:08] <jmkasunich> its already disallowed and always has been
[01:49:37] <jmkasunich> all emc understands at the moment is xyzabc or subsets thereof, as far as I can tell
[01:49:57] <jmkasunich> (but I'm walking on thin ice - I don't know that part of the code well enough)
[01:50:25] <tomp> i hoped for xyzwabc emc2 machines (z plus backslide to change the work envelope)... dissallowed? then moot. i thought till was working on 8 axis, tho we havent heard for a long time now
[01:50:41] <tomp> frantiza
[01:50:49] <tomp> franitza?
[01:50:54] <jmkasunich> something like that
[01:51:05] <tomp> ok, thanks
[01:51:10] <jmkasunich> till worked on machines with lots of joints, not neccessarily lots of axes
[01:53:49] <jmkasunich> we certainly need w, for things like knee mills with both quill and knee driven
[01:54:07] <tomp> :) disallowed ;)
[01:54:22] <jmkasunich> but those are precisely the kinds of machines that muddy the line between axes and joints
[01:54:46] <tomp> right, it changes the work envelope, not xyz motion
[01:54:55] <jmkasunich> not that simple
[01:55:13] <jmkasunich> suppose I have a block, w is at zero, z is at zero, tooltip just touching the top of the block
[01:55:26] <tomp> k
[01:55:53] <jmkasunich> I can drill a 1" deep hole by commanding G1 Z-1, and when I'm done, X,Y,Z still tells me where the tool is relative to the work
[01:56:09] <jmkasunich> I can drill the same hole by commanding G1 W1
[01:56:32] <jmkasunich> and now Z=0 is suddenly 1" inside the workpiece
[01:57:14] <jmkasunich> so all subsequent lines of code CARE about which command you drilled that hole with, even though the hole is the same either way
[01:57:28] <tomp> gotcha, tho i'd never cut with W, just adjust the envelope before cutting ( and so my limited view )
[01:57:50] <jmkasunich> even so, when you adjust W, that throws off Z
[01:58:08] <jmkasunich> in your case, it "throws it on", it gets you where you want to be
[01:58:08] <tomp> you're right 'muddies the line', user will always do the unexpected
[01:58:37] <SWPadnos> there are people who have motorized the knee (for Z), and can adjust things like tool depth with the quill (which they probably adjust by hand, but could just as easily be W)
[01:59:23] <SWPadnos> you wouldn't have the RT / kins code "automatically" handle multiple Z joints (like quill and knee), and luckily, you don't have to
[01:59:30] <SWPadnos> since G-code actually defines 9 axes
[01:59:43] <jmkasunich> what does the EMC interp do with W anyway?
[01:59:48] <cradek> errors
[01:59:59] <SWPadnos> heh - so much for RS274NGC ;)
[02:00:10] <cradek> ngc doesn't mention W anywhere.
[02:00:15] <cradek> (from memory)
[02:00:20] <tomp> silly ngc
[02:00:25] <SWPadnos> and of course motion can't provide enough joints for a trivkins 9-axis machine either (though that's easy to fix)
[02:00:36] <jmkasunich> since W is parallel to Z, it is redundant
[02:00:40] <SWPadnos> oh, I don't know that I've seen a later revision that dropped UVW
[02:00:52] <SWPadnos> no, it's another parallel axis, under G-code control (possibly)
[02:01:00] <jmkasunich> the very existance of W and Z together means that axes are being mapped directly to joints
[02:01:18] <cradek> I'd do the Z vs W in kins. the algorithm could be 'move W only when necessary, and only as far as necessary' or something similar
[02:01:35] <SWPadnos> no itdoesn't, because as you pointed out, there's no way to automatically determine how to split a knee and quill movement, for example
[02:01:42] <jmkasunich> cradek: I don't think it would be very long before you changed your mind
[02:02:09] <cradek> seems like the knee would quickly end up in the right place to cut the program with the quill only
[02:02:13] <jmkasunich> you will want to split the move between W and Z in the g-code
[02:02:32] <jmkasunich> or at least have the option to do so
[02:02:48] <jmkasunich> I should say, between knee and quill
[02:02:55] <tomp> can you just leave the responsibility on the gcoder ( or post )?
[02:02:59] <cradek> I don't see why, but it's silly to argue about since I'm not doing it
[02:03:01] <SWPadnos> imagine drilling/tapping with both knee and quill active - you could potentially accelerate at double speed
[02:03:32] <cradek> gcode specifies feed, not acceleration
[02:03:46] <jmkasunich> tomp: the only way to leave it to the g-coder is if W works in g-code, today it doesn't
[02:03:50] <cradek> drilling with the knee and quill would be the only way to drill deeper than the quill
[02:03:54] <SWPadnos> if G-code no longer defines UVW, then it's a moot point, since there would be no way to specify those motions at a high level (leaving it for kins no matter what)
[02:04:10] <jmkasunich> cradek: quill is typically smoother and more accurate, knee has longer travel
[02:04:23] <jmkasunich> you would not want to use the knee to drill a 0.010 hole
[02:04:28] <cradek> jmkasunich: sure
[02:04:40] <cradek> ok let's move on :-)
[02:04:58] <jmkasunich> I forget where we were and where we were going
[02:05:09] <cradek> (that's why my algorithm always prefers to move the quill whenever possible)
[02:05:13] <jmkasunich> you were trying to decide what to do if g-code tries to move A on a machine with no A
[02:05:18] <cradek> ok right
[02:06:42] <jmkasunich> parting shot: the "move quill when possible" approach could lead to "move quill down 2" in air, then 1" in metal, then drill the last 1" of the hole using the knee" instead of "move knee up 1.1, then move quill down 0.9" in air, and 2.0" in metal"
[02:08:20] <cradek> you have the last word with my compliments :-)
[02:08:29] <jmkasunich> * jmkasunich bows
[02:09:05] <SWPadnos> I say it should be an error if an axis word is encountered for a non-existent axis
[02:09:13] <jmkasunich> I agree
[02:09:30] <jmkasunich> how do we define non-existant axes is the next question
[02:09:36] <jmkasunich> num_axes isn't enough
[02:09:37] <cradek> it seems to me the only other alternative would be to ignore it
[02:09:44] <jmkasunich> 3 could be xyz or xyc
[02:09:45] <SWPadnos> and I guess the [TRAJ]AXES variable can be used to tell the existing axes, since it's a list of axes used ...
[02:09:52] <SWPadnos> in letter form
[02:10:11] <SWPadnos> I know it's currently (mis)used for joints, but that's a different problem
[02:10:29] <jmkasunich> different but related
[02:10:53] <jmkasunich> maybe we can't solve the one until we solve (or at least split out) the other
[02:12:07] <jmkasunich> maybe [TRAJ]AXES should be xyzabc (and maybe uvw)
[02:12:20] <jmkasunich> and we should have a new section [KINS]
[02:12:24] <SWPadnos> I think it makes sense to decide what to do, then go about figuring out what sections of code (and configuration) that needs to touch
[02:13:34] <jmkasunich> I think we need to totally split axes and joints
[02:14:18] <SWPadnos> no argument here - we'll need to discuss where and how they need to interrelate
[02:15:47] <jmkasunich> [JOINT_0] and [AXIS_0]
[02:15:48] <jmkasunich> both have names
[02:15:55] <jmkasunich> axis names are things like x, y, a
[02:16:05] <jmkasunich> joint names are things like knee, saddle, quill
[02:16:36] <jmkasunich> both have type (angular/linear), although for axes, that could be inferred from the name
[02:16:37] <SWPadnos> or A B C
[02:16:45] <jmkasunich> for which?
[02:16:46] <SWPadnos> rather than "rotary 1, rotary 2 ..."
[02:17:10] <SWPadnos> A B C should be valid joint names (unless those are just labels for convenience)
[02:17:20] <jmkasunich> all joint names are just labels
[02:17:23] <SWPadnos> ok
[02:17:35] <jmkasunich> but I would strongly recommend that people not use axis names for them
[02:17:55] <jmkasunich> muddying the axis-joint distinction is how we got in this mess in the first place
[02:18:26] <SWPadnos> true, though strongly suggesting or forcing someone to not name their only rotary stage "A" might be a bad thing ;)
[02:18:58] <jmkasunich> strongly suggesting is in the docs, enforcing is in the code, I never said anything about enforcing
[02:19:18] <SWPadnos> sure - anyway, that's a diversion (sorry)
[02:19:47] <jmkasunich> fact is, many people _can_ get away with ignoring that distinction, and it makes their lives simpler
[02:20:08] <jmkasunich> we want to let the users ignore it, but we cannot allow ourselves to ignore or muddy it in the code
[02:20:33] <SWPadnos> yeah - I don't know what else people would want to call a rotary, other than "Haas Rotary" or "Trotke"
[02:20:38] <SWPadnos> sure
[02:20:47] <SWPadnos> Troyke, that was supposed to be
[02:21:52] <jmkasunich> for some users it will probably make perfect sense to map W directly to the knee and Z directly to the quill, and they can do that - we'll probably provide a kins file that does exactly that
[02:22:35] <jmkasunich> others may want to have Z be the only vertical axis, and intelligently decide how to split the moves between quill and knee
[02:23:09] <SWPadnos> I think this line of discussion will take us into pretty significant changes in the GUIs, status structs, etc. are you thinking of this as a 2.[234] thing or more of a refactor (3.0-ish)?
[02:23:20] <jmkasunich> no idea
[02:23:24] <SWPadnos> heh - ok
[02:23:59] <SWPadnos> I'm just following a logical line from named joints to GUIs that let you jog "knee" or "table"
[02:24:00] <jmkasunich> this is the usual.. cradek has some fairly simple thing he wants to do, but the implications send the discussion spiraling outward
[02:24:04] <SWPadnos> heh
[02:24:17] <jmkasunich> the fact that he is quiet right now probably means he's working on the original issue
[02:24:24] <SWPadnos> I'm surprised jepler hasn't implemented whatever we're talking about already ;)
[02:24:44] <jmkasunich> jepler hasn't popped in here today I don't think
[02:24:58] <SWPadnos> he was in for a very short bit, I think
[02:25:06] <jmkasunich> and I should be messing with FPGA stuff, not this
[02:25:12] <SWPadnos> sometime around when the bad weather hit cradek's area
[02:25:24] <jmkasunich> hope it wasn't too bad
[02:25:29] <petev_> jmk, is the current head rev in a suitable state for testing?
[02:25:38] <SWPadnos> green sun at 5:30 PM - probably not too bad ;)
[02:25:41] <jmkasunich> its not busted that I know of
[02:25:56] <petev_> ok, I was seeing all the joint/axes changes and wasn't sure
[02:26:09] <jmkasunich> should be transparent
[02:26:15] <jmkasunich> except for one line in your ini file
[02:26:21] <jmkasunich> the loadrt line that loads motmod
[02:26:42] <petev_> what needs changing there?
[02:26:53] <jmkasunich> currently has "max_joints=blah", change to "num_joints=blah"
[02:27:04] <petev_> ok
[02:41:53] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_Fest_2007
[02:42:26] <SWPadnos> that may now be a good place to put notes on this kind of discussion
[02:42:57] <tomp> thinking z/w aligned to knee/quill may limit the view, as there are many machines that have backslide/quill (moore,sip) arrangements ( please dont limit the systems without looking further than bridgeport as a machine model)
[02:44:49] <jmkasunich> tomp: backslide means the whole head goes up and down?
[02:45:00] <tomp> yes, gross vs fine
[02:45:11] <tomp> range versus stroke
[02:45:16] <jmkasunich> logically thats no different than a knee, anything that can handle a knee can handle a backslide
[02:45:19] <SWPadnos> you can also motorize many more parts of a BP, such as the ram (Y) travel
[02:45:49] <SWPadnos> don't some large bedmills have both a movable head and a quill?
[02:46:11] <jmkasunich> probably
[02:47:27] <tomp> ram on bp is sliding the quill in and out( the big casting behind the quill, loosen 4 bolts and crank a nut), y on a bp is moving worktable in and out ( turn a handle)
[02:47:48] <SWPadnos> they have the same effective motion
[02:49:18] <tomp> thats thinking in tooltip terms, in another view, one changes the work envelope, and the other changes just the tool tip in that envelope
[02:49:25] <SWPadnos> sure
[02:49:39] <SWPadnos> similar to many people's view of the knee
[02:49:50] <tomp> yep
[02:53:52] <jmkasunich> SWPadnos: thanks for posting the fest page
[02:54:01] <jmkasunich> * jmkasunich can't wait
[02:54:34] <SWPadnos> no problem. Jeff had made a little placebo page - I just dded the topics ;)
[02:54:39] <SWPadnos> added
[02:55:06] <SWPadnos> of course, that reminded me that I need to gather all my reservations and stuff, and I can't find my fest folder
[02:57:51] <jmkasunich> good point
[02:58:12] <jmkasunich> got my reservation info
[02:58:23] <jmkasunich> good thing I keep it in the computer and not paper, I'd never find it
[02:58:37] <SWPadnos> I found it - it just wasn't in a folder
[02:59:48] <SWPadnos> I guess I should spend some time organizing - I've been on 4 trips in the last 6 weeks, plus doing planning for 3 more
[02:59:54] <SWPadnos> oops, 4 more
[03:00:00] <SWPadnos> maybe 6
[03:00:16] <SWPadnos> but anyway - it gets confusing with all the receipts and reservations sitting arounf
[03:00:18] <SWPadnos> around
[03:15:14] <jmk-solo> SWPadnos: you were asking about glxgears fps using the normal kernel?
[03:15:24] <SWPadnos> yep
[03:15:24] <jmk-solo> about 1740
[03:15:34] <SWPadnos> with nv or nvidia?
[03:15:37] <jmk-solo> nvndia
[03:15:51] <SWPadnos> really? wow, that's a lot slower than I would have thought
[03:15:57] <SWPadnos> that's a 7100GS?
[03:16:00] <jmk-solo> yes
[03:16:27] <jmk-solo> there was a webpage that lists all supported card for the nvidia driver - the 7100GS isn't on it
[03:16:44] <jmk-solo> its still a lot faster than nv
[03:16:47] <SWPadnos> damn. the Opteron gets ~13000, the A64 (3500, I think) gets ~18000
[03:16:58] <SWPadnos> with a 7800GT and Quadro FX3500, respectively
[03:17:34] <jmk-solo> those are graphics cards that people who actually care about graphics might buy
[03:17:36] <SWPadnos> NVidia may have a page that tells you the supported models
[03:17:39] <SWPadnos> heh
[03:17:42] <jmk-solo> this one was $39 after rebate
[03:17:56] <SWPadnos> then it's proportionally about the same speed/$
[03:18:03] <jmk-solo> heh
[03:18:06] <jmk-solo> and quieter I bet
[03:18:08] <jmk-solo> no fan
[03:18:23] <SWPadnos> not by much on the quadro. the 7800GT is a jet engine
[03:26:44] <SWPadnos> jmkasunich, do you have the name of the lady we all talked to for reservations at the hotel?
[03:26:59] <jmkasunich> I don't think so, lemme check
[03:27:19] <jmkasunich> nope, sorry
[03:27:24] <jmkasunich> problems?
[03:27:46] <SWPadnos> no, but I didn't get an electronic confirmation, so I went to their website
[03:28:05] <SWPadnos> I can't seem to bring up the reservation with the number and any variation of my last names
[03:28:13] <SWPadnos> though I didn't try the common misspellings
[03:28:46] <cradek> what's the url? I can try mine
[03:29:06] <SWPadnos> http://www.abvigal.com/index.html
[03:29:14] <jmkasunich> I'm gonna do that same, I'm at the frontpage now...
[03:29:40] <SWPadnos> I generally like to have a chotel-provided reservation with the rates and stuff when I check in ...
[03:29:44] <SWPadnos> -c
[03:30:04] <jmkasunich> mine doesn't come up either
[03:30:14] <SWPadnos> ok, as long as it's not just me :)
[03:30:46] <jmkasunich> maybe the website only knows about website reservations
[03:30:52] <SWPadnos> could be
[03:31:01] <SWPadnos> is your reservation number 5 digits long?
[03:31:07] <jmkasunich> yes
[03:31:08] <SWPadnos> ok
[03:31:13] <SWPadnos> mine too
[03:31:22] <cradek> yeah seems like it just doesn't work
[03:31:22] <jmkasunich> starts with 12
[03:31:28] <SWPadnos> yep
[15:34:28] <alex_joni> hi ray
[15:34:39] <rayh> Hi Alex
[15:36:22] <alex_joni> how are you ray? been a while..
[17:43:17] <cradek> hi all
[17:43:24] <alex_joni> hi chris
[17:49:27] <alex_joni> bbl
[18:53:44] <cradek> hey guys, I need help deciding what else (if anything) should be backported for 2.1.5
[19:09:08] <jepler> I don't know of anything off hand -- I did most of my backports at the time
[19:09:24] <cradek> I was lazy - and now I'm paying for it
[19:11:26] <jepler> I'll skim through the check-ins and see if anything catches my eye
[19:11:31] <cradek> thanks
[19:12:41] <jepler> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/tcl/mini.tcl.diff?r1=1.30;r2=1.31
[19:13:54] <cradek> is that a bugfix? I don't even remember it
[19:14:50] <jepler> yes I think you click something in mini and get an error
[19:14:59] <jepler> "the dim labels are about 1 inch - this will get them onscreen better."
http://cvs.linuxcnc.org/cvs/emc2/src/emc/usr_intf/axis/scripts/axis.py.diff?r1=1.73;r2=1.74
[19:15:59] <cradek> that's sure harmless enough
[19:16:25] <jepler> "better check of conditions before homing"
http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/command.c.diff?r1=1.82;r2=1.83
[19:18:34] <cradek> I don't quite understand that one
[19:20:15] <jepler> "Pass the ini file along to the POSTGUI_HALFILE"
http://cvs.linuxcnc.org/cvs/emc2/src/emc/usr_intf/axis/scripts/axis.py.diff?r1=1.75;r2=1.76
[19:20:35] <jepler> I forget exactly what the command.c one was about -- something to do with homing and changing modes, I think
[19:20:58] <jepler> oh nevermind, POSTGUI_HALFILE was already backported
[19:22:55] <jepler> "don't divide by zero during abort"
http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c.diff?r1=1.70;r2=1.71
[19:23:02] <cradek> did that one
[19:23:04] <jepler> oops also backported already
[19:25:59] <jepler> "cleanup of index handling"
http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/hal_ppmc.c.diff?r1=1.47;r2=1.48
[19:26:25] <cradek> eek
[19:27:03] <jepler> several probe-related changes by you
[19:27:06] <cradek> what's the worst that can happen I guess
[19:27:15] <cradek> yeah I think I got the probe stuff already
[19:27:29] <cradek> I'm resisting the G43 change
[19:28:10] <cradek> nah it's too invasive
[19:29:41] <jepler> * fix bug reported by cradek: arrows in mdi area would send "ABORT" messages
[19:29:49] <jepler> ^^^ does this happen on 2.1?
[19:29:54] <cradek> I don't know
[19:30:05] <jepler> the fix is bound to be wrong, because it involves changing a lot of bindings
[19:31:11] <cradek> there are some i2g changes
[19:31:21] <jepler> yeah but it's a new feature, not a bugfix
[19:31:27] <jepler> at least the only one I saw go by (add border)
[19:31:56] <cradek> ok
[19:32:02] <cradek> if options['expand']:
[19:32:05] <cradek> must be it
[19:32:12] <cradek> (I'm just looking at a diff)
[19:36:52] <cradek> hal_input.c changed to use select instead of sleep
[19:36:59] <cradek> err hal_input.py
[19:43:10] <jepler> not important
[19:45:22] <cradek> maybe this is everything then
[19:45:47] <cradek> building...
[19:57:02] <cradek> hm, I broke probing
[19:57:03] <cradek> ... bbl
[19:58:02] <jmk-solo> hi guys
[19:58:55] <jmk-solo> the ppmc index handling - IMO, it is a code inprovement, but I can't point to a specific bug in the old code, and as far as I know, jonE hasn't tested it yet (the lazy bugger!)
[20:02:35] <jmk-solo> pardon my gloat: kernel build:
[20:02:36] <jmk-solo> real 9m35.745s
[20:02:36] <jmk-solo> user 15m27.002s
[20:02:36] <jmk-solo> sys 1m54.791s
[20:02:47] <jmk-solo> of course, if it doesn't work.....
[20:04:25] <SWPadnos> is that kernel only, or kernel+modules?
[20:04:58] <jmk-solo> fakeroot make-kpkg --initrd --append-to-version=-foo kernel_image kernel_headers
[20:05:06] <jmk-solo> I'm under the impression that makes the modules too
[20:05:29] <SWPadnos> ok, I'd expect so
[20:05:43] <jmk-solo> since the howto I'm following goes on to say "install the resulting debs and reboot" ;-)
[20:07:04] <jmk-solo> well, here goes....
[20:13:08] <jmk-solo> no joy
[20:13:09] <alex_joni> hmm.. kinda long reboot
[20:13:15] <jmk-solo> I should have done the first one with all kernel options as defaults
[20:13:15] <cradek> jmk-solo: should I take out the ppmc backport?
[20:13:18] <alex_joni> was just about to say it failed
[20:13:42] <alex_joni> jmk-solo: how does it fail?
[20:13:49] <jmk-solo> cradek: hard to say, I really do believe its better than the old, but if jon hasn't tested it....
[20:14:18] <cradek> well index didn't work before - either it works now or it doesn't
[20:14:31] <jmk-solo> "waiting for root filesystem" - I did exactly what you told me not to do - went thru all the menus turning off stuff I didn't think I needed ;-)
[20:14:49] <cradek> doh
[20:14:51] <alex_joni> jmk-solo: guess I won't tell you now..
[20:14:53] <cradek> why would you do that?
[20:14:54] <jmk-solo> cradek: the index problem was reported as intermittent
[20:15:03] <jmk-solo> cradek: cause I'm an idiot
[20:15:05] <SWPadnos> you probably have SATA on your machine, which needs esxtra stuff in initrd
[20:15:32] <alex_joni> jmk-solo: it wasn't expected that the first one is right..
[20:15:40] <alex_joni> so don't sweat it.. just try again
[20:15:44] <jmk-solo> right
[20:15:46] <cradek> yep
[20:15:52] <alex_joni> take the old config, and use that
[20:15:54] <cradek> you did use ccache right?
[20:15:54] <jmk-solo> I'm just gonna use the stock configuration this time
[20:16:07] <alex_joni> and don't add anything, reboot and make a list with things that don't work
[20:16:13] <alex_joni> then start messing with it
[20:16:46] <cradek> it even took me two tries on my ppc - and I tried very hard to get it right the first time - because it's an 8ish hour build
[20:16:59] <SWPadnos> heh - that's a bit worse than 8 minutes
[20:17:12] <jmk-solo> a 10 minute build makes the process a lot less painfull
[20:17:24] <jmk-solo> it sucks that reboots take 2 minutes tho
[20:17:36] <SWPadnos> I had a working kernel for a while, but that ended after compiling without modversions (needed for RTAI)
[20:17:38] <jmk-solo> damn bios
[20:17:42] <alex_joni> I remember when I started with emc & rtai
[20:17:59] <SWPadnos> I ended up with no devfs, though that may not have been the actual problem
[20:18:08] <alex_joni> it took me about 2 days to finish compiling everything :-/
[20:18:27] <cradek> bbl
[20:19:13] <jmk-solo> when I run menuconfig with the original .config, I get lots of this:
[20:19:22] <jmk-solo> .config:19:warning: trying to assign nonexistent symbol CLEAN_COMPILE
[20:19:22] <jmk-solo> .config:39:warning: trying to assign nonexistent symbol KOBJECT_UEVENT
[20:19:22] <jmk-solo> .config:54:warning: trying to assign nonexistent symbol CC_ALIGN_FUNCTIONS
[20:19:21] <jmk-solo> .config:55:warning: trying to assign nonexistent symbol CC_ALIGN_LABELS
[20:19:21] <jmk-solo> .config:56:warning: trying to assign nonexistent symbol CC_ALIGN_LOOPS
[20:19:22] <jmk-solo> .config:57:warning: trying to assign nonexistent symbol CC_ALIGN_JUMPS
[20:19:24] <jmk-solo> .config:67:warning: trying to assign nonexistent symbol OBSOLETE_MODPARM
[20:19:26] <jmk-solo> .config:144:warning: trying to assign nonexistent symbol ENABLE_ALT_SMP
[20:19:29] <jmk-solo> .config:171:warning: trying to assign nonexistent symbol 05GB
[20:19:30] <jmk-solo> .config:172:warning: trying to assign nonexistent symbol 1GB
[20:19:33] <jmk-solo> .config:173:warning: trying to assign nonexistent symbol 2GB
[20:19:34] <jmk-solo> .config:174:warning: trying to assign nonexistent symbol 3GB
[20:19:38] <jmk-solo> is that normal?
[20:19:41] <alex_joni> yeah, but you're a programmer
[20:19:47] <alex_joni> you shouldn't care about warnings :D
[20:19:55] <alex_joni> bbl..
[20:19:55] <SWPadnos> original .config from where?
[20:19:56] <jmk-solo> I _always_ care about warnings
[20:20:10] <alex_joni> jmk-solo: I know.. was trying to make a joke
[20:20:13] <SWPadnos> heh - you're an EE, not a programmer. warnings are more important in hardware ;)
[20:20:20] <jmk-solo> cp /boot/config-`uname -r` ./.config ; make menuconfig
[20:20:32] <jmk-solo> once in menuconfig, all I did was exit and save
[20:20:48] <alex_joni> jmk-solo: didn't you do the laod alternative?
[20:20:49] <SWPadnos> ok, with the stock ubuntu boot (so 2.6.15.28 or thereabouts)
[20:20:53] <jmk-solo> right
[20:20:58] <jmk-solo> and I'm building 2.6.20.11
[20:21:13] <SWPadnos> ok - a64 or i386?
[20:21:39] <jmk-solo> 2.6.15-28-686
[20:21:50] <jmk-solo> thats the stock ubuntu SMP kernel
[20:21:53] <SWPadnos> what are you trying to build though?
[20:22:03] <jmk-solo> 2.6.20.11
[20:22:05] <SWPadnos> yes, I have the same except for -k8
[20:22:06] <alex_joni> a newer one
[20:22:16] <SWPadnos> 2.6.20.11 for i686 then?
[20:22:38] <jmk-solo> yeah, but I don't recall seeing any place where I pick -386 vs -686, etc
[20:22:46] <SWPadnos> right - that's why I'm asking :)
[20:22:53] <jmk-solo> in menuconfig there was a place that asked for CPU type
[20:23:04] <jmk-solo> last time I told it core 2
[20:23:08] <SWPadnos> I don't know if it picks it up from the running kernel type, or if they actually detect the CPU type
[20:23:15] <jmk-solo> this time I'm using everything as defaults
[20:23:28] <alex_joni> SWPadnos: it detects at runtime
[20:23:35] <SWPadnos> there's a processor type and features page, but it doesn't have the basic class selection now
[20:23:41] <alex_joni> actually the bootloader needs to do that
[20:23:50] <SWPadnos> alex_joni, ok, so it's probably trying to build an x86_64 version now
[20:23:52] <alex_joni> it prepares processor type & arch into some special registers
[20:24:11] <alex_joni> which the kernel reads on startup
[20:24:14] <SWPadnos> I'm wondering about kernel configuration, not kernel booting
[20:24:34] <SWPadnos> I know the more generic kernels auto-detect and select appropriate code where necessary
[20:24:39] <alex_joni> right
[20:24:59] <jmk-solo> it seems to be building i386
[20:25:04] <SWPadnos> ok
[20:25:07] <jmk-solo> CC arch/i386/kernel/process.o
[20:25:14] <jmk-solo> lines like that are scrolling by
[20:25:15] <SWPadnos> ok
[20:25:27] <SWPadnos> and this is the RTAI-patched kernel, I assume?
[20:25:32] <jmk-solo> no
[20:25:36] <alex_joni> vanilla
[20:25:37] <jmk-solo> vanilla source
[20:25:44] <SWPadnos> ok - that eliminates one set of possible problems ;)
[20:25:50] <jmk-solo> not even from ubuntu - straight from kernel.org
[20:26:15] <SWPadnos> make sure when you go for ipipe that you add ipipe to the EXTRAVERSION
[20:26:24] <SWPadnos> right - those are the only ones you can reliably patch for RT
[20:26:29] <jmk-solo> what is ipipe and why am I going for it?
[20:26:44] <SWPadnos> that's the RT kernel subsystem
[20:26:53] <jmk-solo> oh, then I won't be going for it
[20:27:00] <SWPadnos> is it an option?
[20:27:08] <alex_joni> IPIPE is the new name for ADEOS
[20:27:13] <alex_joni> SWPadnos: this is for running VMs
[20:27:14] <jmk-solo> this machine is strictly workstation/server/VMhost, I will not be using it for RT
[20:27:17] <alex_joni> not for running emc
[20:27:20] <SWPadnos> that option appears after you patch the kernel with the RTAI ipipe patches
[20:27:24] <SWPadnos> ok
[20:27:36] <SWPadnos> ah, so you're doing this for KVM
[20:27:49] <alex_joni> jmk-solo: make sure you have vmx enabled in the BIOS
[20:27:50] <jmk-solo> I'm actually doing it to get sensors support for the new mobo
[20:27:55] <SWPadnos> heh
[20:28:15] <alex_joni> http://en.wikipedia.org/wiki/X86_virtualization
[20:28:22] <SWPadnos> make sure you download the nvidia drivers before rebooting into the new kernel, they are kernel-specific
[20:28:35] <alex_joni> bbl
[20:28:38] <SWPadnos> I think nv is too, because it didn't work for me with the RT kernel
[20:28:46] <SWPadnos> see you Alex
[20:28:57] <alex_joni> nah, nv is not kernel dependent
[20:29:22] <jmk-solo> I guess I should switch to nv before rebooting into the new kernal
[20:29:26] <SWPadnos> maybe I screwed up the AGPGART drivers or something, but in the generic SMP kernel (non-RT) I built, nv didn't work
[20:30:05] <SWPadnos> it also didn't work in the RT kernel, but I got nvidia going by downloading their latest driver and doing their install (in the RT SMP A64 kernel)
[20:30:18] <SWPadnos> so I got it working, but it didn't work at first (just to be clear about it :) )
[20:31:12] <jmk-solo> I have both nv and nvidia driver lines in my xorg.conf, I just move the # from one to the other (I did that a lot some days ago when first getting nvidia to work)
[20:32:19] <jmk-solo> interesting: kernel 2.6.20 and up have this:
http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
[20:32:43] <SWPadnos> that's the KVM I referred to
[20:33:07] <SWPadnos> later VMWare versions are aware of it, and it should be a vast improvement in VM speed
[20:33:32] <jmk-solo> maybe I'm mis-reading this, but it seems to me like KVM replaces VMware
[20:33:50] <jmk-solo> as in, a complete open-source virtualization system, instead of relying on VMware
[20:34:05] <jmk-solo> of course QEMU was open too, it just didn't work so nice
[20:34:20] <SWPadnos> I haven't read through all the docs (there are many), but I think the KVM features allow better virtualization, but can't virtualize anything that wasn't designed to be virtualized
[20:34:59] <SWPadnos> so you could use kernel 2.6.20+ virtualized on top of 2.6.20+, but the RT kernels wouldn't work without extra help from QEMU / VMWare
[20:35:11] <jmk-solo> wow, I must have turned off a lot of stuff before... thei build is taking a lot longer
[20:35:16] <SWPadnos> heh
[20:35:27] <SWPadnos> you didn't do "-j" did you?
[20:35:33] <SWPadnos> (without a number)
[20:36:02] <jmk-solo> make-kpkg doesn't use -j directly, instead you set an env var to tell it how much concurrency to use
[20:36:12] <jmk-solo> (which I did - both CPUs are 100% loaded)
[20:36:14] <SWPadnos> ok, and there has to be a number?
[20:36:28] <jmk-solo> its the same number you use with -j
[20:36:32] <jmk-solo> I picked 3
[20:36:42] <SWPadnos> I made the mistake of doing -j once, and the module build ended up taking about a half hour
[20:36:48] <SWPadnos> maybe longer
[20:37:01] <jmk-solo> ?
[20:37:06] <SWPadnos> make ended up spawning hundreds of compiles, which caused massive swap thrashing
[20:37:10] <jmk-solo> oh
[20:37:25] <SWPadnos> when I restricted it to -j12, it was much faster, in the 8-10 minute range
[20:39:39] <jmk-solo> real 15m13.236s
[20:39:40] <jmk-solo> user 24m29.040s
[20:39:40] <jmk-solo> sys 2m47.482s
[20:40:54] <SWPadnos> I guess I should try the make-kpkg thing - it seems easier than manually making bzimage/modules/modules_install/mkinitrd/copying files/editing menu.lst :)
[20:41:22] <jmk-solo> it makes a deb, which you then install with dpkg -i, _however_, I have a problem
[20:41:33] <SWPadnos> what's the problem?
[20:41:34] <jmk-solo> I didn't rename the kernel when I rebuilt
[20:41:42] <SWPadnos> uh-oh
[20:41:55] <jmk-solo> so now dpkg is saying things about "there is already a directory", etc
[20:42:05] <SWPadnos> is the package name the same as the installed kernel?
[20:42:32] <jmk-solo> package name: kernel-imge-2.6.20.11-foo_10.00.Custom_i386.deb
[20:42:47] <jmk-solo> image, not imge
[20:42:58] <SWPadnos> oh, that should be OK - did you remove the kernel you had previously built?
[20:43:02] <jmk-solo> no
[20:43:12] <jmk-solo> probably should have
[20:43:18] <jmk-solo> maybe too late now
[20:43:26] <SWPadnos> that's the conflict then. it may cause a headache in package management, but it shouldn't cause a boot problem
[20:43:49] <SWPadnos> there's a purge/force marking as removed option to dpkg, I think
[20:44:45] <SWPadnos> oh wait - is the package name of the newer build the same as teh older build? (or does that _10 change?)
[20:44:56] <jmk-solo> its the same
[20:45:51] <jmk-solo> I think I solved it by dpkg -r the_package
[20:45:59] <SWPadnos> probably solved that way
[20:47:46] <SWPadnos> interesting - it looks like KVM only needs QEMU/VMWare as a UI to the in-kernel features. I didn't realize that
[20:49:34] <jmk-solo> well, here goes
[20:52:34] <jmkasunich> not good...
[20:52:43] <jmkasunich> stops at "Begin: waiting for root file system"
[20:52:55] <jmkasunich> * jmkasunich googles
[20:53:21] <SWPadnos> did you also get errors about /dev or devfs not being available?
[20:53:42] <SWPadnos> I don't remember the specific errors
[20:53:48] <jmkasunich> not visible on screen
[20:54:01] <jmkasunich> according to google, that wait will time out eventually and maybe print something usefull
[20:54:09] <jmkasunich> last time I bet I didn't wait long enough
[20:54:22] <SWPadnos> ok. I had two distinct failure modes. one was something like "root filesytem not available, unable to mount VFS"
[20:54:47] <jmkasunich> its still waiting
[20:54:51] <SWPadnos> that one occurred after a lot of stuff scrolled by
[20:55:23] <SWPadnos> the other one was very early - something about not being able to mount /devfs or the like, inthe first several lines of statue
[20:55:26] <SWPadnos> status
[20:55:32] <SWPadnos> not even one screenful went by
[20:55:42] <jmkasunich> I had many screens go by
[20:55:55] <SWPadnos> gotta run for a bit. please point out anything you find on this :)
[20:56:25] <jmkasunich> lots of google hits on that message
[20:56:50] <jmkasunich> it finally timed out
[20:57:52] <jmkasunich> ALERT! /dev/sda1 does not exist. Dropping to shell!
[20:58:00] <jmkasunich> I bet its a SATA disk thing
[20:58:18] <cradek> you know you need scsi stuff for sata right?
[20:58:30] <jmkasunich> this time I didn't touch nuttin
[20:59:10] <jmkasunich> I copied the config file from the booted system (2.6.15-28-686), ran menuconfig, and without changing any entries, saved the result and did the build
[20:59:27] <cradek> hmmm
[20:59:37] <cradek> when you install it does it make the initrd correctly?
[20:59:54] <jmkasunich> maybe something changed between 2.6.15 and 2.6.20, such that the default isn't right?
[21:00:09] <cradek> that definitely happens
[21:00:09] <jmkasunich> how would I know what is "correctly"
[21:00:24] <cradek> does it put one with a plausible size in /boot?
[21:01:40] <jmkasunich> there was a file, didn't look at the size
[21:01:47] <jmkasunich> rebooting to the old kernel
[21:04:38] <jmkasunich> google says sata drivers aren't enabled by default
[21:05:53] <jmkasunich> interesting, linux/config.h has been deprecated as of 2.6.19
[21:06:10] <jmkasunich> http://www.linuxquestions.org/questions/showthread.php?t=506363
[21:07:01] <cradek> that's a great idea, 19 releases into the stable kernel release tree
[21:07:11] <jmkasunich> ?
[21:07:28] <jmkasunich> sarcasm detected?
[21:07:33] <cradek> yes
[21:09:39] <jmk-solo> so, I think I have to use menuconfig and find the sata drivers...
[21:10:08] <cradek> what is your eventual goal here? I didn't see the beginning of this
[21:10:36] <jmk-solo> a 2.6.20 kernel, smp, no RT
[21:10:57] <jmk-solo> I want 2.18+ because that is allegedly when sensor support for my mobo was added
[21:11:19] <jmk-solo> and since I'm gonna be running VMs here, it might be nice to have the KVM support that was added in 2.20
[21:11:21] <jmk-solo> 2.6.20
[21:11:28] <cradek> ah
[21:11:37] <cradek> so you started with regular old kernel.org sources?
[21:11:42] <jmk-solo> yep
[21:11:45] <jmk-solo> 2.6.20.11
[21:11:56] <cradek> but used /boot/config-[ubuntu]
[21:12:23] <jmk-solo> I followed this howto:
http://www.howtoforge.com/kernel_compilation_ubuntu
[21:12:30] <cradek> well I feel for you :-)
[21:12:52] <cradek> I don't have much help to offer
[21:13:20] <cradek> maybe you could try the config that comes in the tar instead?
[21:13:25] <jmk-solo> the config from ubuntu is nfg for a vanilla kernel?
[21:13:26] <cradek> I don't know what if anything the ubuntu config gives you
[21:13:52] <cradek> there are some ubuntu specific patches in their kernels. I don't know all the details.
[21:14:01] <jmk-solo> from the howto (which directed me to use vanilla source):
[21:14:02] <cradek> but in general, a config from an older kernel is often nfg
[21:14:02] <jmk-solo> It's a good idea to use the configuration of your current working kernel as a basis for your new kernel. Therefore we copy the existing configuration to /usr/src/linux:
[21:14:02] <jmk-solo> cp /boot/config-`uname -r` ./.config
[21:14:31] <jmk-solo> it seemed reasonable at the time
[21:14:51] <cradek> when you do that, and then make oldconfig, does it ask you anything that seems ominous?
[21:15:04] <jmk-solo> the howto says do make menuconfig
[21:15:12] <jmk-solo> I can try oldconfig instead, stand by
[21:15:20] <cradek> oldconfig will show you the "new" questions
[21:17:03] <jmk-solo> if there are a bazillion of them it will suck
[21:17:19] <jmk-solo> I suppose I should accept the default on the ones that don't mean anything to me
[21:18:58] <jmk-solo> ok, first interesting one: processor family... default is "Pentium Pro(M686)", there is a "Core2/newer Xeon (MCORE2)" option
[21:19:07] <jmk-solo> seems safe to me to use the core2
[21:21:49] <jmk-solo> ok, here's an interesting one
[21:22:05] <cradek> I don't trust those instructions
[21:22:19] <cradek> "the ubuntu way" ... "first, make a root login, then screw up /bin/sh"
[21:22:32] <cradek> ubuntu way my ass
[21:22:37] <alex_joni> hah
[21:22:48] <jmk-solo> under "ATA/ATAPI/MFM/RLL support (IDE) [Y/n/m/?] y" ; "Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support (BLK_DEV_IDE) [Y/n/m/?] y"
[21:22:54] <jmk-solo> I didn't do the root login
[21:22:57] <jmk-solo> did sudo su
[21:23:12] <jmk-solo> and the sh thing is for edgy, non-issue for dapper
[21:23:12] <cradek> I know, just saying the instructions are a little odd
[21:23:23] <jmk-solo> yeah, maybe that should have been a clue
[21:23:34] <alex_joni> the rest isn't that wrong
[21:23:40] <jmk-solo> anyway, getting to the question I'm on now
[21:23:57] <cradek> I think for best results you need to use --stem=linux
[21:24:09] <cradek> the packages haven't been kernel-image-etc for a while now
[21:24:10] <jmk-solo> in the section mentioned before, PNP EIDE support (BLK_DEV_IDEPNP) [N/y/?] (NEW)
[21:24:22] <alex_joni> N is safe I think
[21:24:49] <jmk-solo> ohh, maybe its this one:
[21:24:49] <jmk-solo> SCSI device support (SCSI) [M/n/y/?] m
[21:24:49] <jmk-solo> SCSI target support (SCSI_TGT) [N/m/?] (NEW)
[21:25:05] <alex_joni> * alex_joni has nfc
[21:25:23] <cradek> try ?
[21:25:39] <jmk-solo> if you want to use SCSI target mode drivers enable this option.
[21:25:40] <jmk-solo> If you choose M, the module will be called scsi_tgt.
[21:25:49] <jmk-solo> can't hurt to make it a module I guess
[21:25:59] <cradek> sure why not
[21:26:07] <cradek> (no idea what it means)
[21:26:09] <alex_joni> yeah, but I bet it won't be pulled in the initrd
[21:26:17] <alex_joni> so I'm not sure it might matter
[21:26:22] <jmk-solo> Asynchronous SCSI scanning (SCSI_SCAN_ASYNC) [N/y/?] (NEW)
[21:26:59] <jmk-solo> reading the ? info, N seems the safe bet
[21:27:23] <cradek> yeah it might be a "do something questionable at boot to save 5 seconds"
[21:27:33] <jmk-solo> thats the impression I got
[21:28:21] <jmk-solo> aha!
[21:28:29] <jmk-solo> * Serial ATA (prod) and Parallel ATA (experimental) drivers
[21:28:29] <jmk-solo> *
[21:28:29] <jmk-solo> ATA device support (ATA) [N/m/y/?] (NEW)
[21:28:45] <jmk-solo> that almost certainly wants to be Y
[21:29:00] <jmk-solo> If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
[21:28:59] <jmk-solo> any other ATA device under Linux, say Y and make sure that you know
[21:28:59] <jmk-solo> the name of your ATA host adapter (the card inside your computer
[21:28:59] <jmk-solo> that "speaks" the ATA protocol, also called ATA controller),
[21:28:59] <jmk-solo> because you will be asked for it.
[21:29:28] <jmk-solo> I don't know the name of my adapter tho... could google for mobo info if needed, and I have the mobo manual
[21:29:44] <alex_joni> this doesn't feel right
[21:29:52] <jmk-solo> ATA device support (ATA) [N/m/y/?] (NEW) Y
[21:29:52] <jmk-solo> AHCI SATA support (SATA_AHCI) [N/m/y/?] (NEW) ?
[21:29:52] <jmk-solo> This option enables support for AHCI Serial ATA.
[21:29:52] <jmk-solo> If unsure, say N.
[21:30:35] <alex_joni> jmk-solo: here's a thought..
[21:30:47] <alex_joni> how about locating the kernel package from feisty
[21:30:52] <alex_joni> and use that config file?
[21:30:56] <alex_joni> it's a 2.6.20 afaik
[21:31:17] <cradek> or try that .deb...
[21:31:52] <jmk-solo> I'm gonna muddle thru this newconfig and do one more build, then see what happens
[21:31:52] <alex_joni> or that..
[21:32:39] <alex_joni> http://packages.ubuntulinux.org/feisty/base/linux-image-2.6.20-15-server
[21:34:16] <jmk-solo> here we go:
[21:34:16] <jmk-solo> Intel PIIX/ICH SATA support (ATA_PIIX) [N/m/y/?] (NEW) ?
[21:34:17] <jmk-solo> This option enables support for ICH5/6/7/8 Serial ATA
[21:34:17] <jmk-solo> and support for PATA on the Intel PIIX3/PIIX4/ICH series
[21:34:17] <jmk-solo> PATA host controllers.
[21:34:17] <jmk-solo> If unsure, say N.
[21:34:26] <jmk-solo> ICH8 is my chipset
[21:34:37] <cradek> yep that's surely it
[21:35:43] <alex_joni> that sounds like something
[21:36:14] <jmk-solo> there is a massive list of drivers for sata, all off by default
[21:36:55] <alex_joni> modules when in doubt
[21:37:12] <jmk-solo> the one needed for the boot disk needs to be Y, right?
[21:44:55] <jmk-solo> oldconfig done.... lots of questions ;-/
[21:46:55] <cradek> * cradek is excited that jmk will be able to build the next realtime kernel
[21:47:13] <jmk-solo> surely you jest
[21:47:27] <jmk-solo> in that howto, I skipped completley over step 4, patching
[21:48:25] <alex_joni> jmk-solo: apt-get source linux-source-2.6.*
[21:48:53] <jmk-solo> why?
[21:48:56] <alex_joni> then you have a dir full of patches :)
[21:49:12] <alex_joni> that's the ubuntu/debian way of building kernel packages
[21:49:16] <alex_joni> (for all archs at once)
[21:50:00] <cradek> alex_joni: we? ought to fix installed
[21:50:18] <alex_joni> is it broken?
[21:50:55] <cradek> oh I assumed that was gringos's problem
[21:50:59] <cradek> maybe it's not broken
[21:51:18] <alex_joni> maybe he didn't do sudo make install
[21:51:24] <alex_joni> but I won't suggest that until he knows it runs
[21:51:30] <alex_joni> otherwise he'll get leftovers
[22:11:16] <jmk-solo> interesting message while installing the new kernel package:
[22:11:17] <jmk-solo> Unpacking kernel-image-2.6.20.11-jmk0 (from kernel-image-2.6.20.11-jmk0_10.00.Custom_i386.deb) ...
[22:11:17] <jmk-solo> Setting up kernel-image-2.6.20.11-jmk0 (10.00.Custom) ...
[22:11:17] <jmk-solo> Or maybe you don't want a symbolic link here. Hmm? Lets See.
[22:11:19] <jmk-solo> Or maybe you don't want a symbolic link here. Hmm? Lets See.
[22:11:21] <jmk-solo> Searching for GRUB installation directory ... found: /boot/grub
[22:11:43] <jmk-solo> bad paste
[22:13:36] <jmk-solo> Setting up kernel-image-2.6.20.11-jmk0 (10.00.Custom) ...
[22:13:35] <jmk-solo> /initrd.img does not exist. Installing from scratch, eh?
[22:13:35] <jmk-solo> Or maybe you don't want a symbolic link here. Hmm? Lets See
[22:13:35] <jmk-solo> ./vmlinuz does not exist. Installing from scratch, eh?
[22:13:35] <jmk-solo> Or maybe you don't want a symbolic link here. Hmm? Lets See.
[22:13:35] <jmk-solo> Searching for GRUB installation directory ... found: /boot/grub
[22:13:41] <jmk-solo> better
[22:13:52] <jmk-solo> ignore the . before /vmlinuz
[22:14:27] <alex_joni> odd
[22:15:22] <jmk-solo> is there supposed to be vmlinuz and initrd.img symlinks in /boot? or just the individual files?
[22:15:45] <jmk-solo> hmm, I bet the symlinks were used by lilo, instead of the menu that grub uses
[22:16:10] <jmk-solo> my other system doesn't have symlinks, so its not something I borked up
[22:16:21] <jmk-solo> only one way to find out - rebooting
[22:19:17] <alex_joni> cradek: I'll do SF and linuxcnc tomorrow morning
[22:19:40] <cradek> alex_joni: thanks
[22:19:45] <jmkasunich> cradek: great work on the release, thanks!
[22:19:50] <cradek> maybe someone will do the wiki too :-)
[22:19:54] <cradek> thanks jmk
[22:20:11] <jmkasunich> meanwhile.... it still can't find the boot device
[22:20:18] <cradek> I feel like this may be the last 2.1 release
[22:20:30] <jmkasunich> I think you're right about that
[22:20:45] <alex_joni> cradek: I'll do SF, wiki and linuxcnc tomorrow morning
[22:20:57] <alex_joni> is that better?
[22:21:18] <cradek> sorry, I wasn't hinting, sometimes jepler does it
[22:21:55] <alex_joni> yeah, I know..
[22:21:55] <cradek> sometimes jmk has done it too I think
[22:22:13] <alex_joni> I'll do it tomorrow if it's not done by then.. no worries
[22:22:21] <cradek> thank you
[22:22:39] <jmkasunich> I can do wiki stuff, I just don't/can't do joomla
[22:22:47] <alex_joni> thank _you_ for doing the release
[22:22:57] <alex_joni> jmkasunich: you don't want :P I'm sure you could
[22:24:48] <jmkasunich> ok, the boot has dropped me to a bustbox shell
[22:24:56] <jmkasunich> can anybody think of stuff to check?
[22:25:09] <cradek> lsmod
[22:25:13] <jmkasunich> there is no /dev/hd* or /dev/sd*
[22:25:37] <jmkasunich> lsmod not found
[22:25:48] <cradek> /sbin/lsmod
[22:25:50] <jmkasunich> there are proc entries with the same info I think?
[22:25:53] <cradek> or is there no filesystem?
[22:26:13] <cradek> you might be in the initrd's filesystem
[22:26:44] <jmkasunich> I think so
[22:28:07] <jmkasunich> uname works ;-) shows my kernel
[22:28:27] <jepler> I'll at least get a start on the wiki
[22:29:09] <cradek> this is the earliest in the day I've finished a release for a long time
[22:29:36] <jmkasunich> wtf
[22:29:41] <jmkasunich> foo
[22:29:54] <jmkasunich> irc funnies
[22:30:04] <jmkasunich> did you see me say "/modules is empty" ?
[22:30:35] <alex_joni> nope
[22:30:50] <alex_joni> but if you start with / it sometimes thinks it's an irc command
[22:30:59] <jmkasunich> oh, right
[22:31:00] <jmkasunich> I knew that
[22:31:04] <jmkasunich> (I just forgot)
[22:31:12] <alex_joni> put a space before it
[22:31:15] <jmkasunich> right
[22:31:21] <alex_joni> * alex_joni is off to bed
[22:31:30] <jmkasunich> goodnight
[22:31:57] <cradek> night alex
[22:31:59] <jepler> online docs also updated for 2.1.6.
[22:32:00] <jepler> er, 2.1.5
[22:32:39] <cradek> yay
[22:35:20] <jmkasunich> /proc/mounts shows no disk based filesystems
[22:35:40] <jmkasunich> /proc/scsi shows my cdrom (strangely, since its IDE)
[22:37:16] <jmkasunich> /proc/devices shows ramdisk as the only block device
[22:39:45] <jmkasunich> booting back to old kernel
[22:39:49] <jmkasunich> * jmkasunich hates kernels
[22:49:01] <jmk-solo> does anybody know how I would get boot/config-2.6.20-15-server out of the feisty package linux-image-2.6.20-15-server? I don't think I actually want to install the package....
[22:49:24] <cradek> man dpkg
[22:49:48] <cradek> dpkg -x | --extract filename directory
[22:49:49] <cradek> Extract the files contained by package.
[22:50:09] <jmk-solo> thanks
[22:51:41] <jmk-solo> kinda sucks downloading a 50+ meg package to get one file, but them's the breaks I guess
[22:52:59] <jmk-solo> duh, its only 22meg, I accidentally started downloading the source package
[22:53:04] <jmk-solo> one of those days....
[23:07:32] <jmk-solo> using the config from the fiesty package, I only had to answer 2 questions
[23:09:02] <cradek> and they weren't ominous?
[23:09:39] <jmk-solo> no
[23:09:52] <jmk-solo> we'll see what happens, building now
[23:10:02] <jmk-solo> I'm wondering if I'm going about this the wrong way though
[23:10:09] <jmk-solo> maybe I should just use Fiesty?
[23:14:19] <cradek> that would sure work too
[23:14:39] <cradek> but I'd probably try installing just the kernel package first
[23:15:00] <jmk-solo> I was just thinking about what happens if I get the kernel working, but it doesn't play nice with the rest of dapper
[23:15:19] <cradek> I suspect it'll be fine
[23:29:36] <jmk-solo> this is cool:
http://www.ubuntu.com/news/dell-to-offer-ubuntu
[23:30:20] <cradek> yep
[23:30:30] <cradek> that may have come out of some of the antitrust stuff
[23:30:37] <cradek> previously microsoft did NOT allow that
[23:34:01] <jmk-solo> very interesting - this build took LOTS longer than the previous ones
[23:34:19] <jmk-solo> maybe because it built stuff I need ;-)
[23:40:34] <jmk-solo> woo-hoo!
[23:40:47] <cradek> haha
[23:41:13] <jmk-solo> Linux solo 2.6.20.11-jmk1 #1 SMP Sun May 6 19:07:17 EDT 2007 i686 GNU/Linux
[23:41:32] <cradek> yay
[23:41:46] <jmk-solo> now to figure out the sensors stuff
[23:43:23] <jmk-solo> fooey
[23:43:25] <jmk-solo> Probing for `Andigilog aSC7621'... Success!
[23:43:25] <jmk-solo> (confidence 5, driver `to-be-written')
[23:48:01] <jmk-solo> crap
[23:48:12] <jmk-solo> the coretemp driver still isn't here
[23:48:49] <jmk-solo> there are patches, but they seem to be for 2.6.21
[23:50:30] <cradek> arg!
[23:51:29] <jmk-solo> this is one area where windows users have it easier
[23:51:53] <jmk-solo> cpu temp for this mobo and cpu have been trivial to access for months in doze
[23:53:05] <cradek> the curse of new hardware
[23:55:12] <jmk-solo> yeah
[23:55:19] <jmk-solo> sigh
[23:55:24] <jmk-solo> wasted most of the day
[23:55:34] <cradek> jmk-solo: I thought you changed stepgen.dirsetup etc from periods to nsec? usec?
[23:55:41] <jmk-solo> nsec
[23:55:48] <jmk-solo> for 2.2, not 2.1.x
[23:55:55] <cradek> oh, I was reading the wrong manpage, duh
[23:56:36] <cradek> although the stepgen output is right, I think I'm getting the first step in the wrong direction when it is close to the dir change
[23:56:59] <jmk-solo> I thought I fixed that
[23:57:06] <jmk-solo> (and backported the fix)
[23:57:16] <cradek> no no I think it's a hardware problem
[23:57:32] <cradek> digging up the L297 datasheet now
[23:57:37] <jmk-solo> oh, like setup or hold time or something?
[23:57:43] <cradek> yeah setup
[23:57:49] <jmk-solo> could be
[23:58:07] <jmk-solo> this has me really bummed...
[23:58:16] <cradek> see if the patch applies?
[23:59:02] <jmk-solo> there are a couple, I'm not sure which one to use
[23:59:03] <jmk-solo> http://www.lm-sensors.org/wiki/Devices
[23:59:13] <jmk-solo> quite a way down in the second table
[23:59:23] <jmk-solo> patches 1/3, 2/3, and 3/3
[23:59:38] <jmk-solo> I think 2 and 3 go together, 1 is stand-alone