Back
[08:58:43] <lair82> Good Morning Guys, I want to remove the excess kernels on my machine. I am running Debian Wheezy, and it has an RTAI kernel, and the RT Preempt kernel. I want to get rid of the RTAI kernel, that way when the operator has to start the pc back up for whatever reason he only has the choice of the rt preempt kernel.
[08:58:46] <lair82> I was going to use synaptic, but when I selected the RTAI linux-image, it auto selected linuxcnc and linuxcnc-dev, and I would have to say that would be a bad idea.
[08:58:57] <lair82> Is there a better way, or is this just going to delete the linuxcnc and linuxcnc-dev directories that came stock on the CD, and not the ones I created when compiling?
[09:09:20] <seb_kuzminsky> lair82: i'll reply in email so others can see too, hold on
[09:11:42] <lair82> No problem seb, I emailed the user list this question.
[09:12:13] <pcw_home> Also when you build/install your own kernel it set up grub to boot from that kernel as the default
[09:12:20] <pcw_home> sets
[09:16:11] <lair82> My pc has the rtai kernel first on the grub screen when booting, so it keeps loading the rtai, when I don't catch it during re-booting or starting up.
[09:17:25] <pcw_home> Yeah if you install the official preemt-rt package it doesnt set the new kernel as default
[09:18:18] <lair82> Did you get a chance to work on that firmware with the missing pwmgen module?
[09:18:29] <pcw_home> freeby.mesanet.com/7i80hd_16_rmesvss6_6.bit
[09:19:09] <cradek> lair82: to avoid wasting people's time, please ask questions in only one place at a time, so there can be just one thread generated
[09:20:21] <cradek> sometimes people ask on both lists and the forum and the irc channels all at the same time, and lots of separate threads start, and it's horrible
[09:20:33] <cradek> of course you didn't do it that badly :-)
[09:20:51] <lair82> Ok, Thanks, when I go to load that is it still mesaflash --device 7i80 --addr 10.10.10.10 --write 7i80hd_16_rmesvss6_6.bit
[09:21:19] <pcw_home> I have about 25 kernels in the grub list but it doesn't matter because it boots from the latest
[09:21:20] <pcw_home> something the the kernel make install does
[09:21:29] <pcw_home> that the
[09:21:44] <cradek> you can set the grub default to whatever you want (including boot last-booted)
[09:24:23] <jepler> > I pulled it because it still ends up working for my normal test-cases, but it's wrong -- Linus Torvalds
[09:24:42] <jepler> huh, has linus been kidnapped and replaced by an impostor?
[09:25:52] <cradek> lair82: info -f grub -n 'Simple configuration'
[09:26:00] <lair82> cradek , I'm not trying to create confusion, but so far I have put almost 60hrs on the keyboard, and I'm not exagerating, on trying to setup my 7i80 and get the machine moving, only to realize that, the ethernet driver on my MB isn't supported in debian, I was trying to build under RTAI, not Preemt, and the firmware I was using didn't have the pwmgen module loaded, just the pins were there.
[09:26:02] <cradek> finally found the documentation for GRUB_DEFAULT here
[09:26:38] <lair82> Not really anyones fault but mine, but I am running on overload,
[09:26:58] <cradek> sorry to hear that. it's hard to be on the bleeding edge.
[09:27:39] <lair82> I'm kinda drawing straws, as fast as I can possibly pull them out, if you know what I mean :)
[09:42:52] <lair82> pcw_home ,when I go to load that is it still mesaflash --device 7i80 --addr 10.10.10.10 --write 7i80hd_16_rmesvss6_6.bit ?
[09:43:16] <pcw_home> sure, but with the new file
[09:44:42] <lair82_> Ok, didn't know if it would be something diferent when writing over current firmware.
[09:45:57] <pcw_home> no, it always just overwrites whats there
[09:46:39] <pcw_home> you do have to power cycle the 7I80 or do
[09:46:41] <pcw_home> mesaflash --device 7i80 --addr 10.10.10.10 --reload
[09:49:14] <pcw_home> (to load the new firmware into the FPGA)
[09:55:12] <mozmck> jepler: have you seen the kdbus thread?
[09:55:40] <jepler> mozmck: I have glanced at various parts of it
[09:56:40] <mozmck> I don't know enough about it myself.
[09:57:10] <mozmck> what do you think of the systemd stuff?
[10:01:24] <jepler> I am very concerned by the additional software that systemd keeps getting. For instance, they have added a caching DNS resolver with known security flaws that as far as I know remain unfixed (
http://seclists.org/oss-sec/2014/q4/592) and a time client which does not properly implement the NTP client side (it just warps the clock which breaks all sorts of stuff)
https://wiki.archlinux.org/index.php/S
[10:01:31] <jepler> ystemd-timesyncd
[10:01:53] <jepler> but on the other hand, I have several debian jessie systems with systemd as pid1 and it hasn't directly bitten me in the ass yet
[10:02:27] <jepler> and the anti-systemd people have been by far the less professional on mailing lists about the whole business
[10:04:36] <jepler> well, actually, I have been bitten by systemd
[10:05:13] <jepler> it was writing bogus /etc/resolv.conf that used google's DNS servers by default(?) which is not acceptable for me because I serve a special DNS zone to my intranet
[10:05:20] <jepler> but a big hammer fixed it
[10:05:30] <jepler> that's systemd-networkd, I think
[10:07:14] <cradek> wait they wrote a new ntp client that only steps the time?
[10:07:23] <jepler> cradek: yes
[10:07:58] <cradek> wow
[10:08:19] <jepler> I *think* uspace is resilient against that but I haven't tested it
[10:08:46] <jepler> uspace uses CLOCK_MONOTONIC which "is not affected by discontinuous jumps"
[10:09:46] <mozmck> I haven't followed the mailing lists on it, but it kinda seems like the systemd folks are intent on ruling the linux world.
[10:09:58] <jepler> .. but which does benefit from the fine-tuning of the clock rate "by the incremental adjustments performed by adjtime(3) and NTP [i.e., a proper ntpd that calls adjtime(3) / adjtimex(2)]"
[10:11:28] <cradek> it would be really hard to be polite and helpful if you'd been maintaining a proper ntpd or bind for decades and someone comes along and says "we've superseded that legacy crap!" but they don't have any clue what they're doing
[10:11:37] <mozmck> Seems like also they sorta have the attitude of the gnome folks that theirs is the only way forward no matter how buggy or disliked. I see more and more stuff around about security issues in systemd*
[10:12:08] <mozmck> maybe M$ is paying them... ;)
[10:12:40] <cradek> I actually don't question their motives at all
[10:14:10] <cradek> it's hard for a few people, no matter how earnest, to be experts in all these things
[10:14:41] <cradek> maybe their only mistake is hubris
[10:14:46] <mozmck> I'm teasing about that - probably shouldn't do it.
[10:18:51] <kwallace> Just in case it might be interesting:
http://www.tormach.com/blog/nasa-measures-the-universe-with-the-help-of-a-tormach-pcnc-1100/
[10:18:58] <jepler> I had enough hubris in my youth to know exactly what cradek is talking about
[10:25:52] <pcw_home> after about 3 days of testing it looks like 3.18.11-rt7 is a bit better than 3.18.9-rt4 latency wise
[11:00:24] <mozmck> pcw_home: is that with FULL_NO_HZ?
[11:09:05] <pcw_home> No ,1Khz though I think they fixed the FULL_NO_HZ bug in this version
[11:33:28] <CaptHindsight> it's been interesting looking at the parallels between Linuxcnc and software to control computers that control spark and fuel in engines
[11:34:44] <CaptHindsight> similar arguments by developers over using a micro vs a cpu or where to split the program bettwen a cpu and either a micro and a fpga
[11:36:03] <CaptHindsight> and the timing loops are also similar, down to a few uS for high revving engines
[21:50:00] <seb_kuzminsky> the future is aaaaalmost here:
https://www.youtube.com/watch?v=BhMSzC1crr0
[21:53:39] <cradek> wow that was sure closer than the first one
[22:09:03] <jepler> why not use a big bouncy castle?
[22:09:17] * jepler <-- still bitter nobody got him a bouncy castle for his birthday
[22:15:53] <cradek> we did our best
[22:16:16] <cradek> the bouncy castle engineer said you were too big
[22:55:59] <seb_kuzminsky> the hackspace bought a vfd for the shopbot, we needed 4 kW output with 1 phase input, those turn out to be rare
[22:56:08] <seb_kuzminsky> most 1 phase input vfds top out at 2.2 kW for some reason
[22:56:51] <seb_kuzminsky> the one we found is made by huanyang, and takes modbus over rs-485
[22:57:30] <seb_kuzminsky> i had anticipated writing the driver for it, but in my laziness i typed 'linuxcnc huanyang' into google first and found this:
https://github.com/bebro/linuxcnc-huanyang-vfd
[22:57:33] <seb_kuzminsky> so, awesome
[22:57:46] <seb_kuzminsky> i'm integrating it into 2.7 now