Re: Status of RPi 3 (b) ?
On Fri, 6 Jan 2017, Christian Baer wrote: Good mornin'! :-) Why would you do such a thing? Just for fun. I knew I was going to make multiple mistakes, use multiple SD cards, and basically just screw around. However, I have several other machines running it - primarily because of ZFS. ZFS is a memory hog - and a big fat one at that. This is no big deal on a server or workstation with lots of RAM, but unfortunately, the Raspi doesn't really fit into that category. I totally agree. Most optimizations for ZFS don't even kick in unless you have 4GB of RAM or more. The OpenZFS tuning guide states that 1GB of RAM is sufficient, but more is recommended. ZFS ARC sizes with 1GB are too small for any kind of decent prefetch performance, though. Although I haven't really measured it, I'm pretty sure that ZFS is also pretty heavy on the CPU (compared to FFS). My experience with it on Solaris is that it depends on how you deploy the compression, deduplication, encryption, and built-in file sharing options. Load up on those, start using it heavily, and you can turn the machine into slag. That's also not to mention the checksums ZFS is constantly calculating. I can't prove it either, but I'd bet money you are right vis-a-vis FFS. UFS/FFS with soft updates is probably a better choice for a machine like a Raspi. Yeah, probably. That and I don't even know if they have a boot sector that'd let you put your root disk on ZFS on the ARM platform. I kinda doubt that. However, I wouldn't bet on UFS+softdeps being better than a *well tuned* ZFS rig. One could disable prefetch, lower the arc_max, and then override the TXG write_limit to force it to flush & sync a bit more and you'd probably be just fine and maybe match or beat UFS. It'd be an interesting test, actually. This "multicolor test pattern" is the Raspi's way of telling you that it can't load the OS. I figured it was something like that. That's better than a black screen, I guess. At least the monitor power save doesn't kick in and you can tell what happened. You have stated the reason quite well: The Raspi3 only works with NetBSD current. Thanks for the confirmation. My RPi v2 comes today in the mail, so either way, I'll be playing with NetBSD on some kind of Pi in the near future. That depends. IIRC everything works fine apart from the wireless-stuff (Wifi and Bluetooth). I heard some rumor that the OpenBSD guys have eschew Pis and focus on BeagleBones because of some binary blobs they don't want to distribute. It's always a mess with wifi and bluetooth. That and I can't keep up with who distributes what and who refuses. I think the deal with the OpenBSD crew is they don't want to be on the hook for redistributing blobs, but they'll cope with them if the machine uses them "internally". However, that whole topic gets ranty and endless once it starts. I mostly can't be bothered to care about it. I get a little "consumerish" and I figure folks like Stallman, Theo, and ESR can fight that fight elsewhere without me. I'll just plug in USB dongles as-needed. However, I have always found using any -current OS to be extremely ball-busting. Heh, true. However, I've had okay luck with picking a -current image for whatever weird kit I'm messing with at the time then just not updating once I find an image that works. Now *tracking* -current, oh man, yeah, that's a challenge. I don't yet have all the chops I need to track down bugs and regressions that crop up. I can code in C, but I'm not well practiced enough to find bugs before others do. I'll grant you that NetBSD is a lot more conservative (even in -current) than FreeBSD and especially most Linux distros (which are completely bleeding edge). But even with NetBSD it can happen that after an update (which you installed because some feature was a little flaky), the system won't work anymore or you just have a bug-change. Basically, not the best choice for a production-system. I'm just playing around, so no big deal, though I agree on the finer points you make. If I had a "production" application using Pi's I'd probably just buy two of them and keep known-good SD card images laying around. Plus, I tend to test & harden using very common hardware extensively before I put them in a position to lose money. Still, Pis are fun and definitely powerful enough for "real work" under the righ circumstances. -Swift
Re: -CURRENT cross compilation hangs with fatal error: pass-instances.def: No such file or directory
BERTRAND Joël a écrit : Michael a écrit : Hello, This looks like leftovers from previous builds - did you nuke $OBJDIR and $DESTDIR? IIRC binutils got updated, and a little while ago gcc as well. Also, do you have anything like HAVE_BINUTILS=226 set? I haven't HAVE_BINUTILS=226. I have destroyed $OBJDIR and $DESTDIR and result is the same : #create backend/alpha.d CC=/export/home/bertrand/netbsd/netbsd-cross/current/src/../tools-alpha/bin/alpha--netbsd-c++ /export/home/bertrand/netbsd/netbsd-cross/current/src/../tools-alpha/bin/nbmkdep -f alpha.d.tmp -- -I. -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/usr.bin/backend/../gcc/arch/alpha -DIN_GCC -DHAVE_CONFIG_H -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/. -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/../include -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/../libcpp/include -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/../libdecnumber -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/../libdecnumber/dpd -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/../libbacktrace -DTARGET_NAME=\"alpha--netbsd\" -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/libgcc -I/export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/usr.bin/backend/../../lib/libgcc/libgcov/arch/alpha --sysroot=/export/home/bertrand/netbsd/netbsd-cross/current/src/../obj-alpha/destdir.alpha -DLOCALEDIR=\"/usr/share/locale\" -DNETBSD_NATIVE -I. -DENABLE_SHARED_LIBGCC /export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/config/alpha/alpha.c && mv alpha.d.tmp alpha.d In file included from /export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/config/alpha/alpha.c:93:0: /export/home/bertrand/netbsd/netbsd-cross/current/src/external/gpl3/gcc/dist/gcc/pass_manager.h:125:30: fatal error: pass-instances.def: No such file or directory compilation terminated. nbmkdep: compile failed. *** Failed target: alpha.d Best regards, JKB Solution : pass-instances.def was created by build.sh in $OBJDIR/lib/gcc/alpha--netbsd/5.4.0/plugin/include I have copied this file in $SRCDIR/external/gpl3/gcc/dist/include and I can cross-build NetBSD. Best regards, JKB
Re: Status of RPi 3 (b) ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/05/17 19:14, Swift Griggs wrote: Good mornin'! > I just picked up an RPI3. I guess I should have waited. A few > congenitally systemd-infected distros work on it, but not much > else. FreeBSD was a notable exception. It seems to work, but I > managed to hork up the SD card jacking around with ZFS before I > could test X11 and other stuff. No big deal. Why would you do such a thing? I have not tried FreeBSD on a Raspi yet. However, I have several other machines running it - primarily because of ZFS. ZFS is a memory hog - and a big fat one at that. This is no big deal on a server or workstation with lots of RAM, but unfortunately, the Raspi doesn't really fit into that category. Although I haven't really measured it, I'm pretty sure that ZFS is also pretty heavy on the CPU (compared to FFS). UFS/FFS with soft updates is probably a better choice for a machine like a Raspi. > However, before I start over, how about NetBSD? When I tried to > boot the gzimg on the SD card it just came up with what looked > like a multicolor test pattern, but no boot etc... That was just a > quick and dirty test. I could have been doing any number of things > wrong. For one, I wasn't using -current. This "multicolor test pattern" is the Raspi's way of telling you that it can't load the OS. You have stated the reason quite well: The Raspi3 only works with NetBSD current. > My real question is: Does NetBSD work well enough on the RPi3 to > make it worth trying ? Also, could one of the anointed ones update > the RPI wiki for the RPi3 ? There is only a brief mention of the > RPi3 in the firmware section (nothing that helpful) and another > user in the comment section is seeing the exact same thing as me. That depends. IIRC everything works fine apart from the wireless-stuff (Wifi and Bluetooth). However, I have always found using any -current OS to be extremely ball-busting. I'll grant you that NetBSD is a lot more conservative (even in -current) than FreeBSD and especially most Linux distros (which are completely bleeding edge). But even with NetBSD it can happen that after an update (which you installed because some feature was a little flaky), the system won't work anymore or you just have a bug-change. Basically, not the best choice for a production-system. Kind regards, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iL4EAREKAGYFAlhvbr1fFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgzRDQzNjY2NUYzMDVBMTYxMDY0ODYwNzMy MDIxMzQyODdFMUJGQjIACgkQMgITQofhv7LVvgD+LKmCUSK07ofq9ha5MM6uJFMe Rn9JbjtHl+QHcwWo4jkBAJrZabbUBcl92CoFNH2j1ToFURqMK+ddWQWxWX2fGqiP =Gr5t -END PGP SIGNATURE-
