Re: [lfs-support] Kernel bug involving physical to virtual remapping
On 07/19/2018 09:34 PM, Michael Shell wrote: On Thu, 19 Jul 2018 13:54:19 +0200 Frans de Boer wrote: But I can't compile 4.13. anymore because I now have gcc 8.1 instead of the former 7 series. Frans, What goes wrong when you try to build a 4.13 kernel with gcc 8.1? It should work, right? Are there any good reasons not to use a gcc 8 series kernel? Cheers, Mike I get an syntax error when compiling pager.c. I had this before and remembered that gcc 8.1 is less forgiving then the 7 series. So, I tried to compile the kernel within the LFS development (systemd) environment which ended with said error. The next I tried 4.14.0 and all went well. That said, I just go somewhere else shopping, maybe there is something altered in either systemd (234-8) or the kernel after 4.13.x. I don't believe that this is the right thread anymore. I start with making a VM with a new image of various recent distributions and see if the same problem occurs there. If not, then it must be a LFS problem. -- Frans. -- 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] Kernel bug involving physical to virtual remapping
On Thu, 19 Jul 2018 13:54:19 +0200 Frans de Boer wrote: > But I can't compile 4.13. anymore because I now have gcc 8.1 instead > of the former 7 series. Frans, What goes wrong when you try to build a 4.13 kernel with gcc 8.1? It should work, right? Are there any good reasons not to use a gcc 8 series kernel? Cheers, Mike -- 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] Kernel bug involving physical to virtual remapping - CLOSED
On 07/19/2018 08:32 AM, Frans de Boer wrote: I know that Bruce uses bare metal too, but why not using VM's when one can continue developing without having to reboot into an incomplete system environment. Also, if one has multiple systems to spare, bare metal can be a way. If not, VM's are a welcome solution. I generally build on a dedicated development system accessed via ssh. That accomplishes the same level of convenience as a VM, but I prefer validating LFS on a real system. -- Bruce -- 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] Booting LFS with systemd
On 06-07-18 16:44, Bruce Dubbs wrote: On 07/06/2018 01:20 AM, Frans de Boer wrote: On 07/05/2018 11:56 PM, Bruce Dubbs wrote: On 07/05/2018 02:48 PM, Frans de Boer wrote: On 06/30/2018 01:29 PM, Hazel Russman wrote: On Fri, 29 Jun 2018 01:25:29 -0400 Michael Shell wrote: On Thu, 28 Jun 2018 16:06:00 +0800 Xi Ruoyao wrote: Now I only use "initrd" directive to update CPU microcode and fix the buggy ACPI DSDT of my laptop (another sad story). . And as there now seems to be several people who suffer with the ACPI DSDT driver bug, you guys should make sure upstream is aware of the problem, if they aren't already. ... Cheers, Mike -- I did a git bisect on my system, but I couldn't make much sense of the result. The commit it finally settled on didn't seem to have anything to with acpi. [quote] Bisecting: 2 revisions left to test after this (roughly 1 step) [9af9b94068fb1ea3206a700fc222075966fbef14] x86/cpu/AMD: Handle SME reduction in physical address size Bisecting: 0 revisions left to test after this (roughly 1 step) [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap() Bisecting: 0 revisions left to test after this (roughly 0 steps) [7744ccdbc16f0ac4adae21b3678af93775b3a386] x86/mm: Add Secure Memory Encryption (SME) support [unquote] I sent the result to the kernel acpi development list but never got an answer. If someone else on this list wants to try, I can send him my complete bisect logs. -- Hazel This quite frustrating. After recompiling, following the book to the letter, I still get a frozen LFS system. One thing I do note however is that the freezing always occurs after systemd has detected that it is on a virtual machine. A number of error messages is send, but due to ratelimiting I can't see them because they are suppressed. I had even rebuild everything with systemd-232, and that worked as before. But after 232, things started to behave strange. Now way to debug systemd, whatever I do Help? I don't mean to be pedantic, but I really don't think you would run into these types of problems using System V. Why not try that? -- Bruce Hi Bruce, With System V there is - of course - no problem. The thing is that systemd - if it runs well - is somewhat easier to use because of the use of .service files. I'll have to disagree that service files are easier. What I do agree with is that they are more consistent among distros. The boot scripts for System V are really quite easy to read and, if needed, write. I also noticed that some packages are only shipping .service(.in) files and have abandon the use of sysVinit files. Then they are abandoning those distros that do not use systemd such as the BSDs and Devuan. But those distros can easily add their own boot scripts. I'll note that all the BLFS packages that need boot scripts have them, Combined with the fact that most distributions have embraced systemd as their primary or only init system let me believe that we are stuck with this piece of ever growing mutation. And as LFS is a teaching ground, it should - however reluctant - incorporated this too. As a teaching tool, NOT using systemd is essential. There is far too much done by systemd in an opaque manner that System V demonstrates and, if desired,implemented in custom ways. Also, the goal is that someone fire-up their basic hardware with a LFS born OS, but for testing or use in VM's development is nowadays mostly within the VM realm. When I teach LFS in class, I always have the students use real HW, There are too many things that VMs hide, -- Bruce Bruce, I agree that VM's hide some issues and I do understand you position about systemd. Although I disagree to some level. After all, should we learn people how to crackup a (very) old car or the new generally available way using some sort of key. Just focusing only on System V is precisely what industries mean when they talk about "they are not being taught the modern technics.". Remember the days past, the discussion of having systemd included in the LFS book? Eventual it was included. Now the next "new" thing maybe? Why not using VM's when one can continue developing without having to reboot into an incomplete system environment. Also, if one has multiple systems to spare, bare metal can be a way. If not, VM's are a welcome solution. So, I think that I am chasing the wrong ghost and have a talk with the systemd developers instead. Despite the lack of interest for using VM's, I shall share any positive result with the LFS list. Regards, Frans. -- 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
Re: [lfs-support] Kernel bug involving physical to virtual remapping - CLOSED
On 19-07-18 14:57, Hazel Russman wrote: On Thu, 19 Jul 2018 13:54:19 +0200 Frans de Boer wrote: However a git bisection showed that this is actually a memory management issue. The kernel commit that caused the problem is : [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap(). Reintroducing the code: "if (is_ISA_range(phys_addr, last_addr)) return (__force void __iomem *)phys_to_virt(phys_addr);" makes the system bootable again. I have also tested this on a 4.15 kernel and it works there too. Hello Hazel, What you inserted is already available as from the 4.13.0 release. But I can't compile 4.13. anymore because I now have gcc 8.1 instead of the former 7 series. I continue my search and go for 4.14 where the check is removed. But i guess that will fail too and this is no solution to my problem with systemd freezing just after it found out that it is on a VM. --- Frans -- Yes, I can boot 4.13 kernels without any problems. But I wanted an LTS kernel that can keep up with the newest exploits (especially meltdown) and the next LTS after 4.9 is 4.14. I'm using bare iron, not a VM (and no systemd!), but it's rather old hardware. The processor is an Intel Core Duo. I can send you the cpuinfo if you want it. I suspect that if you did build 4.14, it would behave properly; after all, it does for most people. I have 4.15 on my laptop (which has a Via Nano processor) and no problems there. But I'd be happy to carry out any exploratory tests you like on my desktop, since that's the machine that misbehaves. Hello Hazel, I get the impression you have been send to me with the wrong info/background. I have no problem running things on bare metal, but it is the problem with LFS and having systemd on a VM. As explained in the thread 'Booting LFS with Systemd'. I know that Bruce uses bare metal too, but why not using VM's when one can continue developing without having to reboot into an incomplete system environment. Also, if one has multiple systems to spare, bare metal can be a way. If not, VM's are a welcome solution. So, I think that I am chasing the wrong ghost and have a talk with the systemd developers instead. Despite the lack of interest for using VM's, I shall share any positive result with the LFS list. Discussing closed. Regards Frans. -- 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] Kernel bug involving physical to virtual remapping
On Thu, 19 Jul 2018 13:54:19 +0200 Frans de Boer wrote: > >>> However a git bisection showed that this is actually a memory management > >>> issue. The kernel commit that caused the problem is : > >>> [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove > >>> phys_to_virt() usage in ioremap(). > >>> > >>> Reintroducing the code: > >>> "if (is_ISA_range(phys_addr, last_addr)) > >>> return (__force void __iomem *)phys_to_virt(phys_addr);" > >>> makes the system bootable again. I have also tested this on a 4.15 kernel > >>> and it works there too. > >>> > > Hello Hazel, > > What you inserted is already available as from the 4.13.0 release. But I > can't compile 4.13. anymore because I now have gcc 8.1 instead of the > former 7 series. > > I continue my search and go for 4.14 where the check is removed. But i > guess that will fail too and this is no solution to my problem with > systemd freezing just after it found out that it is on a VM. > > --- Frans > > -- Yes, I can boot 4.13 kernels without any problems. But I wanted an LTS kernel that can keep up with the newest exploits (especially meltdown) and the next LTS after 4.9 is 4.14. I'm using bare iron, not a VM (and no systemd!), but it's rather old hardware. The processor is an Intel Core Duo. I can send you the cpuinfo if you want it. I suspect that if you did build 4.14, it would behave properly; after all, it does for most people. I have 4.15 on my laptop (which has a Via Nano processor) and no problems there. But I'd be happy to carry out any exploratory tests you like on my desktop, since that's the machine that misbehaves. -- 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
Re: [lfs-support] Kernel bug involving physical to virtual remapping
On 07/17/2018 03:15 PM, Hazel Russman wrote: On Tue, 17 Jul 2018 14:06:09 +0200 Frans de Boer wrote: On 07/14/2018 06:56 PM, Hazel Russman wrote: Gentlemen, I was given your contact details by Michael Shell, who has been helping me to troubleshoot this problem via the Linux From Scratch support list. For some time now I have been unable to boot recent kernels (4.14 or later) on my rather elderly desktop machine. The kernel panics during boot and the problem seems (superficially) to lie in the acpi driver. At least that is where the visible error messages come from. Booting with "acpi=off" works but is hardly an ideal solution. However a git bisection showed that this is actually a memory management issue. The kernel commit that caused the problem is : [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap(). Reintroducing the code: "if (is_ISA_range(phys_addr, last_addr)) return (__force void __iomem *)phys_to_virt(phys_addr);" makes the system bootable again. I have also tested this on a 4.15 kernel and it works there too. If you want me to carry out any further tests, I would be happy to oblige, but do please bear in mind that I am not an expert, so you will need to give fairly basic instructions. Hazel Russman Hazel, sorry but where should I remove phys_to_virt()? If I delete the complete if statement in the iounmap function, and replace that with the above code, i get compile errors. btw: acpi=off does not solve the issue too. Frans. -- No, it's the other way around. phys_to_virt() doesn't get removed; it gets inserted/reinserted just above the warning not to let normal RAM be remapped. This is code that was in the kernel before but someone took it out and that was what was causing me all that trouble. Here's the patch that I made: --- linux-4.13.0-rc1/arch/x86/mm/ioremap.c 2018-07-14 13:27:21.0 +0100 +++ linux-4.13.0-rc1.new/arch/x86/mm/ioremap.c 2018-07-14 16:00:14.071456762 +0100 @@ -103,7 +103,12 @@ (unsigned long long)phys_addr); WARN_ON_ONCE(1); return NULL; - } + } +/* Don't remap the low PCI/ISA area, it's always mapped.. +*/ + if (is_ISA_range(phys_addr, last_addr)) + return (__force void __iomem *)phys_to_virt(phys_addr); + /* * Don't allow anybody to remap normal RAM that we're using.. Sorry if this is a bit inexpert. I'm not used to creating patches and I did the actual edit by hand. I didn't touch anything else in that file. And it built normally with just that edit. Hello Hazel, What you inserted is already available as from the 4.13.0 release. But I can't compile 4.13. anymore because I now have gcc 8.1 instead of the former 7 series. I continue my search and go for 4.14 where the check is removed. But i guess that will fail too and this is no solution to my problem with systemd freezing just after it found out that it is on a VM. --- Frans -- 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
