On Sun, Mar 02, 2014 at 05:47:36PM -0600, Bruce Dubbs wrote: > Ken, You mentioned a problem with linux-3.13.5. Can you explain your > issues with that version? > > -- Bruce
Ah! I've just put a short summary in my reply to you re libexecdir on blfs-dev. Here's a MUCH fuller one: I built 7.5 with a 3.13.5 kernel (and 3.13.5 headers) to test some gnome packages. I hadn't built those packages since October/November and there was quite a lot of change amongst them, so I kept the new system in chroot (with a 3.13.4 kernel) until I'd finished libreoffice. Up to then, everything was fine. I then booted it - still ok - and started building the remainder. I'd forgotten that my original "build everything else" script (from when I was testing that everything built with make-4.0) included java/icedtea, and because I'd forgotten that, those versions were out of date. Realised it was building them, thought "oh well, let it build the old versions, no benefit but no harm done" and left it running. When I woke up in the morning, I was surprised to find that my OpenJDK script was still running rm -rf for the source directory, and had been doing so for more than 5 hours (both wall-clock time and CPU time), and was now at 99%-100% of one CPU, according to top. This build was running as root (yeah, I know) and somehow /etc/passwd- seemed to have been altered during OpenJDK. Specifically, I couldn't su or login, and none of the previous package's logs showed that file had changed during the package's build. But I also need to mention that this is an AMD phonon running at -j4 for the builds, and it tends to "lose its lunch" doing that. In fact, pass-1 gcc usually does this (an ICE), and dropping the caches is not usually sufficiebnt to allow it to proceed. So, much of LFS was built with -j3. I think I had changed back to -j4 for docbook and xorg. Anyway, I booted an older system, chrooted, fixed up the passwords. After that I resumed my build - got as far as GConf, and again rm -rf was taking 100% of one cpu, but this time only for about 15 minutes before I killed it. Built 3.13.4, rebooted, everything else built fine running 3.13.4. Tried SysRQ-T before killing the rm -rf, but rm was not running, merely ready to run. So, I asked on lkml about trying to find out what is going on. I got a suggestion to use perf (thought I hadn't enabled that, but in fact I had done or perhaps it is a default on x86), and to perhaps use 'crash' which needs a kernel with debugging information, and a saved vmlinux. So, I turned on a *lot* of debugging options, built crash, booted it - the kernel was noticeably slower, even simple things showed they were using a lot of CPU in top, but I couldn't replicate the problem. Yesterday (Sunday) evening, I went back to the regular 3.13.5 kernel, confirmed that perf did work there, and tried to replicate the problem without any success. Then I built the new system - if nothing else, I'll be able to update and test my kde scripts on this build. Last time I looked, it was still running ok at -j4. Once again, I'm starting to think that cosmic rays are the problem, or perhaps someone forgot to feed or muck-out the imps, or someone upset the camel. [ Can you guess what I'm reading at the moment ? ]. Probably, this kernel is fine for most people. Even if I can replicate the problem, it might be something in my .config. OTOH, this does mean it's going to be some days before I get round to testing 3.14-rc kernels :-( As always, YMMV and you may be burned even by a stable kernel. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
