#emc-devel | Logs for 2008-10-31

[00:01:54] <lerman______> lerman______ is now known as lerman
[01:33:09] <jmkasunich> "Xubuntu can be installed with one of 2 CDs, both requiring at least 1.5GB of hard drive space. Installing with the Desktop CD requires 192 MB of RAM"
[01:33:19] <jmkasunich> http://en.wikipedia.org/wiki/Xubuntu
[01:33:34] <jmkasunich> I wonder if we should point the next person looking for "tiny EMC2" that direction
[01:33:44] <SWPadnos> it almost qualifies
[01:34:10] <SWPadnos> I don't think we're doing anything that requires gnome (gtk libraries yes, gnome no)
[01:34:13] <jmkasunich> somewhere around here I have a laptop with the 5.10 or 6.06 era version of xubuntu on it
[01:34:32] <jmkasunich> it user our RT kernel, and runs RT quite nicely
[01:34:58] <jmkasunich> being able to use the same RT kernel as the "heavy" version would be a huge advantage IMO
[01:35:27] <SWPadnos> they're the same other than the default installed apps and desktop environment, AFAIK
[01:35:41] <jmkasunich> yeah, xfce is a lot lighter than gnome
[01:36:20] <jmkasunich> IIRC, I downloaded xubuntu, then used our normal "install.sh" script to add the RT kernel to it
[01:36:32] <jmkasunich> its been a few years since I did that, but IIRC it was pretty painless
[01:36:34] <SWPadnos> yep, that's the procedure
[01:37:30] <cradek> you will get a whole mess of dependencies, but it ought to work fine when you're done
[01:37:31] <jmkasunich> I wonder how many VMs I can have before something gives
[01:38:04] <jmkasunich> I just got another 2G of memory ($27 after rebate, amazing) and as soon as I finish backing up I'm gonna install it
[01:38:10] <SWPadnos> N=VM memory/(main memory-~500M)
[01:38:26] <jmkasunich> thats kind of what I expected
[01:38:28] <SWPadnos> yeah, I just got another 4G for like $44
[01:38:34] <SWPadnos> it's pretty insane
[01:38:44] <jmkasunich> and since ubuntu VMs won't like less than 512, my limit is probalby 7
[01:38:55] <jmkasunich> more than 4G only works with 64 bits, right?
[01:39:07] <SWPadnos> more than 3G or so actually
[01:39:11] <cradek> wrong
[01:39:15] <cradek> per process, yes
[01:39:18] <SWPadnos> unless you use PAE
[01:39:29] <cradek> per machine, you can have more
[01:39:37] <cradek> sorry, not sure which question you were asking
[01:40:06] <jmkasunich> you mean I could have spent a few bucks more and gotten 4G, for a total of 6G in the machine, and ordinary 6.06-i386 ubuntu would be able to use it all?
[01:40:13] <cradek> yes
[01:40:23] <SWPadnos> is that true on "generic" PCs?
[01:40:28] <jmkasunich> glad I didn't open the package
[01:40:39] <cradek> I thought so ...
[01:40:39] <jmkasunich> gotta read mobo specs, see what the max is
[01:40:43] <cradek> for modern ones
[01:41:25] <cradek> I might be on drugs though
[01:41:28] <jmkasunich> intel 975xbx2
[01:41:30] <jmkasunich> 4 slots
[01:42:04] <cradek> The BadAxe2 board works with DDR2 800 MHz memory, but the support is not official by Intel. Up to 8 GB of memory is supported by the 975XBX2
[01:42:06] <jmkasunich> it says "up to 4GB using 512MB or 1GB technology, up to 8GB using 1GB technology"
[01:42:23] <SWPadnos> the CPU is 64-bit, isn't it?
[01:42:34] <jmkasunich> code 2 duo, E6600
[01:43:02] <jmkasunich> I guess CPU width determines the max physical memory
[01:43:08] <SWPadnos> ok, so it's a 64-bit CPU
[01:43:35] <jmkasunich> but the real question is will ubuntu-i386 use it
[01:43:45] <jmkasunich> * jmkasunich asks google
[01:43:47] <cradek> yes surely it will
[01:44:07] <cradek> I have a 6? GB machine running a 2.4 i686 kernel at work
[01:44:42] <SWPadnos> it's certainly possible, but I don't know if the stock or out RTAI kernels support it
[01:44:46] <SWPadnos> s/out/our/
[01:44:56] <cradek> stock there will be one -- our rtai, nope
[01:44:59] <jmkasunich> I don't care about the RTAI kernels
[01:45:49] <cradek> you may have to run -server or -686, not -i386
[01:46:06] <SWPadnos> 686-bigmem, according to this: http://www.linux.com/feature/119287
[01:48:42] <jmkasunich> my kernel is a -686 (and has been for a long time)
[01:49:44] <cradek> $ egrep 'MEM.*G=' /boot/config-`uname -r`
[01:50:05] <jmkasunich> Y
[01:50:13] <cradek> which? 4G or 64G?
[01:50:19] <jmkasunich> (I kn4G
[01:50:22] <jmkasunich> 4G
[01:50:37] <cradek> oops I meant 'MEM.*G'
[01:50:44] <cradek> # CONFIG_HIGHMEM64G is not set
[01:50:57] <cradek> you might need to use -server or -bigmem or however you spell it
[01:51:05] <cradek> to get over 4G
[01:51:37] <jmkasunich> I'll probalby stick with 4 for now
[01:51:38] <SWPadnos> I'd be surprised if it would work without HIGMEM_64G being set
[01:51:51] <cradek> me too
[01:52:12] <jmkasunich> replacing the sticks I just bought would take me from 4 to 6, but the little nagging voice would say "you should replace the other set and have 8"
[01:52:17] <jmkasunich> and then I'd be doing a new kernel
[01:52:32] <jmkasunich> and then the nagging voice would say "you should update to 8.04"
[01:52:44] <jmkasunich> and before you know it I'd spend two weeks farting around
[01:53:04] <cradek> so true
[01:53:36] <jmkasunich> whereas adding the new sticks and rebooting into the existing 4G kernel will take 10-20 mins tops, maybe 30 if I take advantage of the downtime to clean the dust out of the case fan filter
[01:53:56] <SWPadnos> https://bugs.launchpad.net/ubuntu/+bug/179025
[01:54:26] <SWPadnos> apparently there can be problems with PAE on some systems, which is at least part of why it's not enabled by default
[01:54:43] <SWPadnos> also a 2-6% performance hit for everything
[01:54:46] <SWPadnos> 3-6
[01:55:36] <jmkasunich> running the 64bit versions of the OS is still a bit bleeding edge isn't it?
[01:55:47] <SWPadnos> not terribly
[01:55:48] <cradek> nah
[01:56:12] <cradek> you have to really not care about nonfree software though
[01:56:19] <SWPadnos> there may be some things that don't work (I had an issue compiling an ATI driver, for example)
[01:56:26] <cradek> yeah that kind of crap
[01:56:37] <jmkasunich> from that "bug report": Unfortunately not everything works in the 64 bit world. I just reformatted my perfectly good 64 bit install of Ubuntu Hardy because SageTV will not run in 64 bits
[01:56:38] <cradek> flash, eagle, ...
[01:56:42] <jmkasunich> not that I care about TV
[01:56:57] <jmkasunich> eagle the PCB software?
[01:56:59] <SWPadnos> strangely, I can actually access turbotaxweb with my 64-bit firefox on Ubuntu, but it doesn't work on FF in Windows
[01:57:17] <cradek> jmkasunich: untested
[01:57:23] <cradek> jmkasunich: (I don't have any 64 bit stuff)
[01:57:36] <jmkasunich> I think I won't either ;-)
[01:57:41] <jmkasunich> maybe the next PC
[01:57:42] <cradek> but anything you didn't/can't build is suspect
[01:57:46] <jmkasunich> quad core, 8G
[01:57:54] <jmkasunich> 2009 or 10 ;-)
[01:58:08] <SWPadnos> heh - just got one ;)
[01:58:18] <SWPadnos> under $1500, with the fastest video card on the market
[01:58:25] <SWPadnos> and the fastest hard drive
[01:58:25] <jmkasunich> if SWP just got one, then I know I should wait a year or two
[01:58:42] <SWPadnos> well, I waited a while, so next year may be the right time
[01:58:43] <jmkasunich> * jmkasunich likes his raptor drive
[01:58:59] <SWPadnos> yep, that's what I got - the 300G SATA-II version
[01:59:07] <jmkasunich> and antec solo case - that thing is damned quite
[01:59:08] <cradek> ha
[01:59:09] <jmkasunich> quiet
[01:59:30] <cradek> I wish they still made exactly that case
[01:59:35] <cradek> they keep fuxing with it
[01:59:45] <jmkasunich> the PC is on the desktop, not down on the floor, about 18" from my ears, and I cannot hear it
[02:00:36] <SWPadnos> I was pretty amazed at the WD "green" hard drives
[02:00:45] <jmkasunich> ok, backups done
[02:00:53] <jmkasunich> 130 days of uptime, about to bite the bullet
[02:00:54] <cradek> * cradek grits his teeth and cvsups the lathe
[02:00:58] <SWPadnos> I had one on my lap, connected to a USB<->SATA interface. when I powered it up, I couldn't tell by fell or sound that ir was running
[02:01:13] <SWPadnos> or feel (geez)
[02:05:54] <SWPadnos> heh - I never see jmk's sign-off message :)
[02:09:43] <cradek> hi seb
[02:14:32] <seb_kuzminsky> hiya!
[02:29:18] <cradek> seb_kuzminsky: photo of the completed knobs on timeguy.com (better camera!)
[02:30:07] <jmkasunich> bah humbug
[02:30:09] <jmkasunich> MemTotal: 3364208 kB
[02:30:22] <seb_kuzminsky> cradek: nice work!
[02:30:24] <jmkasunich> BIOS says I have 4G, linux doesn't want to use it
[02:30:29] <seb_kuzminsky> those look great
[02:30:32] <cradek> seb_kuzminsky: thanks
[02:30:39] <jmkasunich> what'd I miss? knobs?
[02:30:46] <cradek> jmkasunich: new photo on timeguy.com
[02:30:50] <seb_kuzminsky> chris is showing us his knobs
[02:30:54] <cradek> (I finished them)
[02:31:00] <SWPadnos> jmkasunich, the HIGHMEM4G option should be set, but you might need a boot parameter to turn it on or something
[02:31:36] <jmkasunich> I also seem to have wasted a whole $7
[02:31:46] <jmkasunich> that was the difference between 5-5-5-18 and 4-4-4-12 RAM
[02:32:13] <jmkasunich> but the BIOS only has one set of timings, and the ram in there already was 5-5-5-18, so both banks are running at that speed
[02:32:14] <SWPadnos> if your present memory is 5-5-5-18, then the 4-4-4-12 shouldn't help on the second bank
[02:32:17] <SWPadnos> right
[02:32:24] <cradek> it's only important if you can buy a pizza with the difference
[02:32:43] <SWPadnos> almost 3 slices at Costco (which is about half a pizza)
[02:32:56] <jmkasunich> I don't regret the $7
[02:33:05] <jmkasunich> I'm a bit annoyed that I won't get the speed tho
[02:33:24] <jmkasunich> much more annoyed about the 3.3G - gotta figure out how to fix that
[02:35:44] <jmkasunich> "the PCI hole"
[02:42:26] <SWPadnos> it appears that the solution is to use the -server kernel instead of -generic, but apparently that can cause problems with VMWare (you'd at least need to recompile the kernel-specific modules)
[02:42:50] <cradek> you always have to do that anyway with vmware
[02:43:04] <jmkasunich> when you install
[02:43:09] <SWPadnos> and when you change kernels
[02:43:14] <jmkasunich> true
[02:43:35] <jmkasunich> which I just did, since there has been a "you need to reboot since we upgraded the kernel" icon showing for a few months
[02:43:44] <SWPadnos> heh
[02:44:06] <SWPadnos> sometimes, it's better to actually reboot when they tell you to (even though it screws uptimes)
[02:44:12] <jmkasunich> conveniently, I did an upgrade right before shutting down, which brought in another new kernel
[02:44:21] <jmkasunich> I'm at -52 now
[02:44:51] <SWPadnos> apparently you end up filling memory (and to a lesser extent disk) with older library versions that are still in use by something that didn't get shut down
[02:45:12] <jmkasunich> if you don't reboot?
[02:45:27] <SWPadnos> yep
[02:46:19] <SWPadnos> since files are guaranteed to be available as long as they're open (including in-use .sos), they may not go away from memory or disk unless all processes get shut down
[02:49:16] <jmkasunich> logger_dev: bookmark
[02:49:16] <jmkasunich> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-10-31.txt
[02:52:08] <jmkasunich> I should just be able to apt-get linux-image-, right?
[02:52:32] <SWPadnos> you probably shouldn't specify the version, if you want to get updates
[02:52:46] <SWPadnos> and you should get both linux-image-server (or whatever) and its headers
[02:53:15] <SWPadnos> argh. I have an annoying itch in the inaccessible place on my back
[02:53:39] <jmkasunich> make like a bear - find the nearest tree with a protruding branch at the right height
[02:53:53] <SWPadnos> well, it's under a bandage since it's probably from the surgery I had on Monday
[02:54:05] <SWPadnos> so scraping too hard is contra-indicated
[02:54:12] <jmkasunich> oh, I suppose you want to go gentle with the tree then
[02:54:16] <SWPadnos> heh
[02:55:40] <SWPadnos> oooh - interactive shell access on SF
[02:56:17] <SWPadnos> oh - not added, replaced with some web-ish things
[02:56:46] <SWPadnos> or something.
[02:58:57] <jmkasunich> http://www.enterprisenetworkingplanet.com/img/examples/ubuntu_server_config_diff.html
[03:03:45] <jmkasunich> hmm, seems that there may be nvidia driver issues with -server (what else is new)
[03:03:50] <jmkasunich> * jmkasunich checks xorg.conf
[03:17:03] <lerman______> lerman______ is now known as lerman
[03:20:55] <jmkasunich> is it expected that the 'nv' driver can't run glxgears?
[03:21:01] <jmkasunich> jmkasunich@mahan:~$ glxgears
[03:21:01] <jmkasunich> Xlib: extension "GLX" missing on display ":0.0".
[03:21:01] <jmkasunich> Error: couldn't get an RGB, Double-buffered visual
[03:21:01] <jmkasunich> j
[03:21:20] <SWPadnos> no, it's expected to be able to run
[03:21:37] <jmkasunich> the nvidia driver didn't work at all, left me in text mode, so I changed to nv
[03:21:56] <jmkasunich> the server kernel does give me 4G
[03:22:08] <SWPadnos> sudo dpkg-reconfigure -phigh xserver-xorg
[03:26:33] <jmkasunich> does that back up the existing xorg.conf?
[03:26:43] <SWPadnos> dunno
[03:26:51] <SWPadnos> that's simple enough though ;)
[03:27:12] <jmkasunich> yep, done
[03:30:52] <jmkasunich> it saw that I had modified xorg.conf, and backed it up
[03:48:24] <jmkasunich> if I'm running the nv driver, this seems odd:
[03:48:38] <jmkasunich> (II) LoadModule: "glx"
[03:48:38] <jmkasunich> (II) Loading /usr/lib/xorg/modules/libglx.so
[03:48:38] <jmkasunich> (II) Module glx: vendor="NVIDIA Corporation"
[04:14:14] <jmkasunich> have I ever mentioned that I hate computers
[04:14:52] <jmkasunich> back to the stock kernel, back to the original xorg.conf, still no GLX, and now my mouse is acting squirrely
[04:15:13] <jmkasunich> going back to the -51 kernel
[04:44:02] <jmkasunich> I can't even run memtest (even after removing the new memory)
[04:44:03] <jmkasunich> http://forum.x86-secret.com/showthread.php?t=4718
[04:44:28] <jmkasunich> apparently a well known problem with grub 0.97
[04:45:00] <jmkasunich> how does a 20 minute job wind up taking all night?
[04:45:19] <jmkasunich> fsck this chit,
[05:05:56] <lerman______> lerman______ is now known as lerman
[12:30:49] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/System_Requirements.lyx: add file
[12:37:10] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Getting_Started.lyx: add sys req and update html
[12:37:10] <CIA-37> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/System_Requirements.lyx: add file
[12:37:10] <CIA-37> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Getting_Started.lyx: add sys req
[12:39:57] <cradek> jmkasunich: http://www.xkcd.com/349/
[12:40:14] <jepler> I bet I remember that comic
[12:40:17] <jepler> * jepler checks
[12:40:57] <cradek> oh heck, am I supposed to be going to work?
[12:40:58] <jepler> (hm, it would be better if the last line of dialog was removed)
[12:41:01] <jepler> cradek: only if you want a bagel
[12:41:09] <cradek> mmmm bagel
[12:41:26] <cradek> I don't know how you do it.
[12:42:07] <cradek> bbl...
[13:05:54] <alex_joni> lol @ xkcd
[14:51:48] <jepler> halcmd: show pin sampler.0.pin.0
[14:51:48] <jepler> Component Pins:
[14:51:48] <jepler> Owner Type Dir Value Name
[14:51:48] <jepler> 3 undef IN undef sampler.0.pin.0
[14:51:50] <jepler> hm this isn't right
[14:54:03] <jepler> (local modifications)
[14:54:15] <cradek> what are you working on?
[14:54:35] <jepler> trying to see what breaks when hal_float is a double
[14:54:40] <cradek> ah
[14:54:55] <jepler> so far there are some obvious things that do -- streamer, sampler, halscope all have "hal_float_t is float" assumptions in them
[14:55:24] <cradek> oh you don't mean atomicity, you mean basic coding problems
[14:55:39] <jepler> yes
[14:56:55] <jepler> and this raises questions I haven't considered before -- for instance, halscope has to move hal_float_t-sized values around, but it can't use the hal_float_t type to do it since it might be in a thread without fp
[14:58:48] <SWPadnos> you need a "hal_float_sized_int_type"
[14:59:57] <jepler> yes, that is a minimum
[15:00:11] <jepler> there's also the question of how to move that type atomically
[15:00:25] <jepler> even if I believe the problem of moving a double atomically can be dismissed
[15:00:39] <jepler> warning: 'error' might be used uninitialized in this function
[15:01:35] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/opto_ac5.c: fix warning
[15:06:25] <SWPadnos> I wonder if gcc is smart enough to just set error=(the first export function) (ie, skip the initialization since "if (!error)" is guaranteed to be true)
[15:11:19] <jepler> it seems like a perverse optimizer would look at what initial value for the undefined variable would give the least/fastest code
[15:15:36] <SWPadnos> the original case shouldn't be optimized, but the modification you made should make it optimizable
[15:16:00] <jepler> * jepler kicks CIA-37
[15:16:00] <CIA-37> ow
[15:17:43] <jepler> SWPadnos: if the optimizer chose to treat the undefined initial value of 'error' as 1, then it could skip both 'if(!error)' comparisons and both if-bodies.
[15:18:12] <jepler> that's what I'm suggesting a perverse optimizing compiler might try to do: find the value to treat an uninitialized value as so that the least or fastest code is generated
[15:18:13] <SWPadnos> heh, sure
[15:18:22] <SWPadnos> right, I understood that :)
[15:19:05] <jepler> are all the tests back to passing on trunk?
[15:19:10] <SWPadnos> but they'd be optimizing away clever hacks that use the previously executed function in perverse ways by explicitly not initializing
[15:21:36] <cradek> jepler: would you look at emccanon.cc:1490 please. does C++ mean the emc_spindle_on_msg.factor is initialized somehow or is it a bug that we don't set a 0 here?
[15:23:51] <jepler> cradek: it is initialized to 0. Look at the definition of the class:
[15:23:52] <jepler> class EMC_SPINDLE_ON:public EMC_SPINDLE_CMD_MSG {
[15:23:52] <jepler> public:
[15:23:52] <jepler> sizeof(EMC_SPINDLE_ON)),
[15:23:54] <jepler> speed(0), factor(0), xoffset(0) {
[15:24:10] <jepler> factor(0) means that at construction time, the field called 'factor' is initialized with '0'
[15:24:22] <cradek> aha, I didn't think to look at the constructor, thanks
[20:23:19] <cradek> jepler: finally, when I wasn't looking for it, I noticed what's odd about the "run anyway" dialog: escape doesn't cancel it
[21:28:05] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/nml_intf/ (motion_types.h emc.hh):
[21:28:05] <CIA-37> EMC: As discussed on emc-developers: wait for the spindle to be "at speed" (as shown
[21:28:05] <CIA-37> EMC: by a hal input to motion) in these cases: before the first feed move after each
[21:28:05] <CIA-37> EMC: spindle start or speed change; before the start of every chain of
[21:28:05] <CIA-37> EMC: spindle-synchronized moves; and if in CSS mode, at every rapid->feed transition.
[21:28:08] <CIA-37> EMC: This checkin also fixes a problem aborting while waiting for spindle index (or
[21:28:10] <CIA-37> EMC: at-speed).
[21:28:12] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/motion/ (command.c control.c mot_priv.h motion.c motion.h):
[21:28:15] <CIA-37> EMC: As discussed on emc-developers: wait for the spindle to be "at speed" (as shown
[21:28:17] <CIA-37> EMC: by a hal input to motion) in these cases: before the first feed move after each
[21:28:19] <CIA-37> EMC: spindle start or speed change; before the start of every chain of
[21:28:21] <CIA-37> EMC: spindle-synchronized moves; and if in CSS mode, at every rapid->feed transition.
[21:28:23] <CIA-37> EMC: This checkin also fixes a problem aborting while waiting for spindle index (or
[21:28:25] <CIA-37> EMC: at-speed).
[21:28:29] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/kinematics/ (tc.h tp.c tp.h):
[21:28:31] <CIA-37> EMC: As discussed on emc-developers: wait for the spindle to be "at speed" (as shown
[21:28:35] <CIA-37> EMC: by a hal input to motion) in these cases: before the first feed move after each
[21:28:37] <CIA-37> EMC: spindle start or speed change; before the start of every chain of
[21:28:39] <CIA-37> EMC: spindle-synchronized moves; and if in CSS mode, at every rapid->feed transition.
[21:28:43] <CIA-37> EMC: This checkin also fixes a problem aborting while waiting for spindle index (or
[21:28:45] <CIA-37> EMC: at-speed).
[21:39:06] <cradek> well that was pretty invasive - I hope I didn't break anything.
[21:40:09] <SWPadnos> bah, it's only 10 files, what could you have harmed?
[21:40:59] <cradek> ... the planner
[21:42:52] <SWPadnos> oh, well I'm sure someone will pipe up if you've broken anything
[21:43:10] <SWPadnos> presumably you need to set some input pin to 1 to get the old behavior?
[21:44:58] <cradek> it defaults to 1
[21:46:10] <cradek> so if you do nothing, you will only notice new bugs, not new features
[21:47:32] <SWPadnos> excellent
[21:49:45] <lerman______> lerman______ is now known as lerman