Back
[00:00:07] <SWPadnos> heh
[00:00:08] <SWPadnos> oops
[00:00:30] <rayh> The calif coast can be cold if the wind is off the water.
[00:01:03] <rayh> The damp goes right through you.
[00:01:04] <SWPadnos> it was just a little cooler than normal there, and a bit warmer than normal here - so we had 65 degrees while VT had 75 degrees
[00:01:22] <rayh> Okay.
[00:01:32] <SWPadnos> luckily we got out before the heatwave hit though - record highs around 95 or so
[01:21:16] <rayh> I just received a call from Roland Friestad. He has had a fairly severe heart attack. Got home from the hospital today and called me.
[01:21:36] <jmkasunich> wow
[01:21:39] <rayh> He remembered that I said that even if the cnc-workshop didn't go the fest would like to.
[01:22:18] <rayh> He plans to contact the other major players and want's to run the workshop in spite of the lateness of starting up the web site.
[01:22:44] <rayh> He and his wife will get the site going but would like us to take the responsibility for all of the EMC side of things.
[01:23:40] <rayh> I don't know how that would make it any different that the previous sessions. We've tended to do that anyway.
[01:24:33] <rayh> I'll plan to show up down there Thursday/Friday before and help arrange things. If a couple of you guys could do the same it would really help us and Roland.
[01:25:05] <jmkasunich> I've already got approval for the week of the fest, and I'd like to be able to take a few days before
[01:25:06] <rayh> I will post a note to the developer and user lists about the reasons for the delay with registration.
[01:25:20] <jmkasunich> but I have a deadline at work that will be cutting it very close
[01:25:24] <rayh> That would be great, john
[01:25:40] <rayh> I presume you plan to drive in?
[01:25:44] <jmkasunich> yes
[01:26:03] <rayh> Say I like the remodel. Looks great.
[01:26:12] <jmkasunich> I was originally thinking of either taking friday off to load up, then driving on Sat, or loading fri nite
[01:26:16] <jmkasunich> (depending on work)
[01:26:39] <jmkasunich> thanks - got the drywall up last night, boxed in the window and working on a bit of trim, then I'm gonna prime tonight
[01:26:50] <rayh> Sure. If you get there during the day Sunday, you can take charge of quite a lot of the final setup.
[01:27:04] <jmkasunich> I'll definitely be there Saturday evening
[01:27:27] <rayh> I don't remember much about that corner. Seems like things were facing the other way when I was there.
[01:27:35] <jmkasunich> if work permits, I could be there earlier, Thur or Fri, but I won't know that for a while
[01:27:43] <rayh> Have you got a room reservation?
[01:27:48] <jmkasunich> not yet
[01:28:00] <rayh> Where you thinking of staying?
[01:28:07] <jmkasunich> hadn't thought that far
[01:28:17] <rayh> I know the feeling!
[01:28:22] <jmkasunich> either the place from last year (on the traffic circle downtown) or the Econo
[01:28:40] <rayh> Was the place last year good?
[01:31:00] <jmkasunich> it was OK
[01:31:11] <jmkasunich> maybe a tad seedier than the Econo
[01:35:18] <rayh> If you can spend Sunday setting up the EMC2 developer area and lan it would help a lot.
[01:35:25] <jmkasunich> that will be no problem
[01:35:39] <jmkasunich> if its like last year, Chris and Jeff will arrive Sat. evening too
[01:36:01] <jmkasunich> the three of us set up Sun morning, and swp arrived Sun afternoon
[01:36:15] <rayh> Okay. That will be great. You guys can get all that together.
[01:36:53] <rayh> I'll ask on our lists for volunteers to help him more directly with things like the presentation schedules and so forth.
[02:01:54] <steves_logging> steves_logging is now known as steve_stallings
[02:03:44] <steve_stallings> YIKES - I hope Roland is doing OK. Running a show is lots of work and lots of stress.
[02:07:35] <rayh> Yes it is.
[02:08:15] <rayh> He sounded good. A bit dazed and confused at one specific set of questions but doing well for a guy with three new stents.
[02:08:56] <cradek> wow, glad to hear he's doing ok. that sounds serious.
[02:09:02] <cradek> of course I'll help however I can
[02:10:15] <rayh> You bet. He's doing well, i think.
[02:11:09] <rayh> I've not no worries about the developer setup. You guys can handle that.
[02:11:28] <cradek> what else can we do?
[02:11:32] <rayh> I'll handle my classroom/lab.
[03:15:35] <SWPadnos> ugh
[03:15:58] <SWPadnos> I just saw the note about Roland. I hope he's doing OK (and his family)
[03:18:11] <SWPadnos> I should be able to come in early and help set up
[03:24:25] <steve_stallings> I just got off the phone with Matt and we will plan to arrive Saturday afternoon and can provide some help with setup of sessions, or whatever.
[03:25:01] <SWPadnos> there were around 100 or so attendees last year, right?
[03:25:12] <SWPadnos> hmmm. maybe that was 2 years ago
[03:25:31] <steve_stallings> I think more, but spread out over the week.
[03:25:50] <SWPadnos> ok. I was just thinking of the size of the mailing list he sent out after the workshop 2 years ago
[03:25:58] <steve_stallings> There were probably almost 200 hanging around for the drawing/food.
[03:26:03] <SWPadnos> heh
[03:38:16] <steve_stallings> steve_stallings is now known as steves_logging
[10:28:17] <alex_joni> http://pastebin.ca/1002754
[10:31:14] <fenn> "a semi-large number" :)
[11:35:33] <rayh> Thanks Steven, Steve. I'll get a note off to Roland this morning.
[12:00:02] <alex_joni> hi ray
[12:09:30] <jepler> on the latest amd64 rtai kernel I've had the emc2 latency-test running for 2 days .. system's fine so far. (this is the first time I've booted the -16 rtai kernel, all my crashes were on -12 .. but it's early to say, as sometimes the kernel was up for a week or more)
[12:10:40] <alex_joni> jepler: thinking about a amd64 livecd?
[12:12:41] <jepler> alex_joni: not yt
[12:12:42] <jepler> yet
[12:15:05] <rayh> Hi alex
[12:15:35] <rayh> Hi jeff
[12:16:59] <skunkworks_> ran all night - still 101 tasks running
[12:19:06] <alex_joni> skunkworks_: sounds good
[12:20:36] <skunkworks_> I did have it where the cone didn't move once when starting a program.. (The code was scrolling though). stopped and restarted the program and the cone moved. (It was so odd that I wasn't sure what was happening at first)
[12:23:33] <jepler> skunkworks_: if you had emc2 version 2.2.4~cvs that's not surprising. if you have version 2.2.5, it is
[12:24:16] <alex_joni> jepler: otoh at his system load it might not be surprising even with 2.2.5
[12:33:12] <skunkworks_> I am not worried about it unless it happens consistantly. As alex said - the system was pretty taxed
[12:38:59] <rayh> jepler, I've got a stock 8.04 on an amd64. Can I modify sources.list and pick up your packages for emc?
[12:39:10] <alex_joni> rayh: you should be able to
[12:39:39] <alex_joni> rayh: the install script should apply to amd64 aswell
[12:39:46] <rayh> I don't quite understand that file. What exactly would that line look like.
[12:39:54] <alex_joni> maybe you can try it directly?
[12:40:00] <alex_joni> http://www.linuxcnc.org/hardy/emc2-install.sh
[12:40:21] <rayh> oh. okay. I'll try that.
[12:53:51] <skunkworks_> * skunkworks_ thinks ray is loving his high speed internet.
[12:58:30] <rayh> Uh yes!
[13:00:23] <alex_joni> rayh: how did you survive with dial-up all those years :D
[13:00:55] <rayh> I spent days waiting for downloads. Wget was my friend.
[13:07:07] <skunkworks_> jepler: should I email saying that the 8255 may still have some bugs?
[13:07:36] <rayh> Looks like I've got a realtime system running. I'll update to the latest 8.04 and then do some testing.
[13:07:52] <alex_joni> rayh: on amd64?
[13:07:59] <alex_joni> * alex_joni runs home..
[13:08:00] <alex_joni> bbl
[13:08:02] <rayh> Yes
[13:08:04] <skunkworks_> neat
[13:08:16] <alex_joni> rayh: cool.. so no isses with the install script
[13:08:18] <alex_joni> nice to know
[13:08:28] <skunkworks_> that is using smp then?
[13:08:34] <rayh> I couldn't get it to run. Ran it a line at a time.
[13:08:58] <rayh> This is a single 64 box
[13:09:43] <rayh> It did start running because it fixed the sources.list.
[13:09:55] <rayh> but I had to run the update and install by hand.
[13:11:12] <skunkworks_> rayh: little testing..
http://imagebin.org/17222
[13:11:32] <rayh> k
[13:13:07] <skunkworks_> load testing? ;)
[13:13:27] <rayh> Looks like it. This a 64?
[13:14:10] <skunkworks_> no - that one was just a pent 4 2.4ghz
[13:14:32] <skunkworks_> this was a dual core..
http://imagebin.org/17235
[13:15:47] <rayh> Okay. xorg does take a lot of cpu.
[13:17:24] <rayh> I've not tried a lot of other packages to distract it. I've seen xorg about 20% on a semperon.
[13:19:39] <rayh> EMC is running on the amd64 proc with asus a8 mobo and video card.
[13:19:54] <rayh> Did say unexpected realtime delay.
[13:21:23] <rayh> what is scrollkeeper and why does it use more than 50% of the cpu
[13:22:41] <skunkworks_> have you run latency-test yet?"
[13:22:59] <skunkworks_> is this onboard video? (shared video memory?)
[13:24:03] <rayh> No it's a cheapo card
[13:24:45] <rayh> No latency test yet. Running cds.ngc and that seems fine.
[13:27:38] <rayh> Now scrollkeeper has dropped way down and xorg is using about 25%. That's about the same as my semperon.
[13:33:32] <skunkworks_> garfield3: what bug?
[13:38:24] <ray1> Wow. Some huge jitter -- 2820206
[13:38:52] <ray1> with glxgears, gimp doing some rendering, and office.
[13:47:17] <rayh> on the semperon it shows 7918 jitter
[13:47:36] <rayh> glxgears runs a lot slower on the 32 bit than the 64.
[13:49:11] <skunkworks_> yikes.. Something is having issues.. Do you have a memory stick plugged in?
[13:53:22] <ray1> No
[13:55:08] <ray1> I should look at the bios on this box.
[13:59:15] <skunkworks_> maybe some power saving settings in the bios?
[13:59:47] <skunkworks_> what is the cheapo video card?
[14:00:07] <skunkworks_> you could try setting it to visa..
[14:00:12] <skunkworks_> vesa
[14:00:28] <jepler> after 48 hours my amd64 machine has pretty good latency -- 11278
[14:02:29] <skunkworks_> That is nice.
[14:03:51] <skunkworks_> Jepler: did you see my question about the 8255 card.. About posting on the list that it may issues at the moment?
[14:08:23] <jepler> skunkworks_: I guess ..
[14:08:33] <jepler> I still haven't gotten motivated to look into that problem
[14:08:59] <skunkworks_> That is ok - I just don't want a bunch of people buying the card expecting it to work.
[14:12:02] <cradek_> cradek_ is now known as cradek
[14:15:02] <rayh> open office hits jitter big time on the 64 bit
[14:15:17] <skunkworks_> sounds like a video issue..
[14:15:29] <jepler> rayh: is 32-bit emc OK on this machine?
[14:15:47] <rayh> I've not tried 32 bit on that box.
[14:16:07] <rayh> I have it running well on a semperon 32 and that hangs right in with jitter.
[14:16:31] <rayh> That is the box I was getting near 80 pulses for stepper testing.
[14:20:13] <rayh> 80K
[14:23:33] <gefink> hallo
[14:24:14] <jepler> hello
[14:24:47] <gefink> i found a minor bug in stepconf-wizard
[14:25:13] <jepler> what is the bug?
[14:26:13] <gefink> the axis moves in the "test axis" dialog over the limit
[14:26:32] <SWPadnos> is your scaling correct?
[14:26:37] <gefink> if you decrase the acceleration while the axis is moving fast
[14:26:45] <SWPadnos> ah
[14:28:14] <SWPadnos> if you decrease accel during a move, you may be making a set of constraints that are impossible to satisfy
[14:28:44] <SWPadnos> you should expect the axis to move too far if you reduce accel drastically near a reversal point
[14:29:00] <SWPadnos> "near" has different values depending on accel and velocity limits
[14:30:03] <gefink> The minimum is 1 and you dont need much spees ...
[14:30:11] <gefink> d
[14:30:35] <SWPadnos> the mimimum accel value is 1?
[14:30:46] <gefink> yes
[14:30:50] <SWPadnos> hmmm
[14:31:14] <gefink> that was changed becise zero was more fatal
[14:31:19] <jepler> how do you think stepconf should behave in this case?
[14:32:02] <gefink> it shold sample the acceleration und only update ich the axisspeed is acceptable
[14:32:15] <gefink> ich=if
[14:32:21] <jepler> how do I know if the speed is "acceptable"?
[14:34:07] <gefink> the simplest way is zero
[14:34:36] <SWPadnos> I didn't understand that
[14:35:11] <gefink> when the axis chage the direction it "stops"
[14:35:50] <gefink> but i think this point in not good to meet
[14:36:05] <gefink> sorry for using wrong words
[14:36:18] <SWPadnos> no problem there - it's much better than me trying german :)
[14:37:53] <gefink> i donkt know how hard it is to calculate the remaining way for the new acceleration
[14:38:48] <rayh> ich ouch
[14:39:16] <gefink> on the other side it must be possible to use the current speed of the axis
[14:40:06] <SWPadnos> the accel is applied when stopping for the reversal
[14:40:25] <SWPadnos> if you reduce accel while it's decelerating, you make a mathematically impossible set of constraints
[14:40:36] <SWPadnos> so something has to give, and at this point it's the end poisition
[14:41:40] <gefink> and how is is only update the acceleration while the axis is incrasing speed?
[14:41:51] <gefink> sorry
[14:41:53] <cradek> throughout the reversal is the full acceleration
[14:42:02] <gefink> i mean only for decrasing
[14:42:16] <cradek> the only time acceleration=0 is in the center of motion when it's moving the fastest
[14:42:34] <SWPadnos> accel limit, not applied accel :)
[14:42:45] <gefink> jes. then ther is no update.
[14:43:15] <gefink> at the moment the acis is accelerating the new value is used
[14:43:49] <SWPadnos> I guess it would be possible to only update the accel value at the start of a move
[14:44:22] <SWPadnos> that would reduce the "interactivity" of the tester, but it should prevent overshoot
[14:44:24] <gefink> the incrase is no problem. only decrasing is a problem
[14:45:13] <gefink> then its possible there ar no sideeffekts
[14:45:37] <SWPadnos> other than the surprise at being able to increase accel but not decrease it in the UI :)
[14:46:08] <gefink> only in one move
[14:46:44] <gefink> the next mov is decrased
[14:47:14] <gefink> and if the axis moves voll speed acceleration is void.
[14:48:36] <gefink> its not so easy as thought first
[14:49:12] <jepler> the only easy alternatives are to disallow changing acceleration during a run, or to allow changing it to any allowed value.
[14:49:42] <gefink> thats not a good alternative
[14:49:45] <jepler> there's no easy way to control when during a test move an acceleration change would be applied
[14:50:06] <jepler> unfortunately, software is compromise
[14:50:11] <gefink> yes
[14:51:07] <gefink> but it looks as sampling the new acceleration for one situation is ok:
[14:51:59] <gefink> decrasing acceleration while axis is not acelerating speed
[14:53:08] <gefink> then the move is finisched with old parameters
[14:53:43] <gefink> at the next move the new acceleration is used
[14:53:48] <SWPadnos> I'm not sure that the GUI knows when accel or decel are being applied
[14:54:06] <jepler> I think I understand what you are suggesting, but it is not easy to do, for the reason that SWPadnos gives
[14:54:35] <gefink> i dont know about stepconf internals
[14:54:52] <jepler> there is no way to make sure that the new acceleration setting is applied at the desired moment. To do that would actually require changes to emc's step generator component.
[14:55:01] <skunkworks_> alex_joni:
http://www.cnczone.com/forums/showpost.php?p=446248&postcount=12
[14:55:58] <SWPadnos> jepler, it may be possible to do it if stepgen has an "in-position" output
[14:56:06] <SWPadnos> it is a PITA though
[14:56:31] <SWPadnos> actually, it can be done even without in-position
[14:56:43] <jepler> SWPadnos: no, because accel is a parameter. even if you can determine which servo cycle is the one you want, you can't do anything until some userspace code runs.
[14:56:49] <SWPadnos> ah, true
[14:56:50] <gefink> the velocity of stepgen is readable...
[14:56:54] <SWPadnos> nevermind :)
[14:58:14] <gefink> i see its harder to do
[14:59:05] <gefink> but i think stepconf makes the move
[14:59:25] <SWPadnos> in the end, we can't protect some users while still giving others the flexibility they need
[14:59:38] <jepler> gefink: please update that bug on sourceforge with your findings an opinions, so that the knowledge lasts longer than this conversation
[14:59:53] <jepler> (the bug that caused me to change the lower limit from 0 to 1)
[15:00:13] <SWPadnos> is it possible to have a non-integer lower limit?
[15:00:19] <SWPadnos> like 0.1 or something
[15:01:09] <gefink> good idea.
[15:01:44] <gefink> no as lower tha value then bigger the Problem
[15:02:51] <gefink> the way you need to stop the axis get longer with decrasing acceleration
[15:05:29] <cradek> 1mm/s2 is way too low. maybe that's the bug, and if so, it's easy to fix
[15:07:53] <gefink> yes alt all if the speed id high
[15:08:20] <gefink> i notied only while using under 5
[15:08:43] <cradek> I don't know of any machine that would need acceleration less than 50mm/s2
[15:08:57] <cradek> that's especially true for stepper driven machines
[15:09:47] <gefink> one idea is to unse something like speed/5 as minimum ?
[15:10:40] <cradek> no, since then when you changed the speed, the acceleration would surpisingly change too
[15:12:12] <gefink> i mean as hidden limit for the operator-knob
[15:14:04] <cradek> I understand. but that limit would change, which means the current value would sometimes need to change
[15:14:56] <gefink> yes
[15:15:22] <gefink> i update my bugreport. maybe somone has a idea
[15:15:30] <cradek> ok thanks
[15:15:39] <gefink> but i dont find the tracker...
[15:15:54] <cradek> sf.net/projects/emc
[15:17:14] <gefink> thanks. i allway git forwarded to wiki
[15:32:14] <skunkworkshardy> bbl
[15:51:46] <skunkworks_> cradek: I sent an email to the list that had the i/o from the 8255.. It says it is waiting for moderation because it is 27k.
[15:56:38] <skunkworks_> cradek: thanks
[16:05:21] <cradek> skunkworks_: please fix your mailreader so it never sends html email to the lists
[16:05:52] <skunkworks_> sure - sorry
[16:06:00] <cradek> then you won't have problems!
[16:06:47] <jepler> hm I wonder if gene is on the right track about an interrupt
[16:06:53] <jepler> I am surprised any kind of interrupt would be enabled by default!
[16:07:28] <SWPadnos> nothing a simple trace cut can't cure :)
[16:07:36] <skunkworks_> heh
[16:07:47] <skunkworks_> seriously?
[16:07:53] <SWPadnos> yes
[16:08:12] <skunkworks_> * skunkworks_ goes and gets a razorblade.. ;)
[16:08:19] <SWPadnos> heh - too funny:
http://www.pci8255.net/
[16:09:33] <SWPadnos> oh - hmmm. the futurlec board actually has 8255s on it. I thought it was an integrated chip
[16:09:52] <jepler> SWPadnos: the version I have has a surface-mount PCI bridge chip plus three socketed DIP 8255s
[16:09:59] <SWPadnos> like the photo
[16:12:30] <rayh> I set up an old computer boards pci with a 8255 on it. Don't remember anything about interrupt.
[16:12:41] <rayh> BDI days though.
[16:12:52] <SWPadnos> different board though
[16:12:59] <rayh> Yep
[16:13:11] <rayh> I had to set it up using a stock linux driver.
[16:13:28] <rayh> That done it would run using emc fine.
[16:13:37] <SWPadnos> the computer boards / measurement computing units I've used have all had jumpers or dipswitches to select interrrupts (if they supported ints at all)
[16:14:11] <skunkworks_> SWPadnos:
http://www.futurlec.com/PCI8255.shtml
[16:14:29] <SWPadnos> yep. can't seem to find a manual though
[16:14:36] <rayh> I'd not heard of it at all. But then most of my experience is with ISA and 8255 boards
[16:16:31] <skunkworks_> SWPadnos: not english..
http://emergent.unpy.net/01165433819
[16:16:32] <jepler> reading an 82c55a datasheet, the chip has some modes where output bits on "port c" are generated from internal logic (it calls them interrupts), but the emc driver shouldn't be operating them in that configuration, and the board shouldn't be connecting them to PCI interrupts anyway
[16:17:28] <SWPadnos> hmmm. yeah, my thai (or whatever that is) is a bit rusty :)
[16:17:31] <skunkworks_> I would think it would be the tiger chip issue
[16:17:59] <SWPadnos> page 3 of the thai manual shows an interrupt line
[16:18:10] <SWPadnos> in the tiger320
[16:18:45] <jepler> yeah I agree it does -- but I think that's just a block diagram copied from tiger320 datasheet, who knows what aux[7:0] is hooked to
[16:19:12] <SWPadnos> it's described on page 4 (DMA interrupt)
[16:19:22] <SWPadnos> but I can only read a few words ;)
[16:20:02] <skunkworks_> hmm - didn't I get the english manual with the cards? jepler: did I send a cd to you?
[16:20:11] <skunkworks_> or maybe I didn't
[16:20:24] <jepler> skunkworks_: I don't recall
[16:20:37] <skunkworks_> I don't either..
[16:22:17] <SWPadnos> skunkworks_, did you get the hard lock when any input was toggled, or only certain ones?
[16:23:12] <skunkworks_> I should hook it up again - but I am pretty sure it would run a long time without touching the inputs.. but when I would physically toggle an input - it would lock after a few <20 toggles.
[16:23:25] <SWPadnos> any input?
[16:23:29] <skunkworks_> yes
[16:23:43] <SWPadnos> did you try using different ports as input?
[16:23:51] <SWPadnos> ie, port A one time, B another, C another
[16:23:55] <skunkworks_> well - on the first 24 inputs
[16:24:00] <SWPadnos> ok
[16:24:00] <skunkworks_> Now - I did not try b or c
[16:24:17] <SWPadnos> ABC are the ports for one chip :)
[16:24:28] <skunkworks_> sorry 1 or 2..
[16:24:34] <SWPadnos> heh
[16:24:36] <skunkworks_> ;)
[16:26:08] <rayh> How does emc handle configuring the chip for IO?
[16:26:23] <SWPadnos> load-time parameters tell the driver how to configure each chip
[16:26:41] <SWPadnos> I don't think it does anything with the tiger320 chip though
[16:27:06] <jepler> the tiger320 is configured not to send any interrupts over the pci bus by default
[16:27:17] <jepler> (tiger320 datasheet page 22, 23)
[16:29:46] <SWPadnos> hmmm. yeah, it looks like it should play nice by default
[16:29:49] <jepler> I do write a few tiger320 configuration registers, near the comment // PIB reset low, 15 cycle operation in the source code
[16:31:43] <SWPadnos> hmmm
[16:32:25] <SWPadnos> shouldn't WRITE(0x10, io[i]+3, 0) actually be WRITE(0.10, io[i], 3) ??
[16:33:05] <SWPadnos> err - 0x10 there, not 0.10
[16:35:45] <jepler> I *think* that the PIB registers are 4 bytes apart, but that the tiger320 registers are 1 byte apart
[16:40:21] <SWPadnos> it's hard to tell
[16:40:36] <jepler> I agree
[16:44:10] <jepler> http://www.etteam.com/download/10PC_INTERFACE/1008/ET_PCI8255_V3_delphi_5.pdf page 8
[16:44:28] <jepler> it has the 8255 registers at 0xc0, 0xc4, ... but the configuration registers at 0x0, 0x1, ...
[16:45:03] <SWPadnos> yes. there's a lot of evidence that they are byte-wide. DMA addresses take up 4 registers for example
[16:45:22] <SWPadnos> it seems silly considering that it's an interface to a 32-bit bus
[16:45:34] <jepler> yeah
[16:45:48] <jepler> hm the delphi code takes care to preserve the other bits of register 0, while I don't.
[16:47:07] <SWPadnos> it's possible that you're turning on contiuous loop DMA mode
[16:47:23] <jepler> but still -- why would it be sensitive to changes in I/O pins?
[16:47:34] <SWPadnos> good question
[16:48:58] <alex_joni> whee.. long backlog :)
[16:49:10] <alex_joni> skunkworks_: wonder if I should sign up there, or you can paste my reply
[16:53:41] <skunkworks_> sure
[17:00:43] <gefink> by. thanks for your work
[17:05:28] <alex_joni> skunkworks_: I noticed he wrote to the list too
[17:05:35] <alex_joni> so I'll keep it just there
[17:07:05] <alex_joni> jepler: seen
http://www.cnczone.com/forums/showpost.php?p=446248&postcount=12 ?
[17:07:37] <alex_joni> I'm not sure that's the proper fix ..
[17:07:49] <alex_joni> I'd rather have RTAI fixed than emc2 work around it
[17:56:15] <jepler> alex_joni: is this fix for amd64 or for i386? on amd64, the flag is passed already
[17:56:20] <jepler> I can't check on i386 right now..
[18:25:38] <jepler> alex_joni: you can see it by running something like this in a configured emc source directory:
[18:25:41] <jepler> touch hal/components/and2.comp | make KBUILD_VERBOSE=1 2>&1 | grep --colmcmodel=[a-z]*
[18:25:45] <jepler> er, first | should be ;
[18:26:24] <jepler> and the command is garbled anyway; let me try again
[18:26:33] <jepler> touch hal/components/and2.comp; make KBUILD_VERBOSE=1 2>&1 | grep --color=auto mcmodel=[a-z]*
[18:51:22] <alex_joni> jepler: I get nothing
[19:04:55] <jepler> I am pretty sure from the 'info gcc' that -mcmodel=kernel only applies on amd6
[19:04:58] <jepler> 4
[19:05:30] <jepler> reading info gcc again, I see that just above the explanation of this flag, it says "these -m switches are supported in addition to the above on AMD x86-64 processors in 64-bit environments", so they wouldn't apply on 32-bit systems
[19:05:49] <alex_joni> might be.. I hope he can duplicate it on a 32-bit install aswell
[19:05:55] <alex_joni> (maybe by running the live-cd)
[19:29:04] <SWPadnos> cool. I wonder if that SMI killer will work at least most ofthe time
[19:30:17] <alex_joni> heh.. I'm just checking the RTAI version of SMI (if it's sane..)
[19:34:20] <alex_joni> the RTAI version of SMI workaround looks sane (to the extent found on dapper)
[19:35:33] <alex_joni> SWPadnos: it doesn't look much more advanced than the RTAI version
[19:36:01] <SWPadnos> ok. does the rtai_smi module disable all SMI functions?
[19:36:08] <alex_joni> yes, by default
[19:36:11] <SWPadnos> ok, cool
[19:36:49] <alex_joni> the rtai smi contains 16 chipsets, the one on that page only 15
[19:37:01] <alex_joni> I bet the 15 are contained in the 16 from RTAI
[19:37:17] <SWPadnos> grep / cut / uniq / sort ... :)
[19:39:35] <alex_joni> AHA
[19:39:44] <SWPadnos> !
[19:39:45] <alex_joni> with SMI enabled, I can't get my laptop to overrun anymore
[19:39:53] <SWPadnos> weird
[19:40:04] <alex_joni> (previously if I would use Fn-F4 to turn brightness up it would overrun)
[19:40:15] <alex_joni> if I didn't touch Fn-foo it would wok ok-ish
[19:40:17] <SWPadnos> does fm-f2 still change the brightness?
[19:40:21] <SWPadnos> err - fn-f4
[19:40:22] <alex_joni> nope ;)
[19:40:28] <SWPadnos> bummer :)
[19:40:37] <alex_joni> yeah, well.. can't have both
[19:40:37] <SWPadnos> did you mean enabled or disabled up there?
[19:40:53] <alex_joni> RTAI smi module loaded
[19:40:59] <alex_joni> preventing SMI I guess
[19:41:02] <SWPadnos> heh
[19:41:10] <SWPadnos> once the SMI disabling module is enabled :)
[19:41:31] <alex_joni> right
[19:42:35] <alex_joni> latency is around 19200, with glxgears maximized (I still get about 300 FPS)
[19:42:55] <alex_joni> I'd say it's an acceptable laptop :)
[19:43:07] <alex_joni> no parport though
[19:43:20] <SWPadnos> same problem here
[19:48:59] <alex_joni> you on i386?
[19:49:10] <SWPadnos> no parport ;)
[19:49:25] <alex_joni> ah.. I have a cardbus parport around
[19:49:29] <SWPadnos> I don't have RT on any laptop at the moment (I loaned my older one out)
[19:49:33] <alex_joni> and I managed to get it working at some point
[20:42:50] <jepler> I wonder when rtai will get the correct solution: use virtualization extensions to virtualize smi.
[20:43:16] <jepler> I saw a note somewhere that this is a feature in the second-generation of that processor feature
[20:43:53] <jepler> fwiw running intel chips with SMI off is violating the thermal design, so I would be pretty reluctant to do it on a laptop
[20:44:32] <SWPadnos> hmmm. I wonder if the SMI killer modules turn fans on before turning the interrupts off
[20:45:36] <alex_joni> SWPadnos: not here
[20:45:43] <SWPadnos> bummer
[20:45:55] <alex_joni> yup.. otoh, the fan seldom turns on here
[20:46:03] <alex_joni> sometimes during a kernel compile..
[20:46:37] <SWPadnos> hmmm. the right thing to do (in our case) is to set the processor speed to full, turn on the fans, and shut off the interrupt
[20:48:31] <cradek> this all sounds scary
[20:48:36] <alex_joni> hmm.. I have SMI off right now, and the fan is running
[20:48:48] <SWPadnos> it can run, but it shouldn't change speed
[20:48:54] <alex_joni> it does
[20:48:58] <alex_joni> it just switched off
[20:49:04] <SWPadnos> strange
[20:49:06] <jepler> it's not about fans
[20:49:12] <SWPadnos> I wonder if they leave thermal stuff on
[20:49:12] <jepler> it's about CPU throttling
[20:49:32] <jepler> intel uses smi to throttle the CPU in order thatn the processor never exceeds the TDP (thermal design power)
[20:49:41] <SWPadnos> it's about cooling or generating less heat. I think both functions can be controlled with SMI
[20:50:09] <jepler> without smi, there's no guarantee that your "23W" laptop processor won't make more heat than the rest of the cooling system is prepared to dissipate
[20:53:13] <jepler> intel datasheets admit that the TCC (thermal control circuit) will occasionally activate even when the rest of the cooling system is properly designed: "It is anticipated that the TCC would only be activated for very short periods of time when running the most power intensive applications"
[20:56:47] <alex_joni> cradek: get a stash of P3's
[20:57:00] <jepler> I think cradek has a stash of P3s
[20:57:01] <alex_joni> I have a feeling those will sell quite good in a couple of years :)
[20:57:11] <SWPadnos> heh
[20:57:16] <cradek> THEY'RE MIIIINE
[20:57:20] <SWPadnos> as long as you have the matching motherboards and memory
[20:57:26] <SWPadnos> preciousssssss
[20:57:39] <alex_joni> SWPadnos: I meant PCs
[20:57:52] <SWPadnos> oh. that's different :)
[20:58:03] <alex_joni> not only processors
[20:58:34] <alex_joni> * alex_joni cuddles his athlon XP
[21:03:49] <skunkworks_> SWPadnos: the other plugs also lock up the computer. (still have not found the ryhme or reason though) Sometimes I can switch the input many times - other times it locks up pretty quick.
[21:04:10] <skunkworks_> If I don't touch it - it runs a long time.
[21:04:21] <skunkworks_> * skunkworks_ goes and tries again to be sure
[21:04:36] <SWPadnos> hmm. then I'm about as stumped as I can be, especially considering that I don't have the hardware: )
[21:04:54] <jepler> skunkworks_: do it without executing 'halcmd start' (you'll need a standalone hal file for this)
[21:05:06] <jepler> or without adding the 8255 functions to the threads
[21:05:35] <skunkworks_> I have run it without the read functions.. And it seems to run forever.
[21:05:38] <SWPadnos> hmmm. actually, you should be able to just load then unload the module, if you want to test whether the initialization code does it
[21:05:49] <jepler> that's a good idea too
[21:06:05] <skunkworks_> (atleast I have not had it lock up without the read functions in the servo thread)
[21:06:10] <SWPadnos> if it runs forever without the read function, that's a good indicator of where the problem could be :)
[21:06:55] <jepler> yep
[21:07:07] <jepler> but I don't remember all the details of this behavior since I forget anything once it scrolls off irc
[21:07:26] <SWPadnos> you need a taller screen ;)
[21:07:47] <skunkworks_> same here.
[21:17:27] <alex_joni> jepler: I still remember where one can look once it's off the screen ;)
[22:02:19] <alex_joni> g'night all
[22:36:00] <jepler> 3 s32 RO 22788 pci8255.read-all.time
[22:36:00] <jepler> 3 s32 RW 2002223624 pci8255.read-all.tmax
[22:36:04] <jepler> this seems .. bad
[22:37:51] <SWPadnos> it seems to be about 100000 times too long there
[22:39:36] <jepler> yes something like that
[22:41:42] <jepler> as far as I can tell, it's the inb() instructions themselves that are introducing huge pauses; after a few moments it kills the machine
[22:41:52] <jepler> I was lucky to get that ^^
[22:42:01] <jepler> but it doesn't always give a huge pause, sometimes the .time is OK
[22:43:22] <SWPadnos> that is mighty weird
[22:43:38] <SWPadnos> I can't think of any reason why inb would pause for that long
[22:43:55] <SWPadnos> or even for 1/1000000 that long
[22:45:53] <jepler> it seems to be the inb() or inl() itself
[22:49:23] <SWPadnos> so it does the same thing whether you use inb or inl?
[22:51:13] <jepler> well for a moment I thought inl() fixed it
[22:51:21] <jepler> but I no longer think that
[22:51:50] <SWPadnos> have you tried using the memory mapped I/O isntead of I/O (since multiplying by SHIFT in read/write)?
[22:52:24] <SWPadnos> oh hmm. the multiply shouldn't be needed
[22:54:24] <jepler> [ 149.041194] spurious 8259A interrupt: IRQ7.
[22:54:24] <jepler> [ 149.041199] Default Trap Handler: vector 0: Suspend RT task f4a46800
[22:54:24] <jepler> [ 151.444808] psmouse.c: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
[22:54:27] <jepler> [ 160.231817] hda: dma_timer_expiry: dma status == 0x24
[22:54:29] <jepler> [ 170.213656] hda: DMA interrupt recovery
[22:54:32] <jepler> this is what I got the last time
[22:54:34] <jepler> [ 170.213663] hda: lost interrupt
[22:54:48] <jepler> (lspci shows a different irq number than 7 for the 8255 board)
[22:55:03] <jepler> the system died again as well
[22:55:06] <jepler> lots of reboots today :-P
[22:57:09] <jmkasunich> any interrupts from that board would be a bad thing I would think
[22:57:16] <jmkasunich> turn it off, it burns
[22:57:25] <SWPadnos> it's supposed to be off already
[22:57:52] <SWPadnos> unless the kernel (or BIOS) decides to enable interrupts/DMA for some reason
[22:59:24] <jmkasunich> is there some init code for the 8255 that tells it to keep its bloody mitts off the IRQ lines?
[22:59:54] <SWPadnos> I'm not sure the IRQ thing is the problem
[23:00:03] <jmkasunich> neither am I
[23:00:04] <SWPadnos> the tiger PCI interface chip would control that
[23:00:12] <jmkasunich> but I'm not sure its NOT the problem
[23:00:18] <SWPadnos> nope
[23:00:28] <jepler> and the power-up states for the tiger chip would *not* ever cause PCI interrupts
[23:00:29] <jmkasunich> I believe the 8255 has an "interrupt on input change" option
[23:00:45] <jmkasunich> and the crashes have been associated with input changes
[23:01:29] <jmkasunich> the tiger is acting like a traffic cop between the 8522 and the bus?
[23:02:05] <jepler> jmkasunich: right
[23:02:10] <SWPadnos> the tiger chip is the equivalent of the PLX chips on the Mesa cards
[23:02:21] <SWPadnos> PCI <-> local bus interface
[23:02:26] <jmkasunich> ok
[23:03:10] <jmkasunich> coming in late here - is there an 8255 on the local bus (or several), or is it some VLSI emulation of an 8255?
[23:03:20] <SWPadnos> 3x 8255
[23:03:32] <SWPadnos> I thought it was some integrated thing, but I was wrong
[23:04:30] <jmkasunich> so, if an 8255 asks for in interrupt but the tiger says no, will the 8255 sit there and pout the next time you try to access it?
[23:04:53] <jepler> dinnertime here .. don't spend too much time thinking about this, those of you who don't have any hardware
[23:04:54] <jmkasunich> (if it somehow thinks its still doing interrupt cycles instead of read cycles)
[23:05:36] <jepler> jmkasunich: nothing that I saw in the 8255 datasheet led me to think that -- there are some modes which use part of one of the ports as an interrupt output, but I shouldn't be using those modes
[23:05:44] <jepler> and they shouldn't stop the device responding on the local bus to I/Os
[23:05:57] <SWPadnos> I don't think the 8255s are doing anything interrupt-related
[23:08:25] <jepler> It seems much more likely that I'm somehow doing I/O to the wrong PCI bus ports, and just don't see why/how
[23:09:03] <SWPadnos> as an aside, if it works using memory-mapped I/O I'd do that instead
[23:09:21] <SWPadnos> it seems like it may not work, since there's commented code for that mode
[23:09:27] <SWPadnos> (in the WRITE/READ functions)
[23:41:37] <skunkworks> * skunkworks is glad his isn't the only computer locking up..
[23:55:28] <jepler> skunkworks: I'm sad that it is :-P
[23:57:28] <skunkworks> heh