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