Back
[00:01:03] <PCW> More that 1 PCI card doesn't make much sense anymore with serial expansion
[00:01:05] <PCW> but more than one Ethernet card might be practical on a large machine
[00:01:07] <PCW> where I/O is more distributed
[00:04:49] -!- Nick001-shop has quit [Remote host closed the connection]
[00:08:07] -!- anth0ny_ has quit [Quit: anth0ny_]
[00:09:57] -!- AshKyd has quit [Quit: https://ash.ms/]
[00:09:58] -!- md-2 has quit [Remote host closed the connection]
[00:26:38] -!- Loetmichel2 has quit [Ping timeout: 265 seconds]
[00:33:15] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[00:35:02] -!- jfindley has quit [Ping timeout: 260 seconds]
[00:40:01] -!- per_sonne has quit [Ping timeout: 244 seconds]
[00:54:37] -!- asdfasd has quit [Read error: Connection reset by peer]
[01:00:37] -!- Abyx has quit [Read error: Connection reset by peer]
[01:03:12] <jepler> how does ethernet actually fare in an enclosure full of drives for multi-kW motors and whatnot?
[01:03:31] <jepler> better than untwisted pairs of the I/O rack ribbon cables I suppose
[01:07:58] -!- gyeates has quit [Ping timeout: 248 seconds]
[01:12:53] -!- anth0ny_ has quit [Quit: anth0ny_]
[01:15:11] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[01:33:38] -!- md-2 has quit [Ping timeout: 264 seconds]
[01:34:37] -!- amiri_ has quit [Ping timeout: 246 seconds]
[01:35:10] -!- remstw has quit [Ping timeout: 248 seconds]
[01:39:17] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[01:41:17] -!- per_sonne has quit [Ping timeout: 240 seconds]
[01:42:42] -!- pjm_ has quit [Ping timeout: 250 seconds]
[02:02:35] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:06:37] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[02:09:47] -!- Tecan has quit [Changing host]
[02:35:27] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[02:39:33] -!- membiblio has quit [Quit: Leaving]
[02:43:28] -!- per_sonne has quit [Ping timeout: 256 seconds]
[02:46:51] -!- kwallace has quit [Read error: Connection reset by peer]
[02:47:27] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[02:53:19] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[02:54:14] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[03:05:02] -!- sector_0 has quit [Quit: Leaving]
[03:05:21] -!- kwallace [kwallace!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[03:06:43] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[03:09:02] <pcw_home> Ethernet works fairly well in electrically noisy environments because it has
[03:09:04] <pcw_home> very good common mode rejection
[03:16:05] <pcw_home> It would be better if random dropped packets were tolerable (which requires good timeout accuracy)
[03:16:06] <pcw_home> A flag from the driver that indicates invalid RXData in the current cycle or failure to write data in the previous cycle
[03:16:08] <pcw_home> would also be desirable to allow better error tolerance, For example say to tell the PID loop to skip updates if the
[03:16:09] <pcw_home> read data is invalid
[03:17:12] -!- Mr_Sheesh has quit [Ping timeout: 255 seconds]
[03:26:18] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[03:31:52] -!- anth0ny_ has quit [Quit: anth0ny_]
[03:32:16] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[03:33:34] -!- skunksleep has quit [Ping timeout: 248 seconds]
[03:33:46] -!- anth0ny_ has quit [Client Quit]
[03:37:46] -!- sumpfralle has quit [Quit: Leaving.]
[03:41:31] -!- SpeedEvil has quit [Client Quit]
[03:44:13] <seb_kuzminsky> http://journaltimes.com/news/local/drowning-victim-a-beloved-business-leader/article_d4672b60-d816-5623-88a5-7d562d240c2b.html
[03:44:59] -!- per_sonne has quit [Ping timeout: 244 seconds]
[03:46:52] -!- SpeedEvil has quit [Client Quit]
[03:52:42] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[03:55:51] -!- jfindley has quit [Ping timeout: 264 seconds]
[03:59:03] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:03:39] <pcw_home> :-(
[04:09:58] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:16:19] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:17:41] -!- gredy has quit [Read error: Connection reset by peer]
[04:20:37] -!- FinboySlick has quit [Quit: Leaving.]
[04:21:40] -!- SpeedEvil has quit [Client Quit]
[04:30:00] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:31:57] -!- ve7it has quit [Remote host closed the connection]
[04:37:51] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:43:11] -!- SpeedEvil has quit [Client Quit]
[04:46:30] -!- per_sonne has quit [Ping timeout: 240 seconds]
[04:47:22] <CaptHindsight> wow
[04:49:02] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:55:52] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[04:59:09] <seb_kuzminsky> jepler: 6eb58550 hm2_eth: allow multiple instances (up to 4)
[04:59:30] <seb_kuzminsky> if an init_board() fails, num_boards will be wrong
[05:00:07] <seb_kuzminsky> chances are good the next thing that happens is hm2_eth_probe will get a partially-initialized board and fail, which will cause rtapi_app_main() to fail completely
[05:00:53] <seb_kuzminsky> the iflist kvlist of interfaces that have had their iptables rule installed is clever
[05:00:58] <seb_kuzminsky> megusta.jpg
[05:01:16] <seb_kuzminsky> the error0 target shouln't call hal_exit() because it must have been hal_init() that failed
[05:01:55] <seb_kuzminsky> 491e63fe hostmot2: support split reads
[05:02:49] <seb_kuzminsky> hm2_eth_enqueue_read()'s overloaded size argument is giving me a headache
[05:03:44] <seb_kuzminsky> the call chain of hm2_read_request() calling hm2_queue_read() caling llio->queue_read(size=-1) illustrates my confusion
[05:04:07] -!- md-2 has quit [Ping timeout: 256 seconds]
[05:04:10] <seb_kuzminsky> hm2_queue_read() does not queue a read as its name implies, instead it drains already-queued read requests (by sending them)
[05:04:41] <seb_kuzminsky> it got its name because it calls the llioo's queue_read() in the magic way that means "dont queue a read, instead drain the read queue"
[05:05:32] <seb_kuzminsky> maybe new llio API functions could more cleanly (or less obscurely) take over the jobs of llio->queue_read(size=-1) and (size=-2)? llio->send_queued_reads() and llio->receive_queued_reads() maybe?
[05:05:53] <seb_kuzminsky> i'd say at least this size thing deserves a comment
[05:06:41] <seb_kuzminsky> i like that the way hm2_read_request() is split out from hm2_read() is nice and backwards compatible (i mean if .read_request doesn't get called)
[05:09:35] <seb_kuzminsky> 81ff3fba hm2_eth: in case of failed recv(), show an error
[05:10:08] <seb_kuzminsky> i have nothing nitpicky about names to say about this commit
[05:11:17] <seb_kuzminsky> it's nice that zeroing errno makes the error message in case of short packets sensible
[05:12:38] <seb_kuzminsky> 81ff3fba hm2_eth: in case of failed recv(), show an error
[05:12:41] <seb_kuzminsky> oops
[05:12:49] <seb_kuzminsky> 7be45d77 hm2_eth: make unrecognized boards work
[05:12:52] <seb_kuzminsky> that's the one
[05:13:44] <seb_kuzminsky> hm2_eth_probe boldly violates layers by parsing the IDROM, but i think the end justifies the means
[05:16:14] <seb_kuzminsky> ... and llio.ioport_connector_name[] is only used for printing, no hal pin generation, so ?? is no problem
[05:16:35] <seb_kuzminsky> this concludes my review
[05:16:38] <seb_kuzminsky> nice branch!
[05:21:36] -!- nofxx has quit [Ping timeout: 244 seconds]
[05:21:44] -!- Connor1 [Connor1!~Connor@c-67-187-108-117.hsd1.tn.comcast.net] has joined #linuxcnc-devel
[05:22:31] -!- anth0ny_ has quit [Quit: anth0ny_]
[05:23:03] -!- sysdef has quit [Disconnected by services]
[05:23:24] -!- jaj_ has quit [Ping timeout: 252 seconds]
[05:23:24] -!- Connor has quit [Ping timeout: 252 seconds]
[05:23:25] -!- meryan00 has quit [Ping timeout: 252 seconds]
[05:23:26] -!- spline has quit [Ping timeout: 252 seconds]
[05:23:27] -!- phantoxeD has quit [Ping timeout: 252 seconds]
[05:23:28] -!- theorbtwo has quit [Write error: Connection reset by peer]
[05:23:28] -!- amiri has quit [Ping timeout: 252 seconds]
[05:23:29] splyne is now known as spline
[05:24:02] meryan00_ is now known as meryan00
[05:26:12] -!- furrywolf has quit [Ping timeout: 264 seconds]
[05:40:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 c8b7864 06linuxcnc 10docs/src/Master_Documentation_es.txt docs: fix an include file name in Spanish * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c8b7864
[05:48:24] -!- per_sonne has quit [Ping timeout: 250 seconds]
[06:03:01] -!- erve has quit [Client Quit]
[06:07:25] -!- kwallace [kwallace!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[06:09:02] <linuxcnc-build_> build #1453 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1453 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:10:59] -!- nofxx has quit [Ping timeout: 256 seconds]
[06:18:58] <linuxcnc-build_> build #3275 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3275 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:19:54] <seb_kuzminsky> huh, the test failure on armhf looks weird
[06:20:32] <seb_kuzminsky> it's supposed to print increasing integers that reset back to 1 when they get to 10 or so
[06:20:47] <seb_kuzminsky> but right in the middle it printed this instead:
[06:22:09] <seb_kuzminsky> http://paste.ubuntu.com/11891493/
[06:22:19] <seb_kuzminsky> stray 0 on line 17
[06:22:25] <seb_kuzminsky> maybe my u3 is getting flaky
[06:22:50] <seb_kuzminsky> it's approaching 1 year of uptime, maybe it wants a therapeutic reboot & cool-down
[06:23:12] <seb_kuzminsky> oh and there's a bug in threads.0's checkresult
[06:23:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 f460494 06linuxcnc 10tests/threads.0/checkresult threads.0 test: report correct line number on error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f460494
[06:28:30] -!- GargantuaSauce has quit [Quit: No Ping reply in 180 seconds.]
[06:28:54] -!- redlegion has quit [Ping timeout: 246 seconds]
[06:33:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 974d78e 06linuxcnc 10src/hal/utils/scope.c halscope: fix a printf format string * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=974d78e
[06:33:27] <seb_kuzminsky> g'nite
[06:38:27] -!- gyeates has quit [Ping timeout: 264 seconds]
[06:49:54] -!- per_sonne has quit [Ping timeout: 246 seconds]
[06:52:23] -!- md-2 has quit [Ping timeout: 252 seconds]
[06:53:39] -!- dan2k3k4 has quit [Ping timeout: 255 seconds]
[07:07:48] -!- dan2k3k4k5 has quit [Ping timeout: 265 seconds]
[07:12:46] -!- KimK has quit [Quit: Leaving]
[07:13:01] -!- anth0ny_ has quit [Quit: anth0ny_]
[07:17:58] -!- englishman has quit [Quit: ZNC - 1.6.0 - http://znc.in]
[07:27:54] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[07:28:32] -!- KimK [KimK!~Kim__@ip68-102-188-176.ks.ok.cox.net] has joined #linuxcnc-devel
[07:30:52] -!- mozmck has quit [Read error: Connection reset by peer]
[07:31:55] -!- rob_h [rob_h!~robh@90.207.194.223] has joined #linuxcnc-devel
[07:33:32] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[07:51:54] -!- per_sonne has quit [Ping timeout: 250 seconds]
[08:24:30] -!- robinsz has quit [Ping timeout: 244 seconds]
[08:28:56] -!- arrowbook [arrowbook!~qicruser@117.136.78.25] has joined #linuxcnc-devel
[08:28:57] -!- dan2k3k4k5 has quit [Ping timeout: 246 seconds]
[08:33:24] -!- just_pink_ has quit [Ping timeout: 246 seconds]
[08:36:30] -!- arrowbook has quit [Ping timeout: 256 seconds]
[08:54:22] -!- per_sonne has quit [Ping timeout: 260 seconds]
[09:14:30] -!- arrowbook [arrowbook!~qicruser@117.136.78.83] has joined #linuxcnc-devel
[09:21:26] -!- arrowbook has quit [Ping timeout: 260 seconds]
[09:24:11] -!- dan2k3k4 has quit [Quit: Leaving]
[09:29:29] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[09:54:47] -!- per_sonne has quit [Ping timeout: 240 seconds]
[10:02:02] -!- b_b has quit [Changing host]
[10:11:54] -!- arekm_ has quit [Changing host]
[10:11:56] arekm_ is now known as arekm
[10:25:29] -!- robinsz has quit [Ping timeout: 265 seconds]
[10:53:09] -!- skunkworks has quit [Ping timeout: 246 seconds]
[10:56:01] -!- per_sonne has quit [Ping timeout: 256 seconds]
[11:26:10] -!- euridium has quit [Quit: Page closed]
[11:33:14] herron_ is now known as archivist_herron
[11:57:39] -!- per_sonne has quit [Ping timeout: 264 seconds]
[12:02:31] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:04:13] <jepler> seb_kuzminsky: I wouldn't be surprised if that failure represents a real, if hard to reproduce, problem.
[12:06:07] <jepler> seb_kuzminsky: the fast thread is executing "count++", which if course is not an atomic operation; it's implemented as a read-modify-write instruction sequence: register x = count; increment x; count = x;
[12:07:35] <jepler> hm, no, that doesn't really explain things
[12:08:07] <jepler> logging a "0" would happen if the reset in the slow thread happened after the increment in the fast thread
[12:08:22] <jepler> but I don't see which scenario allows the value to reset up to the expected one the next loop around
[12:13:01] <jepler> seb_kuzminsky: anyway I'll break out the queue_read function into 3 functions as requested. overloading it for one extra thing was not so bad (and anyway it was the design I inherited from micges' work) but I see that overloading it for 2 things is getting worse
[12:13:34] <jepler> I'll also double-check the error handling
[12:13:42] -!- leptonix has quit [Quit: leaving]
[12:14:12] <jepler> .. I agree about the layering violation. a better solution would be to allow those fields which are not filled out in llio to be filled from idrom; for instance, if they have a placeholder value of 0 or -1
[12:14:47] <jepler> I tried to do this, but it didn't work out for some reason; I think some checking was done before idrom reading and I was hitting the first error checking.
[12:32:21] <skunkworks> zlog
[12:32:21] <zlog> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-07-17.html
[12:39:45] -!- arrowbook [arrowbook!~qicruser@119.176.48.183] has joined #linuxcnc-devel
[12:57:45] -!- per_sonne has quit [Ping timeout: 244 seconds]
[13:10:46] -!- Computer_barf has quit [Ping timeout: 256 seconds]
[13:15:11] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[13:30:54] -!- just_pink has quit [Ping timeout: 246 seconds]
[13:34:44] -!- Tecan has quit [Changing host]
[13:58:13] <seb_kuzminsky> doesn't arm's gcc have atomic intrinsics?
[13:58:47] -!- per_sonne has quit [Ping timeout: 240 seconds]
[14:02:26] <pcw_home> Captain, we must arm the atomic intrinsics!
[14:05:50] <cradek> why does it matter whether the fast thread uses an atomic increment? the fast thread shouldn't be interrupted - that's the whole point of the test.
[14:17:51] -!- theorb has quit [Remote host closed the connection]
[14:25:45] -!- micges_ [micges_!~micges@aeff58.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[14:25:53] <seb_kuzminsky> agreed
[14:27:43] <cradek> I agree getting 8 afterward is the most baffling bit
[14:29:48] -!- micges has quit [Ping timeout: 264 seconds]
[14:31:19] <seb_kuzminsky> it's not the first thing the armhf buildslave has said 0 when it meant something else
[14:31:22] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1100/steps/runtests/logs/stdio
[14:31:27] <seb_kuzminsky> search for limit3
[14:31:48] <seb_kuzminsky> then it goes back to what it's supposed to be doing like nothing happened
[14:32:25] <cradek> I bet it's a sampler bug
[14:32:42] <seb_kuzminsky> that only bites on arm?
[14:33:08] <cradek> mumble mumble
[14:34:09] <seb_kuzminsky> the sampler's queue is larger than the test output, it's not an overrun
[14:35:34] <cradek> I was just wondering that
[14:35:56] <cradek> how big is sampler's queue?
[14:38:24] <seb_kuzminsky> 4096, for that test
[14:38:44] <seb_kuzminsky> but looking at sampler.c, i think there's a bug in the queue allocation
[14:39:14] <cradek> I was just squinting at size =
[14:39:40] <cradek> what do you see?
[14:40:16] <seb_kuzminsky> nevermind
[14:41:57] <seb_kuzminsky> each slot in the queue holds a pin_data_t, which is a union of all the data types it can be
[14:42:17] <seb_kuzminsky> i was worried it was holding 32-bit things, but our floats are 64 bits now
[14:42:39] <seb_kuzminsky> but it's written so well it's immune to stupidity like that
[14:46:00] -!- Abyx has quit [Ping timeout: 265 seconds]
[14:46:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 ce8a5c5 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: warn on errors in harden_rt() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ce8a5c5
[14:51:23] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[14:58:29] -!- Daerist has quit [Quit: Leaving]
[14:59:45] -!- per_sonne has quit [Ping timeout: 244 seconds]
[15:11:13] -!- Valen has quit [Remote host closed the connection]
[15:15:38] -!- greg___ has quit [Quit: rebooting]
[15:16:59] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[15:27:48] micges_ is now known as micges
[15:36:00] -!- malcom2073 has quit [Quit: No Ping reply in 180 seconds.]
[15:38:12] -!- dan2k3k4 has quit [Ping timeout: 265 seconds]
[15:42:07] -!- lair82_ has quit [Quit: Page closed]
[15:45:30] -!- tocka has quit []
[15:48:37] -!- quiqua has quit [Quit: quiqua]
[15:48:42] -!- DaPeace1 has quit [Quit: Leaving.]
[15:50:50] -!- tinkerer has quit [Quit: Leaving]
[15:54:27] <jepler> does the RT part of sampler accidentally say a sample is available before writing all the data for that sample?
[15:54:30] <jepler> that could explain this
[15:57:01] <cradek> I still don't understand the fifo handshake
[15:57:20] -!- amiri_ has quit [Read error: Connection reset by peer]
[15:57:31] <jepler> or we are assuming too much about the ARM memory coherency model, and it actually does permit the write to fifo->in to become visible before the earlier store to dptr, from the viewpoint of another CPU
[15:59:15] <cradek> oh, the rt and usr are certainly on different CPUs aren't they
[15:59:20] <cradek> unlike the fast and slow rt threads
[16:00:48] -!- per_sonne has quit [Ping timeout: 246 seconds]
[16:13:10] -!- Einherjer [Einherjer!~einherjer@178.18.241.175] has joined #linuxcnc-devel
[16:13:50] <jepler> so, yes, we are asking too much of the ARM memory model
[16:14:06] <jepler> > For software programmers, considering the model at the Application level, the key factor is that for accesses to Normal memory barriers are required in some situations where the order of accesses observed by other observers must be controlled.
[16:16:05] <cradek> parse error at "for accesses to Normal memory"
[16:16:35] <jepler> the key factor is that (for acesses to 'Normal memory'), barriers are required in some situations
[16:16:39] <jepler> that's my parse
[16:17:32] <cradek> is big-N-Normal something defined nearby?
[16:17:37] <jepler> yes
[16:17:51] <jepler> basically, anything but memory-mapped I/O is Normal
[16:18:13] <cradek> what's a barrier?
[16:18:16] <seb_kuzminsky> we must assume intel-style memory access ordering all over our code
[16:18:30] <seb_kuzminsky> memory accesses are not reordered across barriers
[16:18:31] <archivist> barrier=a lock ?
[16:19:04] <seb_kuzminsky> ie: write0, barrier, write1 will always be percieved by other cpus as write0, write1, never as write1, write0
[16:19:06] <jepler> barriers are special instructions
[16:19:58] <seb_kuzminsky> memory access reordering made my blood run cold when i first learned of it
[16:20:01] <cradek> do you ever just get an uneasy feeling about software?
[16:20:07] <cradek> ok yes
[16:20:10] <seb_kuzminsky> heh
[16:20:30] <jepler> so in this case, I think a barrier would be required just before updating fifo->in, so that the writes to that 'line' of the fifo have to appear before the updated value of fifo->in appears
[16:21:40] -!- sheppard has quit [Remote host closed the connection]
[16:21:54] <cradek> can you think of a way we could make it worse, for testing the barrier fix?
[16:22:11] -!- malcom2073 has quit [Quit: No Ping reply in 180 seconds.]
[16:23:12] <jepler> not offhand
[16:24:30] -!- md-2 has quit [Quit: Leaving...]
[16:32:13] <jepler> I mean, assuming the task is "identify where barriers are needed for correct operation", no. probably you could write a standalone threaded program without barriers that more quickly showed up a problem
[16:33:22] <jepler> since you get a comparatively strong ordering guarantee on x86, this is just something we've taken for granted on arm
[16:33:39] <jepler> boy I've been looking at this documentation for 15 minutes and it's still clear as mud
[16:34:24] <jepler> > The second part of the definition of Group A is recursive. Ultimately, membership of Group A derives from the observation by Py of a load before Py performs an access that is a member of Group A as a result of the first part of the definition of Group A.
[16:34:28] <jepler> yeah thanks a lot
[16:35:09] <jepler> http://herbsutter.com/2012/08/02/strong-and-weak-hardware-memory-models/ boils it down to "man we hate this for writing efficient software" but is sparse on details unless you already know what terms like SC-DRF mean (I don't)
[16:35:19] <archivist> I sent a flame to ARM about one of their manuals and got told off by the boss at the time
[16:35:26] <jepler> hah
[16:39:13] amnesic_away is now known as amnesic
[16:41:19] <seb_kuzminsky> i just realized that cradek called it: it's a sampler bug that only bites on arm
[16:41:41] <jepler> yeah that's basically the position I'm coming to as well
[16:42:21] <seb_kuzminsky> and likely there are other bugs with the same underlying cause sprinkled liberally through our code
[16:42:29] <jepler> the other thing I can think of this affecting linuxcnc offhand is in the task/motion interface where we write a big buffer and the last(-ish) write to that buffer marks the fresh buffer as available and filled out for the other side
[16:42:47] <seb_kuzminsky> yep, and the ui/task interface
[16:43:00] <jepler> yeah so the nml shared memory stuff
[16:43:03] <jepler> ugh
[16:43:04] <seb_kuzminsky> and streamer
[16:43:09] <jepler> well yeah
[16:43:13] <seb_kuzminsky> and halscope
[16:43:19] <jepler> I have a patch set that unifies streamer/sampler because it's really all the same stuff
[16:43:24] <jepler> hm yeah
[16:43:28] <seb_kuzminsky> anything that uses shmem
[16:43:32] <seb_kuzminsky> of any sort
[16:44:11] <jepler> hal shared memory has never really promised an ordering between updating signal foo and signal bar..
[16:45:02] <jepler> I feel like it's a good thing we don't actively encourage users to use ARM systems, we keep running into pitfalls
[16:45:02] <seb_kuzminsky> but i bet some code relies on ordering for handshaking
[16:45:24] <seb_kuzminsky> encoder writes a latched position, then clears index-enable?
[16:45:38] <seb_kuzminsky> probe works similarly
[16:45:40] <jepler> oh yeah that would be a good example
[16:45:57] <cradek> but is it still a problem if it's just one cpu, ie all in realtime threads?
[16:46:25] <jepler> everything that runs on one CPU is not a problem
[16:46:34] <seb_kuzminsky> i think it's only an issue across cpus
[16:46:46] <cradek> so then it's only when the writer is in rt and the reader in userland, or the other way
[16:46:55] <cradek> ... or both are in userland
[16:46:55] <seb_kuzminsky> each cpu will think its memory accesses happened in the order it asked for
[16:47:04] <seb_kuzminsky> yep, all of uspace is vulnerable
[16:47:33] <cradek> in uspace are different rt threads on different cpus? I thought they weren't
[16:47:59] <seb_kuzminsky> hmm you may be right
[16:48:01] <jepler> so if all memory starts out zeroed, and you execute CPU0: [X]=1; [Y]=1; CPU1: r1=[X]; r2=[Y];
[16:49:01] <jepler> errrr
[16:49:10] <jepler> CPU1: r2=[Y]; r1=[X]
[16:49:27] <jepler> .. it's possible to get r2==1 [write to Y appears to have occurred] but r1==0 [write to X appears not to have occurred]
[16:49:56] <jepler> which, as far as I understand, isn't one of the possiblities on the x86 memory model
[16:50:14] <jepler> and the fix is for CPU0 to execute [X]=1; barrier; [Y]=1;
[16:50:34] <seb_kuzminsky> jepler: i think the behavior you described can be observed on weak memory ordering systems like arm, and can not be observed on strong memory ordering systems like i386 and amd64
[16:51:17] -!- Nick001-shop has quit [Ping timeout: 244 seconds]
[16:51:19] Nick001-shop_ is now known as Nick001-shop
[16:51:23] <seb_kuzminsky> and i agree with your fix
[16:53:49] <seb_kuzminsky> i opened the arm manual and saw this:
http://goo.gl/ZX2n6O
[16:54:54] <jepler> actually in the "ARM Architecture Reference Manual (ARM ARM?) ARMv7-A and ARMv7-R edition" way down at appendix G it is greatly clarified with real-world examples
[16:55:10] <jepler> in fact G2.2 "Message Passing" is exactly what we do and what they say not to do
[16:55:50] <jepler> and the fix is given as a barrier on *both* sides (reader and writer)
[16:56:48] <cradek> I don't understand how you can barrier at the reader
[16:57:19] <seb_kuzminsky> to prevent reordering of the reads?
[16:57:30] <cradek> oh I see
[16:57:31] <jepler> yes, I think the read of R1 could be reordered above the read of R2
[16:59:46] <jepler> ugh the trick on the next page where the read-side barrier is replaced by an address dependency is super-gross
[17:00:03] <jepler> r2 = *(r3 + (r1 & 0))
[17:00:08] -!- maurris has quit []
[17:00:23] <seb_kuzminsky> now they're just fucking with us
[17:01:48] -!- per_sonne has quit [Ping timeout: 250 seconds]
[17:23:04] <jepler> yeah I agree
[17:23:31] <seb_kuzminsky> only a psychopath would write code like that in public
[17:23:53] <jepler> wellllllll
[17:24:13] <jepler> it depends on how harmful the barrier instruction is compared to those rather stupid instructions
[17:24:19] <jepler> for performance
[17:25:16] <seb_kuzminsky> no number of nanoseconds is worth that
[17:36:21] -!- A_Nub has quit [Ping timeout: 246 seconds]
[17:45:06] amnesic is now known as amnesic_away
[17:46:55] Abyx_ is now known as Abyx
[18:02:30] -!- per_sonne has quit [Ping timeout: 240 seconds]
[18:07:09] -!- syyl_ has quit [Ping timeout: 246 seconds]
[18:11:02] <cradek> I wonder what guarantees you get for line 3 if you use an implicit barrier like that
[18:12:13] <cradek> or would you have to write that for every read forever
[18:19:09] <jepler> "imagine N boots stomping concurrently on a programmer's face -- forever" -- not george orwell
[18:28:25] Guest2996 is now known as hendrik
[18:28:36] -!- anth0ny_ has quit [Ping timeout: 264 seconds]
[18:31:55] -!- furrywolf has quit [Read error: No route to host]
[18:55:53] -!- b_b has quit [Remote host closed the connection]
[19:00:04] -!- gyeates has quit [Ping timeout: 246 seconds]
[19:03:55] <jepler> wow the 96boards website is pretty special. on firefox it frequently takes >30s to load a page, and makes the rest of the browser unresponsive for that long.
[19:04:00] -!- per_sonne has quit [Ping timeout: 264 seconds]
[19:11:56] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[19:16:21] -!- greg___ has quit [Ping timeout: 246 seconds]
[19:29:46] <skunkworks> well... I like are mini van...
[19:29:51] <skunkworks> our
[19:31:11] <mozmck> only thing I don't like about ours is that it's not diesel
[19:31:50] <skunkworks> yah.. not many of them
[19:31:57] <skunkworks> volkswagan
[19:32:33] <mozmck> I don't know if they have a diesel one. I read their van is actually made by dodge
[19:35:28] <skunkworks> we need 4wd so that limited us to toyota for the most part.
[19:36:39] <mozmck> I see. Ours is an '02 honda, and it's been great.
[19:40:28] <skunkworks> we had a subaru forester - with 2 kids and 2 adults - that is all you can fit. no taking grandma or others.
[19:40:57] <skunkworks> unless you stuff them in the back.. ;)
[19:54:19] -!- Abyx has quit [Ping timeout: 246 seconds]
[20:00:09] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:04:17] -!- per_sonne has quit [Ping timeout: 240 seconds]
[20:22:14] -!- rob_h has quit [Ping timeout: 260 seconds]
[20:23:03] -!- PetefromTn_ [PetefromTn_!~IceChat9@97-81-58-82.dhcp.kgpt.tn.charter.com] has joined #linuxcnc-devel
[20:23:17] -!- rob_h [rob_h!~robh@2.127.20.182] has joined #linuxcnc-devel
[20:25:21] -!- tjtr33 has quit [Quit: Leaving]
[20:32:35] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:35:26] -!- theorbtwo has quit [Ping timeout: 248 seconds]
[20:42:04] -!- anth0ny_ has quit [Ping timeout: 264 seconds]
[21:03:56] -!- Deejay has quit [Quit: bye]
[21:05:29] -!- per_sonne has quit [Ping timeout: 244 seconds]
[21:17:55] <mozmck> having multiple identical keys in the ini file causes problems with some inifile parsers.
[21:20:08] <cradek> that's not too surprising. our ini file spec (haha) does allow that, though.
[21:20:34] -!- rob_h has quit [Ping timeout: 260 seconds]
[21:21:13] -!- rob_h [rob_h!~robh@2.217.96.32] has joined #linuxcnc-devel
[21:21:17] <mozmck> yes. I found one library that can handle multiple keys, but it writes them back with each muliple key next to the other.
[21:21:26] <mozmck> EMBED_TAB_NAME = THC
[21:21:26] <mozmck> EMBED_TAB_NAME = THC Settings
[21:21:26] <mozmck> EMBED_TAB_LOCATION = thc_box
[21:21:26] <mozmck> EMBED_TAB_LOCATION = thc_settings
[21:21:39] <mozmck> Which I'm pretty sure won't work :)
[21:21:48] <cradek> why not?
[21:22:02] <cradek> you mean it reorders the lines?
[21:22:05] <mozmck> Yes.
[21:22:26] <cradek> the order of lines with matching keys matters, but otherwise I don't think order matters
[21:22:59] <cradek> I think queries are of the form (first,second,third) occurrence of (key) in (section)
[21:24:38] <mozmck> The two EMBED_TAB_COMMAND lines were next. So the first TAB_COMMAND would be associated with the first TAB_LOCATION?
[21:25:15] <cradek> I don't know how they're used exactly
[21:25:42] <mozmck> If so, it would probably work. I'm making a simple gui configurator, but I want to read and modify the ini and hal files directly instead of writing them new each time.
[21:25:46] <cradek> but I'm saying that I think if you don't change the order of *matching* keys within a section you don't change the meaning of the ini file
[21:26:32] <mozmck> I don't either. I may have to dig into that farther. I would prefer the keys the go together be grouped together though.
[21:29:09] <mozmck> huh, it worked!
[21:29:37] <cradek> haha
[21:29:42] <cradek> said like a true programmer
[21:29:56] <cradek> oh wait, that's "huh, it compiled!"
[21:30:43] <mozmck> I'm playing with
https://github.com/brofield/simpleini
[21:31:21] <mozmck> the test file reads and re-writes the ini file, and I took that output and ran it in linuxcnc and it worked fine.
[21:36:47] -!- Cromaglious_ has quit [Ping timeout: 252 seconds]
[21:45:43] <jepler> an ideal inifile modifier would somehow preserve all the layout choices of the original, except for the part that was requested to be changed
[21:50:04] -!- Flipp__ has quit [Remote host closed the connection]
[21:51:33] <mozmck> Yes, I've been trying to find something like that. This one at least preserves the comments, which most don't do.
[21:52:28] <jepler> anybody getting e-mail from the lists today? My last mail was received Thu, 16 Jul 2015 11:22:46 -0500
[21:53:02] <jepler> and a message I sent at Fri, 17 Jul 2015 12:23:42 -0500 hasn't shown up yet
[21:53:17] <jepler> also I have trouble not typing "sourceforget"
[21:53:29] <mozmck> latest I have is about the same, from kirk
[21:53:47] <mozmck> sourceforge has been losing respect lately.
[21:55:19] <jepler> yeah the list service website is down
http://https.downforeveryone.com/check.php?url=https://lists.sourceforge.net/
[21:55:28] <jepler> though the smtp service (at mx.sourceforge.net.) is up
[21:56:05] <jepler> > The sourceforge.net website is temporarily in static offline mode.
[21:56:06] <jepler> Only a very limited set of project pages are available until the main website returns to service.
[21:56:16] <jepler> (you get a 404 if you click the 'help' link on their front page)
[21:56:31] <jepler> > SourceForge down due to storage platform bug, working 24x7 on recovery and data validation, service restoral. Slashdot restored.
[21:57:22] <jepler> ah this brings back memories of that one time that cvs was broken for a month
[21:59:36] <mozmck> ouch!
[22:00:23] <mozmck> Just make sure they don't start distributing linuxcnc with adware/spyware in the installer :)
[22:06:27] -!- per_sonne has quit [Ping timeout: 244 seconds]
[22:19:25] -!- Abyx has quit [Ping timeout: 256 seconds]
[22:21:08] <jepler> we use them for two things of consequence -- bug tracker and mailing lists
[22:21:26] <jepler> I think we could easily move the bug tracker to github
[22:21:30] <jepler> mailing lists are harder to move
[22:21:44] <jepler> whatever you do, you lose a lot of subscribers
[22:21:57] <jepler> and aside from google groups I don't know who is out there for free
[22:33:04] <mozmck> Yeah, I don't know. Kicad uses launchpad for the development list (and development)
[22:33:19] -!- exitcode1 has quit [Quit: quit]
[22:33:26] <mozmck> launchpad could get more interesting as they are switching to git.
[22:39:17] -!- PetefromTn_ has quit [Ping timeout: 240 seconds]
[22:40:24] -!- Camaban has quit [Quit: Leaving]
[22:48:37] -!- asdfasd has quit [Ping timeout: 246 seconds]
[23:03:09] -!- jubjub has quit [Ping timeout: 246 seconds]
[23:07:28] -!- per_sonne has quit [Ping timeout: 256 seconds]
[23:28:26] -!- anth0ny_ has quit [Ping timeout: 256 seconds]
[23:38:30] -!- jubjub has quit [Ping timeout: 246 seconds]
[23:43:44] -!- rob_h has quit [Ping timeout: 256 seconds]
[23:43:59] -!- Flipp_ has quit [Remote host closed the connection]
[23:44:17] -!- rob_h [rob_h!~robh@90.204.236.205] has joined #linuxcnc-devel