Back
[05:46:21] <KGB-linuxcnc> 03John Thornton 052.7 cf68d66 06linuxcnc 10docs/src/Master_Documentation_es.txt Docs: fixed broken include * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cf68d66
[10:25:35] <KGB-linuxcnc> 03John Thornton 052.7 adaac2e 06linuxcnc 10(45 files in 5 dirs) Docs: make file names follow the same convention. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=adaac2e
[11:28:26] <mozmck> I want to close the (non) bug #426 I posted, should I give it the status closed-invalid?
[11:30:39] <cradek> that sounds fine to me
[11:32:36] <cradek> yay
[11:32:40] <cradek> any closed is a good closed
[11:32:45] <mozmck> :)
[11:33:04] <mozmck> I do think it might be better if Q defaulted to either 0 or .001
[11:34:05] <cradek> rob didn't want to remove the ncd because the new tp still benefits from it
[11:34:06] <mozmck> It was not real clear reading the documentation what it would do. It looked at first like not specifying Q would disable NCD
[11:34:56] <cradek> I wonder if it's a doc bug or a have-sensible-defaults bug
[11:35:00] <mozmck> I will probably leave it at .001 for our stuff.
[11:35:19] <cradek> I bet that almost always just disables it
[11:35:24] <mozmck> I don't know! If you are setting P pretty low, then it probably doesn't matter.
[11:35:37] <cradek> doubt there's much gcode with moves < .001 inch length
[11:36:33] <mozmck> I'm sure it will for our stuff, because we mostly use Sheetcam and it will do "NCD" to a tolerance when it loads a drawing.
[11:36:35] <jepler> NCD is not about length. NCD can turn 2 100-inch moves into 1 ~200-inch move.
[11:36:50] <cradek> oops, right
[11:39:10] <pcw_home> so doesn't take much q at all to eliminate in 1 ms segments
[11:39:25] <pcw_home> eliminate splits
[11:41:26] <pcw_home> Wonder if .001 Q would be a workaround for bug 424
[11:42:20] <cradek> I don't know what the bug is, so I can't guess
[11:43:13] <pcw_home> the accel violation on the new TP
[11:43:18] <pcw_home> in
[11:43:25] <cradek> I mean I don't know the cause of it
[11:43:43] <pcw_home> I thought it was related to splits
[11:45:01] <cradek> that was only my straw-grasping - rob's fix (which may not be complete?) looked like something pretty different
[11:45:18] <pcw_home> ahh
[11:45:20] <cradek> skunkworks said something about the fix (sometimes?) not fixing it
[11:47:39] <pcw_home> wonder whats special about the test file? its not terribly easy to trigger
[11:48:35] <cradek> it's 3 arcs in a row with the same center point, the middle one is tiny
[11:48:59] <cradek> I bet it's pretty unusual
[12:33:01] <skunksleep> At one point Rob removed the interaction between p and q (you had to specify q) but that wasn't backwards compatible so was put back
[12:34:12] <skunksleep> Could someone else try robs fix? It seems too little. I have not heard back yet.
[12:44:21] <skunksleep> Dad had an interesting issue. The g1 feedrate seemed capped at around 2ipm. Restarting linuxcnc didn't fix it - reboot did
[12:59:29] <skunksleep> I know of one other person that has had a similar issue.
[13:07:22] <jthornton> does anyone know if /docs/docs.xml is used anymore? I think it's left over from lyx days...
[13:15:23] <seb_kuzminsky> jthornton: it's referenced by docs/src/Submakefile as a dependency for building the translated xrefs (spanish & french)
[13:15:30] <seb_kuzminsky> i dont know if that means it's still in use...
[13:17:40] <jthornton> I see it in the default: docs of submakefile
[13:19:02] <jthornton> it's not in the html files after building so I'm guessing it is not used anymore
[13:36:16] <seb_kuzminsky> jthornton: i think you're right, the docs Submakefile does not even pass docs.xml to xsltproc
[13:48:57] <jthornton> so this line and the one for the spanish docs are not used at all?
[13:49:01] <jthornton> $(DOC_DIR)/html/xref_fr.html: objects/xref_fr.xml $(DOC_SRCDIR)/xref.xsl $(DOC_SRCDIR)/docs.xml
[14:10:20] <seb_kuzminsky> i think it is used, but the next line uses $< as the argument to xsltproc, which expands to just the first dependency, objects/xref_fr.xml
[14:17:55] <jepler> new toy is here
[14:17:55] <jepler> 127|shell@msm8916_64:/ $ cat /proc/cpuinfo
[14:17:58] <jepler> Processor : AArch64 Processor rev 0 (aarch64)
[14:18:40] <jepler> preinstalled with android, I'll be putting an ubuntu image on it tonight, then try to build linuxcnc for sim
[14:19:05] <seb_kuzminsky> ooh nice!
[14:19:10] <seb_kuzminsky> your 96board?
[14:19:25] <jepler> yeah it's the dragonboard 410c
[14:19:41] <seb_kuzminsky> does it run the kvm hypervisor?
[14:20:18] <jepler> I don't know
[14:20:25] <jepler> ugh this is not confidence-inspiring
[14:20:40] <jepler> <6>[ 40.023230] lowmemorykiller: Killing 'omm.location.XT' (1378), adj 1000,
[14:20:45] <jepler> and about 20 more
[14:20:59] <jepler> or maybe that's normal in android
[14:21:51] <jepler> seb_kuzminsky: anyway with only 1GB RAM it's not going to be a great choice for virtualization
[14:22:37] <jepler> > [kvm] is currently not possible, it’s a limitation of the (proprietary) bootloaders that ship with this board
[14:22:40] <jepler> boo
[14:22:46] <jepler> (source:
https://www.96boards.org/forums/topic/kvmarm-for-dragonboard-410c/)
[14:23:16] * seb_kuzminsky puts his wallet away
[14:25:23] <jepler> heh
[14:28:27] <jepler> in 6 months or a year there will probably be a much better lineup of aarch64 boards. this is just the first sub-$100 that shipped.. (hikey is apparently shipping now too, but it's >$100 and doesn't really seem to beat the dragonboard on specs)
[14:29:42] <seb_kuzminsky> does it have spi so you can hook up your hm2 board?
[14:30:04] <jepler> yes, the 96boards "LS Expansion" header has SPI with a 1.8v I/O standard
[14:30:22] <seb_kuzminsky> cool
[14:30:41] <jepler> so just like you could make an SPI daughtercard for any arduino-compatible, you can for any 96boards-compatible
[14:31:43] <jepler> not that the form factor is guaranteed to be commercially successful by any means
[14:41:11] <jepler> the 96boards spec doesn't cover anything about the signals on the expansion connectors beyond saying they're 1.8v
[14:42:09] <jepler> well, I mean, it covers that these are GPIOs, those are SPI, etc
[14:42:29] <skunksleep> Why Ubuntu?
[14:42:32] <jepler> but stuff like rise and fall time, drive strength, parasitic capacitance etc
[14:42:35] <seb_kuzminsky> will your spi dev work from the u3 carry over?
[14:42:44] <jepler> skunksleep: the easy choices are ubuntu or androia, and android is not particularly useful.
[14:42:58] <skunksleep> Ah
[14:43:28] <jepler> seb_kuzminsky: parts of it might. my kernel modifications touched 3 layers of the SPI stack: the userspace spidev interface, the generic kernel spi layer, and the specific spi hardware driver
[14:43:44] <jepler> seb_kuzminsky: so depending how much the kernel has changed from 3.8 to 4.0, 2/3 of it might apply
[14:43:54] <jepler> in either case it will be useful experience to have under my belt
[14:44:27] <jepler> but that's about step .. 4, at least
[14:47:55] <skunksleep> Will your board plug in? Or is some redesign needed?
[14:48:11] <jepler> skunksleep: no, it needs a fresh board layout
[14:48:37] <jepler> but the basic design of the board is virtually the same
[15:18:19] <KGB-linuxcnc> 03John Thornton 052.7 853b70c 06linuxcnc 10(28 files in 6 dirs) Docs: make file names follow the same convention. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=853b70c
[15:39:42] <skunksleep> https://groups.yahoo.com/neo/groups/Emco_cnc_users/conversations/topics/4751
[15:40:40] <seb_kuzminsky> Oops!
[15:40:41] <seb_kuzminsky> You need to be a member to perform this action.
[15:41:36] <skunksleep> Aww sorry
[15:42:40] * Tom_itx gives seb_kuzminsky a secret decoder ring
[15:43:45] <skunksleep> I have an Emco Compact 5 PC lathe. It runs fine otherwise, but the steppers on both axes slow way down after the machine has been on for some time. I'm not sure whether the problem is the stepper motors themselves or something else.
[15:44:46] <skunksleep> Running linuxcnc. It goes the right amount just slow. Restarting linuxcnc fixes it
[15:44:58] <skunksleep> Just odd
[15:45:11] <seb_kuzminsky> overheating & losing steps?
[15:45:21] <seb_kuzminsky> hmm no, i guess not
[15:45:32] <cradek> what troubleshooting have you done?
[15:45:42] <jepler> pressing a digit to set axis's feed override percentage?
[15:46:02] <seb_kuzminsky> jepler: i've done that plenty of times
[15:46:25] <skunksleep> Dad had similar issue last night that only rebooting fixed..
[15:46:48] <skunksleep> I wasn't there...
[15:47:22] <jepler> the digit keys alone set the feed override percentage, except that when in machine on mode, some of them select an axis by number (` = 0 = X, 1 = Y, etc)
[15:50:36] <skunksleep> Maybe a stuck key, he said g0 was uneffected
[15:51:08] <cradek> it's very hard to believe that wasn't somehow operator error :-/
[15:51:34] <cradek> but don't tell him I said that
[15:51:46] <cradek> (hi sam's dad)
[15:51:46] <cradek> haha
[15:52:41] <PCW> I thought rebooting was the _windows_ fixit strategy
[15:53:11] <jepler> for everything you don't care to troubleshoot, there's rebooting
[15:53:14] <jepler> .. there's even an xkcd about it
[15:54:11] <skunksleep> :)
[15:56:02] <skunksleep> He had a rough day,. He accidentally pressed the pallet change button and that doesn't have as much logic as it should
[15:56:55] <skunksleep> (My fault for never getting back to it after 'hey it works'
[15:58:05] <skunksleep> He unloaded the pallet 180 deg out so none of the sensors worked.
[15:58:58] <skunksleep> It should not let him do that
[16:08:40] <jepler> oops
[16:09:34] <cradek> if he didn't get hurt and the machine didn't get destroyed it was a good day
[16:12:40] <skunksleep> Exactly
[18:03:51] <micges> did you try amd64 netinstaller or i386?
[18:06:44] <andypugh> i386
[18:07:22] <micges> what exact mb do you have?
[18:08:05] <micges> I have J1800N-D2P
[18:08:50] <andypugh> that one
[18:09:13] <andypugh> (eating back later)
[18:09:34] <micges> k
[18:28:01] <andypugh> What puzzles me is at the end of the dd, the USB stick is “there” but wont mount.
[18:28:39] <andypugh> (with the stock binary iso, or the LinuxCNC version)
[18:29:50] <andypugh> (Actually, forget that, after re-inserting it does show)
[18:33:34] <micges> my steps to run from stick: on boot press F12, choose UMAP: pendrive
[18:34:09] <andypugh> Fresh download of LinuxCNc binary hybrid, DD, continual reboot when trying to start from USB
[18:35:05] <micges> did you check you can start from this stick on other pc?
[18:35:25] <andypugh> I don’t have any other PCs working at the moment
[18:36:05] <andypugh> They have all been canibalised for parts.
[18:36:14] <micges> meh
[18:37:04] <micges> can you try unetbootin with debian netinstall, i386?
[18:37:35] <Brunetty> I use universal usb installer software for deb8
[18:40:23] <PCW> andypugh what BIOS version?
[18:41:17] <andypugh> No idea what BIOS version
[18:41:23] <seb_kuzminsky> andypugh: does memtest86 pass?
[18:42:36] <andypugh> How do I run memtest on a computer that won’t boot?
[18:45:08] <micges> andypugh: boot, press DEL and check what bios version do you have first
[18:45:56] <andypugh> I am rapidluy losing interest.
[18:46:10] <andypugh> Especially as the machine is out in the workshop fastened to the mill.
[18:48:30] <andypugh> BIOS version F1
[18:49:28] <micges> F2 here
[18:51:34] <andypugh> Yes, and the way to upgrade is to… boot from USB..
[18:51:59] <andypugh> The motherboard is looking increasingly like a frisbee
[18:53:11] <andypugh> Is UEFI actually intended to make it hard to install Linux, or is that accidental?
[18:53:31] <Tom_itx> seems to be working no matter the intent
[18:56:42] <andypugh> To be fair, I have actually installed Ubuntu on the drive in the PC. It just won’t boot from it.
[18:57:04] <andypugh> Which a BIOS update might fix, I suppose.
[18:58:23] <Tom_itx> i get nervous doing BIOS updates
[18:59:33] <andypugh> It seems you need a util from HP, and a Windows machine to update the BIOS too.
[19:00:30] <micges> easy
[19:01:04] <Tom_itx> some offer about 3 different ways to update it
[19:01:12] <PCW> I have a Gigabyte D2H and it runs linuxcnc fine. I think I may have had to update the BIOS to get it to boot linux
[19:01:36] <PCW> F1 is hopeless
[19:02:08] <PCW> (F3 is current I think)
[19:02:35] <andypugh> I have downloaded the F3 BIOS, but that seems to only be part of the process.
[19:03:05] <andypugh> There is a .bat and a .exe and no instructions. I have a Mac and a non-booting Linux box...
[19:03:10] <PCW> I made a bootable DOS sub stick
[19:03:15] <PCW> USB
[19:03:45] <PCW> and put those files on it and ran the batch file
[19:04:10] <PCW> F1 UEFI will boot DOS :-)
[19:05:15] <andypugh> Yes, but where do I get DOS from?
[19:05:33] <PCW> freedos
[19:06:21] <andypugh> I re-iterate my opinion that this is worryingly hard if we actually want machinists to be able to use our software.
[19:06:40] <PCW> this is not a linuxcnc issue
[19:06:52] <PCW> or really even a linux issue
[19:06:55] <andypugh> No, but it is an issue for LinuxCNC
[19:07:10] <PCW> its a broken BIOS issue
[19:07:36] <andypugh> And they seem to be breaking BIOSs on purpose now.
[19:07:50] <PCW> Well they fixed this one
[19:08:01] <andypugh> Not really
[19:08:19] <PCW> F2 and F3 work fine
[19:08:50] <andypugh> They made it possible to fix it if you can find the downoad, if you can find DOS, if you can make a bootable USB stick, and if you can update the BIOS without error.
[19:09:04] <PCW> http://www.chtaube.eu/computers/freedos/bootable-usb/
[19:09:17] <andypugh> You are missing my point.
[19:09:24] <andypugh> We are all computer experts.
[19:09:28] <andypugh> And we find it hard.
[19:10:02] <andypugh> I am sure that I will get to the bottom of this, possibly in less than a week.
[19:10:20] <andypugh> But an ordinary person would have lst interest and installed Mach3 by now.
[19:10:32] <PCW> well you have a motherboard with a first rev ~2 year old BIOS so its not terribly surprising that there are issues
[19:10:49] <andypugh> It surprises me, I bought it last week
[19:10:57] <PCW> nope win7 wont boot either
[19:11:21] <PCW> so mach 3 is out also unless you want WIN8.1
[19:11:22] <andypugh> OK, I am about to tru the Debian8 installer.
[19:11:39] <andypugh> I doubt it will work, if the problem is the BIOS.
[19:12:40] <micges> yeah but won't hurt to try
[19:13:31] <PCW> well there are 2 possible issues
[19:13:32] <PCW> 1. F1 BIOS is so buggy that it barely works
[19:13:34] <PCW> 2. You need a fairly up-to-date kernel on the J1800 so you dont lose USB in the middle of booting
[19:15:19] <PCW> The first RTAI kernel on the wheezy binary ISO would not work on the J1800/J1900 cards (USB turned off) , this is fixed now
[19:15:53] <andypugh> No, Debian 8 doesn’t boot either
[19:16:47] <andypugh> (so, it is looking rather remarkable that the Ubuntu 12.04 Live-image booted with no problems, but it installed a non-booting setup on the SSD)
[19:17:00] <PCW> I spent ~1 day fing with BIOS settings until i gave up and flashed the BIOS
[19:18:00] <andypugh> To add to my misery, there is something horribly wrong with my Mac too.
[19:18:25] <andypugh> The system locks up for a few seconds every minute or so, even with nothing running.
[19:18:52] <PCW> Thats bad, just started doing that?
[19:21:21] <andypugh> Yes
[19:21:40] <andypugh> It _might_ correlate with installing Webex
[19:23:07] <andypugh> I need to re-install from the recovery partition and restore from backup. All blessedly painless and automatic, but time-consuming
[19:27:48] <andypugh> Oh for crying out loud.
[19:28:25] <andypugh> That freedos link gets you a .img file, which the startup disk creator doesn’t see.
[19:28:49] <andypugh> (and the Mac says “invalid parameter” whatever that means
[19:36:15] <PCW> probably just want dd or the equivalent since its a physical image
[19:36:57] <Tom_itx> https://rufus.akeo.ie/
[19:37:01] <andypugh> The instructions say otherwise…
[19:37:05] <Tom_itx> i used that to make a DOS bootable thumb drive
[19:37:15] <Tom_itx> maybe you can put your bios on a DOS disk like that
[19:37:27] <andypugh> PCW:
http://www.chtaube.eu/computers/freedos/bootable-usb/howto/
[19:37:53] <jepler> hm so far the dragonboard's builtin wlan seems to be a bit flaky
[19:37:58] <andypugh> Not exactly a simple process :-(
[19:38:38] <PCW> none of that is needed with the image
[19:39:37] <andypugh> So why is that process linked from the image download page?
[19:39:42] <PCW> just this
[19:39:44] <PCW> dd if=FreeDOS-1.1-memstick-2-256MB.img of=/dev/sdz bs=512k
[19:40:03] <PCW> (after unzipping the image file)
[19:41:50] <PCW> they explain the process of making the image (but you dont need to do that)
[19:53:38] <andypugh> so, booting from FreeDOS..
[19:54:01] <andypugh> “Press enter to boot Freedos” just reboots to the same screen
[19:54:26] <andypugh> memtest, gets to a blue screen of stuff, then reboots
[19:54:35] <andypugh> fdos - just reboots
[19:54:45] <andypugh> odin - Aha! A command line.
[19:55:08] <andypugh> Autoexec.bat ……. J1800 BIOS F3 ….. BIOS ID MIsmatch…
[19:55:35] <andypugh> Perhaps I can return the MB?
[19:57:36] <PCW> I just remember the F1 BIOS was really broken and F2 fixed most things
[19:57:37] <PCW> So free DOS will boot to a prompt?
[19:59:04] <PCW> if memtest will not run that's not terribly promising
[19:59:05] <andypugh> Not really. Syslinux boots to a prompt. Only FreeDOS won’t boot, but the Odin floppy-image will boot to a command line.
[19:59:51] <andypugh> How can they release a BIOS that broken? Do they not do any testing at all?
[20:00:30] <andypugh> But the BIOS flashing Utility gives a “BIOS ID Mismoatch” error...
[20:00:57] <cradek> jeez
[20:01:01] <PCW> yuck
[20:01:54] <PCW> updating just worked for me.... sigh
[20:02:12] <Tom_itx> what bios ver do each of you have?
[20:02:43] <PCW> I have F2 (started at F1)
[20:04:30] <cradek> can't believe they just go on selling something so totally broken, instead of pulling and replacing them
[20:04:50] <PCW> it will boot win8.1
[20:04:52] <cradek> it's like they didn't even try it
[20:05:05] <cradek> ohh
[20:05:48] <cradek> so it's only everything except uefi-dvd-boot that's broken?
[20:05:59] <PCW> it has to be old stock because F2 came out quite while ago
[20:06:09] <andypugh> It feels like yoiu should be able to run the BIOS flasher from the EFI prompt.
[20:06:34] <andypugh> (the EFI prompt is also hopeless, the help screens scroll right off the top of the display)
[20:07:12] <jepler> dragonboard gets a new mac address every boot, no known fix at this time
https://www.96boards.org/forums/topic/wireless-issue/
[20:07:23] <jepler> linuxcnc configure runs out of ram if you don't create a swapfile
[20:07:24] <cradek> wtf
[20:07:31] <andypugh> A new _MAC_ address?
[20:07:49] <jepler> yes
[20:08:04] <andypugh> I thought that MAC addresses were fixed to hardware
[20:08:09] <cradek> well that'll quickly eat up your dhcps
[20:08:17] <andypugh> (give or take MAC spoofing)
[20:08:21] <PCW> http://www.newegg.com/Product/Product.aspx?Item=N82E16813128688
[20:08:23] <PCW> if you look at the first review it has step/step bios upgrade instructions
[20:09:00] <jepler> [ 69.576347] wcn36xx wcn36xx: Failed (-11) to read macaddress file wlan/macaddr0, using a random address instead
[20:09:03] <jepler> [ 69.577141] wcn36xx: mac address: 00:0a:f5:50:df:25
[20:10:13] <jepler> and this causes it to (A) not have a nic for ~70 seconds after booting and (B) not automatically configure, so you have to interact at the console to get on the network so it's (C) going to be useless as a headless machine
[20:11:36] <PCW> they could not allocate $ .0000001 worth of flash or EEPROM for a MAC address?
[20:12:21] <jepler> andypugh: there is a range set aside for use as "random MACs". this is what most virtualization systems use these days, aiui, except the random address is also fixed for the lifetime of the vm
[20:16:14] <jepler> hmph, except this randomly generated address is not in the "locally administered" range as I expected.
http://serverfault.com/questions/40712/what-range-of-mac-addresses-can-i-safely-use-for-my-virtual-machines
[20:17:04] <andypugh> PCW: I wonder if the chap who wrote those update instructions tried every possible combination of UEFI / Legacy in CSM setttings? It reads that way.
[20:17:54] <andypugh> (for fun, the rest of you might want to read that newegg link, it’s amazingly arcane)
[20:18:29] <cradek> oh and keep trying keyboards until you find one that happens to work with the original bios
[20:24:10] <andypugh> Luckily I have a PS2 keyboard that only needs some keys pressing twice to work
[20:24:33] <cradek> they probably didn't test ps2 keyboard support either
[20:25:26] <andypugh> Anyway, those instructions don’t work with FreeDOS, as it doesn’t boot far enough to find the autoexec.bat on C:. I can only boot to A: then cd to C:. and then it is too late.
[20:26:31] <andypugh> So, it looks like I need to download a pirated HP tool, a pirated version of Win98….
[20:28:09] <andypugh> Anyway, it’s 2am and I am stopping. I stopped on the way out of the workshop and seriously considered pulling the MB out of the machine and seeing how far into the woods I can throw it. I think if I go through another iteration I will end up actually doing it.
[20:29:33] <cradek> g'night andypugh
[20:30:35] <cradek> iirc, an autoexec on A: will be executed too
[20:31:01] <andypugh> cradek: But how do I put an autoexec on an A: that doesn’t really exist?
[20:31:33] <andypugh> The A: in question is a disk image on the USB stick
[20:32:00] <andypugh> Anyway, I have hit the “return item” button and will print the label tomorrow.
[20:32:16] <cradek> yay, I guess
[20:32:44] <andypugh> Can anyone suggest a mini-itx motherboard with a full-size PCI slot that does actually work?
[20:32:53] <cradek> if you were nearby I'd bring you a working (pre-uefi) pc
[20:33:27] <andypugh> It needs to be a Mini-ITX board to fit into my control cabinet.
[20:33:58] <cradek> I can't recommend. I know nothing.
[20:34:36] <andypugh> I still don’t actually know that the motherboard was the problem. It might be something wrong with the 5i23, and all this might have been a total waste of time, but I didn’t get far enough to find out even.
[20:35:28] <Tom_itx> andypugh, i got this one on PCW's recomendation but haven't tried it as of yet:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157497&cm_re=asrock_Q1900B_itx-_-13-157-497-_-Product
[20:35:40] <Tom_itx> i have that one and the full size version
[20:36:03] <andypugh> PCI-e though….
[20:36:24] <Tom_itx> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157565&cm_re=q1900M_pro3-_-13-157-565-_-Product
[20:36:25] <jepler> so the compile problem so far is <sys/io.h> doesn't exist on aarch64, which leads to various problems.
[20:36:31] <jepler> in retrospect I'm surprised that 32-bit arm has it
[20:36:33] <Tom_itx> a tiny bit wider than the other one
[20:36:41] <Tom_itx> (2 slots wider)
[20:36:52] <Tom_itx> other than that they're the same
[20:37:16] <Tom_itx> it may fit in your box
[20:37:36] <andypugh> No, the box is very definitely mini-ITX.
[20:37:42] <Tom_itx> ok
[20:38:15] <Tom_itx> i still plan to test them eventually.
[20:38:29] <Tom_itx> still waiting on a mesa board to fix my control
[20:39:53] <Tom_itx> i booted one from my previous 10.04 install but didn't do alot with it
[21:10:11] <jepler> and now odd compiler errors
[21:10:26] <jepler> relocation truncated to fi: R_AARH64_LD64_GOT_LO12_NC against `loop'
[21:15:08] <jepler> ... aaannd most or all runtests fail
[21:15:16] <jepler> "unhandled level 0 translation fault"
[21:19:45] <jepler> .. and that's enough for one night
[21:20:50] <jepler> well here's the cause of the one thing:
https://www.sourceware.org/ml/binutils/2014-07/msg00155.html (we do exactly that thing)