Re: [lfs-support] A speedup with 4.14 and later kernels (against Meltdown)
On Thu, Feb 15, 2018 at 12:43:21PM +, Hazel Russman wrote: > I'm not sure what Ken means by "bisect" but I have established that the most > recent 4.13 kernel (4.13.16) boots with acpi enabled and 4.14.1 doesn't, nor > anything later than that. > 'git bisect'. In other words, working through the commits from 4.13.0 to 4.14.0 in linus's tree (the stable git tree for 4.14 is separate). This obviously requires git, but it also needs towards 3.0 GB of space for linus's git tree. Bisection tries to do a binary search from known-good to known-bad. And it is tedious. If you want to do it, once you have the files install the .config, then at each step 'make clean, make oldconfig, make'. Sometimes the reported version of the kernel will be surprisingly old. For each build, install modules and kernel, try to boot. If ok, 'git bisect good'. If it has the problem, 'git bisect bad'. If it fails to build, or dies from a different problem, 'git bisect skip'. Have you tried 4.14.0 itself ? If not, that might be worth trying just in case the problem is in the 4.14-stable tree. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
I am afraid I have to bother you again with theser SEARCH_DIRs.
While the question above pertained to step 6.10, I now have a similar
thing in Step 6.20 (Installation of GCC)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib"
Because this will, as I believe, the final GCC for LFS, there should
not be
any /tools reference at all.
Also of course, the book also mentions much more directories like lib64
and the various $(uname -m) directories.
I am not sure what GCC is supposed to search in these directories,
but I assume
that it is for shared libraries that are not specified with -L to the
linker.
Anyway, when GCC is compiled, from where does ./configure(? or the
compile process) take the information
which SEARCH_DIRs it compiles into its binary/binaries(?). If I knew
that, I could go back
to the respective point in my build and go on from there again.
The above was from 6.10
Ok the below is what you should get from 6.20
If you get something other than this you may indeed have missed
something or something has gone wrong.
I script my builds because I know I will screw up. Just ask my wife
she will tell you how much and how often I screw up! According to her
she is the only thing that keeps me from becoming a complete mess.
I can review each step and see what stupid thing I did and fix it.
Then I can wipe out the /mnt/lfs and run the script to start over.
That makes sure something did not get over looked only to come back
and bite me.
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Book: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o
succeeded
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
/usr/include
Book: #include <...> search starts here:
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
Book: /usr/local/include
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
Book: /usr/include
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
Book: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
Book: SEARCH_DIR("/usr/local/lib64")
Book: SEARCH_DIR("/lib64")
Book: SEARCH_DIR("/usr/lib64")
Book: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
Book: SEARCH_DIR("/usr/local/lib")
Book: SEARCH_DIR("/lib")
Book: SEARCH_DIR("/usr/lib");
dummy.log:attempt to open /lib/libc.so.6 succeeded
dummy.log:attempt to open /lib/libc.so.6 succeeded
Book: attempt to open /lib/libc.so.6 succeeded
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
Book: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
I am actually pretty convinced that I goofed up something. Like you, I
am trying to create my repeatable scripts.
Now, it's one thing to know that I am wrong, but a completely different
thing to determine why I am wrong.
So, I am still trying to figure out where the GCC compilation process
takes the information from what will constitute the
SEARCH_DIRS in the produced compiler suite.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
On 2/15/2018 10:58 AM, René Nyffenegger wrote:
On 02/15/2018 01:54 PM, Baho Utot wrote:
On 2/15/2018 5:51 AM, René Nyffenegger wrote:
As I am proceeding with building LFS, I am now in Step 6.10,
Adjusting the Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I
am still
a bit worried about the paths that start with /tools. I just want to
be 100% positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings
ALTHOUGH they start with /tools?
This is what my build produces, the Output lines are from the Book and
what you should be looking for. The lines not prefixed by Output: are
the actual lines from the test. I believe you are good to go. The
"real" test comes after gcc. That is the one that gave me the most
grief. Since I am doing scripted builds and I failed to remove the
gcc symlink the install process got all balled up.
Output: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Output: /usr/lib/../lib/crt1.o succeeded
Output: /usr/lib/../lib/crti.o succeeded
Output: /usr/lib/../lib/crtn.o succeeded
/usr/lib/../lib/crt1.o succeeded
/usr/lib/../lib/crti.o succeeded
/usr/lib/../lib/crtn.o succeeded
Output: #include <...> search starts here:
Output: /usr/include
#include <...> search starts here:
/usr/include
Output: SEARCH_DIR(/usr/lib)
Output: SEARCH_DIR(/lib)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
Output: attempt to open /lib/libc.so.6 succeeded
attempt to open /lib/libc.so.6 succeeded
Output: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
I am afraid I have to bother you again with theser SEARCH_DIRs.
While the question above pertained to step 6.10, I now have a similar
thing in Step 6.20 (Installation of GCC)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib"
Because this will, as I believe, the final GCC for LFS, there should not be
any /tools reference at all.
Also of course, the book also mentions much more directories like lib64
and the various $(uname -m) directories.
I am not sure what GCC is supposed to search in these directories, but I
assume
that it is for shared libraries that are not specified with -L to the
linker.
Anyway, when GCC is compiled, from where does ./configure(? or the
compile process) take the information
which SEARCH_DIRs it compiles into its binary/binaries(?). If I knew
that, I could go back
to the respective point in my build and go on from there again.
The above was from 6.10
Ok the below is what you should get from 6.20
If you get something other than this you may indeed have missed
something or something has gone wrong.
I script my builds because I know I will screw up. Just ask my wife she
will tell you how much and how often I screw up! According to her she is
the only thing that keeps me from becoming a complete mess.
I can review each step and see what stupid thing I did and fix it. Then
I can wipe out the /mnt/lfs and run the script to start over. That
makes sure something did not get over looked only to come back and bite me.
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Book: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crt1.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crti.o
succeeded
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/crtn.o
succeeded
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
/usr/include
Book: #include <...> search starts here:
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
Book: /usr/local/include
Book: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
Book: /usr/include
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
Book: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
Book: SEARCH_DIR("/usr/local/lib64")
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
On 02/15/2018 01:54 PM, Baho Utot wrote:
On 2/15/2018 5:51 AM, René Nyffenegger wrote:
As I am proceeding with building LFS, I am now in Step 6.10,
Adjusting the Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I
am still
a bit worried about the paths that start with /tools. I just want to
be 100% positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings
ALTHOUGH they start with /tools?
This is what my build produces, the Output lines are from the Book and
what you should be looking for. The lines not prefixed by Output: are
the actual lines from the test. I believe you are good to go. The
"real" test comes after gcc. That is the one that gave me the most
grief. Since I am doing scripted builds and I failed to remove the
gcc symlink the install process got all balled up.
Output: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Output: /usr/lib/../lib/crt1.o succeeded
Output: /usr/lib/../lib/crti.o succeeded
Output: /usr/lib/../lib/crtn.o succeeded
/usr/lib/../lib/crt1.o succeeded
/usr/lib/../lib/crti.o succeeded
/usr/lib/../lib/crtn.o succeeded
Output: #include <...> search starts here:
Output: /usr/include
#include <...> search starts here:
/usr/include
Output: SEARCH_DIR(/usr/lib)
Output: SEARCH_DIR(/lib)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
Output: attempt to open /lib/libc.so.6 succeeded
attempt to open /lib/libc.so.6 succeeded
Output: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
I am afraid I have to bother you again with theser SEARCH_DIRs.
While the question above pertained to step 6.10, I now have a similar
thing in Step 6.20 (Installation of GCC)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib"
Because this will, as I believe, the final GCC for LFS, there should not be
any /tools reference at all.
Also of course, the book also mentions much more directories like lib64
and the various $(uname -m) directories.
I am not sure what GCC is supposed to search in these directories, but I assume
that it is for shared libraries that are not specified with -L to the linker.
Anyway, when GCC is compiled, from where does ./configure(? or the compile
process) take the information
which SEARCH_DIRs it compiles into its binary/binaries(?). If I knew that, I
could go back
to the respective point in my build and go on from there again.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] make -k check hangs in installation of GCC
On 15/02/2018 15:11, René Nyffenegger wrote: I am trying to install GCC (Step 6.20, http://www.linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html) The line reading make -k check seems to hang. The last lines printed are (before my intervention with CTRL-C) are WARNING: Couldn't find the global config file. Test run by root on Thu Feb 15 13:58:56 2018 Native configuration is x86_64-pc-linux-gnu === gcc tests === Schedule of variations: unix Running target unix Using /tools/share/dejagnu/baseboards/unix.exp as board description file for target. Using /tools/share/dejagnu/config/unix.exp as generic interface file for target. Using /sources/untarred/gcc-7.2.0/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sources/untarred/gcc-7.2.0/gcc/testsuite/gcc.c-torture/compile/compile.exp ... Without an error message, I am quite hopeles to even think of a cause. However, there is this WARNING: Couldn't find the global config file I am not sure if this warning has anything to do with my problem. "Torture" tests take a long time... Just wait (on my computer, at -j1 (core-i7 4790), the GCC tests take almost 3 hours, and I'd say torture tests are around 10 mn or so). I've always seen the warning: it is harmless. Regards Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[lfs-support] make -k check hangs in installation of GCC
I am trying to install GCC (Step 6.20, http://www.linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html) The line reading make -k check seems to hang. The last lines printed are (before my intervention with CTRL-C) are WARNING: Couldn't find the global config file. Test run by root on Thu Feb 15 13:58:56 2018 Native configuration is x86_64-pc-linux-gnu === gcc tests === Schedule of variations: unix Running target unix Using /tools/share/dejagnu/baseboards/unix.exp as board description file for target. Using /tools/share/dejagnu/config/unix.exp as generic interface file for target. Using /sources/untarred/gcc-7.2.0/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /sources/untarred/gcc-7.2.0/gcc/testsuite/gcc.c-torture/compile/compile.exp ... Without an error message, I am quite hopeles to even think of a cause. However, there is this WARNING: Couldn't find the global config file I am not sure if this warning has anything to do with my problem. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A speedup with 4.14 and later kernels (against Meltdown)
Hallo, > Thomas, I'm not quite sure what you are asking me to do. I save all > my config files for reference. I've got a 4.14.1 kernel building now, > made with oldconfig using the 4.13.16 config file and defaults for > all new options. What exactly do you want me to do with it when it's > finished? I was suggesting exactly what you did: use the config from 4.13 as a starting point, then compile the 4.14 kernel with that, and check exactly while answering the questions for new features. Don't stick to the defaults, try to understand whether there might be problems with each option. Or simply, do not use 4.14.1 - use some later kernel from 4.14 series. Maybe the early releases of 4.14 had some problems like yours and they got fixed. I'd try with something like .10, right before the Meltdown/Spectre patches. Tschau...Thomas -- "Do you wanna be a legend or a passing footprint on the sands of time?" signature.asc Description: OpenPGP digital signature -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
On 2/15/2018 5:51 AM, René Nyffenegger wrote:
As I am proceeding with building LFS, I am now in Step 6.10, Adjusting
the Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I am
still
a bit worried about the paths that start with /tools. I just want to be
100% positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings
ALTHOUGH they start with /tools?
This is what my build produces, the Output lines are from the Book and
what you should be looking for. The lines not prefixed by Output: are
the actual lines from the test. I believe you are good to go. The
"real" test comes after gcc. That is the one that gave me the most
grief. Since I am doing scripted builds and I failed to remove the gcc
symlink the install process got all balled up.
Output: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
Output: /usr/lib/../lib/crt1.o succeeded
Output: /usr/lib/../lib/crti.o succeeded
Output: /usr/lib/../lib/crtn.o succeeded
/usr/lib/../lib/crt1.o succeeded
/usr/lib/../lib/crti.o succeeded
/usr/lib/../lib/crtn.o succeeded
Output: #include <...> search starts here:
Output: /usr/include
#include <...> search starts here:
/usr/include
Output: SEARCH_DIR(/usr/lib)
Output: SEARCH_DIR(/lib)
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib");
Output: attempt to open /lib/libc.so.6 succeeded
attempt to open /lib/libc.so.6 succeeded
Output: found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
found ld-linux-x86-64.so.2 at /lib/ld-linux-x86-64.so.2
removed 'dummy.c'
removed 'a.out'
removed 'dummy.log'
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A speedup with 4.14 and later kernels (against Meltdown)
On Thu, 15 Feb 2018 09:47:33 +0100 Thomas Seeling wrote: > Hallo, > > >> I wonder if that explains the problems I am having with recent > >> kernels. I am running on an old machine without PCID (I just > >> checked) and I cannot boot anything later than the end of series > >> 4.13. The panic occurs in the acpi driver > > I have some old machines which I reuse as DNS, NAS, Squid etc., with > Pentium 4 and Core2 CPUs. > I rebuilt LFS-svn-20180128 with success on the Pentium 4 machine and > I'll build the kernels with gcc 7.3 on this machine now. The kernels > boot fine on the newer Core2 CPUs. > > What type of CPU is giving you grief? Can you compile the new kernel > with "make oldconfig" to query your exact current kernel settings (if > the running kernel was compiled to support this)? > > Tschau...Thomas > -- > "Do you wanna be a legend or a passing footprint on the sands of time?" > The cpu is an Intel Core Duo model 23 stepping 10 with flags fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm kaiser dtherm. I'm not sure what Ken means by "bisect" but I have established that the most recent 4.13 kernel (4.13.16) boots with acpi enabled and 4.14.1 doesn't, nor anything later than that. Just for amusement, I created a hybrid kernel, 4.14.1 with a mostly 4.13.16 acpi driver. I had to include a few acpi files from 4.14.1 to get it to build. I half expected it to fail in a completely new way (after all, it was a monstrosity) but, to my surprise, it panicked in an identical way to the pure 4.14 kernels. I can only conclude that the cause of the panic lies in one of the 4.14.1 files that I had to use. I have a list of them somewhere, if that would be any help. Thomas, I'm not quite sure what you are asking me to do. I save all my config files for reference. I've got a 4.14.1 kernel building now, made with oldconfig using the 4.13.16 config file and defaults for all new options. What exactly do you want me to do with it when it's finished? Hazel -- -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[lfs-support] Adjusting the Toolchain: components with '-linux-gnu' should be ignored
As I am proceeding with building LFS, I am now in Step 6.10, Adjusting the
Toolchain.
The book instructs me to
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' On my system, the
output is:
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("=/tools/x86_64-pc-linux-gnu/lib")
Although the book tells me to ignore components with '-linux-gnu', I am still
a bit worried about the paths that start with /tools. I just want to be 100%
positive
about going on with my build process.
So, the question is: can I ignore these -linux-gnu search strings ALTHOUGH they
start with /tools?
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Step 6.9: error: missing __attribute__ ((constructor)) support
I'm afraid your problem is just a stupid typo somewhere in either glibc, binutils or gcc, either in chapter 5 or 6. Tim, you're right. I must have overlooked something. I was able to build Glibc in the second step now. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Step 6.9: error: missing __attribute__ ((constructor)) support
you seem to be misreading what the book says. The current stable book is 8.1, and the following specific minimum versions are mentioned: gcc-4.7 (you imply versions > 4.4.1 are not tested) glibc-2.11. As Pierre said, gcc-7.3.0 did not exist when 8.1 was released. In practice it should be fine for building 8.1 And glibc-2.26 is the highest version which had been tested, so it is explicitly OK. In other words, the versions you have mentioned are fine. We also say "Earlier versions of the listed software packages may work, but have not been tested." The things which commonly break a build are: /bin/sh not pointing to bash. host systems without bison (i.e. with a different yacc). mawk instead of gawk. missing packages from the list of requirements. I probably have to somehow first bild an old version of gcc and glibc before I can even think about trying to create my own LFS. No, building an older version of gcc is a recipe for pain - you can probably go back one or two versions, but sooner or later the current version will not understand the older source, particularly in g++). ĸen Ken, thanks for the clarificatino. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A speedup with 4.14 and later kernels (against Meltdown)
Hallo, >> I wonder if that explains the problems I am having with recent >> kernels. I am running on an old machine without PCID (I just >> checked) and I cannot boot anything later than the end of series >> 4.13. The panic occurs in the acpi driver I have some old machines which I reuse as DNS, NAS, Squid etc., with Pentium 4 and Core2 CPUs. I rebuilt LFS-svn-20180128 with success on the Pentium 4 machine and I'll build the kernels with gcc 7.3 on this machine now. The kernels boot fine on the newer Core2 CPUs. What type of CPU is giving you grief? Can you compile the new kernel with "make oldconfig" to query your exact current kernel settings (if the running kernel was compiled to support this)? Tschau...Thomas -- "Do you wanna be a legend or a passing footprint on the sands of time?" signature.asc Description: OpenPGP digital signature -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A speedup with 4.14 and later kernels (against Meltdown)
On Thu, Feb 15, 2018 at 07:57:31AM +, Hazel Russman wrote: > On Thu, 15 Feb 2018 06:52:02 + > Ken Moffat wrote: > > > If anyone is still using an older stable kernel on stressed-out > > intel hardware, I've just been reading a post which mentions that > > 4.14 now *uses* PCID (Processor Context ID, apparently added with > > Westmere (previously known as Nehalem-C). > > > > http://archive.is/ma8Iw > > > I wonder if that explains the problems I am having with recent kernels. I am > running on an old machine without PCID (I just checked) and I cannot boot > anything later than the end of series 4.13. The panic occurs in the acpi > driver and can be prevented by switching acpi off, but obviously that's not a > preferred solution. Unfortunately, because it happens so early in the boot > sequence, I haven't been able to capture the full traceback even with > pause_on_oops set. > > I originally thought that this might be linked to some acpi errors reported > by earlier kernels. By dint of much editing of dsdt and ssdt files, I have > managed to clear all of these, but the panic continues. Unless I can find > some solution, I shall have to build my next LFS with an older kernel than > the native one. Hi Hazel, I'm sorry to hear that is still a problem, but I haven't seen other reports of anything which looked similar. The usual upstream response will probably be "can you bisect it ?" which might be a tedious process if it is slow. What processor is it ? > > I read somewhere that there may be an incompatibility between newer kernels > and gcc-7. Is this the case? Definitely not. A pre-release version of gcc might have problems (gcc-8 apparently changes how part of the perf tools from the kernel build things (if I understood correctly, but in any case something in the kernel source but not used in a normal kernel), but releases - particularly gcc-7.3 - should be fine for building 4.14 or 4.15. And gcc-7.2 seems to be ok apart from lacking the code to enable full retpoline. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A speedup with 4.14 and later kernels (against Meltdown)
On Thu, 15 Feb 2018 06:52:02 + Ken Moffat wrote: > If anyone is still using an older stable kernel on stressed-out > intel hardware, I've just been reading a post which mentions that > 4.14 now *uses* PCID (Processor Context ID, apparently added with > Westmere (previously known as Nehalem-C). > > http://archive.is/ma8Iw > I wonder if that explains the problems I am having with recent kernels. I am running on an old machine without PCID (I just checked) and I cannot boot anything later than the end of series 4.13. The panic occurs in the acpi driver and can be prevented by switching acpi off, but obviously that's not a preferred solution. Unfortunately, because it happens so early in the boot sequence, I haven't been able to capture the full traceback even with pause_on_oops set. I originally thought that this might be linked to some acpi errors reported by earlier kernels. By dint of much editing of dsdt and ssdt files, I have managed to clear all of these, but the panic continues. Unless I can find some solution, I shall have to build my next LFS with an older kernel than the native one. I read somewhere that there may be an incompatibility between newer kernels and gcc-7. Is this the case? -- Hazel Russman -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
