Back
[01:07:31] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #162: I'm not able to reproduce this problem. I'm testing with 88e22fa (which is just after 2.7.7) on Debian Stretch.... 02
https://github.com/LinuxCNC/linuxcnc/issues/162#issuecomment-246911664
[07:22:46] <skunkworks> zlog
[07:27:02] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #162: I am seeing something similar to @zultron . Debian Jessie, 2.7 branch at... 02
https://github.com/LinuxCNC/linuxcnc/issues/162#issuecomment-246990507
[07:28:09] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #162: ~~~~... 02
https://github.com/LinuxCNC/linuxcnc/issues/162#issuecomment-246990755
[07:30:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #162: valgrind:... 02
https://github.com/LinuxCNC/linuxcnc/issues/162#issuecomment-246991175
[07:33:30] <KGB-linuxcnc> 03Jeff Epler 052.7 0316a08 06linuxcnc 10tests/interp/compile/use-rs274.cc testsuite: specify var filename * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0316a08
[07:33:55] <jepler> seb_kuzminsky: +++++
[07:40:02] <skunkworks> That is why you get paid the big bucks
[07:43:11] <jepler> I wrote that crap test in the first place
[07:43:16] <jepler> then I must have ignored the problem for awhile
[07:43:26] <jepler> yeah it explains my pay rate
[07:50:19] <skunkworks> heh
[08:31:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #162: I haven't tested, but sweet! Looks like @jepler nailed it. Thanks fellas. 02
https://github.com/LinuxCNC/linuxcnc/issues/162#issuecomment-247005904
[09:27:28] <JT-Shop> pcw_home: do you have a 7i92_7i77_7i76.bit? I see 7i92_7i77_7i76D.pin but P1 is empty when I do a readhmid
[09:29:25] <pcw_home> Hmm probably a file copy mistake. Let me see if i have a correct VHDL pinout file here...
[09:30:46] <JT-Shop> ok thanks
[09:30:57] <JT-Shop> what does the D mean?
[09:33:31] <pcw_home> means it has the DPLL
[09:35:19] <pcw_home> the DPLL allows accurate Stepgen and servo encoder position sampling even with large latencies (say 500 usec or so)
[09:35:29] <JT-Shop> thanks
[09:36:13] <pcw_home> mainly needed for Uspace/Ethernet that tends to have larger latencies
[09:40:14] <seb_kuzminsky> jepler: so wait, why does it do the right thing on my machine but not on yours or zultron's?
[09:46:01] <pcw_home> JT-Shop:
http://freeby.mesanet.com/7i92_7i77_7i76D.bit
[09:46:05] <jepler> seb_kuzminsky: I don't know. dumb luck? the first byte of that stacked array for the filename happened to be \0?
[09:46:28] <seb_kuzminsky> mmmaybe
[09:46:57] <jepler> seb_kuzminsky: it would be slightly interesting to see what you get when you strace -e open it
[09:47:01] <seb_kuzminsky> it always gets the right name, as shown by strace -e open and by ls, i don't feel *that* lucky
[09:47:02] <jepler> it's near the end
[09:47:12] <jepler> huh so you get the expected name? that is lucky.
[09:47:54] <jepler> seems like I must have also experienced getting the right name, since I wrote that ignore in gitignore (right?)
[09:47:56] <pcw_home> JT-Shop: That bit file is untested, so I would be cautious ( Maybe try it in the 7I92 fallback area first )
[09:54:26] <JT-Shop> how do you test it in the fallback area?
[09:54:30] <pcw_home> mesaflash --device 7i92 --write 7i92_7i77_7i76D.bit --fallback
[09:54:31] <pcw_home> mesaflash --device 7i92 --reload --fallback
[09:54:33] <pcw_home> mesaflash --device 7i92 --readhmid
[09:54:38] <JT-Shop> thanks
[09:55:12] <pcw_home> note that that will revert to the user config when you cycle the power
[09:55:53] <skunkworks> jepler, lvm vgchange -a y registered the logical volumes - and was able to boot. How just have to figure out why that isn't working :)
[09:55:55] <JT-Shop> thanks
[09:55:57] <skunkworks> Thank you!
[09:56:58] <seb_kuzminsky> jepler: i see junk passed into GET_EXTERNAL_PARAMETER_FILE_NAME
[10:12:43] <skunkworks> Yay - stuart and kim for a visit
[10:12:54] <cradek> hi stuart and kim and sam!
[10:13:15] <cradek> hope to see you in all in a month or so
[10:13:35] <skunkworks> I am not making it this year - too much stuff going on
[10:13:44] <skunkworks> I will be there is spirit..
[10:17:45] <JT-Shop> pcw_home: the terminal session and the pin file
http://paste.ubuntu.com/23178205/
[10:17:51] <jepler> I already tried to guilt-trip skunkworks too
[10:18:05] <JT-Shop> I have to run to town for a bit
[10:18:51] <pcw_home> you forgot the -- on reload
[10:19:47] <seb_kuzminsky> sometimes interp passes in "file_name" to GET_EXTERNAL_PARAMETER_FILE_NAME, which is both the name of a local char* variable and the name of a function in Interp:: scope
[10:20:22] <jepler> seb_kuzminsky: that's .. can we call it "refreshing" ?
[10:20:45] <jepler> if it was picking up the member function the type system would have complained
[10:21:02] <seb_kuzminsky> i agree
[10:23:55] <seb_kuzminsky> the test calls GET_EXTERNAL_PARAMETER_FILE_NAME in two sets of two, first for restore_parameter() and second for save_parameters()
[10:24:33] <seb_kuzminsky> my restore_parameters() calls get binary garbage, but the save_parameters() calls get null, so they use the default name
[10:24:45] <seb_kuzminsky> that's why i'm not seeing the problem you and zultron saw
[10:25:10] <seb_kuzminsky> both times it's a stack variable, so maybe i'm just getting lucky?
[10:25:15] <seb_kuzminsky> maybe it's a stretch thing?
[10:26:26] <seb_kuzminsky> ah, it's just one set of two: one restore and one save
[10:26:29] <seb_kuzminsky> that makes more sense
[10:27:23] <seb_kuzminsky> ok, i guess i can accept "sometimes garbage on the stack works for you and sometimes it doesn't", and move on with my life
[11:29:11] <JT-Shop> silly mistokes can make you pull your hair out lol
[11:29:21] <JT-Shop> pcw_home: looks better thanks
http://paste.ubuntu.com/23178446/
[12:47:35] <skunkworks> what are peoples thoughts on lvm
[12:48:58] <archivist> blissfully unaware :)
[13:09:53] <cradek> better than not having lvm, but a very poor substitute for zfs
[13:10:52] <cradek> the mirroring works, and it's a fine way to do full disk encryption
[13:11:09] <cradek> I think those are the only useful features
[13:11:24] <cradek> it doesn't have any reasonable snapshot/rollback
[13:13:37] <cradek> oh you can also grow partitions while they're online. that's pretty nice.
[13:16:14] <skunkworks> cradek, thanks!
[13:16:32] <cradek> I'm surprised that helped you :-)
[13:16:44] <jepler> for a new system I'd sure look at debian stretch with zfsonlinux fwiw
[13:16:55] <skunkworks> it is almost like which text editor to use.. Almost
[13:17:48] <jepler> but zfs has its own problems: lower performance than ext4-on-lvm, for instance. too little confidence in being able to take a volume from, say, freebsd 10 and mount on debian, if you've enabled "feature flags"
[13:18:08] <jepler> since each arm of zfs development is different, and you have to check carefully that all the feature flags are supported everywhere you might want to mount it
[13:18:47] <cradek> sure, but there are better chances than trying to mount your ext4-on-lvm on your freebsd10
[13:19:14] <cradek> you're not wrong, but still that's a different stick you're measuring with
[13:19:35] <jepler> yes
[13:19:57] <cradek> but I totally agree it does seem awfully slow in some situations
[13:19:58] <jepler> though it was a nail-biting concern when I was trying to use a debian gnu/linux system to recover a disk from a debian gnu/kfreebsd system
[13:20:48] <jepler> cradek: I don't know about ext4 support, but
https://www.freebsd.org/cgi/man.cgi?query=geom_linux_lvm&sektion=4&apropos=0&manpath=FreeBSD+8.2-RELEASE+and+Ports
[13:21:33] <cradek> oh hey look at that maybe I'm wrong
[13:21:38] <jepler> ext4 is so relatively slow moving (compared to zfs in the age of feature flags) that I assumed a read-only mount of ext4 would go just fine
[13:23:35] <cradek> I think RO ext4 is just ext3, which is decades? old
[13:24:53] <jepler> The ext2fs(5) driver allows the FreeBSD kernel to both read and write to ext2 file systems.
[13:24:56] <jepler> Note:
[13:24:59] <jepler> This driver can also be used to access ext3 and ext4 file systems. However, ext3 journaling and extended attributes are not supported. Support for ext4 is read-only.
[13:25:02] <jepler> https://www.freebsd.org/doc/handbook/filesystems-linux.html
[13:25:12] <jepler> so yeah looks like you should get read-only ext4-on-lvm from your freebsd rescue media
[13:25:27] <cradek> that's good to know
[13:26:02] <jepler> http://open-zfs.org/wiki/Feature_Flags
[13:26:08] <jepler> but I shouldn't worry about feature flags so much
[13:26:26] <jepler> except multi_vdev_crash_dump, freebsd 10.2 and zol 1.6.5 all support all of them
[13:27:21] <jepler> 0.6.5
[13:29:30] <jepler> https://github.com/zfsonlinux/zfs/issues/2438
[13:30:13] <jepler> apparently if you have multi_vdev_crash_dump enabled, you can at least now hack it out with current versions of zol and the "zhack" tool
[13:30:58] <jepler> (current == git, I think it's in no released version)
[13:32:14] <cradek> feature flags seems like such a blunt tool. they match? great, you can import. nope? well good day sir.
[13:32:32] <jepler> cradek: feature flags can be "read-only compatible" (but multi_vdev_crash_dump is not)
[13:32:48] <cradek> ah
[13:33:15] <cradek> I'm sorry to learn that you know more about this than I do. It probably means you have had more suffering in your life.
[13:33:22] <jepler> hah!
[13:33:38] <jepler> I still have all my limbs and the scar is normally concealed by clothing
[13:48:01] <skunkworks> adding lvm vgchange -ay to the lvm conf file fixed the booting issue. Although the comment from the internets was it wasn't elegant..
[13:48:28] <skunkworks> sounds like it was/is an issue moving to systemd
[13:52:02] <skunkworks> KimK, are you active?
[17:59:05] <jepler> now here's a curious one: "./mesaflash" fails, "strace ./mesaflash" succeeds :(
[18:00:15] <jepler> inserting a sleep after each spi ioctl "fixes" it, agagawrgargasrgasgr
[18:00:31] <jepler> this is a pi3; no wonder people just WTF and write a bit-banging driver instead
[18:01:54] <jepler> it also doesn't support 32-bit transfers, even though that's fucking stupid -- you can build 32-bit transfers right out of 8-bit transfers, even if the hardware doesn't have a special way to talk about transfers of other widths
[18:04:08] <pcw_mesa> Does the SPI mesaflash actually work? Ive forgotten (probably more than once)
[18:06:52] <jepler> pcw_mesa: yes I've now used it on a total of 3 different arm-based systems (odroid u3, odroid xu4, and now pi3) and it works modulo kernel spidev bugs
[18:07:08] <jepler> but 2 of those three platforms had terrible kernel spidev bugs :-/
[18:07:11] <jepler> afk to make some dinner
[18:07:39] <jepler> but anyway tinkerer if you're reading this I see why you did what you did
[20:35:55] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky closed issue #162: `/tests/interp/compile` test creates junk file 02
https://github.com/LinuxCNC/linuxcnc/issues/162
[21:20:21] <jepler> https://lwn.net/SubscriberLink/700530/f607394bb4faf873/ "Backports and long-term stable kernels"
[21:20:47] <jepler> > [Greg K-H] closed by saying there might not be a long-term support kernel next year, since it wouldn't be needed. Or, at least, "one has to dream."
[23:06:32] <cradek> each of the poisons you might pick are so poisonous