Back
[11:13:43] <pcw_home> hmm, what is the state of an unknown bit?
[11:20:11] <seb_kuzminsky> it is equal to banana
[11:23:20] <pcw_home> not sure how that encoded in 1 bit
[12:08:05] <archivist> 42
[12:08:21] <cradek> it contains how long a stick is
[12:10:20] <pcw_home> wheres the hal pin metadata when you need it
[12:10:55] <cradek> what are you trying to do?
[12:12:23] <pcw_home> probably the wrong thing
[12:13:36] <cradek> sure but which wrong thing?
[12:13:37] <pcw_home> so if we lose comms with a remote device should we force the return data to a certain state?
[12:14:18] <cradek> hmm
[12:14:45] <cradek> seems like yes, but that leads to a harder question
[12:14:58] <pcw_home> Yes
[12:17:04] <seb_kuzminsky> is there a .data-is-valid pin coming out of your component?
[12:17:27] <pcw_home> No but there probabl should be
[12:20:47] <pcw_home> it gets a bit messy since we may want to gloss over short outages
[12:32:32] <seb_kuzminsky> debounce
[12:50:59] <pcw_home> yeah but unless theres a global debounce option, this has to happen in the driver
[13:02:33] <seb_kuzminsky> in the driver is probably a good place for it (because it makes things simple for the user and they can't mess it up), but you also have the option of adding a debounce component in hal
[15:57:42] <seb_kuzminsky> http://pastie.org/9820924
[16:03:12] <seb_kuzminsky> that should fix the PAE memory issue Gene reported
[16:05:36] <seb_kuzminsky> i wonder if i need to bump the abi number and recompile everything and have a giant flag day?
[16:05:58] <seb_kuzminsky> i think pointers are still 32 bits, except for somewhere deep in the page map system
[16:06:31] <seb_kuzminsky> i'm sure userspace doesn't care, but what about kernel modules (like the rtai modules, and our rtai realtime components)?
[16:08:46] <seb_kuzminsky> in case anyone wants to try it:
http://highlab.com/~seb/linuxcnc/linux-image-3.4-9-rtai-686-pae_3.4.55-5linuxcnc_i386.deb
[17:14:27] <seb_kuzminsky> hmm, when i boot the 5linuxcnc kernel (the one where i added pae), i can no longer insmod rtai_hal.ko
[17:14:37] <seb_kuzminsky> rtai_hal: disagrees about version of symbol module_layout
[17:15:04] <seb_kuzminsky> that rtai_hal.ko was built against a pre-pae linux-image
[17:21:38] <seb_kuzminsky> looks like our choices are:
[17:22:03] <seb_kuzminsky> 1. live without PAE until we make the next kernel (ie, a kernel newer than 3.4.55-rtai)
[17:22:41] <seb_kuzminsky> 2. make a new kernel with PAE and a new ABI, linux-image-3.4-10-rtai-686-pae, rebuild the rtai-modules, and start building linuxcnc against that instead
[17:23:23] <seb_kuzminsky> if we go with option 2, users can stay with the current kernel and the current version of linuxcnc (ie not update either one)
[17:23:33] <seb_kuzminsky> or they can update both
[17:24:06] <seb_kuzminsky> if we go with 2, i'd switch the rtai buildslaves to the new pae-enabled kernel and we'd start producing linuxcnc debs that only work on that kernel
[17:24:11] <seb_kuzminsky> i dont like either option :-(
[17:35:31] <PCW> wait for 2.7?
[17:37:45] <seb_kuzminsky> i use the same buildslaves for all branches of linuxcnc
[17:42:08] <PCW> arghh
[17:42:26] <seb_kuzminsky> i'm thinking we should wait for jessie & a new RTAI kernel, and just acknowledge that our "686-pae" kernel doesn't do pae
[17:42:31] * seb_kuzminsky <-- dunce
[17:43:48] <seb_kuzminsky> either that or a flag day for wheezy and precise
[17:46:37] <PCW> Yeah not sure why you would need more than 4G on a machine controller
[17:47:30] <PCW> maybe rename the existing kernel to avoid confusion
[17:55:50] <seb_kuzminsky> yeah
[17:56:49] <PCW> and tell gene to get another computer for home server or whatever he's using it for :-)
[22:09:06] <seb_kuzminsky> Ben Hutchings (of the debian kernel team) confirms what Gene and I discovered: changing kernel flavor (such as enabled PAE) changes the kernel ABI
[22:26:42] <skunkworks> Doesn't using QBL fix that in the FDE sense?
[22:44:32] <seb_kuzminsky> skunkworks: hmm, maybe the quantified bidder's list *would* fix the module versioning problem, in the full-disk encryption sense
[22:54:08] <skunkworks> seb_kuzminsky: only if you take into account the bit range between installed vs applied dynamic layering of the base processing.
[22:58:47] <cradek> I don't see what's wrong with option #2. you could just use apt dependencies to make them install together?
[22:59:47] <memfrob> jessie uses kernel 3.16 and rtai works on 3.16 :) rt for jessie is done!
[23:00:09] <cradek> on the other hand, I don't think this matters, especially if it's all because of gene's incorrect belief that something is wrong if his machine ever swaps anything out
[23:41:00] <seb_kuzminsky> i agree swapping is normal and good, even in high-memory-free systems
[23:41:48] <seb_kuzminsky> the drawback with option 2 is fresh installs need one more reboot, and between the initial upgrade and the subsequent reboot, linuxcnc will fail to start, and with unhelpful error messages
[23:44:55] <cradek> a simple cd regen would fix that
[23:46:07] <seb_kuzminsky> yep, good point
[23:52:47] <seb_kuzminsky> users have the same problem if they have an existing install & they upgrade. they'll get the new linux-image, rtai-modules, and linuxcnc debs, and until they reboot nothing will work
[23:53:31] <mozmck> Can more than one HAL_IO pin be connected together?
[23:55:43] <mozmck> I think the package manager notifies users to reboot if a new kernel is installed.
[23:55:59] <seb_kuzminsky> mozmck:
http://linuxcnc.org/docs/html/hal/basic_hal.html#_net_a_id_sub_net_a
[23:56:18] <seb_kuzminsky> i think that says: a net (signal) can have any number of In and IO pins, but at most one Out pin
[23:57:12] <mozmck> oh, duh! I did not read down far enough - thanks seb.
[23:58:07] <seb_kuzminsky> we dont have a linux-image-rtai meta-package, so deliberate user action is required to upgrade from 3.4-9 to a hypothetical 3.4-10 kernel
[23:58:48] <seb_kuzminsky> mozmck: sometimes our docs are a little disorganized and hard to search
[23:59:07] <mozmck> I'm finding that to be true with the HAL manual :)