#linuxcnc-devel | Logs for 2019-04-25

Back
[00:16:13] -!- jthornton has quit [Read error: Connection reset by peer]
[00:16:33] -!- JT-Shop2 has quit [Read error: Connection reset by peer]
[00:16:38] -!- JT-Shop has quit [Read error: Connection reset by peer]
[00:16:55] -!- jthornton has joined #linuxcnc-devel
[00:17:00] -!- JT-Shop2 has joined #linuxcnc-devel
[00:18:50] -!- JT-Shop has joined #linuxcnc-devel
[01:06:58] -!- c-log has quit [Ping timeout: 276 seconds]
[01:09:41] -!- c-log has joined #linuxcnc-devel
[01:40:08] -!- c-log has quit [Ping timeout: 250 seconds]
[01:43:47] -!- c-log has joined #linuxcnc-devel
[01:51:05] -!- ve7it has quit [Remote host closed the connection]
[02:18:18] -!- c-log has quit [Ping timeout: 268 seconds]
[02:21:36] -!- c-log has joined #linuxcnc-devel
[07:03:13] -!- pcw_home has quit [Remote host closed the connection]
[07:12:50] -!- JT-Shop2 has quit [Read error: Connection reset by peer]
[07:12:50] -!- JT-Shop has quit [Read error: Connection reset by peer]
[07:12:50] -!- jthornton has quit [Read error: Connection reset by peer]
[07:21:36] -!- JT-Shop2 has joined #linuxcnc-devel
[07:23:01] -!- JT-Shop has joined #linuxcnc-devel
[07:25:05] -!- jthornton has joined #linuxcnc-devel
[07:40:31] -!- jthornton has quit [Read error: Connection reset by peer]
[07:40:37] -!- JT-Shop has quit [Read error: Connection reset by peer]
[07:40:37] -!- JT-Shop2 has quit [Read error: Connection reset by peer]
[07:42:31] -!- pcw_home has joined #linuxcnc-devel
[07:58:08] -!- JT-Shop has joined #linuxcnc-devel
[07:58:11] -!- JT-Shop2 has joined #linuxcnc-devel
[07:58:11] -!- jthornton has joined #linuxcnc-devel
[09:10:01] -!- Roguish has joined #linuxcnc-devel
[10:21:46] <mozmck> The problem I see with a 3.16.x rtai kernel is that it is (I believe) as old as the wheezy kernel. The people fussing about wheezy being EOL aren't going to be any happier with a newer distribution with an ancient kernel I suspect.
[10:24:54] -!- c-log has quit [Ping timeout: 250 seconds]
[10:26:14] -!- c-log has joined #linuxcnc-devel
[10:27:25] <JT-Shop2> let them eat cake then...
[10:31:22] <Roguish> mozmck: at some point there is an EOL for everything. For old installations, that people don't want to mess with, ok, turn off the updates and leave 'em alone. For new installation, use something 'current', not necessarily bleeding edge but is stable and has some lifetime to go. For the 'bleeding edge' folks, let 'em do what they want.
[10:32:22] <Roguish> Trying to make everyone happy without making anyone upset is just impossible. And a pretty big waste of valuable support time.
[10:32:54] <JT-Shop2> yea I'm happy that the CHNC is running Ubuntu 10.04 well I was until I found QtPyVCP now I gotta upgrade it to debian 9
[10:33:36] <JT-Shop2> I still don't see how a livecd is tied to a release, I know it's nice to have one
[10:38:28] <CaptHindsight> mozmck: there is no stable RTAI for > 3.16
[10:39:58] <Roguish> CaptHindsight: is there any reason that RTAI needs to be continued? real functional reason?
[10:41:00] <CaptHindsight> just for those that want to use a LPT for stepping and preempt_rt is bot fast enough or for application that just need faster
[10:41:11] <CaptHindsight> bot/not
[10:42:25] <CaptHindsight> we kept RTAI going for several years when the rtai.org dev just didn't have time anymore
[10:43:01] <Roguish> Ok. makes sense. Though personally I thing LPT should die. Sort of like DOS.......
[10:43:21] <CaptHindsight> but he seems to resent help and most RTAI users are the cheapest of the cheap
[10:43:42] <CaptHindsight> even the guberment military contractors
[10:44:09] <CaptHindsight> nothing wrong with LPT ports for stepping
[10:44:40] <CaptHindsight> I'd rather see the cloud die or M$ or a ton of other slime
[10:45:17] <Roguish> with you on 'the cloud'.
[10:46:02] <CaptHindsight> back doored factory firmware is high on my list
[10:46:41] <CaptHindsight> but you'll probably get your LPT wish vs any of my desires
[10:47:04] <CaptHindsight> LPT never hurt anybody
[10:50:34] <Roguish> maybe the Linuxcnc should be forked. one LPT/RTAI branch and one prempt/modern branch. don't really know. I just see an awfully lot of support time devoted to getting someone's IBM XT running
[10:51:54] <Roguish> maybe I'm just too cynical.
[10:53:21] <mozmck> Roguish: I personally don't care about EOL on the distribution. But this whole renewed effort to get stretch out with a newer rtai kernel is due to people complaining about wheezy going EOL
[10:54:38] <mozmck> Yeah, LPT is nice because you get cheap and fast IO.
[10:57:40] <CaptHindsight> how cheap are the FPGA's with hardware PCI?
[10:57:41] <Roguish> Ok, well EOL doen't mean it quits running. just turn off the updates..... Heck, I have a computer still running XP. no big deal...... wish it were NT..
[10:59:09] <JT-Shop2> try and reinstall XP
[10:59:49] <mozmck> I think people now are worried about security. But EOL also doesn't mean it automatically gets hacked - and for a machine control? Just take it off the 'net or put it behind a good firewall.
[11:00:56] <Roguish> security????? they're machine controllers. keep 'em off the internet for goodness sakes. that is the lamest excuse possible.
[11:01:17] <Roguish> seriously.
[11:01:21] <mozmck> CaptHindsight: from mesa it looks like the 5i25 is $89
[11:01:46] <mozmck> Roguish: that's my thought as well, but some people...
[11:02:28] <Roguish> no sympathies here. gotta tell people to get real.
[11:02:46] <mozmck> https://github.com
[11:02:48] <CaptHindsight> budget conscious users with new hardware that just want stepping
[11:03:14] <CaptHindsight> they are the ones that need a newer kernel
[11:03:52] <mozmck> I think you can still get a workable LPT card for $10 - $15?
[11:04:45] <CaptHindsight> I was one of the few that used RTAI with Mesa cards and still needed fast threads for machine vision
[11:06:05] <CaptHindsight> why we kept RTAI alive
[11:06:06] <Roguish> that's like worrying about latency when the machine is made of plywood and 80/20 ......
[11:06:59] <CaptHindsight> but it was disheartening to see that the plywood and 8020 users were the ones besides us using it
[11:07:37] <Roguish> the budget conscious sure don't mind spending lots of support hours, especially when it freeeeee.
[11:08:07] <CaptHindsight> but there a few threads about forking LCNC to use cheap ARM's to do the RT
[11:08:43] <CaptHindsight> yes, they don't value their time, and especially not yours
[11:10:04] <CaptHindsight> paid support was near non-existent, big OEM's would take months to budget a few $K
[11:10:05] <Roguish> is there still a 'board of directors' for linuxcnc?
[11:10:29] <CaptHindsight> and still want free help
[11:11:26] <CaptHindsight> or we contracted for a RTAI package for this hardware and 32b, can you send us a package for another completely different distro and with 64b support?
[11:12:35] <CaptHindsight> "Linux engineers" that couldn't seem to build anything on their own
[11:38:36] <CaptHindsight> imx8 PCIe can acts as an endpoint but it's not a cheap ARM soc
[11:39:58] <CaptHindsight> price is higher than a spartan6
[13:00:24] -!- jthornton has quit [Read error: Connection reset by peer]
[13:00:25] -!- JT-Shop2 has quit [Read error: Connection reset by peer]
[13:00:25] -!- JT-Shop has quit [Read error: Connection reset by peer]
[13:00:51] -!- jthornton has joined #linuxcnc-devel
[13:01:04] -!- JT-Shop2 has joined #linuxcnc-devel
[13:01:32] -!- JT-Shop has joined #linuxcnc-devel
[13:14:11] -!- ve7it has joined #linuxcnc-devel
[14:14:59] -!- micges has joined #linuxcnc-devel
[14:19:20] -!- andypugh has joined #linuxcnc-devel
[14:24:56] -!- micges has quit [Remote host closed the connection]
[14:25:24] -!- micges has joined #linuxcnc-devel
[15:12:52] -!- micges has quit [Quit: Wychodzi]
[15:49:24] <andypugh> CaptHindsight: I have done a few more tests on this PC / RTAI
[15:49:50] <andypugh> Booting from the Wheezy Live CD gives apparent stability and good latency
[15:53:35] <andypugh> insmod of rtai_ha.ko and rtai_sched.ko manually causes no problems and nothing odd in dmesg
[15:56:06] <andypugh> andypugh@RM-one:~$ cat /proc/cpuinfo
[15:56:07] <andypugh> processor : 0
[15:56:08] <andypugh> vendor_id : GenuineIntel
[15:56:09] <andypugh> model name : Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz
[15:56:10] <andypugh> cpu cores : 2
[15:57:32] <andypugh> [ 292.891916] RTAI[hal]: compiled with gcc version 6.3.0 20170516 (Debian 6.3.0-18) .
[15:57:32] <andypugh> [ 293.155396] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
[15:57:34] <andypugh> [ 293.155402] SYSINFO: CPUs 4, LINUX APIC IRQ 33025, TIM_FREQ 87297998, CLK_FREQ 2793536000, CPU_FREQ 2793536000
[15:57:35] <andypugh> [ 293.155406] RTAI_APIC_TIMER_IPI: RTAI DEFINED 33026, VECTOR 33027; LINUX_APIC_TIMER_IPI: RTAI DEFINED 33025, VECTOR 33025
[15:57:37] <andypugh> [ 293.155410] TIMER NAME: lapic; VARIOUSLY FOUND APIC FREQs: 87297998, 87297998, 0
[15:57:38] <andypugh> [ 300.533206] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[15:57:40] <andypugh> [ 300.580500] , kstacks pool size = 524288 bytes.
[15:57:41] <andypugh> [ 300.580506] RTAI[sched]: hard timer type/freq = APIC/87297998(Hz); default timing: oneshot; linear timed lists.
[15:57:42] <andypugh> [ 300.580522] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 2793536000 hz.
[15:57:43] <andypugh> [ 300.580525] RTAI[sched]: timer setup = 19 ns, resched latency = 3924 ns.
[16:00:55] <andypugh> I see some compiler warnings compiling RTAI
[16:00:59] <andypugh> calibration_helper.c: In function ‘main’:
[16:00:59] <andypugh> calibration_helper.c:134:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[16:01:00] <andypugh> rt_thread_create((void *)user_calibrator, (void *)loops, 0);
[16:01:10] <andypugh> home/andypugh/RTAI/base/math/e_asin.c: In function ‘__ieee754_asin’:
[16:01:12] <andypugh> } else
[16:02:00] <andypugh> home/andypugh/RTAI/base/math/e_asin.c: In function ‘__ieee754_asin’:
[16:02:01] <andypugh> home/andypugh/RTAI/base/math/e_asin.c:83:8: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
[16:02:01] <andypugh> } else
[16:02:17] <andypugh> and
[16:02:39] <andypugh> home/andypugh/RTAI/base/math/k_rem_pio2.c: In function ‘__kernel_rem_pio2’:
[16:02:40] <andypugh> home/andypugh/RTAI/base/math/k_rem_pio2.c:170:6: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
[16:02:41] <andypugh> for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw;
[16:20:52] -!- CaptHindsight has quit [Ping timeout: 245 seconds]
[16:21:53] -!- JT-Shop has quit [Read error: Connection reset by peer]
[16:21:53] -!- JT-Shop2 has quit [Read error: Connection reset by peer]
[16:24:46] -!- jthornton has quit [Ping timeout: 276 seconds]
[16:29:04] -!- CaptHindsight has joined #linuxcnc-devel
[16:29:04] -!- CaptHindsight has quit [Changing host]
[16:29:04] -!- CaptHindsight has joined #linuxcnc-devel
[16:35:26] <CaptHindsight> andypugh: back
[16:36:42] <CaptHindsight> andypugh: since the live cd works I'll or memleak will send you a new kernel config
[16:37:18] -!- JT-Shop has joined #linuxcnc-devel
[16:37:39] -!- JT-Shop2 has joined #linuxcnc-devel
[16:37:46] -!- jthornton has joined #linuxcnc-devel
[16:37:54] <andypugh> Worth noting that LiveCD is i696 not x86_64
[16:46:36] <jthornton> hmmm wonder why?
[17:07:33] <mozmck> I know back in '10 we did only i686 because it worked on all hardware and there was a lot of 32-bit only hardware still.
[17:08:03] <mozmck> We also had some problems with 64 bit - at least on multi-core AMD systems.
[17:10:41] -!- memfrob has joined #linuxcnc-devel
[17:11:07] <memfrob> Hi andypugh, just to test and debug, can I make a specialized kernel config for you to try?
[17:12:22] <memfrob> If you send me your dmesg, lsmod, and lspci -k output, I can make a kernel tuned specific to your hardware -- This will cut down the compile time by a large margin too so recompiles won't take long at all.
[17:13:14] <andypugh> Yes, though at the moment (for fun) I am compiling a vanilla 4.9.80 kernel
[17:13:19] <andypugh> But I can interrupt that
[17:13:27] <memfrob> No that's fine, go ahead.
[17:14:10] <memfrob> With the current 3.16.52 RTAI kernel you have running right now, I know it seems a bit silly but do you have a second machine with a way to read off the serial port of the trouble system?
[17:14:57] <memfrob> If not (or too much work) you can try my suggestion yesterday of simply loading rtai_hal.lo and rtai_sched.ko and run dmesg in time to see if you get any errors.
[17:15:18] <andypugh> I tried that, no erroirs
[17:15:31] <andypugh> Give me a momemt
[17:15:42] <memfrob> This is the first time I've seen someone have trouble with my RTAI tree, but no trouble on the live CD.
[17:16:18] <andypugh> Ah, can’t do what I thought, as the machine is currently booted from the preempr-rt kernel
[17:16:53] <memfrob> You can send the output of those commands through any kernel as long as it supports all your hardware.
[17:17:01] <andypugh> OK
[17:18:35] <andypugh> https://pastebin.com
[17:19:20] <andypugh> It’s a Core i3 cpu, if that matters
[17:20:42] <andypugh> Interestingly latency is 17k servo 18k base with LiveCD Wheezy RTAI and 10k / 6k with Stretch preempt RT.
[17:21:21] <memfrob> Did you apply all 7 patches against 3.16.52 ?
[17:21:31] <andypugh> Yes
[17:21:40] <andypugh> (And all took cleanly)
[17:22:26] <memfrob> OK I'll go through it all.
[17:22:31] <andypugh> The kernel appears OK in normal use now, but things go pretty wrong when I tun RTAI
[17:25:24] <memfrob> Hmm, the kernel is perfectly stable until the RTAI modules load?
[17:26:37] <andypugh> Hard to say. I haven’t tried to do much other than run RTAI
[17:26:57] <memfrob> Oh, CPU group scheduler is on and a few other things.
[17:27:07] <andypugh> And it seems stable with rtai_hal and rtai_sched loaded (but probably not doing anything)
[17:27:27] <memfrob> They load???
[17:27:42] <andypugh> Seem to
[17:28:08] <memfrob> With no problems? Can you post dmesg output after you loaded rtai_hal and rtai_sched under the 3.16.52 RTAI kernel?
[17:28:33] <andypugh> OK. Let me stop this compile and boot into the 3.16 kernel
[17:30:41] <memfrob> Watchdog is on too.. I missed a few things.
[17:30:53] <memfrob> I think this new config will fix it all.
[17:31:42] <memfrob> Is it possible for you to turn off EDAC?
[17:31:58] <memfrob> (in BIOS)
[17:33:03] <andypugh> https://pastebin.com
[17:33:47] <memfrob> WARNING: CPU: 0 PID: 0 at kernel/sched/idle.c:175 cpu_startup_entry+0x52f/0x540()
[17:34:13] <memfrob> Tickless idle was on too.
[17:34:34] <memfrob> So yeah, I missed a few things. The debian config needs several options throughout disabled or toggled to different options.
[17:34:53] <andypugh> I looked in the BIOS (it’s a facny one with a graphical interface and search) and “edac” “eda” and “dac” all come up blank
[17:35:28] <memfrob> ok.
[17:36:08] <andypugh> Is it a problem that /proc/cpuinfo says 2 CPUs and RTAI is configured for 4 ?
[17:37:24] <andypugh> Anything else to look at in the BIOS while I am here? Virtialisation / Power states / AHCI ?
[17:37:40] <memfrob> Virtualization and power states should all be off. AHCI is fine.
[17:37:46] <memfrob> ACPI is another story :P
[17:40:16] <andypugh> I can try turning that off or on (or off and then on again :-)
[17:43:14] <andypugh> ACPI is already off, as far as I can see
[18:00:15] <memfrob> Ok, this is the new generic config: https://pastebin.com
[18:00:46] <memfrob> Needs initrd -- not tuned for your hardware but this one should work on all systems.
[18:02:51] <andypugh> When you say “needs initrd” what do you mean? Would I notice if the previous attempt lacked it?
[18:04:03] <memfrob> When a Linux kernel (the bzImage itself) does not have your specific ATA/PATA/SATA/IDE controller built-in (Y) but rather as a module (M) you'll get a kernel panic saying that it can't find your root device.
[18:04:36] <andypugh> OK. I would have noticed that :-)
[18:04:37] <memfrob> Considering you already have a 3.16.52 kernel booted with RTAI enabled with those drivers as modules, you made an initial ramdisk to go with it.
[18:05:08] <memfrob> I just want to make it clear when I send configs because I've had customers in the past say my kernel didn't boot because of a step they missed on their end.
[18:05:14] <andypugh> Did you add -RTAI in the config? I see it aftger loading your config and I am wondering if I am using your config or have loaded the old one
[18:05:30] <memfrob> I added it.
[18:05:33] <andypugh> OK
[18:06:17] <memfrob> You won't need the nomodeset line btw, I disabled nouveau to fix that, and it also allowed me to disable WMI.
[18:06:30] <memfrob> WMI has a mind of it's own and can cause problems similar to the one you're having.
[18:06:52] <memfrob> Radeon and Intel DRM drivers only.
[18:07:20] <memfrob> (and displaylink if anyone is using those USB monitors)
[18:08:16] <memfrob> If it still doesn't work, I'll go through making a system-tuned kernel config from scratch, just for you.
[18:08:33] <andypugh> just checking, when I exit menuconfig is your config saved to .config, or does “make” rememeber that it is using your config
[18:09:00] <andypugh> memfrob: The aim here is to have a generic kernel for an alternaive ISO
[18:09:15] <memfrob> It is best to save it manually to .config on top of whatever it wants to do on it's own.
[18:09:21] <andypugh> If we need a custom-tuned one, that’s not owrth bothering with
[18:10:02] <memfrob> Yes, I understand that. But if your system, personally, doesn't work with my RTAI tree, I need to know, because my knowledge, my RTAI tree is rock solid stable.
[18:10:14] <memfrob> *to my
[18:10:42] <andypugh> OK, so the custom config would be to prove that my PC system is to blame?
[18:11:16] <andypugh> Compiling now, I will give the the news in an hour or more
[18:11:18] <memfrob> Yes, but I sent you the generic one.
[18:11:56] <memfrob> Since you needed the nomodeset line for your system, I disabled nouveau in case others have nvidia cards too that have problems with 3.16.52
[18:12:16] <andypugh> Is this a concern? Just scrolled past
[18:12:18] <andypugh> kernel/sched/core.c: In function ‘context_switch’:
[18:12:18] <andypugh> kernel/sched/core.c:2414:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
[18:12:19] <andypugh> if (unlikely(__ipipe_switch_tail()))
[18:12:40] <memfrob> Support more hardware by disabling hardware in config, sounds counter-intuative..
[18:12:59] <memfrob> No, that's just GCC throwing a warning about indentation.
[18:13:41] <memfrob> Will be back in 15 min, let me know how it goes!
[18:13:56] <andypugh> It will take more than 15 mins!
[19:32:36] <andypugh> The kernel has compiled.
[19:32:49] <andypugh> I recompiled RTAI, but still seem to get:
[19:32:50] <andypugh> insmod: ERROR: could not insert module /usr/realtime/modules/rtai_hal.ko: Invalid module format
[19:40:38] <andypugh> OK, I seem to have fixed that (repeated make install and make modules_install)
[19:43:56] <andypugh> (incidentally, I still need “nomodeset”)
[19:55:27] <andypugh> Mayve there is a clue here?
[19:55:46] <andypugh> I logged in to the machine with ssh and set up a tail -f on the kernel log.
[19:55:48] <memfrob> you need to rebuild RTAI against your new kernel
[19:55:57] <memfrob> sorry I was afk.
[19:56:06] <andypugh> Then I started the testsuite on the actual PC
[19:56:09] <andypugh> https://pastebin.com
[19:57:04] <memfrob> RTAI modules (rtai_hal.ko etc) must always be in line with your RTAI kernel. You can't rebuild the kernel and not RTAI otherwise you'll get all kinds of errors.
[19:57:32] <andypugh> I have done that
[19:57:41] <memfrob> Ok, did the testsuite work?
[19:57:55] <andypugh> (RTAI) make clean, make menuconfig make make install
[19:58:09] <memfrob> Sounds right.
[19:59:09] <andypugh> The testsuite seems to freeze, then when I Ctrl-C that terminal it says something about CANNOT FIND MAILBOX
[19:59:25] <andypugh> Then some info about the calibration testduite
[19:59:59] <andypugh> and nothing after # timer mode is oneshot
[20:01:20] <memfrob> CANNOT FIND MAILBOX .. are you loading rtai_hal.ko and rtai_sched.ko by hand before trying to run the testsuite?
[20:01:55] <memfrob> The testsuite should handle all of the module loading by itself.
[20:05:12] <andypugh> I just tried booting with nolapic, but the result is the same
[20:05:32] <memfrob> Because you need nomodeset I'm not sure you built the kernel right as this is an nvidia card.
[20:05:52] <andypugh> No, just sudo bash /usr/realtime/testsuite/run
[20:06:45] <andypugh> Well, the kernel has certainly built differently, as it now uncomresses the kernel whereas it mentioned ramdisk before
[20:07:28] <memfrob> I thought the system you sent me the info about has nvidia graphics, but I don't see any nvidia card in lspci.
[20:07:42] <andypugh> But it is more than likely that I have messed up somewhere
[20:08:36] <andypugh> Anyway, thanks for your efforts
[20:08:56] <andypugh> But I think it is time for me to accept defeat for tonight
[20:09:27] <memfrob> Ok, and because the decompress message came up, it is in fact the new kernel.
[20:10:21] <memfrob> CANNOT FIND MAILBOX means the testsuite isn't loading the modules properly which means there's probably a mismatch somewhere.
[20:11:18] <andypugh> Apr 26 01:04:30 RM-one kernel: RTAI[sched]: timer setup = 69 ns, resched latency = 3873 ns.
[20:11:18] <andypugh> Apr 26 01:04:30 RM-one kernel: LXRT releases PID 1047 (ID: display).
[20:11:19] <andypugh> packet_write_wait: Connection to fe80::42a5:efff:fe05:a291%en1 port 22: Broken pipe
[20:11:26] <andypugh> LXRT?
[20:11:39] <memfrob> That message is fine.
[20:11:55] <memfrob> What does bash --version say?
[20:12:25] <andypugh> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
[20:13:00] <memfrob> Ok, just double checking.
[20:13:38] <memfrob> I re-wrote all the ancient 200+ line RTAI scripts with features from either Bash 4.4 or 4.3
[20:14:21] <andypugh> After trying to run the testsuite the machine still accepts mouse movement and clicks, but very sluggishly. I can bring up the boot menu, but restart just freezes and I have to use the power button.
[20:14:22] <memfrob> Oh nevermind, the only line that does any of that is the setsmi script.
[20:15:26] <memfrob> Well tomorrow I'll send you a suggestion to try and maybe we can see why it's failing then.
[20:15:32] <andypugh> Maybe I should run the dmesgg tail on the same PC, maybe networking goes down first?
[20:20:58] <andypugh> I actually see slightly less on the actual machine, (Don’t see the LXRT message)
[20:22:39] <memfrob> Because it can't find the mailbox, something else is wrong
[20:23:18] <andypugh> I didn’t see that message this time…
[20:23:38] <memfrob> Because it's inconsistent that's also a problem.
[20:25:36] <memfrob> I have no idea what
[20:26:04] <memfrob> 's going on, honestly. The only way to find out would be to load the testsuite by hand, without the scripts, and see exactly what's happeing.
[20:26:43] <andypugh> I can try that, but tomorrow
[20:27:23] <memfrob> Sounds good, because it's almost acting like the real-time code itself is what is killing it, and the testsuite itself isn't broken.
[20:27:56] <memfrob> Generally with crashes, it crashes when you load rtai_sched -- I've never seen a case of this before.
[20:28:18] <andypugh> Well, at least it isn’t a boring problem :-)
[20:28:48] <memfrob> Yeah it's actually quite interesting. Well, good night andypugh!
[20:28:55] <andypugh> Goodnight
[20:29:00] -!- andypugh has quit [Quit: andypugh]
[20:38:35] -!- memfrob has quit [Quit: Leaving]
[20:55:27] -!- c-log has quit [Ping timeout: 245 seconds]
[20:57:47] -!- c-log has joined #linuxcnc-devel