Back
[00:26:08] -!- hive8 has quit [Ping timeout: 240 seconds]
[00:55:09] -!- morfic has quit [Read error: Connection reset by peer]
[01:01:24] -!- Roguish has quit [Remote host closed the connection]
[01:05:51] <jepler> that message indicates something has gone wrong in kernel memory management. The value passed as the first argument to krealloc doesn't seem to be a valid pointer from a prior memory allocation..
[01:05:56] <jepler> more than that I can't say
[01:06:10] <jepler> (andypugh's oops)
[01:06:29] <andypugh> Ah, hi.
[01:06:56] <andypugh> krealloc is meant to be able to initialise memory too.
[01:07:31] <andypugh> ie, it is identical to kmalloc for uninitialised pointers.
[01:08:22] <andypugh> There was, however, something rather odd happening, as the data moved in memory every time it was krealloced.
[01:08:32] <jepler> no. If the first argument is 0, it's like kmalloc .. but if it's just uninitialized (i.e., junk) then that's bad
[01:08:37] <andypugh> I have not seen that before.
[01:09:13] <andypugh> The code seems to be working fine in the released version.
[01:09:15] -!- rob_h has quit [Ping timeout: 256 seconds]
[01:09:25] <jepler> krealloc in at least some cases will move the data (return a pointer not equal to the passed in pointer)
[01:09:27] -!- factor has quit [Read error: Connection reset by peer]
[01:09:46] <andypugh> But I would very much appreciate it if you could have a look in case it is actually broken and I have messed up
[01:09:59] <jepler> for example if object X is 4 bytes at 0x100 and object Y is 4 bytes at 0x104, then to reallocate X to 8 bytes means moving it
[01:11:27] <andypugh> hal/drivers/mesa-hostmot2/mesa_autoconf.c line 266. If there is a problem there then I need to shift my priorities
[01:13:33] -!- i_tarzan has quit [Ping timeout: 246 seconds]
[01:13:37] <andypugh> Yes, I understand that krealloc will sometimes need to move things, but my experience is that it normally doesn't. I was seeing it moving every time (and flagging a warning that became a problem). I am wondering if it is something a bit technical, like wear-balancing on the SSD?
[01:13:40] <jepler> at line 266 do you know that chan->conf is either NULL or a pointer returned from an earlier memory management API like kmalloc or krealloc?
[01:14:03] -!- toastyde1th has quit [Read error: Connection timed out]
[01:14:24] <jepler> around line 64 you seem to assume this is not true for other fields in chan, like chan->num_confs
[01:15:08] <andypugh> I think it is NULL to that point. But that might be a false assumption. Do I have to explicitly zero memory in newly-created structs?
[01:15:42] <jepler> [ 991.975361] hm2/hm2_5i25.0: Before krealloc, &chan->confs[0]=c057f540
[01:16:06] <jepler> you printed the value, so you know it's not NULL
[01:16:43] <andypugh> Now you point it out..
[01:17:26] <jepler> Whether memory from an allocator is 0'd out when you get it depends on the allocator. For instance, in userspace C, malloc() gives memory filled with undefined values and calloc() gives memory filled with '0' bytes
[01:17:48] <jepler> I don't know what allocator 'chan' came from so I don't know whether the expectation of 0ness is right or wrong
[01:19:01] <andypugh> I think it is line 51 in that file
[01:19:37] <andypugh> (sorry for the vagueness, but I am in the middle if a huge reorganisation of this stuff)
[01:20:28] <andypugh> So I am looking at a file about to be deleted, referencing a struct that no longer exists in my live code)
[01:21:14] -!- i_tarzan has quit [Read error: Connection reset by peer]
[01:21:49] <jepler> I can't immediately find any documentation that says that memory returned by kalloc has been zero'd out.
[01:22:53] <jepler> If that's the case, you could for instance use memset to set the whole allocation to 0, or chan->confs = 0 (or NULL) to set just the one field to 0, or use kmalloc instead of krealloc at the site where you make the allocation
[01:24:06] <andypugh> True.
[01:25:26] <andypugh> I wonder if (and why) this causes a problem? It was a bit odd, in that sometimes it would work and make me think I had it fixed.
[01:25:55] <jepler> I hesitate to speculate
[01:26:14] <andypugh> How does krealloc work out whether a given memory segment has room?
[01:27:11] <andypugh> I have actually re-written the code to run through twice, once to count the pin definitions, and then again after a conventional kmalloc to do the work.
[01:28:08] <jepler> the memory allocator keeps information about the size of each allocated block. There are lots of different designs that can facilitate this, and I don't know the details in linux these days
[01:28:17] <andypugh> If the real problem was that kmalloc can't spot that the pointer it has been given is junk, then perhaps I should revert that and meset instead. I do prefer the once-through method.
[01:28:51] <andypugh> But it's quite a bit of work to revert it then find it is still broken.
[01:28:56] <jepler> for instance, one very simple scheme is to have just before each block a structure which gives the size of this block and the pointer or offset to the next block
[01:29:21] <jepler> I suspect the linux system is much more complicated than that
[01:29:27] -!- asdfasd has quit [Ping timeout: 252 seconds]
[01:30:35] <andypugh> I guess what I should do is branch my code, try reverting that part, and merge if Iike it?
[01:30:45] <jepler> this article describes the 'slub' allocator, which was called out in your error messages. But it's from 2007 so I have no idea how pertinent it is to a 2010 kernel.
https://lwn.net/Articles/229984/
[01:30:56] <jepler> that is one possibility.
[01:31:40] <jepler> (such clever people, having slab, slub and slob memory allocators.. and probably slib, sleb, slyb and slwb by now)
[01:32:06] <andypugh> You know you are in the wild fringes when man kmalloc and man krealloc return nothing.
[01:32:28] <alex4nder> real men operate in kernel space
[01:32:35] <alex4nder> (and cry like women when things go wrong)
[01:33:31] <jepler> hm. the internet does have manpages for kmalloc (e.g.,
http://www.fiveanddime.net/man-pages/kmalloc.9.html) but who knows what kernel they're related to.
[01:34:10] <jepler> or if that's even a linux manpage; a bunch of the rest look like bsd
[01:34:30] <jepler> bbl and good luck
[01:35:48] <andypugh> Thanks. I am almost relieved that the causes of my travails are at least a bit non-trivial
[02:02:56] -!- i_tarzan has quit [Read error: Operation timed out]
[02:26:15] -!- toastyde1th has quit [Read error: Connection timed out]
[02:26:44] <andypugh> jepler: When you get back. I am struggling to find any good reason not to find/replace every kmalloc in the LinuxCNC source with a kzalloc.
[02:31:26] -!- JT-Shop has quit [Read error: Network is unreachable]
[02:31:46] -!- jthornton has quit [Read error: No route to host]
[02:31:56] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[02:32:00] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[02:32:10] -!- JT-Left has quit [Read error: No route to host]
[02:35:43] -!- JT-Left1 has quit [Read error: Connection reset by peer]
[02:35:48] -!- JT-Shop has quit [Read error: Connection reset by peer]
[02:35:53] -!- jthornton has quit [Read error: Connection reset by peer]
[02:36:20] -!- kurt_ek has quit [Remote host closed the connection]
[02:46:09] -!- hive8 has quit []
[03:00:02] -!- toastyde1th has quit [Read error: Connection reset by peer]
[04:04:27] -!- ve7it has quit [Remote host closed the connection]
[04:08:45] -!- tjb1 has quit [Quit: tjb1]
[04:12:00] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[04:12:00] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[04:21:44] -!- toastyde1th has quit [Read error: Connection reset by peer]
[04:52:02] -!- taiden has quit [Quit: taiden]
[04:52:02] -!- andypugh has quit [Quit: andypugh]
[05:04:12] -!- Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:10:30] -!- JT-Left has quit [Read error: Connection reset by peer]
[05:10:30] -!- JT-Shop has quit [Read error: Connection reset by peer]
[05:10:30] -!- jthornton has quit [Read error: Connection reset by peer]
[05:24:09] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[05:24:10] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[05:35:49] -!- jthornton has quit [Ping timeout: 248 seconds]
[05:36:07] -!- JT-Left has quit [Ping timeout: 264 seconds]
[05:36:21] -!- JT-Shop has quit [Ping timeout: 248 seconds]
[05:41:51] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[05:42:32] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[05:50:51] -!- JT-Left has quit [Read error: Connection reset by peer]
[05:50:51] -!- jthornton has quit [Read error: Connection reset by peer]
[05:53:04] -!- JT-Shop has quit [Ping timeout: 245 seconds]
[06:17:51] -!- factor has quit [Read error: Connection reset by peer]
[06:18:59] -!- FinboySlick has quit [Quit: Leaving.]
[06:40:28] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[06:40:34] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[06:43:08] -!- dimas has quit [Ping timeout: 240 seconds]
[07:08:42] -!- hive8 has quit [Ping timeout: 244 seconds]
[07:24:33] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[07:33:39] -!- iwoj has quit [Quit: Computer has gone to sleep.]
[07:34:58] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[08:21:39] cylly2 is now known as Loetmichel
[08:50:31] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[09:12:41] -!- rob_h [rob_h!~rob_h@5e046419.bb.sky.com] has joined #linuxcnc-devel
[10:11:42] -!- rob_h has quit [Ping timeout: 255 seconds]
[10:13:32] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[10:15:08] kent is now known as Guest61747
[10:19:00] Guest61747 is now known as OoBIGeye
[10:26:29] -!- maximilian_h [maximilian_h!~bonsai@stgt-5f709c9e.pool.mediaWays.net] has joined #linuxcnc-devel
[10:26:31] -!- maximilian_h has quit [Client Quit]
[10:48:25] -!- rob_h [rob_h!~rob_h@5e015cea.bb.sky.com] has joined #linuxcnc-devel
[11:00:45] -!- morfic has quit [Read error: Connection reset by peer]
[11:14:08] -!- mhaberler has quit [Quit: mhaberler]
[11:19:42] -!- sumpfralle has quit [Read error: Connection reset by peer]
[12:03:19] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[12:15:30] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[12:21:42] -!- andypugh has quit [Quit: andypugh]
[12:29:27] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[12:43:52] -!- factor has quit [Ping timeout: 265 seconds]
[12:51:37] -!- micges [micges!~micges@adcw252.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[13:22:25] <jthornton> I've written a converter from the mach xml to stepconf xml but I'm stumped on what to do with <property name="md5sums"
[13:23:16] <jthornton> it seems that if a valid line is there stepconf will open the xml file but will revert to default if it is a bad value
[13:23:25] <jthornton> any way to work around this?
[13:37:59] <cncbasher> John, are you wanting to check the md5 sum ? see
http://www.fourmilab.ch/md5
[13:44:02] <cncbasher> or perhaps test or always make the result 0
[13:54:17] -!- hive8 has quit [Ping timeout: 244 seconds]
[13:55:40] <jthornton> I'm not sure what the stepconf wizard wants from it
[13:56:32] <jthornton> it writes three file names with md5sums to that property in the xml file then when you open the wizard up it checks to see if they have been modified
[14:01:13] <jthornton> I'm doing some speariments now to see if I can fool the wiz
[14:03:37] <cncbasher> all md5 will do probably is to check if the files been altered , as it's coming from windows and md sums are not usualy used , i'd just fudge it to return o
[14:04:58] <jthornton> I don't think you understand the problem... the xml file that stepconf uses has some file names and md5sums in it, if they do not exist the the stepconf wizard throws an error
[14:05:05] -!- psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[14:05:47] <jthornton> when I create the stepconf xml file from the data in the mach xml file I don't have the data to put in that property
[14:07:03] <jthornton> File "<string>", line 1
[14:07:04] <jthornton> [(README', '85848a50bcfbf6017a5c2e1ee60e6a3e'))]
[14:07:04] <jthornton> ^
[14:07:04] <jthornton> SyntaxError: invalid syntax
[14:07:53] <jthornton> I may have made an error in the syntax
[14:09:51] <jthornton> wow, I think I solved it!
[14:10:36] <jthornton> only to find another problem...
[14:16:19] <cncbasher> yea so you need to run md5sum to give you the value
[14:18:29] <jthornton> yea, I think I'm past that and actually have stepconf wizard generating a new config from the converted from mack config
[14:19:16] <jthornton> [(README', '85848a50bcfbf6017a5c2e1ee60e6a3e'))] should have been [('README', '85848a50bcfbf6017a5c2e1ee60e6a3e')]
[14:19:35] <jthornton> and as long as I have that it ignores the other
[14:19:56] <jthornton> and creates a new .stepconf
[14:21:22] <cncbasher> great keep going .... your on a roll
[14:22:14] <jthornton> yea, just need to convert the rest of the properties and it is done
[14:46:11] <jthornton> weee step and direction pins done as well as invert
[14:46:49] <cncbasher> your just too good ....
[14:47:31] -!- draig has quit [Ping timeout: 264 seconds]
[14:49:03] <jthornton> more like lucky sometimes
[14:49:30] <cncbasher> if it was not for bad luck , i'd have none
[14:50:29] <cncbasher> are you doing it as an add in to stepconf or seperate app
[14:50:57] <jthornton> just a separate python thing
[14:51:14] <jthornton> it is a one time use AFAIK for a user
[14:51:34] <cncbasher> i'd be interested
[14:52:08] <cncbasher> might help with some querys with people swapping over
[14:52:18] <jthornton> I'll copy you on it when I get close
[14:52:53] <jthornton> it's pretty simple to use
[14:52:59] <cncbasher> ok , got one guy , dont even know the difference between 5v and ground
[14:53:08] <jthornton> python mack.py filename.xml newconfigname
[14:53:34] <jthornton> ouch
[14:53:35] <cncbasher> and he's building a router ..
[14:53:50] <cncbasher> the head moves about 1/2" or more
[14:54:06] <jthornton> you'll put your eye out with that thing lol
[14:54:06] <cncbasher> he's blew the controller already ..
[14:54:18] <cncbasher> haha
[14:54:25] -!- syyl_ws has quit [Quit: Verlassend]
[14:54:49] <cncbasher> metal rails , but wooden uprights
[14:54:59] <cncbasher> all mdf
[14:55:11] <jthornton> I'd like to see a photo of that
[14:55:13] <cncbasher> oh i do get em
[14:55:38] <cncbasher> but we try to help and advise as we all do
[14:56:14] <cncbasher> oh forgot ... plastic router mount
[14:57:18] <cncbasher> remind me your email
[14:57:44] <jthornton> jthornton at gnipsel dot com
[14:59:15] <cncbasher> on it's way
[15:00:02] -!- Sunnyday has quit []
[15:01:51] <jthornton> he must have ran out of 8020 hehe
[15:01:54] <cncbasher> sent you another john
[15:03:16] <cncbasher> precision cut give or take 3/4"
[15:03:49] <jepler> jthornton: try this: <property name="md5sums" type="eval" value="[]"/>
[15:03:53] <jthornton> lol
[15:04:02] <jthornton> thanks jepler
[15:04:13] <jepler> I think that will tell stepconf not to check the md5sums of any files
[15:06:04] -!- DJ9DJ has quit [Quit: DJ9DJ]
[15:08:11] <jthornton> jepler, yes that works thank you
[15:11:57] <jthornton> yikes what a cut
[15:27:10] <jepler> jthornton: welcome
[15:28:07] -!- morfic has quit [Read error: Connection reset by peer]
[15:48:30] <cncbasher> thought you'd like that high tech cut
[15:50:34] -!- Tom_itx has quit [Ping timeout: 272 seconds]
[15:51:43] -!- zlog has quit [Ping timeout: 276 seconds]
[15:53:19] -!- zlog [zlog!~zlog@ip68-102-202-1.ks.ok.cox.net] has joined #linuxcnc-devel
[16:19:19] -!- syyl_ has quit [Ping timeout: 245 seconds]
[16:26:54] -!- DrZimmerman has quit [Remote host closed the connection]
[17:22:11] -!- psha has quit [Read error: No route to host]
[17:22:19] -!- dimas has quit [Ping timeout: 264 seconds]
[17:23:04] -!- psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[17:24:19] -!- skunkworks__ has quit [Ping timeout: 245 seconds]
[17:30:56] -!- heathmanc has quit [Client Quit]
[17:33:18] -!- Roguish [Roguish!~chatzilla@2601:9:1400:73:250:5bff:fe04:62d4] has joined #linuxcnc-devel
[17:37:31] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[17:38:15] -!- mhaberler has quit [Quit: mhaberler]
[17:39:00] <jthornton> cncbasher, do you have any mack xml files laying about?
[17:39:21] <cncbasher> i may have
[17:39:24] <cncbasher> 1 min
[17:44:30] <cncbasher> check your email john
[17:44:55] <jthornton> lol, I was going to send you the python file
[17:48:22] <cncbasher> just sent you another one which is more advanced
[17:48:31] <cncbasher> takes 5 axis
[17:48:47] <jthornton> can't convert more than 4 axis to stepconf
[17:49:58] <cncbasher> arh ... if people are converting from say a smoothstepper then a mesa card or whatever would be needed
[17:51:13] <cncbasher> although i think you can get 5 axis on a parrell port , but not much else ...
[17:51:27] <jthornton> yea, and I think that pncconf is based on the stepconf wizard... dunno if it will open the same xml file
[17:52:10] <cncbasher> yea may need to look at a seperate one for pncconf
[17:52:25] <jthornton> did you get the revised one?
[17:53:01] <cncbasher> yea just got it
[17:53:11] <cncbasher> not looked at it yet
[17:53:45] <jthornton> you can just run it against a mack xml file
[17:54:21] <jthornton> I think the only thing not done is what to do with mack's step pulse and dir pulse
[17:55:30] <cncbasher> i'd leave that out or default to 2000 / 5000 etc
[17:55:53] <jthornton> ok, that makes it easy
[17:57:19] <cncbasher> majority probably are using base line stepper drives anyhow
[17:58:54] <jthornton> I just ran it against the pmdx one and no accel or vel had been set
[17:59:31] -!- iwoj has quit [Quit: Computer has gone to sleep.]
[18:00:18] <jthornton> seems if you don't set them in mack and press save this axis the entries are not even there so I put some values in there so stepconf would load
[18:00:32] <jthornton> try running it on your end
[18:01:32] <cncbasher> just sent you a link to a few more for testing
[18:02:04] <jthornton> ok
[18:02:53] <cncbasher> is it worth testing for a value and if not stick some default in
[18:03:15] <cncbasher> makes it a bit more complex though
[18:03:54] <jthornton> I test for existence of the ones that might not be there
[18:04:12] <jthornton> if it is a running mack config then they will be there
[18:04:24] <jthornton> if it is an example config they might not be there
[18:04:55] <cncbasher> ok got ya
[18:04:57] <jthornton> this applies to accel vel and scale
[18:05:59] -!- tjb1 has quit [Quit: tjb1]
[18:08:54] * jthornton wanders off for a bit
[18:14:07] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[18:22:56] -!- WillenCMD2 has quit [Ping timeout: 245 seconds]
[18:26:07] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 13.0/20120601201853]]
[18:42:10] -!- mhaberler has quit [Quit: mhaberler]
[18:42:46] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has parted #linuxcnc-devel
[18:52:34] -!- factor has quit [Read error: Connection reset by peer]
[18:52:55] -!- hive8 has quit [Ping timeout: 244 seconds]
[18:56:06] -!- James628 has quit [Quit: Page closed]
[18:57:59] -!- hive8 has quit [Client Quit]
[19:05:55] -!- micges has quit [Quit: Leaving]
[19:05:59] -!- vladimirek has quit [Remote host closed the connection]
[19:06:37] -!- tjb1 has quit [Quit: tjb1]
[19:12:38] -!- factor has quit [Read error: Connection reset by peer]
[19:36:27] -!- tjb1 has quit [Client Quit]
[19:59:18] -!- FinboySlick has quit [Quit: Leaving.]
[19:59:55] -!- bedah has quit [Quit: Ex-Chat]
[20:03:17] -!- iwoj has quit [Quit: Computer has gone to sleep.]
[20:03:31] -!- psha has quit [Quit: Lost terminal]
[20:29:33] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has joined #linuxcnc-devel
[20:29:37] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has parted #linuxcnc-devel
[21:01:58] -!- DJ9DJ has quit [Quit: bye]
[21:07:08] -!- mikegg has quit [Ping timeout: 255 seconds]
[21:31:23] -!- _abc_ has quit [Ping timeout: 252 seconds]
[21:34:37] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[21:44:15] -!- Loetmichel has quit [Ping timeout: 250 seconds]
[21:51:06] -!- syyl__ has quit [Quit: Leaving]
[22:44:11] -!- WillenCMD has quit [Ping timeout: 245 seconds]
[23:02:51] -!- Valen has quit [Quit: Leaving.]
[23:05:29] -!- frallzor has quit []
[23:09:51] -!- tjb1 has quit [Quit: tjb1]
[23:16:08] -!- iwoj has quit [Quit: Computer has gone to sleep.]
[23:29:24] -!- brentmore has quit [Quit: brentmore]
[23:38:38] -!- asdfasd has quit [Ping timeout: 245 seconds]