Back
[02:32:32] <CIA-5> EMC: 03jepler 07master * r7b03efb4247f 10/docs/src/drivers/pico_ppmc.lyx: looks like index-enable is in the ppmc driver nowadays
[02:33:02] <CIA-5> EMC: 03jepler 07master * ra211875cd93b 10/src/emc/rs274ngc/interp_read.cc: Allow unary negation of expressions
[03:00:50] <cradek> yay
[03:48:45] <jepler> http://emergent.unpy.net/files/sandbox/0001-new-load-pin-immediately-copies-input-to-output.patch
[03:49:12] <jepler> I don't know exactly what jfingle is up to, but this is a bit of a glaring omission in retrospect
[09:07:12] <christel> [Global Notice] Hi all, it appears one of our volunteers set a network ban which were way too wide last night in an attempt to deal with the current attacks; as a result a truckload of genuine users have been banned from the network, with a misleading and unhelpful message. For more information please enable +w in your client. Apologies for the inconvenience, we'll try tidy up after them now.
[13:27:18] <CIA-5> EMC: 03jthornton 07master * r708a1bc47b5b 10/docs/src/hal/ (basic_hal.lyx images/wsum01.png): add info about weighted sum
[13:27:27] <CIA-5> EMC: 03jthornton 07master * r5d7cc06ca8a8 10/docs/man/man9/ (6 files): parameters were converted to pins on 2008-10-26
[13:56:41] <jthornton> * jthornton thinks he didn't miss any
[14:00:23] <cradek> any what?
[14:00:49] <jepler> parameters converted to pins, I think
[14:00:51] <jepler> 5d7cc06ca8a8
[14:01:14] <cradek> ah
[17:37:54] <seb_kuzminsky> micges: have you tried cooling the southbridge?
[17:57:27] <micges> nope
[17:57:34] <micges> I didn't checked that
[17:57:51] <micges> but I'll
[17:58:05] <micges> I'll do that
[18:07:51] <micges> but one hang was 3 min after start
[18:09:03] <micges> boot up pc, load emc some jog-> close emc -> start again -> mesa hang
[18:09:19] <seb_kuzminsky> :-(
[18:16:15] <micges> today on my devel pc I'll loaded over and over my plasma config (with mesa) and once I've loaded joints_axes3 sim and after that my plasma mesa config didn't load
[18:16:28] <micges> maybe this helps a little
[18:16:41] <micges> maybe this is driver closing issue
[18:18:24] <seb_kuzminsky> do you mean it worked fine until you ran joints_axes3 sim, and after that the hostmot2 driver failed to load the 5i20 firmware?
[18:18:49] <micges> yes that was today
[18:19:13] <seb_kuzminsky> strange... sim shouldnt touch the mesa hardware at all, as i understand it
[18:19:24] <micges> but two days ago it was on real plasma cutter with only mesa config
[18:19:58] <seb_kuzminsky> is it repeatable, does sim always break firmware loading? does a reboot always bring it back?
[18:20:21] <micges> and it doesn't touch
[18:21:15] <micges> reboot bring it back in 60% of cases, rest is restored by either power off for 10min or mesa swap to other pci
[18:21:55] <micges> I can't tell if sim always break firmware loading
[18:22:22] <seb_kuzminsky> this is only observed on that Asus P5KPL-CM motherboard, never on any other machines?
[18:28:32] <micges> it never happened on any hp or my old asus mainboard with celeron (I'm on oit now)
[18:28:43] <seb_kuzminsky> well that's good to hear
[18:31:16] <micges> hmm I've just recall that we had parport problems with that mainboard too, they burned off with no reason
[18:31:40] <seb_kuzminsky> Danger! Danger!
[18:31:41] <micges> now we're only using parprot pci card
[18:31:59] <seb_kuzminsky> i wonder how much of the sb got cooked when the parports burned
[18:32:44] <micges> we have 16 those mb here, 12 were used for machines
[18:33:13] <micges> 3 first mb was parport damaged
[18:33:57] <micges> but my parport at work (last hang) was never connected to sth
[18:35:15] <micges> so still no scheme but it seems that tthose mb are sh*t
[18:35:35] <seb_kuzminsky> that's what it sounds like to me too
[18:36:41] <micges> gladly only 4 machines are far away from here ;P
[18:37:14] <micges> rest was simply replacement of old pc here at workshop
[18:38:44] <micges> and parport that burned off was fully optoisolated and on it was simple slow spi transfer
[18:39:46] <micges> anyway I will make some changes on monday, and many thanks for looking and testing this issue
[18:40:11] <skunkworks_> newserver
[18:40:14] <skunkworks_> heh
[18:49:13] <jepler> looks like there's a windbond chip on there, so the parport drivers would not be in the same package as the south bridge
[18:50:14] <jepler> if you've got a bad batch of systems, the power supplies might also be to blame
[18:51:27] <micges> mhm
[19:40:41] <PCW> micges: maybe a BIOS upgrade will help. The ASUS P5KPL-CM uses common chipset parts (G31, ICH7) , so if theres a problem
[19:40:42] <PCW> I'd like to get to the bottom of it. I'm ordering a P5KPL-CM from Newegg for testing here so I can try and duplicate your troubles
[19:42:53] <micges> cool
[19:44:17] <jepler> PCW: when you have a chance, can you send me the card and ucf files for building the 3x20 firmwares?
[19:44:50] <jepler> is there a different 'top' file for the PCIE bridge too?
[19:45:22] <PCW> ASUS at least used to be a good name... Though the P5KPL-CM is only $59.99 so its a prettty low end MB
[19:47:17] <SWPLinux> jepler: did you change the logger software?
[19:47:26] <SWPLinux> I see that they're now logger_1 and logger_2
[19:47:57] <jepler> SWPLinux: I haven't touched it in weeks
[19:48:09] <SWPLinux> oh. I may have just not noticed :)
[19:48:14] <SWPLinux> been busy
[19:48:52] <jepler> I don't recall intentionally changing the nicks they use
[19:49:28] <SWPLinux> ok. I just happened to notice the topic for this channel, looked for logger_dev, and saw logger_2
[19:49:34] <jepler> indeed
[19:49:58] <PCW> jepler: Top file is the same: Top9054...
[19:50:00] <PCW> I think there are a bunch of source changes to accommodate 144 pins including a change in the IDROM version
[19:50:01] <PCW> so firmware built from the new source will not work with 2.3.4
[19:50:33] <jepler> PCW: I see
[19:50:45] <jepler> PCW: I don't even have one of the cards, but I want to get it added to my scripts that build "all" the firmwares
[19:58:27] <alex_joni> SWPLinux: that happened as they somehow reconnected today
[19:58:47] <alex_joni> I saw the new nicks (_1 & _2) connect, and the other ones die a bit later
[19:58:55] <alex_joni> may be connected to the new ircd server
[20:00:09] <SWPLinux> ah, ok
[20:00:21] <micges> PCW: I'll try bios update on one machine and I'll look for some scheme of that issue
[20:00:29] <SWPLinux> so maybe the cron thing is working :)
[20:00:46] <SWPLinux> wow. $439 for 16GB RAM
[20:00:49] <PCW> jepler: The problem is that the old (V2) IDROM had the pindescs terminated by a 0 sentinel
[20:00:51] <PCW> with 144 pins we used all the IDROM locations so theres no room for the sentinel. I changed the IDROM for all
[20:00:53] <PCW> cards to the new layout and changed the IDROM version (so the older driver will bail). I guess I could make the IDROM version
[20:00:54] <PCW> card dependent so only the 3X20 uses the new version for now. I wont be able to get to this for a week or so however.
[20:02:36] <PCW> (now the choice is all new source that will make firmware that will only work with 2.4 or old source that does not include the 3X20)
[20:03:56] <cradek> 2.4 seems like a fine time to add support for new hardware
[20:03:56] <jepler> PCW: I don't see a lot of firmware updates for emc 2.3 in the future
[20:04:16] <jepler> hmph, what's wrong with my Makefile
[20:04:28] <jepler> (make is great, once you've convinced it to do what you want...)
[20:08:29] <SWPLinux> hey PCW, got a website suggestion for you. Make the part numbers in the price list be links to the product pages
[20:08:56] <SWPLinux> (I haven't found the 6I68 yet, going through the categories on the left)
[20:09:31] <PCW> I'm pretty sure the latest HM2 driver will work with either old or new firmware, but of course the old HM2 driver will bail on new bitfiles
[20:09:36] <cradek> or put the prices with the products
[20:09:52] <SWPLinux> s/or/and/ :)
[20:09:54] <PCW> Sounds like work to me...
[20:09:57] <SWPLinux> heh
[20:10:25] <cradek> IMO it's quite an irritation to not see the feature list and price for a product together
[20:11:02] <SWPLinux> right. the price list is a good place to jump to the descriptions
[20:11:04] <cradek> on some sites you can't find the price at all without signing up or calling - twice as bad - I never ever buy from them
[20:11:11] <SWPLinux> since it lists all the products in one place
[20:11:42] <SWPLinux> and also never buy from places that make you sign up to get the datasheets/specs
[20:11:45] <SWPLinux> silly
[20:11:56] <cradek> yep
[20:12:16] <PCW> The 6I68 is not on the website yet, (it just looks like a 7I68 with a 1 lane PCIE slot connector)
[20:12:35] <SWPLinux> hmmm. PCW, is it a typo that the 1MGate and 2MGate 3x20's are the same price?
[20:12:48] <SWPLinux> if so, I'll take a 2M before the price goes up ;)
[20:13:01] <SWPLinux> ah, ok
[20:13:20] <jepler> Is the 2Mgate one the one that can't be built with free xilinx ise?
[20:13:27] <jepler> I always remember there's one that can't be
[20:13:28] <PCW> We will have a much cheaper integrated PCIE card later this year
[20:13:30] <PCW> (1M and 2M FPGA prices are the same, note for 2M Webpack will not work)
[20:13:36] <SWPLinux> ah, ok
[20:13:48] <jepler> and if I get my way that board will be a very second-class citizen, since my plan is to build all the firmwares we ship with the free ise
[20:14:03] <PCW> (X gets there money back from licenses I guess)
[20:14:33] <SWPLinux> hmmm. what's the largest spartan3?
[20:14:51] <SWPLinux> they usually add the non-flagship parts to ISE a year or two later
[20:15:14] <SWPLinux> (and take them out a few years before, so you have to fork over the cash to support legacy applications)
[20:15:19] <PCW> Looks like all of the SP6 are supported
[20:15:32] <PCW> (by webpack)
[20:16:00] <PCW> (New PCIE uses SP6)
[20:16:10] <PCW> bbl lunch
[20:28:12] <jepler> WARNING:Xst:1336 - (*) More than 100% of Device resources are used
[20:28:17] <jepler> how is this only a warning!?
[20:39:57] <SWPLinux> is that the last placement/optimization stage?
[20:41:18] <jepler> SWPLinux: it must not have been
[20:41:21] <jepler> so many messages scroll by
[20:41:31] <jepler> later on it does error
[20:41:56] <SWPLinux> ok, so my assumption is that either they're dumb and that should be an error, or they may be able to remove some stuff with later optimizations
[20:41:58] <SWPLinux> ok
[20:42:10] <jepler> I wonder if my older ISE is dumber than pcw's or whether I'm missing some optimization flag; at the end it still doesn't fit, but this should be the same as a bitfile that he's provided us..
[20:42:33] <jepler> (this is some 7i43 firmware, SVST4_6S)
[20:43:06] <SWPLinux> using the 400k or 200k part?
[20:43:23] <jepler> the suffix "S" indicates the 200k part
[20:43:50] <SWPLinux> ah, ok
[20:44:29] <jepler> bbl
[20:44:51] <jepler> urp, I just discovered that (A) I had a bug in my build script that caused errors in the ise subprograms to be ignored
[20:45:00] <SWPLinux> oops
[20:45:03] <jepler> and (B) other firmwares don't fit either, such as 5i20 SVST8_4
[20:45:29] <SWPLinux> what version are you using?
[20:45:31] <SWPLinux> ISE
[20:45:45] <jepler> apparently Xilinx92i
[20:45:55] <SWPLinux> oh. that's at least 2 years old I think
[20:45:59] <jepler> I'm sure
[20:46:00] <jepler> bbiab
[20:46:03] <SWPLinux> see you
[21:10:35] <jepler> I wonder in how many other programs I've assumed the return value of os.spawnvp(P_WAIT, ...) was the same as os.waitpid(...) i.e., suitable for WEXITSTATUS-type checks
[21:10:56] <jepler> if r:
[21:10:56] <jepler> - raise SystemExit, os.WEXITSTATUS(r)
[21:10:56] <jepler> + raise SystemExit, r
[21:42:20] <jepler> looks like the "-r" (disable register ordering) option to map, which is suggested in the error messages, makes the 3 non-fitting designs fit again; now to do the long step of seeing whether everything builds with map -r
[21:43:06] <PCW> I use 9.2 normally (11.4 only for SP6)
[21:43:19] <jepler> hi again pcw
[21:43:41] <PCW> Hi
[21:44:20] <PCW> 11.4 took something like 18G to install
[21:44:23] <jepler> any idea if you have set the equivalent of map -r in the project when you build (some of) these firmwares?
[21:45:18] <jepler> I got similar errors for 5i20 SVST8_4, 7i43 SVST4_6S, and 4i65 SVST8_4:
http://pastebin.ca/1752851
[21:47:37] <jepler> and as I was saying, they went away when I specified -r
[21:49:42] <PCW> I can take a look at my build options, let me try building 5I20 SVST8_4...
[21:57:39] <PCW> 5i20 SVST8_4 builds ok without -r
[21:57:45] <PCW> (just)
[21:59:54] <jepler> I assume there's a downside to -r, but the docs aren't really spelling it out for me
[22:03:54] <PCW> As usual, it may be my fault, you may have the source with the probe enabled counters always used regardless of whether there is a probe input
[22:03:55] <PCW> -r may limit the speed, but HM2 should meet timing easily
[22:07:43] <jepler> well, in hostmot2.vhd I have 'useprobe1: if UseProbe generate ...' and other stuff that looks like it is making choices based on whether there's a probe input
[22:08:30] <jepler> and in the toplevel files, lines like constant UseProbe: boolean := PinExists(ThePinDesc,QCountTag,QCountProbePin);
[22:09:28] <jepler> any settings from the project files I don't have, so it could also be something earlier in the build process
[22:11:17] <PCW> OK well its not that, let me look at the log file
[22:15:18] <jepler> if you wonder what's in any of the files I'm building from:
http://git.unpy.net/view?p=hostmot2-firmware.git;a=tree;h=66b42bf5e6a762e576a24384cac24478b757b0e4;hb=66b42bf5e6a762e576a24384cac24478b757b0e4
[22:18:19] <jepler> bbl, it's beer-o-clock in Nebraska
[22:20:47] <CIA-5> EMC: 03micges 07defer-format * r2f33e257bebb 10/ (429 files in 145 dirs): Merge branch 'master' into defer-format
[22:21:11] <PCW> http://pastebin.ca/1752907 is the command log for building top9030
[22:21:29] <PCW> (should you scroll back...)
[22:26:22] <PCW> http://filebin.ca/qdbacb
[22:26:24] <PCW> is the latest source including the 3X20 support (but rev3 IDROM so not for 2.3)
[22:31:53] <jepler> PCW: thanks, will look later