Back
[10:11:26] <memleak> jepler, are you experienced with assembly?
[10:12:44] <memleak> starting with kernel 3.16 they reworked entry_64.S quite a bit and im having trouble merging in the IPIPE code with that file. i dont know any assembly.
[10:13:37] <memleak> dpaste.com/06B36N8
[10:13:58] <memleak> all the rest of the kernel is done except for that file. that file is the patch reject output
[10:14:28] <memleak> upstream file is here:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/kernel/entry_64.S?h=linux-3.16.y
[10:17:43] <seb_kuzminsky> 2.5, 2.6, and master all build without lintian errors now, and future lintian errors will fail the build
[10:17:54] <jepler> seb_kuzminsky: cool
[10:18:13] <jepler> so you recovered from your ragequit?
[10:18:15] <memleak> jepler, thanks for the patch set against my RTAI btw!
[10:18:41] <jepler> memleak: so you're successfully patching 3.14 but not 3.16?
[10:19:29] <memleak> correct. 3.16 has different macros and a lot of the entries you change for 3.16 are no longer existant
[10:19:56] <memleak> i mean "change for 3.14 are no longer existent"
[10:20:25] <memleak> all of the zeroentry * * * stuff is gone
[10:20:54] <memleak> i.e. zeroentry divide_error do_divide_erro
[10:21:30] <jepler> memleak: I can't look at this at the moment, soonest's likely to be the weekend.
[10:21:37] <jepler> memleak: and even so I don't know if I have the smarts to figure it out
[10:22:03] <memleak> ill give the xenomai IPIPE team a go too
[10:23:16] <jepler> anyway, it looks like three macros were merged into one
[10:23:20] <jepler> - * - errorentry/paranoidentry/zeroentry - Define exception entry points.
[10:23:23] <jepler> + * - idtentry - Define exception entry points.
[10:23:40] <memleak> so its not too complicated?
[10:23:47] <jepler> dunno, it could be easier though
[10:23:52] <memleak> heh..
[11:03:01] <jepler> everytime I look at a screenshot of the other GUIs, I think: I must really just have no idea how people would prefer their machine control's UI to look
[11:03:08] <jepler> that makes me sad
[11:07:19] <cradek> jepler: the other possibility is everyone but you is just wrong
[11:08:07] <kwallace3> Was that my test UI? It was not meant for general use. BTW I went with your mux hint -- so much easier to do.
[11:13:25] <seb_kuzminsky> if axis is wrong, i dont want to be right
[11:16:12] <kwallace3> Oh, I think you mean the 70's look UI.
[11:16:35] <seb_kuzminsky> ugh, sourceforge pages have more ads than content now
[11:17:13] <cradek> kwallace3: it's clearly 90s - don't be hyperbolic
[11:18:08] <cradek> actually it's probably newer than that since we get antialiased fonts now
[11:19:34] <jepler> some days I want to say we should host our own gitlab ce. It does git, issue tracking, etc, much like github.
[11:19:44] <jepler> it would solve the sf ads problem except for the mailing list
[11:20:10] <jepler> but .. I wouldn't want to administer it
[11:20:17] <cradek> yeah
[11:21:49] <cradek> or bugzilla plus mailman (a new enough version to deal with the brave new world, unlike what sf has)
[11:22:34] <cradek> (I wish I loved github)
[11:22:57] <jepler> I am coming around to the idea of github a little bit
[11:24:37] <jepler> but I haven't really processed it enough to articulate my position well
[11:25:45] <seb_kuzminsky> i wouldnt say i love github, but i like it better than sourceforge
[11:26:00] <jepler> using github doesn't break anybody's ability to use the decentralized workflow, but it enables new workflows which are very popular
[11:26:21] <jepler> I'd rather use the github issue tracker than the sf one
[11:26:35] <jepler> now that I understand I can resolve a pull request *not* in the github web interface, I like pull requests
[11:27:25] <seb_kuzminsky> i like the integrated code review/commenting system
[11:27:30] <jepler> we'll never have the linux and git project's dedication to e-mailing patches around until they're right. github pull requests are the next best thing
[11:28:08] <jepler> particularly for attracting one-time and first-time contributors, github is a net positive
[11:29:13] <seb_kuzminsky> because of the single-click clone feature?
[11:29:41] <jepler> because a first-time linuxcnc contributor may already be a github contributor who knows how to do the github thing
[11:30:29] <jepler> and if not, it's still more friendly than "you'd better subscribe to the mailing list and figure out how to mail patches" or "you'd better figure out how to host git" or "you'd better hope somebody sympathetic is on irc and will look at your pastebin" or whatever our so-called workflow is now.
[11:31:08] <jepler> just like in 2002 everyone knew how to get a cvs checkout from sourceforge
[11:31:32] <seb_kuzminsky> seems reasonable
[11:32:03] <jepler> (of course, with cvs they couldn't do anything but mail cvs diffs, but that's beside my point)
[11:32:50] <seb_kuzminsky> one of the options on the table is hosting our own git-webgui-thingy, if we go that way we should get off snotra and onto a sensible host
[11:33:30] <jepler> now you're making more balls of worms
[11:33:48] <seb_kuzminsky> mmmmaybe
[11:35:39] <jepler> next you'll say "and get rid of joomla"
[11:36:46] <cradek> if not for taking the forum with it, yeah, because it sucks
[11:37:07] <cradek> but these are all huge distractions from doing useful work
[11:38:29] <jepler> hm, unfortunately someone (and github will not show who) has already registered the name "linuxcnc" as an organization.
[11:38:45] <jepler> I don't suppose it's one of you who is squatting it.
[11:39:56] <seb_kuzminsky> 'taint me
[11:40:06] <jepler> seb_kuzminsky: you're a taint
[11:41:29] <seb_kuzminsky> it was created October 2013, one month after the creation of the "UBC3 LinuxCNC" group
[11:41:35] <cradek> I did it
[11:41:43] <seb_kuzminsky> the truth comes out
[11:41:46] <jepler> cradek: oh that's good!
[11:41:57] * cradek shrugs
[11:41:58] <seb_kuzminsky> that was foresightful of you
[11:42:09] <cradek> I can often predict the future
[11:42:28] <jepler> hah
[11:43:06] <cradek> here I'll do it: in the future github will be as passe and ad-laden as sourceforge
[11:43:21] <jepler> sure, I bet at least half of that prediction is true
[11:43:23] <cradek> also maybe in the future I'll be able to type passe with the right accent and all of you will see it properly
[11:43:29] <jepler> passé
[11:43:34] <jepler> that's been going on for years
[11:43:49] <cradek> heh
[11:43:50] <jepler> cradek: but that doesn't mean we shouldn't adopt it for the next 3-5-8 years
[11:46:02] <jepler> I wonder if we should move the linuxcnc-mirror repository into the LinuxCNC group on github
[11:47:32] <jepler> oh geez, talk about needy users
[11:47:41] <jepler> I use newsblur to read rss
[11:47:50] <jepler> some problem has caused many users feeds to stop updating
[11:47:56] <jepler> this has been going on for *hours*
[11:48:03] <jepler> anyway, now there's a support request with the following title:
[11:48:17] <jepler> Should we call 911? It's been over 24 hours. Really worried about Samuel [site founder].
[11:48:28] <seb_kuzminsky> yes
[11:48:30] <seb_kuzminsky> call 911
[11:49:52] <seb_kuzminsky> i'm guess the linuxcnc-mirror repo would belong better in the linuxcnc group instead of in jepler's personal github space
[11:50:17] <jepler> it's a step towards github that might be controversial to some
[11:50:51] <cradek> yeah...
[11:51:04] <seb_kuzminsky> it's a purely symbolic change, but maybe people care about symbols
[11:51:25] <seb_kuzminsky> i guess the main thing we should try to work on is figuring out if we should jump ship from sf, and if so where we should jump to
[11:51:43] <seb_kuzminsky> the outcome of that will inform what (if anything) we change about our github presense
[11:51:52] <cradek> does github host mailing lists?
[11:51:56] <jepler> cradek: no.
[11:52:06] <jepler> they cover git hosting and issue tracking
[11:52:08] <cradek> then we have at least two problems
[11:52:12] <seb_kuzminsky> 2/3
[11:52:13] <seb_kuzminsky> yeah
[11:52:32] <jepler> bbl, time for early lunch here.
[11:52:42] <seb_kuzminsky> seeya
[11:52:46] <seb_kuzminsky> i think i'll get a coffee
[11:59:18] <mozmck> why would github be controversial to some?
[12:40:37] <skunkworks> machinekit is using google groups for mail.
[12:41:05] <skunkworks> seems ok.. (our local linux user group also uses it - I should make it to a meeting one of these days)
[12:41:22] <skunkworks> this week they are talking about linuxcnc :(
[12:42:16] <mozmck> bleh, I refuse to have a google account
[12:42:56] <mozmck> although at least some of the google groups allow you to join by email without getting a google account - I don't know if they all do.
[12:45:13] <kwallace3> I seem to recall HAL commands in a .hal file have to be on one line -- if not, how can a command span lines?
[12:58:07] <cradek> status: assigned --> wont-fix
[12:58:16] <cradek> http://sourceforge.net/p/forge/site-support/7413/
[12:58:33] <jepler> kwallace3: yes, I'm pretty sure there's no "continuation line" syntax in halcmd
[12:59:34] <jepler> kwallace3: but the limit on line length is 1024 characters. do you really need more than 1024 characters in a halcmd line?
[13:00:34] <seb_kuzminsky> maybe he wants it for legibility?
[13:01:04] <mozmck> cradek: if enough places do that it may force yahoo to change as it looses email users.
[13:01:41] <cradek> mozmck: nah. their change mostly benefits their users, while hurting the rest of email users everywhere
[13:02:18] <kwallace3> I'll have around 30 buttons to mux and the select pin will have all the button pin names.
[13:02:22] <mozmck> how does it benefit their users? It will hurt them if they get bumped off all non-yahoo groups.
[13:03:09] <cradek> when yahoo users post to mailing lists, it doesn't bump them off the lists. it bumps innocent random people off the lists instead.
[13:03:43] <jepler> kwallace3: you can build a net over several lines
[13:04:14] <kwallace3> Dooooh, of course.
[13:05:02] <jepler> cradek: the 'network' graph on github is still pretty useless, even not on mobile
[13:05:39] <cradek> mozmck:
http://article.gmane.org/gmane.linux.distributions.emc.user/50866
[13:06:23] <cradek> if sf said why they decided to do nothing, it would have been nice
[13:06:24] <jepler> Status: wont-fix
[13:06:36] <mozmck> cradek: oh, nasty. I say unsub all yahoo emails.
[13:07:43] <cradek> one of the options in new mailman is to warn and blacklist them
[13:08:17] <cradek> mozmck: I'm sure other providers have followed them by now
[13:08:30] <cradek> mozmck: it's not really just a yahoo problem
[13:08:48] <mozmck> grumble...
[13:09:48] <jepler> yes, it's a problem for any site which adopts DMARC
[13:10:02] <cradek> dmarc with p=reject
[13:13:55] <jepler> yeah but I don't think you deploy damrc except with the expectation of eventually doing p=reject
[13:15:01] <kwallace3> BTW, this is what I have so far:
http://wallacecompany.com/tmp/auto_test_ui/ . Now I'm off to the shop to try to add hardware.
[14:25:24] <PCW> jepler: should I flash a SPI config into 1 of the 7I90s config chips?
[14:26:45] <jepler> PCW: yes that would be convenient for me
[14:27:09] <jepler> PCW: I'll potentially want to measflash it over epp though
[14:27:16] <PCW> it avoids dicking around with EPP
[14:27:19] <jepler> yeah
[14:27:34] <jepler> can you put the main configuration as spi and the backup as epp?
[14:27:51] <PCW> primary=SPI (P)
[14:28:31] <PCW> DONOT forget to move the jumper, not sure theres anyway home from SPI/SPI
[14:29:13] <PCW> (I mean other than JTAG)
[14:29:30] <jepler> I think I have a jtag dongle somewhere but yeah, that would be a bit of a pain to recover from
[14:30:16] <jepler> PCW: not quite related, but it occurred to me that once you make the d8's code loadable, maybe you want to load the initial code from an unused block of the eeprom
[14:31:11] <jepler> PCW: when you say "no recovering from spi/spi", do you mean that spi can't write the eeprom, or that it's not written in mesaflash yet?
[14:31:30] <PCW> I dont know actually
[14:31:44] <jepler> if it's the latter, I can put it on the stack of things to look at doing
[14:32:13] <jepler> hm given the pin assignments I don't think you could talk spi at it through an spp parport
[14:32:42] <PCW> you could (very slowly)
[14:33:12] <jepler> won't trouble arise with both the PC and the FPGA trying to drive pin PD6?
[14:33:38] <PCW> but it would have to have clean signals (PP signals at end of cable are not very good)
[14:34:05] <PCW> (you would need a cable adapter)
[14:35:25] <jepler> yeah, if SPIOUT went to one of the parport "in" pins via a modified cable I agree you could do it very slowly if the signal is clean
[14:35:54] <PCW> the lack of standards in host SPI hardware makes the mesaflash issue a bit painful
[14:36:44] <PCW> for now boot as EPP MOVE JUMPER flash SPI half is probably the best
[14:37:26] <PCW> I should figure out how to write protect the secondary EEPROM
[14:40:10] <PCW> its something you need to write to the flash chip to enable the hardware WP input
[14:41:34] <jepler> mesaflash seems to have stubs for spi stuff
[14:42:05] <jepler> why does the same jumper control which EEPROM half gets written and which EEPROM half gets booted?
[14:46:29] <PCW> no real choice, its just a hardware chip1/chip2 selection
[14:49:16] <jepler> oh, I read the section on fallback and dual eeproms again
[14:49:23] <PCW> There may be something clever you could do with a dual boot config where a option selection config boots read some pins, sets up the SPI start address and reboots
[14:49:25] <PCW> but that beyond my ICAP foo
[14:50:21] <PCW> the fallback is a different issue (a bad or corrupted bitfile will cause reboot to fallback in same EEPROM)
[14:51:36] <PCW> so for example if you start mesaflash writing and pull the plug in the middle, the bitfile in the flash will have a bad CRC so will reboot into the fallback
[14:53:27] <PCW> I just added ICAP support to Ethernet and PCI cards so for example on a 5I25 after flashing a new config you can reload the FPGA and go on without needing a power cycle
[14:54:59] <PCW> (or a reboot thanks to mesaflash saving the PCI BAR and command regs before reconfig and restarting after)
[14:55:24] <PCW> s/restarting/restoring/
[14:57:06] <PCW> the ICAPstuff also allows you to load a FPGA config at a arbitrary flash address
[14:57:39] <PCW> (I will add ICAP support to the 7I90 but its not there yet)
[15:01:07] <jepler> the epp eeprom flashing processes uses 8-bit addresses and data
[15:03:04] <PCW> all low level flashing works this way (even on a 5i25)
[15:03:39] <PCW> Ethernet is a bit different since theres a processor available
[15:04:37] <PCW> low level stuff just has a very simple 8 bit SPI interface (just a shift register really) and a I/O bit for CS control
[15:07:38] <jepler> so is this 8-bit address EPP_SPI_SREG_REG not even part of the regular hostmot2 address space?
[15:08:05] <PCW> it is part of the same space
[15:08:11] <jepler> is it like 007E then?
[15:08:30] <PCW> I think 0x70 and 0x74
[15:08:50] <jepler> in my copy of mesaflash I have
[15:08:51] <jepler> #define EPP_SPI_CS_REG 0x7D
[15:08:51] <jepler> #define EPP_SPI_SREG_REG 0x7E
[15:09:17] <PCW> Hmm maybe
[15:15:37] <PCW> for 7I90 is HM2 address space 0x0070, 0x0074
[15:15:38] <PCW> 7I43 is funny and writing flash is not even supported by hm2 configs
[15:16:25] <PCW> I could be but no one ever asked for it
[15:16:47] <jepler> oh I guess I've only written bitfiles via usb, and only to boot them, not to the eeprom
[15:17:16] <jepler> so what device is this EPP_SPI_CS_REG for?
[15:18:08] <PCW> its for a basic bootstrap confg for the 7I43
[15:18:14] <jepler> it matches TopUSBHostMot2.vhd
[15:18:34] <PCW> so you can load the boostrap then flash the eeprom
[15:19:42] <PCW> yeah if it was an issue I would add the 0x0070 0x0074 SPI stuff to 7i43 hm2 configs
[15:20:22] <PCW> but i dont think anyone uses configs in flash on the 7I43 with linuxcnc
[15:20:33] <jepler> I don't think so either
[15:21:43] <PCW> (I dont think it would even work, it would have the same problem you have with a 7I90 and the 7I43 driver
[15:21:45] <PCW> (it resets the FPGA without checking if theres a config there first)
[15:22:01] <jepler> I'm sure it was just cost-savings on your part but I sort of liked the days that a firmware had to be uploaded first of all
[15:22:11] <jepler> I dunno why, just old fashioned I suppose.
[15:22:16] <jepler> bbiab
[15:22:30] <PCW> Yeah its more bulletproof (but more expensive)
[17:09:52] <CaptHindsight> how do you save changes to Grub v2 in Wheezy? edit /etc/default/grub, then run update-grub?
[17:21:01] <cradek> yes, same as lucid
[17:22:33] <CaptHindsight> thanks
[17:24:16] <CaptHindsight> with isolcpus=1 on dual core APU and 3.4-9 pae rtai ~12,000nS, without isolcpus= ~25,000nS
[17:39:14] <jepler> yay. level translator board showed up, seems to work
[17:39:28] <jepler> I successfully decoded a transmission with my logic scope from a linux userspace program
[17:40:00] <CaptHindsight> \0/
[17:40:37] <seb_kuzminsky> jepler: great!
[17:41:04] <jepler> http://emergent.unpythonic.net/files/sandbox/odroid-spi-decoded.png
[17:41:47] <jepler> the open logic analyzer calls it "mode 0", 32 bits, MSB first
[17:43:01] <jepler> so the basic problem I was facing last time was exactly what we thought: too much unshielded, unpaired wiring, particularly at 1.8v
[17:43:53] <cradek> cool!
[17:44:14] <cradek> I thought the board was going to be wrong in many ways...?
[17:44:35] <jepler> cradek: yes, it's not perfect
[17:45:39] <jepler> two of the signal pins are reversed .. but the logic analyzer doesn't care
[17:46:33] <jepler> for the actual 7i90 there's a problem with choice of supply voltage (I don't want the voltage provided on the 26-pin header)
[17:46:47] <jepler> and there are some good design suggestions like impedence-matching resistors
[17:47:32] <jepler> but none of the problems bad enough to make the board just junk
[17:48:43] <jepler> the way the OLS shows the |----| part of the signal covered by each spi word is weird
[17:48:57] <jepler> it seems to be implying there's a "stop bit" or something, but I don't think there is
[17:49:27] <jepler> It should be |----|----|, not |---| |---|
[17:59:46] <skunkworks> cradek: I was goofing around with the emco - I used spindle-postion instead of interpolated - I still get a pause ever so often when I turn the spindle back on while in sync
[18:00:17] <skunkworks> I need to try a pre-new tp version to see if I get the same effect
[18:00:57] <skunkworks> no - That was 2.5.4
[18:02:38] <PCW> Sort of too bad there's not a start bit defined for SPI
[18:02:40] <PCW> (been messing with BISS and BISS uses the first returned bit to sync the receive clock to remove skew)
[18:15:01] <skunkworks> I should probably scope the encoder signal just to make sure it isn't missing pulses or something
[18:21:34] <skunkworks> cnc's are awesome
[18:59:08] <cradek> skunkworks: if a ground is missing somewhere, it might be ac-coupled
[18:59:23] <cradek> that might explain why it only works once it gets going
[19:01:01] <skunkworks> right - and only some of the time depending on how the ac motor starts.. (not a normal run mode)
[19:16:02] <jepler> AA AA AA AA 00 00 00 00
[19:16:02] <jepler> 00 00 00 00 00 00 00 00
[19:16:02] <jepler> 00 00 00 00 41 53 45 4D
[19:16:02] <jepler> 33 34 49 37 00 00 01 90
[19:16:02] <jepler> 00 00 00 90 00 00 00 02
[19:16:22] <jepler> ASEM34I7
[19:17:18] <jepler> (that's what 41 ... 37 decodes to)
[19:17:33] <jepler> in other words .. we have communication
[19:25:51] <jepler> > 0100a840 00000000 00000000 00000000 00000000
[19:25:51] <jepler> < aaaaaaaa 55aacafe 54534f48 32544f4d 00000400
[19:25:51] <jepler> > 040ca840 00000000 00000000 00000000 00000000
[19:25:51] <jepler> < aaaaaaaa 4153454d 33344937 00000190 00000090
[19:25:54] <jepler> the rest is easy
[19:28:05] <jepler> just looking at a few reps of those two transactions, the level translator seems to be working up to 33MHz but not at 40MHz.
[19:28:37] <jepler> which is in line with my expectations from the datasheet
[19:29:48] <jepler> PCW: it's alive ^^^
[19:30:23] <PCW> Well jolly good!
[19:36:57] <PCW> at 33 Mhz its not that different than target only PCI speed wise (~1 usec.transaction)
[19:36:59] <PCW> obviously bursting multiple channels of register data is better
[19:43:04] <jepler> yeah I think that'll be necessary
[19:46:27] <jepler> hmm interesting note #1: speed limit drops to ~12MHz when the logic analyzer is powered on
[19:46:54] <PCW> maybe termination issues
[19:47:42] <jepler> interesting and distressing note #2: there's a ~10us gap between the first and second word of a single transfer, and a ~75us gap between the first transfer and the second transfer
[19:47:52] <jepler> PCW: yes, this board iteration doesn't have termination, that's on the list for next board
[19:47:55] <jepler> bbiab
[19:57:00] <jepler> so the 10us gap is because I organize one read as two transactions submitted at the same time (similar to writev). apparently that's just not performant
[19:57:18] <jepler> but the 75us gap is pretty unacceptable too, so I'll need hm2_eth-style buffering
[19:57:22] <jepler> good thing somebody wrote that .. thanks, micges
[20:06:00] <jepler> int r;
[20:06:00] <jepler> r = spidev_set_mode(dev, mode);
[20:06:09] <jepler> gcc says 'r may be used uninitialized in this function'
[20:06:10] <jepler> whaaa
[20:12:04] <PCW> Yeah Ethernet/SPI even DMA type interfaces are similar
[20:13:15] <PCW> wheres the 75 usec from? is that because you are using the kernel driver for the SPI?
[20:14:51] <jepler> http://emergent.unpythonic.net/files/sandbox/delay-between-spi.png
[20:15:33] <jepler> I think some of it is due to debug prints
[20:15:43] <seb_kuzminsky> jepler: is spidev_set_mode() a macro?
[20:16:04] <jepler> seb_kuzminsky: no it's a function which says 'return ioctl(...)'
[20:16:33] <jepler> updated the scope capture with debug prints off
[20:17:02] <jepler> program just does ioctl(SPI_IOC_MESSAGE) twice back to back. it is not running at realtime speed, but I doubt that's the real deal
[20:17:14] <jepler> I mean, I doubt that's the cause
[20:17:30] <jepler> ugh, I hope there's not some other device in the system that's sharing this SPI but with a different chip select
[20:18:23] <jepler> int spidev_set_mode(struct spidev *dev, uint8_t mode) {
[20:18:23] <jepler> return ioctl(dev->fd, SPI_IOC_WR_MODE, &mode);
[20:18:23] <jepler> }
[20:18:35] <jepler> spidev.c:51:9: warning: ‘r’ may be used uninitialized in this function [-Wmaybe-uninitialized]
[20:18:38] <jepler> int r = spidev_set_mode(dev, mode);
[21:36:20] <CaptHindsight> jepler: according to the schematic the SPI pins go from the pads on the SOC right out to the headers, no passives, no other connections
[22:06:50] <jepler> http://paste.debian.net/116845/
[22:06:59] <jepler> stepgen steps over spi
[22:07:56] <jepler> however, the watchdog keeps biting
[22:08:10] <jepler> halcmd: setp hm2_7i43spi.0.watchdog.has_bit 0
[22:08:10] <jepler> halcmd: hm2/hm2_7i43spi.0: trying to recover from IO error or Watchdog bite
[22:08:13] <jepler> hm2/hm2_7i43spi.0: error recover successful!
[22:08:15] <jepler> hm2/hm2_7i43spi.0: Watchdog has bit! (set the .has-bit pin to False to resume)
[22:09:13] <jepler> hmm running a 2ms thread "fixes" it
[22:09:22] <jepler> not for long
[22:09:27] <jepler> Unexpected realtime delay on task 0
[22:09:27] <jepler> This Message will only display once per session.
[22:09:27] <jepler> Run the Latency Test and resolve before continuing.
[22:09:27] <jepler> hm2/hm2_7i43spi.0: Watchdog has bit! (set the .has-bit pin to False to resume)
[22:09:30] <jepler> hmmm
[22:11:28] <skunkworks> logger[psha]:
[22:11:28] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-08-22.html
[22:14:37] <skunkworks> jepler: looks like your getting close
[22:16:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/cleanup-src-configure fc5f833 06linuxcnc 10src/configure.in src/configure: remove --enable-run-in-place * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc5f833
[22:16:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/cleanup-src-configure 83854db 06linuxcnc 10src/configure.in src/configure: use AS_HELP_STRING() everywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=83854db
[22:16:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/cleanup-src-configure b8b7e1e 06linuxcnc 10src/configure.in src/configure: --enable-simulator deprecation warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8b7e1e
[22:16:24] <jepler> bumping spi speed and lowering servo rate makes it more stable
[22:16:28] <jepler> but who wants a 2ms servo rate?
[22:17:00] <seb_kuzminsky> increase the watchdog timeout for now?
[22:17:58] <pcw_home> preemt-rt?
[22:18:46] <jepler> oh hah -- I was using a 1.2MHz SPI clock, not 12MHz
[22:18:51] <jepler> that should help
[22:18:54] <jepler> PCW: yes
[22:23:51] <jepler> http://emergent.unpythonic.net/files/sandbox/clockwork-2ms.png
[22:23:57] <jepler> now it's running like clockwork with a 2ms thread
[22:24:21] <jepler> 8MHz SPI clock (even 12MHz is marginal with the logic analyzer in the mix)
[22:24:31] <jepler> let's see what it looks like come morning...
[22:25:39] <jepler> (the keen eye will count 4 packets per cycle :-/)
[22:26:42] <pcw_home> does the logic analyser use passive (resistove divider) probes? it will really screw up the signals (especially the clock) if not
[22:27:48] <pcw_home> (a Tee connection is not allowed on the clock line)
[22:27:56] <skunkworks> that looks like it should run at 1ms - right?
[22:28:04] <jepler> skunkworks: yes probably
[22:28:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 6911ff5 06linuxcnc 10src/Makefile build: -fstrict-overflow is redundant with -fwrapv * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6911ff5
[22:28:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 50b314c 06linuxcnc 10src/emc/pythonplugin/python_plugin.cc 10src/emc/pythonplugin/python_plugin.hh pythonplugin: remove unused fields * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50b314c
[22:28:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master e200957 06linuxcnc 10src/emc/task/taskclass.hh taskclass: remove unused field * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e200957
[22:28:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master cc52288 06linuxcnc 10src/emc/tp/tp.c tp: Remove unused functions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc52288
[22:28:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4be68a2 06linuxcnc 10src/emc/usr_intf/axis/extensions/_toglmodule.c togl: cast to avoid warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4be68a2
[22:28:14] <skunkworks> jepler: nice!@
[22:28:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 9b133bb 06linuxcnc 10src/emc/usr_intf/axis/extensions/emcmodule.cc emcmodule: Disable invalid offsetof warnings explicitly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b133bb
[22:28:17] <jepler> PCW: passive probes to a buffer chip of some sort
[22:28:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 783203a 06linuxcnc 10src/hal/classicladder/files_project.c 10src/hal/classicladder/files_sequential.c ladder: get rid of unused dbg_printf * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=783203a
[22:28:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4cb7707 06linuxcnc 10src/hal/utils/halrmt.c halrmt: If you mean NULL, say NULL * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4cb7707
[22:28:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master b86857c 06linuxcnc 10src/libnml/buffer/memsem.cc nml: 'register' is a deprecated keyword * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b86857c
[22:28:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 06241b9 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Don't call RtapiApp a struct * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06241b9
[22:28:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 3fff9c0 06linuxcnc 10src/rtapi/vsnprintf.h rtapi: don't uselessly test if an unsigned is less than zero * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3fff9c0
[22:28:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 13a2349 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/rs274ngc_interp.hh interp: use strings to avoid buffer hell * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=13a2349
[22:28:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 2c11d6f 06linuxcnc 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2c11d6f
[22:29:10] <jepler> PCW: M74LCX16245DTR2G buffer
[22:29:46] <pcw_home> Yeah so not a probe
[22:30:12] <jepler> nothing like a proper probe, this is something they can chuck out at $50 a pop and make money
[22:30:46] <pcw_home> I would try without probing the clock line
[22:31:40] <jepler> Unexpected realtime delay on task 0
[22:31:40] <jepler> This Message will only display once per session.
[22:31:40] <jepler> Run the Latency Test and resolve before continuing.
[22:31:40] <jepler> hm2/hm2_7i43spi.0: Watchdog has bit! (set the .has-bit pin to False to resume)
[22:31:50] <jepler> I think the realtime is dodgy, this happened again.
[22:31:55] <jepler> probably while I was git pushing or something :-/
[22:32:21] <skunkworks> idle=poll!
[22:32:28] <jepler> skunkworks: does that even do anything on an arm?
[22:33:04] <seb_kuzminsky> awesome jepler
[22:33:25] <jepler> it sure must indicate a real problem when I get a realtime delay followed immediately by watchdog bite
[22:33:56] <pcw_home> does the latency test have reasonable numbers?
[22:35:12] <jepler> PCW: OK if you're not stressing it, borderline if you are
[22:37:42] <pcw_home> is the "Unexpected realtime delay" message still printed with a > 20% of period delay? (400 usec at 2 ms thread rate)
[22:38:16] <skunkworks> jepler: no clue
[22:38:32] <jepler> PCW: no.
[22:38:54] <jepler> PCW: before sleeping, it checks the current time. If that's later than the target time of the next period, a realtime delay is logged.
[22:39:47] <jepler> I should probably log the target and actual times
[22:40:53] <pcw_home> is halscope working?
[22:41:27] <jepler> hmm did I bump a wire? now all reads are coming back all ones
[22:41:32] <jepler> it must be time to call it a night
[22:41:39] <jepler> PCW: yes, I should log the function times via halscope
[22:41:58] <pcw_home> plotting the read and write times is instructive
[22:42:26] <pcw_home> I suspect the low level SPI driver
[22:42:56] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 23cc00f 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=23cc00f
[22:44:16] <CaptHindsight> idel=poll is x86 only iirc
[22:44:21] <pcw_home> (I suspect its where the delays are coming from)
[22:47:18] <jepler> http://emergent.unpythonic.net/files/sandbox/thread-timing.png
[22:47:39] <jepler> times are in units of 1 = 1ns
[22:48:07] <jepler> so yeah, sometimes the read and write functions take a very very long time
[22:50:06] <jepler> anyway, goodnight
[22:50:11] <pcw_home> hmm just like the parallel port, might have to poke at the SPI hardware directly
[22:50:11] <jepler> it was still good progress!
[22:50:24] <jepler> yucky but possible
[22:50:44] <pcw_home> yes quite a big step
[22:52:58] <CaptHindsight> if the file /dev/cpu_dma_latency exists, open it and write a zero into it. This will tell the power management system not to transition to a high cstate (in fact, the system acts like idle=poll) When the fd to /dev/cpu_dma_latency is closed, the behavior goes back to the system default.
[22:53:49] <jepler> umm
[22:53:58] <jepler> it turns out I may have failed to "sudo make setuid" for at least this most recent test
[22:54:21] <jepler> CaptHindsight: linuxcnc does that
[22:54:32] <jepler> CaptHindsight: (is that helpful in rtai too?)
[22:56:05] <memleak> jepler, does -ffreestanding imply -fno-builtin-sin/cos?
[22:56:17] <jepler> memleak: yes
[22:56:27] <memleak> ok so i have redundant CFLAGS
[22:56:33] <jepler> hm2_eth-objs := \
[22:56:33] <jepler> hal/drivers/mesa-hostmot2/hm2_eth.o \
[22:56:34] <jepler> oops
[22:56:38] <jepler> http://emergent.unpythonic.net/files/sandbox/thread-timing-setuid.png
[22:56:49] <jepler> it's substantially better when actually running with realtime priority
[22:57:05] <jepler> (same scale per div as last image)
[22:57:24] <jepler> worst case is much less worse
[22:57:42] <jepler> 'night
[23:01:55] <memleak> night!
[23:29:59] <CaptHindsight> pcw_home: we tested the Norther Islands gpu hardware accel driver with 3.14 RTAI and latency is much better without it :(
[23:30:27] <CaptHindsight> Norther/Northern
[23:32:57] <linuxcnc-build> build #2352 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2352 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:34:21] <CaptHindsight> pcw_home: that BIOSTAR A68N-2100 AMD E1-2100 has a Radeon™ HD 8210 so I expect it to have the same results until there's a driver fix, but I can't confirm it
[23:37:05] <linuxcnc-build> build #2149 of 1901.clang-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2149 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:37:36] <CaptHindsight> the BIOSTAR A68N-5000 AMD A4-5000 Quad-Core has a HD 8330 and uses the same gpu hardware accel driver
[23:40:33] <linuxcnc-build> build #2351 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2351 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:41:33] <linuxcnc-build> build #2353 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2353 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:53:31] <linuxcnc-build> build #509 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/509 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:53:39] <linuxcnc-build> build #700 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/700 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:55:16] <linuxcnc-build> build #509 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/509 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:55:35] <linuxcnc-build> build #20 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/20 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:57:13] <seb_kuzminsky> for once the buildbot reports an actual error with linuxcnc of interest to developers
[23:57:27] <seb_kuzminsky> instead of the usual, false positives of interest only to seb
[23:58:36] <linuxcnc-build> build #2352 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2352 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[23:59:09] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master eebad1f 06linuxcnc 10src/configure.in src/configure: remove --enable-run-in-place * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eebad1f
[23:59:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master c70ccc2 06linuxcnc 10src/configure.in src/configure: use AS_HELP_STRING() everywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c70ccc2
[23:59:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master acaecf0 06linuxcnc 10src/configure.in src/configure: --enable-simulator deprecation warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=acaecf0
[23:59:31] <KGB-linuxcnc> 05seb/master/cleanup-src-configure b8b7e1e 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8b7e1e
