Re: Upcoming Fedora kernel workflow changes
On 3/12/20 10:57 AM, Bastien Nocera wrote: - Original Message - The git tags are still signed by Linus. Does that cover your concerns? Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas. If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning. I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Have the 5.6 kernels dropped support for user input of entropy to the kernel?
On 2/24/20 1:24 PM, stan wrote: On Mon, 24 Feb 2020 17:29:07 +0100 Florian Weimer wrote: * stan: I built my first 5.6 custom kernel from the src.rpm yesterday in F31. And my patch to enable the use of a daemon I run to gather entropy from an rtl2832 (atmospheric) and put it into the kernel to keep the entropy pool full failed. This has happened in the past, that's why I have to patch, but the interface was never removed before. If it has been removed, can you point me to the discussion that led to that decision. I haven't done a complete analysis yet, the changes are pretty extensive. But the marker that the callback used to trigger the daemon has been removed. - .procname = "read_wakeup_threshold", - .data = _read_wakeup_bits, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = proc_dointvec_minmax, - .extra1 = _read_thresh, - .extra2 = _read_thresh, - }, This seems to have been replaced with hard-coded functions that read from specific sources (mouse, key strokes, hard drives, etc.) to gather system entropy. I wanted to see the rationale for the changes before I invested the time to see how it is all working together now, and how to insert my code without disrupting everything. This is a pretty critical part of the kernel (I would say vital), so I like to be sure that everything is making sense, and that it was vetted properly. I'm not an expert in this, so I could be reading it all wrong, but I want to investigate before I decide. The developer description of the changes and the reasoning behind them would be the place to start. Maybe the decision was that no one was using this interface, so it didn't make sense to keep it around (more code to rot, and threaten security). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/random.c?id=c95ea0c69ffda19381c116db2be23c7e654dac98 And the thread if you'd like to read https://lore.kernel.org/linux-api/cover.1577088521.git.l...@kernel.org/ ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
stepping down as fedora kernel maintainer
After quite a bit of soul searching, I've decided to step down from being a full-time Fedora kernel maintainer and move on to other things. Having come in as a relative outsider to the Fedora community almost 5 years ago, I deeply appreciate you all welcoming me with open arms. I still expect to be around to some degree but probably not as directly involved on a day-to-day basis. I would also like to thank jcline, jforbes and jwboyer for being amazing supportive teammates during my tenure. Thank you everyone for being patient as I attempted to fix more bugs than I introduced in the kernel. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: NO_HZ_IDLE on x86_64?
On 12/12/19 9:10 AM, Justin Forbes wrote: On Thu, Dec 12, 2019 at 3:48 AM Peter Robinson wrote: Hey All. In digging through some pieces around CPU_IDLE I noticed that NO_HZ_IDLE is explicitly disabled on x86_64 but not on all other architectures. Doing a "git log --follow configs/fedora/generic/x86/x86_64/CONFIG_NO_HZ_IDLE" it goes all the way back to 2016 when we changed the way the configs were handled. The upstream kernel's opinion [1] on it is "Most of the time you want to say Y here." so I'm wondering if there's a reason why we're difference on x86_64 or is it just lost in the winds of time? Peter PS was digging around CPU_IDLE_GOV_TEO for those curious. [1] https://cateee.net/lkddb/web-lkddb/NO_HZ_IDLE.html commit 3836faf6e68495fc70316229a3540506f7ce4c98 Author: Kyle McMartin Date: Wed Sep 17 13:10:12 2014 -0500 re-enable RCU_FAST_NO_HZ, enable NO_HZ_FULL on x86_64 - I also like to live dangerously. (Re-enable RCU_FAST_NO_HZ which has been off since April 2012. Also enable NO_HZ_FULL on x86_64.) Yeah I wouldn't quite say it's been "lost" but the real question is if it still makes sense. I don't have a strong opinion without data. Prarit, any opinion here? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: bringing back tools/perf into the kernel.spec file
On 11/8/19 11:32 AM, Laura Abbott wrote: Hi, Continuing on the theme of bringing things into Fedora, one other task I'm currently looking at is bringing the tools building back into the kernel.spec file for testing purposes only. Fedora split the kernel-tools and userspace packages out into a separate repository at least two years ago. From my perspective, this has been a success since we've been able to avoid issues with tools breaking kernel builds and let the userspace tools build in a more standard way since we don't need to do all the weird hacks to build the kernel. This change has encountered some resistance downstream since their workflow involves more process and splitting out into a separate repository could potentially have more impact. I'm still working to resolve this but as an intermediate step I'd like to bring back the build commands into the kernel.spec file. We'd still keep building the tools in a separate repository but this would at least let us work towards the goal of having a common tree. If we decide to go with the split downstream, we will remove it again. If we decide to not go with the split downstream, I expect Fedora will want to follow and we'll need to bring the code back in anyway. I don't know exactly when I'll be getting to this but this is just a heads up that this work will be coming. Thanks, Laura I ended up pushing this work today. As always, let me know if you see any issues. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: cleaning out some scripts from the kernel dist-git
On 11/22/19 4:27 PM, Laura Abbott wrote: The kernel dist-git has a number of scripts in the script directory. Some are used for regular work (stable-update.sh, rawhide-rc.sh, rawhide-snapshot.sh) but some of them haven't been used in a long time. I'd like to delete the following: - check-patchlist.sh - check-TODO.sh - combine.sh - grab-logs.sh - newpatch.sh Does anyone have an issue with removing these scripts? Thanks, Laura I ended up removing this along with a few more files that were floating around. As always, let me know if I removed something I shouldn't have. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Upstream fix for Raven Ridge
On 11/24/19 12:38 AM, Luya Tshimbalanga wrote: Hello team, Upstream provided several bug fix related to AMD APU Raven Ridge which hangs when using some applications like radeontop to read its interface [1]. Test model was 2018 HP Envy x360 Ryzen 2500U (device id 15dd): drm/amdgpu: disable gfxoff when using register read interface -- https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.4=c57040d333c6729ce99c2cb95061045ff84c89ea Original Raven Ridge (15d8) becomes unstable when using gfxoff. The test model Ryzen 2500U with id 15dd and above is unaffected drm/amdgpu: disable gfxoff on original raven - https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.4=941a0a7945c39f36a16634bc65c2649a1b94eee1 Revert "drm/amd/display: enable S/G for RAVEN chip" https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.4=a0184d71163aab258d73141a8839675d6cbdcf40 It will be nice to backport for the current kernel 5.3. Thanks in advance. Do the fixes apply cleanly to 5.3? I saw they are tagged for stable so it may just be easier to wait until they show up there. Given the time frame, it may end up about the same as waiting for 5.4 anyway. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building custom kernel using rpmbuild method fails with config conflicts between kernel-local and x86_64.config
On 11/25/19 11:02 AM, stan wrote: On Mon, 25 Nov 2019 08:15:46 -0500 Laura Abbott wrote: The process_configs.sh checks are designed to catch values changing unexpecedtly the message override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state This indicates that some value set are now changed. This looks like process_configs doing its job and not an actual error. It's also a little hard to tell without seeing the full build log and what changes you are actually making. I see two options: Then this makes the kernel-local obsolete, because the point of having a kernel-local file is to change config options from the default state. I'm making extensive changes to the config file to customize it for my system exclusively. File systems I don't use are gone. Graphics devices I don't use are gone. Ditto audio devices. Ditto network cards. etc. When I use the custom config file with make oldconfig, there are no complaints. I notice that this is a warning rather than an actual error, even though the configcheck is treating it as an error. Could configcheck be changed to allow warnings to pass? Is there already a switch I can pass to configcheck that does so? Your changes to kernel-local should still be going through when you build, if not that is absolutely a bug that needs to get fixed. The message "override" is coming from the kernel tree not the Fedora kernel tree What process_configs.sh is doing is checking to make sure all of the settings you have given will not get changed. Kconfig will silently switch the settings of options if you set things incorrectly, (switching from =y to =m or just turning options off completely) which can be confusing. The goal of these checks is to be pedantic and make sure all the values are set to what you expect. We actually want to treat all warnings as errors because even if Kconfig thinks this is a warning, the actual issue is that CONFIG_PSTORE_LZ4HC_COMPRESS_DEFAULT may not be what you expect. 1) Update the set of options you are setting to set all appropriate dependencies I tried this by setting various values in both kernel-local and in the rpmbuild/SOURCES/kernel*.config file. No dice. Next kernel I build, I'll do it in make menuconfig to see if it makes a difference. 2) Turn off the checking by building --without configchecks It looks like this is what I'll have to do, though I don't like bypassing consistency checks. Heh, my kernels have been building and running fine for years without this, so maybe it's OK. :-) If the options you've been using are working, it's probably fine to turn the checks. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Building custom kernel using rpmbuild method fails with config conflicts between kernel-local and x86_64.config
On 11/24/19 1:00 PM, stan wrote: I use the src.rpm from rawhide kernels to build a kernel custom configured for my hardware in F31, and with a local patch, using the old rpmbuild method. For rc5 this worked, when I tried rc7 it didn't. And rc8 is failing with the same error. The error message is this: scripts/gen_compile_commands.py: updating Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-aarch64.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl-lpae.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-i686.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-ppc64le.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-s390x.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-x86_64.config ... Found misconfigured config items, please set them to an appropriate value /home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-x86_64.config.orig:4359:warning: override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state So, kernel-local is not overriding the default kernel configuration. I think it should; so whatever is checking the configuration consistency has a bug, I think. The process_configs.sh checks are designed to catch values changing unexpecedtly the message override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state This indicates that some value set are now changed. This looks like process_configs doing its job and not an actual error. It's also a little hard to tell without seeing the full build log and what changes you are actually making. I see two options: 1) Update the set of options you are setting to set all appropriate dependencies 2) Turn off the checking by building --without configchecks ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Even though I have nobuild set for architectures, rpmbuild is processing their configs. Is this correct?
On 11/24/19 1:10 PM, stan wrote:
I build a custom local kernel using the rawhide kernel src.rpm here on
F31. I change the spec file to build only for my arch, x86_64, and not
to build cross headers. But I notice that the config files for all the
nobuild archs are still processed. This seems like an error to me. Is
it?
What you are suggesting is an optimization. There's no technical issue
with running the checks on nobuild arches. If you have a patch to
not run the checks we can see about incorporating it.
In the kernel.spec file.
%define nobuildarches i386 i686 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
Output from rpmbuild -bb kernel.spec.
Processing
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-aarch64.config
... done
Processing
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl-lpae.config
... done
Processing
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-armv7hl.config
... done
Processing
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-i686.config
... done
Processing
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-ppc64le.config
... done
Processing
/home/stan/rpmbuild/BUILD/kernel-5.3.fc31/linux-5.4.0-0.rc8.git1.2.20191124.fc31.x86_64/configs/kernel-5.4.0-s390x.config
... done
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
cleaning out some scripts from the kernel dist-git
The kernel dist-git has a number of scripts in the script directory. Some are used for regular work (stable-update.sh, rawhide-rc.sh, rawhide-snapshot.sh) but some of them haven't been used in a long time. I'd like to delete the following: - check-patchlist.sh - check-TODO.sh - combine.sh - grab-logs.sh - newpatch.sh Does anyone have an issue with removing these scripts? Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Some more upcoming Fedora kernel changes
On 11/9/19 12:51 PM, Jóhann B. Guðmundsson wrote: Hi On 11/8/19 4:19 PM, Laura Abbott wrote: Hi, I'm looking to bring in another piece of downstream work into Fedora sometime next week. The short summary is that Fedora will be bringing in some files to build against a RHEL buildroot but Fedora will still be the same. If you change a board in a boat is it still the same boat?, If you change 10 boards in the boat is it still the same boat? 100 boards, thousands and in the when you have replaced it all? This looks like some backward move should not downstream be adopting Fedora not the other way around? What's the end game here in general and for the other components in the distribution. How long before we be entirely colonized by RHEL? I can't speak for other components but at least for the kernel this work is attempting to bridge the gap between RHEL and Fedora that's been around for too long and keeps growing. The goal is to help both RHEL and Fedora take fixes and feedback from each other. In an ideal world, yes downstream would be adopting Fedora and they do to a degree. The bigger issue is that changes happen in downstream and then don't get back into Fedora or only get added back as an afterthought. Some things we don't care about but some are actual bug fixes or fixes we might want. A good example is some downstream work for optimizing module compression in the spec file. This would help Fedora as well but it never got submitted. Even when RHEL does take what Fedora has done upstream, there have been issues with integration. A good example here is the split into kernel-core and kernel-modules. This worked fine technically but when RHEL picked it up there were some unexpected issues (documentation updates and I think a few scripts) To try and bridge this gap, we're working to get a src-git tree that works for both Fedora and RHEL. Even without the RHEL component, using a src-git tree for most of our daily work in Fedora would be a good thing. dist-git tends to trip up people who want to build their own kernels, especially if they are trying to build something non-trivial (e.g. an entire graphics branch). src-git is what most work is done in anyway. The RHEL kernel tree has been src-git based for a while so aligning on that makes sense. I realize my wording about "Fedora will still be the same" was vague. None of this work should meaningfully impact the kernel binaries generated by the Fedora build process. Kernel configuration options are still the same, external modules should still build. Parts of the build process may change and some extra files will be packaged. So yes some things _will_ change but it should be changes that are transparent to users or have minimal impact. If these changes cause regressions or are not acceptable for other reasons, I'm more than willing to fix or revert. One of the changes I brought in (weak-updates) caused a regression due to missing a fix in kmod. I reverted it for now and will be bringing it back when things are built. Part of "Fedora will still be the same" means that our current policies are still in place. Fedora still has the freedom to make changes how it wants. We can still turn on configuration options and make build changes as we need. We're not getting RHEL process (cheering from the background). What we'd like to change is to be more thoughtful about what will happen for RHEL down the road. This means that when Fedora sets configuration options and build changes, we'll be reviewing what we want to happen for RHEL as well. This doesn't mean RHEL gets to come in an dictate what happens but like other community members, RHEL can say "I see you are making change X. This impacts me in way Y. Can we consider change Z instead to lessen my impact?". Sometimes the answer is no, we're doing X and then RHEL gets to figure out how to workaround this. We already see this happening with things like configuration options (e.g. CONFIG_LIBNVDIMM https://bugzilla.redhat.com/show_bug.cgi?id=1696481) This freedom to make changes makes it easier for downstream as well since we can say "well Fedora has had CONFIG_BLAH on for months now and there have been no complaints". Fedora has an incredibly valuable community and the goal here is not to subvert it but make sure we can bring the benefits of that community back to downstream in the kernel. I also look forward to bringing more downstream kernel developers into Fedora so they can continue making changes and fixes directly in Fedora. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
bringing back tools/perf into the kernel.spec file
Hi, Continuing on the theme of bringing things into Fedora, one other task I'm currently looking at is bringing the tools building back into the kernel.spec file for testing purposes only. Fedora split the kernel-tools and userspace packages out into a separate repository at least two years ago. From my perspective, this has been a success since we've been able to avoid issues with tools breaking kernel builds and let the userspace tools build in a more standard way since we don't need to do all the weird hacks to build the kernel. This change has encountered some resistance downstream since their workflow involves more process and splitting out into a separate repository could potentially have more impact. I'm still working to resolve this but as an intermediate step I'd like to bring back the build commands into the kernel.spec file. We'd still keep building the tools in a separate repository but this would at least let us work towards the goal of having a common tree. If we decide to go with the split downstream, we will remove it again. If we decide to not go with the split downstream, I expect Fedora will want to follow and we'll need to bring the code back in anyway. I don't know exactly when I'll be getting to this but this is just a heads up that this work will be coming. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Some more upcoming Fedora kernel changes
Hi, I'm looking to bring in another piece of downstream work into Fedora sometime next week. The short summary is that Fedora will be bringing in some files to build against a RHEL buildroot but Fedora will still be the same. The longer answer: The goal with this work is bring Fedora and RHEL closer together and reduce work between the kernels. What we'd like to happen is that if we build against a Fedora buildroot we bring in the Fedora kernel configuration options and if we're building against a RHEL buildroot we bring in the RHEL kernel configuration. What this will do is let us test and verify configuration options easily in both RHEL and Fedora configuration without having to do redundant work. As a step towards this goal, I'll be bringing in some changes to the build scripts and moving some files around. You'll see a number of empty files brought in for the RHEL side just as a place holder. Part of this work also involves bringing in a few certificates for RHEL secureboot signing on powerpc and s390x. A big part of this goal is to let Fedora do most of its work from a src-git tree. The reason I'm working to bring parts of these commits in now is so when it comes time to start using the src-git tree the diff doesn't look so scary. Small changes help make sure things aren't getting broken (I've already found a few things that need to be fixed during the course of this work) My goal is to still keep Fedora stable and let Fedora be Fedora. I expect to keep tweaking the scripts to make the process easier. If you have feedback, feel free to let me know. You can see the tree with some other changes at https://pagure.io/fedora-kernel-labbott/tree/ark_sync_nov8 Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Enable CONFIG_DEBUG_INFO_BTF option
On 10/31/19 1:04 PM, Jiri Olsa wrote: hi, please consider attached patch for fedora kernel.spec. It enables CONFIG_DEBUG_INFO_BTF options to export BTF info in /sys/kernel/btf/vmlinux file. I tested on x86_64/s390x/aarach64/ppc servers and the file /sys/kernel/btf/vmlinux shows correctly. I checked the armv7hl arch build.log and it containes the pahole execution, so I assume it's generated properly. brew: https://koji.fedoraproject.org/koji/taskinfo?taskID=38681853 thanks, jirka I applied to rawhide. Thanks! --- Plus adding dwarves build dependency which is needed for BTF debuginfo to be generated and attached to kernel. Signed-off-by: Jiri Olsa --- configs/fedora/generic/CONFIG_DEBUG_INFO_BTF | 2 +- kernel-aarch64-debug.config | 2 +- kernel-aarch64.config| 2 +- kernel-armv7hl-debug.config | 2 +- kernel-armv7hl-lpae-debug.config | 2 +- kernel-armv7hl-lpae.config | 2 +- kernel-armv7hl.config| 2 +- kernel-i686-debug.config | 2 +- kernel-i686.config | 2 +- kernel-ppc64le-debug.config | 2 +- kernel-ppc64le.config| 2 +- kernel-s390x-debug.config| 2 +- kernel-s390x.config | 2 +- kernel-x86_64-debug.config | 2 +- kernel-x86_64.config | 2 +- kernel.spec | 3 ++- 16 files changed, 17 insertions(+), 16 deletions(-) diff --git a/configs/fedora/generic/CONFIG_DEBUG_INFO_BTF b/configs/fedora/generic/CONFIG_DEBUG_INFO_BTF index 3b5ac748f282..39227b4511af 100644 --- a/configs/fedora/generic/CONFIG_DEBUG_INFO_BTF +++ b/configs/fedora/generic/CONFIG_DEBUG_INFO_BTF @@ -1 +1 @@ -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y diff --git a/kernel-aarch64-debug.config b/kernel-aarch64-debug.config index 25917ed7c0a2..f40220d5c179 100644 --- a/kernel-aarch64-debug.config +++ b/kernel-aarch64-debug.config @@ -1289,7 +1289,7 @@ CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set diff --git a/kernel-aarch64.config b/kernel-aarch64.config index aaa967b286df..55f21773af73 100644 --- a/kernel-aarch64.config +++ b/kernel-aarch64.config @@ -1289,7 +1289,7 @@ CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set diff --git a/kernel-armv7hl-debug.config b/kernel-armv7hl-debug.config index d7d7a9f0a485..d54ce8ceb0e9 100644 --- a/kernel-armv7hl-debug.config +++ b/kernel-armv7hl-debug.config @@ -1279,7 +1279,7 @@ CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set diff --git a/kernel-armv7hl-lpae-debug.config b/kernel-armv7hl-lpae-debug.config index adda1dc48d4e..e049ebdddacf 100644 --- a/kernel-armv7hl-lpae-debug.config +++ b/kernel-armv7hl-lpae-debug.config @@ -1239,7 +1239,7 @@ CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set diff --git a/kernel-armv7hl-lpae.config b/kernel-armv7hl-lpae.config index b3788525651d..e572f653140f 100644 --- a/kernel-armv7hl-lpae.config +++ b/kernel-armv7hl-lpae.config @@ -1239,7 +1239,7 @@ CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set diff --git a/kernel-armv7hl.config b/kernel-armv7hl.config index 6e8ea6ec9783..e840ac68c870 100644 --- a/kernel-armv7hl.config +++ b/kernel-armv7hl.config @@ -1279,7 +1279,7 @@ CONFIG_DEBUG_FS=y # CONFIG_DEBUG_GPIO is not set CONFIG_DEBUG_HIGHMEM=y # CONFIG_DEBUG_HOTPLUG_CPU0 is not set -# CONFIG_DEBUG_INFO_BTF is not set +CONFIG_DEBUG_INFO_BTF=y # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set diff --git a/kernel-i686-debug.config b/kernel-i686-debug.config index 7ef076f3646f..bd6a05f5004f 100644 ---
New subpackages for Fedora
Some of the downstream work I'm looking to bring back into Fedora is some new subpackages. Here's a brief explanation of what I'd like to bring in: - several packages with 'kabi' in the name. These are related to downstream ABI guarantees. All of the packages would be turned off for Fedora. No Fedora isn't getting any ABI guarantee. - ipaclones: this is related to kpatch support. This package will be turned off in Fedora. There are no plans to get kpatch support for Fedora at this time but like any feature if it makes sense to support it in the future we would consider it. - selftests: These are some bpf related selftests. This package will be turned off in Fedora. - modules-internal: Downstream wanted to designate a set of modules that get turned on but are not officially shipped. The existing design ends up building this package unconditionally so I was planning on bringing this in for Fedora. There are currently 4 modules that are designated for this package at the moment: mac80211_hwsim netdevsim pktgen rocker None of these seem like things that would be used in a regular Fedora system so I think it would be safe to move them around. I don't expect any of these changes to be particularly controversial but please let me know if you see any issue with this. I have a tree at https://pagure.io/fedora-kernel-labbott/tree/align_fedora_oct25 with everything I'd like to bring in. I've been testing and everything seems to work fine. If there are no objections, I plan to bring this in sometime next week. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Talk from Flock up and a note on some upcoming work
If you didn't get a chance to see it, the talk I gave at Flock is up https://www.youtube.com/watch?v=kb2VS2_P6Ts . I'm linking this not for self-promotion but to give a heads up that some of the work related to this talk may start to land in Fedora. Some of the boring cleanup work will just go in but for some of the bigger pieces I'll post here to see if anyone has any objections. The goal is to eventually get a src-git that we can use as the daily driver for most of the Fedora work. When that switch over will actually happen depends on when we get a tree that meets Fedora needs. I don't want to regress Fedora or violate any packaging guidelines or make anything harder. If you have any questions, feel free to reach out to me. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Kernel 5.3 rebase plans
On 10/8/19 6:51 AM, Thorsten Leemhuis wrote: Laura Abbott schrieb am 16.09.19 um 16:24: Kernel 5.3 was released upstream yesterday Sept 16. Fedora will be following the same rebase schedule as with past kernels. This means F30 will be rebased to 5.3 first followed by F29 shortly thereafter. We typically wait until the 2nd or 3rd stable release to push a rebase. Based on past timings, I'd expect this to happen around mid-October. Would it be wise to tighten the "same rebase schedule as with past kernels" a little bit in the future (maybe by one week)? Just wondering, as it seems the fast few transitions from one version line to the next iirc all finished some time after a line went EOL. This time it looks worse: 5.2 is EOL as of today and 5.3 hasn't even hit updates-testing for the current Fedora release yet afics. And the stabilization copr wasn't much in action this time either. But whatever, I assume there are reasons why things are a little bit more bumpy this time, that not why I'm writing this mail. I was just wondering if a slightly faster schedule for the rebases might be a good idea in general. CU, knurd The timing is kind of tricky because once we push a rebase we are stuck with it. That means if key CVEs come in we have to work to get them on the next kernel. It's also usually good to wait for the next merge window to close so any really obvious fixes have a chance to make it to a .1 or .2 stable kernels. We also wanted to wait for the kernel test week to complete, which happened last week. Based on all that's, that's how we got to the date today. We might be able to push a few of these things next time but it's also very hard to tell since sometimes the early releases are mostly unusable. As for the stabilization copr, part of that was my fault for not being diligent there since I was traveling the last two weeks. I did the initial test build to make sure my f30 rebase was okay (didn't miss any pieces) and then mostly left it alone since I figured it would be just as easy to run the f31 kernel which was already on 5.3. I do appreciate the feedback. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Support buildid in kernel-headers
On 9/26/19 11:44 AM, Paul Moore wrote:
On Wed, Aug 21, 2019 at 3:30 PM Paul Moore wrote:
On Wed, 2019-08-21 at 14:48 -0400, Josh Boyer wrote:
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore
wrote:
Hello,
Last year there was a change to how the kernel-headers package is
built, and unfortunately that change made it so that changes to the
kernel's buildid variable do not carryover to the the kernel-
header's
build. While I recognize that this is problem that only affects a
small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
Sorry about that, a little birdie warned me against sending patches inline to
this list (something about whitespace
mangling), but the patch is pasted below. Also, in the case there are issues,
I put a copy of the patch here:
Any thoughts on fixing this problem?
Thanks for the reminder this completely slipped my mind. I put this into
rawhide and we can test it for a few releases of that. If it works, we can
also bring it into the stable releases.
--- scripts/create_headers_tarball.sh.orig 2019-05-06 17:50:49.533846042
-0400
+++ scripts/create_headers_tarball.sh 2019-05-06 17:57:54.259359305 -0400
@@ -26,13 +26,14 @@ BASE=`grep "%define base_sublevel" kerne
STABLE=`grep "%define stable_update" kernel.spec| cut -d ' ' -f 3`
RC=`grep "%global rcrev" kernel.spec| cut -d ' ' -f 3`
GITREV=`grep "%define gitrev" kernel.spec| cut -d ' ' -f 3`
+BUILDID=`grep "^%define buildid" kernel.spec| cut -d ' ' -f 3`
if [ $RELEASED -eq 0 ]; then
cd kernel-$MAJORVER.$BASE.fc??
NEWBASE=$(($BASE+1))
- KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE
- cd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE.fc*/
+ KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDID
+ cd
linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDID.fc*/
else
- cd
kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE.fc*/
+ cd
kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE$BUILDID.fc*/
KVER=$MAJORVER.$BASE.$STABLE-$BASERELEASE
fi
@@ -64,6 +65,7 @@ BASERELEASE=$(($BASERELEASE-1))
BASERELEASE=$BASERELEASE perl -p -i -e 's|%global baserelease.*|%global
baserelease $ENV{'BASERELEASE'}|' kernel-headers.spec
if [ $RELEASED -eq 0 ]; then
+ [ -n $BUILDID ] && sed -i -e 's/^# define buildid .local/%define
buildid '$BUILDID'/' kernel-headers.spec
RC=$RC perl -p -i -e 's|%global rcrev.*|%global rcrev $ENV{'RC'}|'
kernel-headers.spec
GITREV=$GITREV perl -p -i -e 's|%define gitrev.*|%define gitrev
$ENV{'GITREV'}|' kernel-headers.spec
rpmdev-bumpspec -c "Linux v$MAJORVER.$NEWBASE-rc$RC.git$GITREV"
kernel-headers.spec
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Kernel 5.3 rebase plans
On 9/17/19 6:40 AM, Sérgio Basto wrote: Hi, Shouldn't we have kernel updates for F31 in updates-testing ? Yes, I completely forgot to file them for the -rc updates. I did file for the final 5.3.0 and I'll be requesting that for stable (although I expect it won't go through until freeze is over) On Mon, 2019-09-16 at 10:24 -0400, Laura Abbott wrote: Hi, Kernel 5.3 was released upstream yesterday Sept 16. Fedora will be following the same rebase schedule as with past kernels. This means F30 will be rebased to 5.3 first followed by F29 shortly thereafter. We typically wait until the 2nd or 3rd stable release to push a rebase. Based on past timings, I'd expect this to happen around mid-October. You can find test builds in the kernel- stabilization COPR. Note that F31 will be shipping with 5.3 so you can always test those kernels too. Please also keep an eye out for the 5.3 test day which will happen before the rebase as well. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/9] Clean up some old patches post F31
On 8/15/19 8:57 PM, Laura Abbott wrote: I'd like to drop a bunch of patches Fedora has been carrying since forever. Most of these are fairly minor tweaks most people forgot we had and nobody cares about. My motivation is both in the spirit of cleaning up and also to better align Fedora + RHEL (I had a talk about this at Flock, video should be up soon). If someone wants to make an effort at upstreaming any of these, feel free to do so but I really think most of these are cruft. Thanks, Laura Laura Abbott (9): Drop namespaces config tweak Drop cpumask auto select patch Drop scsi warning patch Remove ancient ath9k workaround Drop old lis3 patch Remove some old modalias adjustments Remove old keyboard logging patch Remove patch for GCC VTA Remove crash driver Kbuild-Add-an-option-to-enable-GCC-VTA.patch | 94 --- ath9k-rx-dma-stop-check.patch | 38 - .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- crash-driver.patch| 722 -- die-floppy-die.patch | 29 - input-kill-stupid-messages.patch | 30 - kernel.spec | 20 - ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 - lis3-improve-handling-of-null-rate.patch | 75 -- namespaces-no-expert.patch| 27 - no-pcspkr-modalias.patch | 22 - ...validate_disk-prevent-NULL-ptr-deref.patch | 39 - 12 files changed, 1 insertion(+), 1131 deletions(-) delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch delete mode 100644 ath9k-rx-dma-stop-check.patch delete mode 100644 crash-driver.patch delete mode 100644 die-floppy-die.patch delete mode 100644 input-kill-stupid-messages.patch delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch delete mode 100644 lis3-improve-handling-of-null-rate.patch delete mode 100644 namespaces-no-expert.patch delete mode 100644 no-pcspkr-modalias.patch delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch Given there were no major objections I cleaned up the few comments and pushed the patches to rawhide. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Kernel 5.3 rebase plans
Hi, Kernel 5.3 was released upstream yesterday Sept 16. Fedora will be following the same rebase schedule as with past kernels. This means F30 will be rebased to 5.3 first followed by F29 shortly thereafter. We typically wait until the 2nd or 3rd stable release to push a rebase. Based on past timings, I'd expect this to happen around mid-October. You can find test builds in the kernel-stabilization COPR. Note that F31 will be shipping with 5.3 so you can always test those kernels too. Please also keep an eye out for the 5.3 test day which will happen before the rebase as well. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel 5.3.0-0.rc7.git1.1 src.rpm fails at the patching stage, on the first patch.
On 9/8/19 5:49 PM, stan wrote:
Hi,
I build a custom kernel with rpmbuild. The latest kernel,
5.3.0-0.rc7.git1.1, fails when it patches. I noticed that the last
successful spec file had the lines shown below, while the latest
doesn't. However, adding them back does not enable patches, the build
still fails immediately when it tries to patch, on the first patch.
"""
Applying: lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
dependency Patch failed at 0001 lib/cpumask: Make CPUMASK_OFFSTACK
usable without debug dependency When you have resolved this problem,
run "git am --continue". If you prefer to skip this patch, run "git am
--skip" instead. To restore the original branch and stop patching, run
"git am --abort".
error: lib/Kconfig: does not exist in index
hint: Use 'git am --show-current-patch' to see the failed patch
"""
This looks more like the patch is being applied in the wrong directory
if it can't find lib/Kconfig. Were there errors further up in the build
log?
https://kojipkgs.fedoraproject.org//packages/kernel/5.3.0/0.rc7.git1.1.fc32/data/logs/x86_64/build.log
this is the official build log
If I comment out the first patch, the second patch fails with the same
messages, except the directory missing from the index is the directory
where the second patch applies. What has changed in the kernel build
process, and how do I fix the spec file so it works?
Gone from latest spec:
"""
< patch_command='patch -p1 -F1 -s'
< ApplyPatch()
< {
< local patch=$1
< shift
< if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
< exit 1
< fi
< if ! grep -E "^Patch[0-9]+: $patch\$"
%{_specdir}/${RPM_PACKAGE_NAME%{?variant}}.spec ; then < if
[ "${patch:0:8}" != "patch-5." ] ; then < echo "ERROR: Patch
$patch not listed as a source patch in specfile" < exit 1
< fi
< fi 2>/dev/null
< case "$patch" in
< *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command
${1+"$@"} ;; < *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" |
$patch_command ${1+"$@"} ;; < *.xz) unxz<
"$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; < *)
$patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;; < esac
< }
<
< # don't apply patch if it's empty
< ApplyOptionalPatch()
< {
< local patch=$1
< shift
< if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
< exit 1
< fi
< local C=$(wc -l $RPM_SOURCE_DIR/$patch | awk '{print $1}')
< if [ "$C" -gt 9 ]; then
< ApplyPatch $patch ${1+"$@"}
< fi
< }
<
"""
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] enable driver for accessing HMC CD/DVD drive
On 9/4/19 3:54 PM, Dan Horák wrote: --- configs/fedora/generic/s390x/CONFIG_HMC_DRV | 1 + kernel-s390x-debug.config | 2 +- kernel-s390x.config | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) create mode 100644 configs/fedora/generic/s390x/CONFIG_HMC_DRV diff --git a/configs/fedora/generic/s390x/CONFIG_HMC_DRV b/configs/fedora/generic/s390x/CONFIG_HMC_DRV new file mode 100644 index 0..fc68dc34b --- /dev/null +++ b/configs/fedora/generic/s390x/CONFIG_HMC_DRV @@ -0,0 +1 @@ +CONFIG_HMC_DRV=m diff --git a/kernel-s390x-debug.config b/kernel-s390x-debug.config index 61d06297a..eb0cd3526 100644 --- a/kernel-s390x-debug.config +++ b/kernel-s390x-debug.config @@ -1758,7 +1758,7 @@ CONFIG_HIGH_RES_TIMERS=y # CONFIG_HIPPI is not set CONFIG_HIST_TRIGGERS=y # CONFIG_HMC6352 is not set -# CONFIG_HMC_DRV is not set +CONFIG_HMC_DRV=m CONFIG_HOLTEK_FF=y # CONFIG_HOSTAP is not set CONFIG_HOTPLUG_CPU=y diff --git a/kernel-s390x.config b/kernel-s390x.config index 696652ba9..0d3be1ed5 100644 --- a/kernel-s390x.config +++ b/kernel-s390x.config @@ -1741,7 +1741,7 @@ CONFIG_HIGH_RES_TIMERS=y # CONFIG_HIPPI is not set CONFIG_HIST_TRIGGERS=y # CONFIG_HMC6352 is not set -# CONFIG_HMC_DRV is not set +CONFIG_HMC_DRV=m CONFIG_HOLTEK_FF=y # CONFIG_HOSTAP is not set CONFIG_HOTPLUG_CPU=y Thanks, applied to rawhide. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On 8/28/19 1:58 PM, Josef Bacik wrote: On Tue, Aug 27, 2019 at 07:53:20AM -0400, Laura Abbott wrote: On 8/26/19 11:39 PM, Neal Gompa wrote: On Mon, Aug 26, 2019 at 11:16 AM Laura Abbott wrote: On 8/23/19 9:00 PM, Chris Murphy wrote: On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson wrote: So, there was recently a Thing where btrfs installs were broken, and this got accepted as a release blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1733388 Summary: This bug was introduced and discovered in linux-next, it started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug resulted in a somewhat transient deadlock which caused installs to hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 deletions (1/2 the insertions are comments). How remarkable or interesting is this bug? And in particular, exactly how much faster should it have been fixed in order to avoid worrying about it being a blocker bug? 7/25 14:27 utc bug patch was submitted to linux-btrfs@ 7/25 22:33 utc bug was first reported in Fedora bugzilla 7/26 19:20 utc I confirmed upstream's patch related to this bug with upstream and updated the Fedora bug 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug So in the context of status quo, where Btrfs is presented as an option in the installer and if there are bugs they Beta blocking, how could or should this have been fixed sooner? What about the handling should have been different? That's a fair question. This bug actually represents how this _should_ work. The concern is that in the past we haven't seen a lot engagement in the past. Maybe today that has changed as demonstrated by this thread. I'm still concerned about having this be a blocker vs. just keeping it as an option, simply because a blocker stops the entire release and it can be a last minute scramble to get things fixed. This was the ideal case for a blocker bugs and I'm skeptical about all bugs going this well. If we had a few more people who were willing to be on the btrfs alias and do the work for blocker bugs it would be a much stronger case. Out of curiosity, how many such issues have we had in the past 2 years? I personally can't recall any monumental occasions where people were scrambling over *Btrfs* in Fedora. If anything, we continue to inherit the work that SUSE and Facebook are doing upstream as part of us continually updating our kernels, which I'm grateful for. And in the instances where we've had such issues, has anyone reached out to btrfs folks in Fedora? Chris and myself are the current ones, but there have been others in the past. Both of us are subscribed to the linux-btrfs mailing list, and Chris has a decent rapport with most of the btrfs developers. What more do you want? Actual btrfs developers in Fedora? We don't have any for the majority of filesystems Fedora supports, only XFS. Is there some kind of problem with communicating with the upstream kernel developers about Fedora bugs that I'm not aware of? Again, it's about length of overall development. ext and XFS have a much longer history in general which is something that's important for file system stability in general. It's also a bit of a catch-22 where the rate of btrfs use in Fedora is so low we don't actually see issues. I note here that ext2 and ext3 are offered as file systems in Custom/Advanced partitioning and in this sense have parity with Btrfs. If this same bug occurred in ext2 or ext3 would or should that cause discussion to drop them from the installer, even if the bug were fixed within 24 hours of discovery and patch? What about vfat? That's literally the only truly required filesystem that must work, for the most commonly supported hardware so it can't be dropped, we'd just be stuck until it got fixed. That work would have to be done upstream, yes? I don't think that's really a fair comparison. Just because options are presented doesn't mean all of them are equal. ext2/ext3 and vfat have been in development for much longer than btrfs and length of development is something that's particularly important for file system stability from talking with file system developers. It's not impossible for there to be bugs in ext4 for example (we've certainly seen them before) but btrfs is only now gaining overall stability and we're still more likely to see bugs, especially with custom setups where people are likely to find edge cases. Nope. We can totally use this because LVM has not existed as long (we use LVM + filesystem by default, not plain partitions), and we still encounter quirks with things like thinp LVM combined with these filesystems. OverlayFS is mostly hot garbage (kernel people know it, container people know it, filesystem people know it, etc.), and yet we continue to try to use it in more places. Stratis is in an odd state of limbo now, since its main developer and advocate left Red Hat
Re: Simple Firmware Interface being deprecated
On 8/27/19 8:46 AM, Hans de Goede wrote: Hi, On 27-08-19 09:14, Peter Robinson wrote: On Mon, Aug 26, 2019 at 9:27 PM Laura Abbott wrote: https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulw...@gmail.com/ menuconfig SFI bool "SFI (Simple Firmware Interface) Support" ---help--- The Simple Firmware Interface (SFI) provides a lightweight method for platform firmware to pass information to the operating system via static tables in memory. Kernel SFI support is required to boot on SFI-only platforms. Currently, all SFI-only platforms are based on the 2nd generation Intel Atom processor platform, code-named Moorestown. For more information, see http://simplefirmware.org Say 'Y' here to enable the kernel to boot on SFI-only platforms. I have no idea how common this is but Fedora does enable this option. If you are interested in salvaging this, please speak up! Grepping config and the kernel it seems Moorestown is the Intel MID platform and we explicitly disable X86_INTEL_MID so I'm not sure it's a problem. Yeah I'm pretty sure this is just for the Intel X86 "phone" SoCs which never went anywhere. As you know I've spend a lot of (spare) time on improving support for Intel Atom based hw (mainly Bay Trail and Cherry Trail tablets) and even I don't care for the phone chips, for one exactly because of SFI, instead of coming with EFI these phones come with some frankenstein firmware AFAIK, I never even bothered getting one to try and make it boot mainline ... TL;DR: I do not think this will missed, actually I think it should be fine to disable it in the Fedora kernels right away. I've just disabled it for the builds which I do from my personal kernel tree. It does not seem to affect any other Kconfig options. Regards, Hans Ah the x86 phone. Such dreams. Thanks for the confirmation Peter and Hans. I'm planning on dropping a bunch of stuff after 5.3 releases so I'll turn it off in rawhide there. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Simple Firmware Interface being deprecated
https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulw...@gmail.com/ menuconfig SFI bool "SFI (Simple Firmware Interface) Support" ---help--- The Simple Firmware Interface (SFI) provides a lightweight method for platform firmware to pass information to the operating system via static tables in memory. Kernel SFI support is required to boot on SFI-only platforms. Currently, all SFI-only platforms are based on the 2nd generation Intel Atom processor platform, code-named Moorestown. For more information, see http://simplefirmware.org Say 'Y' here to enable the kernel to boot on SFI-only platforms. I have no idea how common this is but Fedora does enable this option. If you are interested in salvaging this, please speak up! Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On 8/23/19 9:00 PM, Chris Murphy wrote: On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson wrote: So, there was recently a Thing where btrfs installs were broken, and this got accepted as a release blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1733388 Summary: This bug was introduced and discovered in linux-next, it started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug resulted in a somewhat transient deadlock which caused installs to hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 deletions (1/2 the insertions are comments). How remarkable or interesting is this bug? And in particular, exactly how much faster should it have been fixed in order to avoid worrying about it being a blocker bug? 7/25 14:27 utc bug patch was submitted to linux-btrfs@ 7/25 22:33 utc bug was first reported in Fedora bugzilla 7/26 19:20 utc I confirmed upstream's patch related to this bug with upstream and updated the Fedora bug 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug So in the context of status quo, where Btrfs is presented as an option in the installer and if there are bugs they Beta blocking, how could or should this have been fixed sooner? What about the handling should have been different? That's a fair question. This bug actually represents how this _should_ work. The concern is that in the past we haven't seen a lot engagement in the past. Maybe today that has changed as demonstrated by this thread. I'm still concerned about having this be a blocker vs. just keeping it as an option, simply because a blocker stops the entire release and it can be a last minute scramble to get things fixed. This was the ideal case for a blocker bugs and I'm skeptical about all bugs going this well. If we had a few more people who were willing to be on the btrfs alias and do the work for blocker bugs it would be a much stronger case. I note here that ext2 and ext3 are offered as file systems in Custom/Advanced partitioning and in this sense have parity with Btrfs. If this same bug occurred in ext2 or ext3 would or should that cause discussion to drop them from the installer, even if the bug were fixed within 24 hours of discovery and patch? What about vfat? That's literally the only truly required filesystem that must work, for the most commonly supported hardware so it can't be dropped, we'd just be stuck until it got fixed. That work would have to be done upstream, yes? I don't think that's really a fair comparison. Just because options are presented doesn't mean all of them are equal. ext2/ext3 and vfat have been in development for much longer than btrfs and length of development is something that's particularly important for file system stability from talking with file system developers. It's not impossible for there to be bugs in ext4 for example (we've certainly seen them before) but btrfs is only now gaining overall stability and we're still more likely to see bugs, especially with custom setups where people are likely to find edge cases. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On 8/23/19 1:10 PM, Neal Gompa wrote: On Fri, Aug 23, 2019 at 3:48 PM Justin Forbes wrote: On Fri, Aug 23, 2019 at 2:17 PM Adam Williamson wrote: Hey folks! So, there was recently a Thing where btrfs installs were broken, and this got accepted as a release blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1733388 The bug was fixed, so that's fine, but along the way, Laura said this: "I'm strongly against anything with btrfs being a blocker. If that's in the criteria I think we should see about removing btrfs simply because we don't have the resources to actually deal with btrfs besides reporting bugs upstream." and Justin followed up with: "Agreed, btrfs has been a gamble pretty much always. See previous discussion around proposals to make btrfs default. Ext4 and xfs should be the only release blocking." So, that's the whole kernel team 'strongly against' blocking on btrfs. Which means we should talk about not doing that any more! This is a bit complicated, though, because of how the Final criteria are phrased. Basic does not include btrfs at all, and Beta includes a laundry list we can just remove btrfs from: "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: * Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions * Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions ..." so those two are easy. However, the Final criterion is not laundry list-style. The relevant Final criterion is this: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." with a somewhat apologetic explanatory footnote: "Wait, what? Yeah, we know. This is a huge catch-all criterion and it's subject to a lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is that you should be able to do anything sane that the Installation Destination spoke attempts to let you do, without the installer exploding or failing. We are trying to write more specific criteria covering this area, but it's not easy. Patches welcome, as the kids say..." so as the footnote says, the rule is basically "if the installer lets you do it, it ought to work". It seems a bit awkward to craft an exception for btrfs from that. I mean, technically it's easy: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration, except btrfs." but that's odd. Why is btrfs, alone, an exception? It kinda goes against the fundamental idea of the criterion: that we stand behind everything the UI offers. All of this, the criteria, and the UI support for btrfs are from the many years old proposal to make btrfs the default filesystem. In the beginning, it was not ready, but did show promise. This proposal came up for several releases in a row, and at the end of it, even the upstream developers recommended against it. At this point, it is safe to say that btrfs will not be the default. Since that time, things have not gotten better. Yes, there is active btrfs development upstream. It is fairly narrowly focused, and not something we can rely upon for a supported default among the Fedora use cases. Getting btrfs in Fedora to be in a state where it *could* be the default is something I am working towards. However, it is *very* hard when people keep shutting down discussions that I try to have about enablement related to it. The situation with btrfs today is many orders of magnitude better than before, and yet I've mostly been improving Btrfs support in Fedora in tiny ways because the bigger things to do (improving kickstart, Anaconda, etc.) are impossible due to how difficult it is to contribute to those projects. The *only* remaining "major" issue in Btrfs itself is the RAID 5/6 feature, which does not provide write hole protection without additional work (similar to mdraid). There was some work last year by David Sterba to rework the the RAID code for the SUSE Hackweek 17, but it has not been completed yet. Some work was done again to try to land this for the 5.3 cycle, but some last minute issues got that postponed. It's definitely on the radar to fix, though. I've been watching and using Btrfs since May of 2015, and the development has drastically improved. I know for a fact no one has asked the upstream developers in at least the last two years, because I've gotten "cautionary" recommendations that it'd be okay to do so since early last year, and last week I've gotten much more enthusiastic responses when I met some of
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/22/19 8:58 AM, Prarit Bhargava wrote: On 8/19/19 9:15 AM, Laura Abbott wrote: On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. I think I measured the impact of 8192 vs 512 (or 256?) a long time ago and we are talking about _k_ of memory. We should stick with what upstream has at 8192. It's easier to debug when we have the same value as the default IMO. Having said that, it has been a long time since I had to debug a NR_CPUS/nr_cpus issue in the kernel. We're just not seeing bugs around the value anymore. I was going to ask about the actual impact of a larger number of CPUs. If it's actually only k of memory it's probably better to just set MAXCPUS all the time. Even the lowest end machines probably see more change when frameworks change. And yes, I also think that we've come a long way so NR_CPUS is less of an important option to optimize these days. I think I'll just submit another patch to just do the max cpus. Thanks, Laura P. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: test patch for zswap bug
On 8/19/19 3:29 PM, Chris Murphy wrote: Hi, Is it possible to get the following test patch in a Rawhide kernel as a one off for testing? Or is that a PITA? Ordinarily I'd just build a kernel myself locally, but that build machine is in a very confused Rawhide<-->Branched state and so I can't. But that led me to wonder about the general case of whether it's ordinary to request test patches for testing in Rawhide kernels, or if such things considered out of scope until they get merged? https://bugzilla.kernel.org/attachment.cgi?id=284507=diff We generally prefer not to bring in patches for testing in rawhide. It's easy to bring a patch in but much harder to drop one. https://koji.fedoraproject.org/koji/taskinfo?taskID=37168533 Here's a scratch build that should have the patch. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 2:55 PM, Paul Bolle wrote: Hi Laura, Laura Abbott schreef op do 15-08-2019 om 15:57 [-0400]: .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- kernel.spec | 2 -- ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 --- 3 files changed, 1 insertion(+), 37 deletions(-) delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS index 27d187f4d..9ce2b2de6 100644 --- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS +++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS @@ -1 +1 @@ -CONFIG_NR_CPUS=1024 +CONFIG_NR_CPUS=512 This patch needs an included regeneration of the kernel-*.config files to be complete. Thanks, Paul Bolle Thanks for the reminder ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 2:57 PM, Paul Bolle wrote: Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]: RHEL has a larger NR_CPU value, though. For example, it's 8192 on x86-64, while Fedora 31 has 1024. On the Fedora x86-64 debug builds it's 8192 again. Why's that? Paul Bolle That's the option for max cpus. We don't want to turn it on in all Fedora builds since it would use up more resources we probably don't actually need. Turning on for debugging in Fedora is okay though. RHEL is focused on larger footprints and makes the trade off to have it enabled all the time. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/9] Drop cpumask auto select patch
On 8/16/19 6:58 AM, Josh Boyer wrote:
On Thu, Aug 15, 2019 at 3:57 PM Laura Abbott wrote:
We've been carrying a patch to make CPUMASK_OFFSTACK selectable
without debugging for a long time now. The comment said this was
going to be replaced with something else but that never seemed
to happen. We're carrying it to have a higher number of CPUs but
at this point I don't think it's worth it since the upper bound is
now 512. This should be enough for most Fedora use cases so just
drop the patch.
I likely agree, but copying Prarit because this was something he and I
poked at forever ago.
Given that RHEL no longer bothers with this I hope he would be
okay with it :)
josh
Signed-off-by: Laura Abbott
---
.../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +-
kernel.spec | 2 --
...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 ---
3 files changed, 1 insertion(+), 37 deletions(-)
delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
index 27d187f4d..9ce2b2de6 100644
--- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
+++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
@@ -1 +1 @@
-CONFIG_NR_CPUS=1024
+CONFIG_NR_CPUS=512
diff --git a/kernel.spec b/kernel.spec
index a662ee004..4253ff035 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
# Standalone patches
# 100 - Generic long running patches
-Patch110: lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
-
Patch111: input-kill-stupid-messages.patch
Patch112: die-floppy-die.patch
diff --git a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
b/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
deleted file mode 100644
index 5e6d6611e..0
--- a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From: Josh Boyer
-Date: Mon, 11 Nov 2013 08:39:16 -0500
-Subject: [PATCH] lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
- dependency
-
-When CPUMASK_OFFSTACK was added in 2008, it was dependent upon
-DEBUG_PER_CPU_MAPS being enabled, or an architecture could select it.
-The debug dependency adds additional overhead that isn't required for
-operation of the feature, and we need CPUMASK_OFFSTACK to increase the
-NR_CPUS value beyond 512 on x86. We drop the current dependency and make
-sure SMP is set.
-
-Bugzilla: N/A
-Upstream-status: Nak'd, supposedly replacement coming to auto-select
-
-Signed-off-by: Josh Boyer
- lib/Kconfig | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/lib/Kconfig b/lib/Kconfig
-index 3a2ef67db6c7..4af1e7e5a611 100644
a/lib/Kconfig
-+++ b/lib/Kconfig
-@@ -396,7 +396,8 @@ config CHECK_SIGNATURE
- bool
-
- config CPUMASK_OFFSTACK
-- bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
-+ bool "Force CPU masks off stack"
-+ depends on SMP
- help
- Use dynamic allocation for cpumask_var_t, instead of putting
- them on the stack. This is a bit more expensive, but avoids
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 6/9] Remove some old modalias adjustments
On 8/16/19 7:00 AM, Josh Boyer wrote:
On Thu, Aug 15, 2019 at 3:58 PM Laura Abbott wrote:
We've come a long way. Let's just leave these drivers alone.
Can we not build them at all instead? Or put them in modules-extra if
we're too chicken to disable them entirely.
I like the suggestion of putting them in mod-extra.
josh
Signed-off-by: Laura Abbott
---
die-floppy-die.patch | 29 -
kernel.spec | 4
no-pcspkr-modalias.patch | 22 --
3 files changed, 55 deletions(-)
delete mode 100644 die-floppy-die.patch
delete mode 100644 no-pcspkr-modalias.patch
diff --git a/die-floppy-die.patch b/die-floppy-die.patch
deleted file mode 100644
index caaa2dde5..0
--- a/die-floppy-die.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From: Kyle McMartin
-Date: Tue, 30 Mar 2010 00:04:29 -0400
-Subject: [PATCH] die-floppy-die
-
-Kill the floppy.ko pnp modalias. We were surviving just fine without
-autoloading floppy drivers, tyvm.
-
-Please feel free to register all complaints in the wastepaper bin.
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- drivers/block/floppy.c | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
-index a08cda955285..e320e1e679cf 100644
a/drivers/block/floppy.c
-+++ b/drivers/block/floppy.c
-@@ -4633,8 +4633,7 @@ static const struct pnp_device_id floppy_pnpids[] = {
- {"PNP0700", 0},
- {}
- };
--
--MODULE_DEVICE_TABLE(pnp, floppy_pnpids);
-+/* MODULE_DEVICE_TABLE(pnp, floppy_pnpids); */
-
- #else
-
diff --git a/kernel.spec b/kernel.spec
index 1a7af5cd4..0e9ba6be4 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -497,10 +497,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
Patch111: input-kill-stupid-messages.patch
-Patch112: die-floppy-die.patch
-
-Patch113: no-pcspkr-modalias.patch
-
Patch115: Kbuild-Add-an-option-to-enable-GCC-VTA.patch
Patch116: crash-driver.patch
diff --git a/no-pcspkr-modalias.patch b/no-pcspkr-modalias.patch
deleted file mode 100644
index 2ccd87202..0
--- a/no-pcspkr-modalias.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-From: "kernel-t...@fedoraproject.org"
-Date: Thu, 29 Jul 2010 16:46:31 -0700
-Subject: [PATCH] no pcspkr modalias
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- drivers/input/misc/pcspkr.c | 1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/drivers/input/misc/pcspkr.c b/drivers/input/misc/pcspkr.c
-index 56ddba21de84..23534f420e68 100644
a/drivers/input/misc/pcspkr.c
-+++ b/drivers/input/misc/pcspkr.c
-@@ -23,7 +23,6 @@
- MODULE_AUTHOR("Vojtech Pavlik ");
- MODULE_DESCRIPTION("PC Speaker beeper driver");
- MODULE_LICENSE("GPL");
--MODULE_ALIAS("platform:pcspkr");
-
- static int pcspkr_event(struct input_dev *dev, unsigned int type,
- unsigned int code, int value)
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 9/9] Remove crash driver
On 8/16/19 6:56 AM, Josh Boyer wrote:
On Thu, Aug 15, 2019 at 4:02 PM Laura Abbott wrote:
This has since been replaced by other in kernel pieces. We
can finally drop it.
Which pieces?
/proc/kcore now does most of the work of the crash driver. I've helped
fix up misc pieces in the past (c.f. 3955333df9a5 ("proc/kcore: don't bounds
check against address 0")
josh
Signed-off-by: Laura Abbott
---
crash-driver.patch | 722 -
kernel.spec| 2 -
2 files changed, 724 deletions(-)
delete mode 100644 crash-driver.patch
diff --git a/crash-driver.patch b/crash-driver.patch
deleted file mode 100644
index 164dc90f5..0
--- a/crash-driver.patch
+++ /dev/null
@@ -1,722 +0,0 @@
-From 973e23bf27b0b2e5021321357fc570cccea3104c Mon Sep 17 00:00:00 2001
-From: Dave Anderson
-Date: Tue, 26 Nov 2013 12:42:46 -0500
-Subject: [PATCH] crash-driver
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- arch/arm/include/asm/crash-driver.h | 6 ++
- arch/arm64/include/asm/crash-driver.h | 6 ++
- arch/ia64/include/asm/crash-driver.h| 90 ++
- arch/ia64/kernel/ia64_ksyms.c | 3 +
- arch/powerpc/include/asm/crash-driver.h | 6 ++
- arch/s390/include/asm/crash-driver.h| 60 +++
- arch/s390/mm/maccess.c | 2 +
- arch/x86/include/asm/crash-driver.h | 6 ++
- drivers/char/Kconfig| 3 +
- drivers/char/Makefile | 2 +
- drivers/char/crash.c| 128
- include/asm-generic/crash-driver.h | 72 ++
- 12 files changed, 384 insertions(+)
- create mode 100644 arch/arm/include/asm/crash-driver.h
- create mode 100644 arch/arm64/include/asm/crash-driver.h
- create mode 100644 arch/ia64/include/asm/crash-driver.h
- create mode 100644 arch/powerpc/include/asm/crash-driver.h
- create mode 100644 arch/s390/include/asm/crash-driver.h
- create mode 100644 arch/x86/include/asm/crash-driver.h
- create mode 100644 drivers/char/crash.c
- create mode 100644 include/asm-generic/crash-driver.h
-
-diff --git a/arch/arm/include/asm/crash-driver.h
b/arch/arm/include/asm/crash-driver.h
-new file mode 100644
-index 000..06e7ae9
/dev/null
-+++ b/arch/arm/include/asm/crash-driver.h
-@@ -0,0 +1,6 @@
-+#ifndef _ARM_CRASH_H
-+#define _ARM_CRASH_H
-+
-+#include
-+
-+#endif /* _ARM_CRASH_H */
-diff --git a/arch/arm64/include/asm/crash-driver.h
b/arch/arm64/include/asm/crash-driver.h
-new file mode 100644
-index 000..43b26da
/dev/null
-+++ b/arch/arm64/include/asm/crash-driver.h
-@@ -0,0 +1,6 @@
-+#ifndef _ARM64_CRASH_H
-+#define _ARM64_CRASH_H
-+
-+#include
-+
-+#endif /* _ARM64_CRASH_H */
-diff --git a/arch/ia64/include/asm/crash-driver.h
b/arch/ia64/include/asm/crash-driver.h
-new file mode 100644
-index 000..404bcb9
/dev/null
-+++ b/arch/ia64/include/asm/crash-driver.h
-@@ -0,0 +1,90 @@
-+#ifndef _ASM_IA64_CRASH_H
-+#define _ASM_IA64_CRASH_H
-+
-+/*
-+ * linux/include/asm-ia64/crash-driver.h
-+ *
-+ * Copyright (c) 2004 Red Hat, Inc. All rights reserved.
-+ *
-+ * This program is free software; you can redistribute it and/or modify
-+ * it under the terms of the GNU General Public License as published by
-+ * the Free Software Foundation; either version 2, or (at your option)
-+ * any later version.
-+ *
-+ * This program is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-+ * GNU General Public License for more details.
-+ *
-+ * You should have received a copy of the GNU General Public License
-+ * along with this program; if not, write to the Free Software
-+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-+ *
-+ */
-+
-+#ifdef __KERNEL__
-+
-+#include
-+#include
-+#include
-+
-+static inline void *
-+map_virtual(u64 offset, struct page **pp)
-+{
-+ struct page *page;
-+ unsigned long pfn;
-+ u32 type;
-+
-+ if (REGION_NUMBER(offset) == 5) {
-+ char byte;
-+
-+ if (__get_user(byte, (char *)offset) == 0)
-+ return (void *)offset;
-+ else
-+ return NULL;
-+ }
-+
-+ switch (type = efi_mem_type(offset))
-+ {
-+ case EFI_LOADER_CODE:
-+ case EFI_LOADER_DATA:
-+ case EFI_BOOT_SERVICES_CODE:
-+ case EFI_BOOT_SERVICES_DATA:
-+ case EFI_CONVENTIONAL_MEMORY:
-+ break;
-+
-+ default:
-+ printk(KERN_INFO
-+ "crash memory driver: invalid memory type for %lx: %d\n",
-+ offset, type);
-+ return NULL;
-+ }
-+
-+ pfn = offset >> PAGE_SHIFT;
-+
-+ if (!pfn_valid(pfn)) {
-+ printk(KERN_INFO
-+ "crash memory driver: invalid pfn: %lx )\n
[PATCH 9/9] Remove crash driver
This has since been replaced by other in kernel pieces. We
can finally drop it.
Signed-off-by: Laura Abbott
---
crash-driver.patch | 722 -
kernel.spec| 2 -
2 files changed, 724 deletions(-)
delete mode 100644 crash-driver.patch
diff --git a/crash-driver.patch b/crash-driver.patch
deleted file mode 100644
index 164dc90f5..0
--- a/crash-driver.patch
+++ /dev/null
@@ -1,722 +0,0 @@
-From 973e23bf27b0b2e5021321357fc570cccea3104c Mon Sep 17 00:00:00 2001
-From: Dave Anderson
-Date: Tue, 26 Nov 2013 12:42:46 -0500
-Subject: [PATCH] crash-driver
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- arch/arm/include/asm/crash-driver.h | 6 ++
- arch/arm64/include/asm/crash-driver.h | 6 ++
- arch/ia64/include/asm/crash-driver.h| 90 ++
- arch/ia64/kernel/ia64_ksyms.c | 3 +
- arch/powerpc/include/asm/crash-driver.h | 6 ++
- arch/s390/include/asm/crash-driver.h| 60 +++
- arch/s390/mm/maccess.c | 2 +
- arch/x86/include/asm/crash-driver.h | 6 ++
- drivers/char/Kconfig| 3 +
- drivers/char/Makefile | 2 +
- drivers/char/crash.c| 128
- include/asm-generic/crash-driver.h | 72 ++
- 12 files changed, 384 insertions(+)
- create mode 100644 arch/arm/include/asm/crash-driver.h
- create mode 100644 arch/arm64/include/asm/crash-driver.h
- create mode 100644 arch/ia64/include/asm/crash-driver.h
- create mode 100644 arch/powerpc/include/asm/crash-driver.h
- create mode 100644 arch/s390/include/asm/crash-driver.h
- create mode 100644 arch/x86/include/asm/crash-driver.h
- create mode 100644 drivers/char/crash.c
- create mode 100644 include/asm-generic/crash-driver.h
-
-diff --git a/arch/arm/include/asm/crash-driver.h
b/arch/arm/include/asm/crash-driver.h
-new file mode 100644
-index 000..06e7ae9
/dev/null
-+++ b/arch/arm/include/asm/crash-driver.h
-@@ -0,0 +1,6 @@
-+#ifndef _ARM_CRASH_H
-+#define _ARM_CRASH_H
-+
-+#include
-+
-+#endif /* _ARM_CRASH_H */
-diff --git a/arch/arm64/include/asm/crash-driver.h
b/arch/arm64/include/asm/crash-driver.h
-new file mode 100644
-index 000..43b26da
/dev/null
-+++ b/arch/arm64/include/asm/crash-driver.h
-@@ -0,0 +1,6 @@
-+#ifndef _ARM64_CRASH_H
-+#define _ARM64_CRASH_H
-+
-+#include
-+
-+#endif /* _ARM64_CRASH_H */
-diff --git a/arch/ia64/include/asm/crash-driver.h
b/arch/ia64/include/asm/crash-driver.h
-new file mode 100644
-index 000..404bcb9
/dev/null
-+++ b/arch/ia64/include/asm/crash-driver.h
-@@ -0,0 +1,90 @@
-+#ifndef _ASM_IA64_CRASH_H
-+#define _ASM_IA64_CRASH_H
-+
-+/*
-+ * linux/include/asm-ia64/crash-driver.h
-+ *
-+ * Copyright (c) 2004 Red Hat, Inc. All rights reserved.
-+ *
-+ * This program is free software; you can redistribute it and/or modify
-+ * it under the terms of the GNU General Public License as published by
-+ * the Free Software Foundation; either version 2, or (at your option)
-+ * any later version.
-+ *
-+ * This program is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-+ * GNU General Public License for more details.
-+ *
-+ * You should have received a copy of the GNU General Public License
-+ * along with this program; if not, write to the Free Software
-+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-+ *
-+ */
-+
-+#ifdef __KERNEL__
-+
-+#include
-+#include
-+#include
-+
-+static inline void *
-+map_virtual(u64 offset, struct page **pp)
-+{
-+ struct page *page;
-+ unsigned long pfn;
-+ u32 type;
-+
-+ if (REGION_NUMBER(offset) == 5) {
-+ char byte;
-+
-+ if (__get_user(byte, (char *)offset) == 0)
-+ return (void *)offset;
-+ else
-+ return NULL;
-+ }
-+
-+ switch (type = efi_mem_type(offset))
-+ {
-+ case EFI_LOADER_CODE:
-+ case EFI_LOADER_DATA:
-+ case EFI_BOOT_SERVICES_CODE:
-+ case EFI_BOOT_SERVICES_DATA:
-+ case EFI_CONVENTIONAL_MEMORY:
-+ break;
-+
-+ default:
-+ printk(KERN_INFO
-+ "crash memory driver: invalid memory type for %lx: %d\n",
-+ offset, type);
-+ return NULL;
-+ }
-+
-+ pfn = offset >> PAGE_SHIFT;
-+
-+ if (!pfn_valid(pfn)) {
-+ printk(KERN_INFO
-+ "crash memory driver: invalid pfn: %lx )\n", pfn);
-+ return NULL;
-+ }
-+
-+ page = pfn_to_page(pfn);
-+
-+ if (!page->virtual) {
-+ printk(KERN_INFO
-+ "crash memory driver: offset: %lx page: %lx page->virtual:
NULL\n",
-+ offset, (unsign
[PATCH 8/9] Remove patch for GCC VTA
It's been years and gcc has changed a lot.
Signed-off-by: Laura Abbott
---
Kbuild-Add-an-option-to-enable-GCC-VTA.patch | 94
kernel.spec | 2 -
2 files changed, 96 deletions(-)
delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch
diff --git a/Kbuild-Add-an-option-to-enable-GCC-VTA.patch
b/Kbuild-Add-an-option-to-enable-GCC-VTA.patch
deleted file mode 100644
index 6bbb0efdf..0
--- a/Kbuild-Add-an-option-to-enable-GCC-VTA.patch
+++ /dev/null
@@ -1,94 +0,0 @@
-From a446d2f94ce540689c7a46bf457d92409e9c4d7e Mon Sep 17 00:00:00 2001
-From: Josh Stone
-Date: Fri, 21 Nov 2014 10:40:00 -0800
-Subject: [PATCH] Kbuild: Add an option to enable GCC VTA
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Due to recent codegen issues, gcc -fvar-tracking-assignments was
-unconditionally disabled in commit 2062afb4f804a ("Fix gcc-4.9.0
-miscompilation of load_balance() in scheduler"). However, this reduces
-the debuginfo coverage for variable locations, especially in inline
-functions. VTA is certainly not perfect either in those cases, but it
-is much better than without. With compiler versions that have fixed the
-codegen bugs, we would prefer to have the better details for SystemTap,
-and surely other debuginfo consumers like perf will benefit as well.
-
-This patch simply makes CONFIG_DEBUG_INFO_VTA an option. I considered
-Frank and Linus's discussion of a cc-option-like -fcompare-debug test,
-but I'm convinced that a narrow test of an arch-specific codegen issue
-is not really useful. GCC has their own regression tests for this, so
-I'd suggest GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle is more
-useful for kernel developers to test confidence.
-
-In fact, I ran into a couple more issues when testing for this patch[1],
-although neither of those had any codegen impact.
- [1] https://bugzilla.redhat.com/show_bug.cgi?id=1140872
-
-With gcc-4.9.2-1.fc22, I can now build v3.18-rc5 with Fedora's i686 and
-x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.
-
-Cc: Frank Ch. Eigler
-Cc: Jakub Jelinek
-Cc: Josh Boyer
-Cc: Greg Kroah-Hartman
-Cc: Linus Torvalds
-Cc: Andrew Morton
-Cc: Markus Trippelsdorf
-Cc: Michel Dänzer
-Signed-off-by: Josh Stone
-Signed-off-by: Jeremy Cline
- Makefile | 4
- lib/Kconfig.debug | 18 +-
- 2 files changed, 21 insertions(+), 1 deletion(-)
-
-diff --git a/Makefile b/Makefile
-index 9ef547fc7ffe..5777d902f8f3 100644
a/Makefile
-+++ b/Makefile
-@@ -735,7 +735,11 @@ KBUILD_CFLAGS += -fomit-frame-pointer
- KBUILD_CFLAGS += -ftrivial-auto-var-init=pattern
- endif
-
-+ifdef CONFIG_DEBUG_INFO_VTA
-+DEBUG_CFLAGS += $(call cc-option, -fvar-tracking-assignments)
-+else
- DEBUG_CFLAGS := $(call cc-option, -fno-var-tracking-assignments)
-+endif
-
- ifdef CONFIG_DEBUG_INFO
- ifdef CONFIG_DEBUG_INFO_SPLIT
-diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
-index 0d9e81779e37..424206212931 100644
a/lib/Kconfig.debug
-+++ b/lib/Kconfig.debug
-@@ -217,7 +217,23 @@ config DEBUG_INFO_DWARF4
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
--variables in gdb on optimized code.
-+variables in gdb on optimized code. The gcc docs also
-+recommend enabling -fvar-tracking-assignments for maximum
-+benefit. (see DEBUG_INFO_VTA)
-+
-+config DEBUG_INFO_VTA
-+ bool "Enable var-tracking-assignments for debuginfo"
-+ depends on DEBUG_INFO
-+ help
-+Enable gcc -fvar-tracking-assignments for improved debug
-+information on variable locations in optimized code. Per
-+gcc, DEBUG_INFO_DWARF4 is recommended for best use of VTA.
-+
-+VTA has been implicated in codegen bugs (gcc PR61801,
-+PR61904), so this may deserve some caution. One can set
-+GCC_COMPARE_DEBUG=-fvar-tracking-assignments-toggle in the
-+environment to automatically compile everything both ways,
-+generating an error if anything differs.
-
- config DEBUG_INFO_BTF
- bool "Generate BTF typeinfo"
---
-2.20.1
-
diff --git a/kernel.spec b/kernel.spec
index e7e73d104..c91483f3d 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
# Standalone patches
# 100 - Generic long running patches
-Patch115: Kbuild-Add-an-option-to-enable-GCC-VTA.patch
-
Patch116: crash-driver.patch
Patch122: Input-synaptics-pin-3-touches-when-the-firmware-repo.patch
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US
[PATCH 7/9] Remove old keyboard logging patch
Let's see if this results in flooding.
Signed-off-by: Laura Abbott
---
input-kill-stupid-messages.patch | 30 --
kernel.spec | 2 --
2 files changed, 32 deletions(-)
delete mode 100644 input-kill-stupid-messages.patch
diff --git a/input-kill-stupid-messages.patch b/input-kill-stupid-messages.patch
deleted file mode 100644
index 04205f857..0
--- a/input-kill-stupid-messages.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From: "kernel-t...@fedoraproject.org"
-Date: Thu, 29 Jul 2010 16:46:31 -0700
-Subject: [PATCH] input: kill stupid messages
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- drivers/input/keyboard/atkbd.c | 4
- 1 file changed, 4 insertions(+)
-
-diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
-index ec876b5b1382..9d5216e23a09 100644
a/drivers/input/keyboard/atkbd.c
-+++ b/drivers/input/keyboard/atkbd.c
-@@ -436,11 +436,15 @@ static irqreturn_t atkbd_interrupt(struct serio *serio,
unsigned char data,
- goto out;
- case ATKBD_RET_ACK:
- case ATKBD_RET_NAK:
-+# if 0
-+ /* Quite a few key switchers and other tools trigger this
-+ * and it confuses people who can do nothing about it */
- if (printk_ratelimit())
- dev_warn(>dev,
-"Spurious %s on %s. "
-"Some program might be trying to access
hardware directly.\n",
-data == ATKBD_RET_ACK ? "ACK" : "NAK",
serio->phys);
-+#endif
- goto out;
- case ATKBD_RET_ERR:
- atkbd->err_count++;
diff --git a/kernel.spec b/kernel.spec
index 0e9ba6be4..e7e73d104 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
# Standalone patches
# 100 - Generic long running patches
-Patch111: input-kill-stupid-messages.patch
-
Patch115: Kbuild-Add-an-option-to-enable-GCC-VTA.patch
Patch116: crash-driver.patch
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 6/9] Remove some old modalias adjustments
We've come a long way. Let's just leave these drivers alone.
Signed-off-by: Laura Abbott
---
die-floppy-die.patch | 29 -
kernel.spec | 4
no-pcspkr-modalias.patch | 22 --
3 files changed, 55 deletions(-)
delete mode 100644 die-floppy-die.patch
delete mode 100644 no-pcspkr-modalias.patch
diff --git a/die-floppy-die.patch b/die-floppy-die.patch
deleted file mode 100644
index caaa2dde5..0
--- a/die-floppy-die.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From: Kyle McMartin
-Date: Tue, 30 Mar 2010 00:04:29 -0400
-Subject: [PATCH] die-floppy-die
-
-Kill the floppy.ko pnp modalias. We were surviving just fine without
-autoloading floppy drivers, tyvm.
-
-Please feel free to register all complaints in the wastepaper bin.
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- drivers/block/floppy.c | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
-index a08cda955285..e320e1e679cf 100644
a/drivers/block/floppy.c
-+++ b/drivers/block/floppy.c
-@@ -4633,8 +4633,7 @@ static const struct pnp_device_id floppy_pnpids[] = {
- {"PNP0700", 0},
- {}
- };
--
--MODULE_DEVICE_TABLE(pnp, floppy_pnpids);
-+/* MODULE_DEVICE_TABLE(pnp, floppy_pnpids); */
-
- #else
-
diff --git a/kernel.spec b/kernel.spec
index 1a7af5cd4..0e9ba6be4 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -497,10 +497,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
Patch111: input-kill-stupid-messages.patch
-Patch112: die-floppy-die.patch
-
-Patch113: no-pcspkr-modalias.patch
-
Patch115: Kbuild-Add-an-option-to-enable-GCC-VTA.patch
Patch116: crash-driver.patch
diff --git a/no-pcspkr-modalias.patch b/no-pcspkr-modalias.patch
deleted file mode 100644
index 2ccd87202..0
--- a/no-pcspkr-modalias.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-From: "kernel-t...@fedoraproject.org"
-Date: Thu, 29 Jul 2010 16:46:31 -0700
-Subject: [PATCH] no pcspkr modalias
-
-Bugzilla: N/A
-Upstream-status: Fedora mustard
- drivers/input/misc/pcspkr.c | 1 -
- 1 file changed, 1 deletion(-)
-
-diff --git a/drivers/input/misc/pcspkr.c b/drivers/input/misc/pcspkr.c
-index 56ddba21de84..23534f420e68 100644
a/drivers/input/misc/pcspkr.c
-+++ b/drivers/input/misc/pcspkr.c
-@@ -23,7 +23,6 @@
- MODULE_AUTHOR("Vojtech Pavlik ");
- MODULE_DESCRIPTION("PC Speaker beeper driver");
- MODULE_LICENSE("GPL");
--MODULE_ALIAS("platform:pcspkr");
-
- static int pcspkr_event(struct input_dev *dev, unsigned int type,
- unsigned int code, int value)
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 4/9] Remove ancient ath9k workaround
It's been years. Let's see if we actually still need this.
Signed-off-by: Laura Abbott
---
ath9k-rx-dma-stop-check.patch | 38 ---
kernel.spec | 2 --
2 files changed, 40 deletions(-)
delete mode 100644 ath9k-rx-dma-stop-check.patch
diff --git a/ath9k-rx-dma-stop-check.patch b/ath9k-rx-dma-stop-check.patch
deleted file mode 100644
index 40cbafc7b..0
--- a/ath9k-rx-dma-stop-check.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From: "kernel-t...@fedoraproject.org"
-Date: Wed, 6 Feb 2013 09:57:47 -0500
-Subject: [PATCH] ath9k: rx dma stop check
-
- drivers/net/wireless/ath/ath9k/mac.c | 12 +++-
- 1 file changed, 11 insertions(+), 1 deletion(-)
-
-diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
-index bba85d1a6cd1..ebbee8f17130 100644
a/drivers/net/wireless/ath/ath9k/mac.c
-+++ b/drivers/net/wireless/ath/ath9k/mac.c
-@@ -693,7 +693,7 @@ bool ath9k_hw_stopdmarecv(struct ath_hw *ah, bool *reset)
- {
- #define AH_RX_STOP_DMA_TIMEOUT 1 /* usec */
- struct ath_common *common = ath9k_hw_common(ah);
-- u32 mac_status, last_mac_status = 0;
-+ u32 mac_status = 0, last_mac_status = 0;
- int i;
-
- /* Enable access to the DMA observation bus */
-@@ -723,6 +723,16 @@ bool ath9k_hw_stopdmarecv(struct ath_hw *ah, bool *reset)
- }
-
- if (i == 0) {
-+ if (!AR_SREV_9300_20_OR_LATER(ah) &&
-+ (mac_status & 0x700) == 0) {
-+ /*
-+ * DMA is idle but the MAC is still stuck
-+ * processing events
-+ */
-+ *reset = true;
-+ return true;
-+ }
-+
- ath_err(common,
- "DMA failed to stop in %d ms AR_CR=0x%08x
AR_DIAG_SW=0x%08x DMADBG_7=0x%08x\n",
- AH_RX_STOP_DMA_TIMEOUT / 1000,
diff --git a/kernel.spec b/kernel.spec
index 260976479..79aabba51 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -507,8 +507,6 @@ Patch116: crash-driver.patch
Patch117: lis3-improve-handling-of-null-rate.patch
-Patch120: ath9k-rx-dma-stop-check.patch
-
Patch122: Input-synaptics-pin-3-touches-when-the-firmware-repo.patch
# This no longer applies, let's see if it needs to be updated
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 2/9] Drop cpumask auto select patch
We've been carrying a patch to make CPUMASK_OFFSTACK selectable
without debugging for a long time now. The comment said this was
going to be replaced with something else but that never seemed
to happen. We're carrying it to have a higher number of CPUs but
at this point I don't think it's worth it since the upper bound is
now 512. This should be enough for most Fedora use cases so just
drop the patch.
Signed-off-by: Laura Abbott
---
.../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +-
kernel.spec | 2 --
...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 ---
3 files changed, 1 insertion(+), 37 deletions(-)
delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
diff --git a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
index 27d187f4d..9ce2b2de6 100644
--- a/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
+++ b/configs/fedora/generic/x86/x86_64/CONFIG_NR_CPUS
@@ -1 +1 @@
-CONFIG_NR_CPUS=1024
+CONFIG_NR_CPUS=512
diff --git a/kernel.spec b/kernel.spec
index a662ee004..4253ff035 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -495,8 +495,6 @@ Source5000: patch-5.%{base_sublevel}-git%{gitrev}.xz
# Standalone patches
# 100 - Generic long running patches
-Patch110: lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
-
Patch111: input-kill-stupid-messages.patch
Patch112: die-floppy-die.patch
diff --git a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
b/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
deleted file mode 100644
index 5e6d6611e..0
--- a/lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From: Josh Boyer
-Date: Mon, 11 Nov 2013 08:39:16 -0500
-Subject: [PATCH] lib/cpumask: Make CPUMASK_OFFSTACK usable without debug
- dependency
-
-When CPUMASK_OFFSTACK was added in 2008, it was dependent upon
-DEBUG_PER_CPU_MAPS being enabled, or an architecture could select it.
-The debug dependency adds additional overhead that isn't required for
-operation of the feature, and we need CPUMASK_OFFSTACK to increase the
-NR_CPUS value beyond 512 on x86. We drop the current dependency and make
-sure SMP is set.
-
-Bugzilla: N/A
-Upstream-status: Nak'd, supposedly replacement coming to auto-select
-
-Signed-off-by: Josh Boyer
- lib/Kconfig | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/lib/Kconfig b/lib/Kconfig
-index 3a2ef67db6c7..4af1e7e5a611 100644
a/lib/Kconfig
-+++ b/lib/Kconfig
-@@ -396,7 +396,8 @@ config CHECK_SIGNATURE
- bool
-
- config CPUMASK_OFFSTACK
-- bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
-+ bool "Force CPU masks off stack"
-+ depends on SMP
- help
- Use dynamic allocation for cpumask_var_t, instead of putting
- them on the stack. This is a bit more expensive, but avoids
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 3/9] Drop scsi warning patch
It's been years since we've seen this warning. Just drop it.
Signed-off-by: Laura Abbott
---
kernel.spec | 2 -
...validate_disk-prevent-NULL-ptr-deref.patch | 39 ---
2 files changed, 41 deletions(-)
delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
diff --git a/kernel.spec b/kernel.spec
index 4253ff035..260976479 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -507,8 +507,6 @@ Patch116: crash-driver.patch
Patch117: lis3-improve-handling-of-null-rate.patch
-Patch118: scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
-
Patch120: ath9k-rx-dma-stop-check.patch
Patch122: Input-synaptics-pin-3-touches-when-the-firmware-repo.patch
diff --git a/scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
b/scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
deleted file mode 100644
index a19267cc1..0
--- a/scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-From 7afe9a8d7dca86a8f35250f21f5f0a62ea2fedf7 Mon Sep 17 00:00:00 2001
-From: "kernel-t...@fedoraproject.org"
-Date: Fri, 10 Feb 2012 14:56:13 -0500
-Subject: [PATCH] scsi: sd_revalidate_disk prevent NULL ptr deref
-
-Bugzilla: 754518
-Upstream-status: Fedora mustard (might be worth dropping...)
- drivers/scsi/sd.c | 7 ++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
-
-diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
-index 3d22fc3..07aec76 100644
a/drivers/scsi/sd.c
-+++ b/drivers/scsi/sd.c
-@@ -2825,7 +2825,7 @@ static inline u32 logical_to_sectors(struct scsi_device
*sdev, u32 blocks)
- static int sd_revalidate_disk(struct gendisk *disk)
- {
- struct scsi_disk *sdkp = scsi_disk(disk);
-- struct scsi_device *sdp = sdkp->device;
-+ struct scsi_device *sdp;
- struct request_queue *q = sdkp->disk->queue;
- sector_t old_capacity = sdkp->capacity;
- unsigned char *buffer;
-@@ -2833,6 +2833,11 @@ static int sd_revalidate_disk(struct gendisk *disk)
- SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp,
- "sd_revalidate_disk\n"));
-
-+ if (WARN_ONCE((!sdkp), "Invalid scsi_disk from %p\n", disk))
-+ goto out;
-+
-+ sdp = sdkp->device;
-+
- /*
-* If the device is offline, don't try and read capacity or any
-* of the other niceties.
---
-2.5.0
-
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 1/9] Drop namespaces config tweak
We've come a long way for namespaces since 2013 and all arches now enable namespaces. Drop the patch where we can turn it off and on. Signed-off-by: Laura Abbott --- kernel.spec| 2 -- namespaces-no-expert.patch | 27 --- 2 files changed, 29 deletions(-) delete mode 100644 namespaces-no-expert.patch diff --git a/kernel.spec b/kernel.spec index 734ffaed1..a662ee004 100644 --- a/kernel.spec +++ b/kernel.spec @@ -511,8 +511,6 @@ Patch117: lis3-improve-handling-of-null-rate.patch Patch118: scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch -Patch119: namespaces-no-expert.patch - Patch120: ath9k-rx-dma-stop-check.patch Patch122: Input-synaptics-pin-3-touches-when-the-firmware-repo.patch diff --git a/namespaces-no-expert.patch b/namespaces-no-expert.patch deleted file mode 100644 index d732f9d0a..0 --- a/namespaces-no-expert.patch +++ /dev/null @@ -1,27 +0,0 @@ -From 235b02d70a6a9837896c2ff4ca9d03f172cc4281 Mon Sep 17 00:00:00 2001 -From: "kernel-t...@fedoraproject.org" -Date: Wed, 30 Jan 2013 10:55:31 -0500 -Subject: [PATCH] namespaces: no expert - -Bugzilla: N/A -Upstream-status: Fedora mustard - init/Kconfig | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/init/Kconfig b/init/Kconfig -index 2934249fba46..19d9ee8c120b 100644 a/init/Kconfig -+++ b/init/Kconfig -@@ -871,7 +871,7 @@ config SOCK_CGROUP_DATA - endif # CGROUPS - - menuconfig NAMESPACES -- bool "Namespaces support" if EXPERT -+ bool "Namespaces support" - depends on MULTIUSER - default !EXPERT - help --- -2.14.3 - -- 2.21.0 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 5/9] Drop old lis3 patch
We've been carrying this patch for years. If someone wants to
do the work to get it upstream, they are welcome to do so.
Signed-off-by: Laura Abbott
---
kernel.spec | 2 -
lis3-improve-handling-of-null-rate.patch | 75
2 files changed, 77 deletions(-)
delete mode 100644 lis3-improve-handling-of-null-rate.patch
diff --git a/kernel.spec b/kernel.spec
index 79aabba51..1a7af5cd4 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -505,8 +505,6 @@ Patch115: Kbuild-Add-an-option-to-enable-GCC-VTA.patch
Patch116: crash-driver.patch
-Patch117: lis3-improve-handling-of-null-rate.patch
-
Patch122: Input-synaptics-pin-3-touches-when-the-firmware-repo.patch
# This no longer applies, let's see if it needs to be updated
diff --git a/lis3-improve-handling-of-null-rate.patch
b/lis3-improve-handling-of-null-rate.patch
deleted file mode 100644
index 1dd00b645..0
--- a/lis3-improve-handling-of-null-rate.patch
+++ /dev/null
@@ -1,75 +0,0 @@
-From: =?UTF-8?q?=C3=89ric=20Piel?=
-Date: Thu, 3 Nov 2011 16:22:40 +0100
-Subject: [PATCH] lis3: improve handling of null rate
-
-When obtaining a rate of 0, we would disable the device supposely
-because it seems to behave incorectly. It actually only comes from the
-fact that the device is off and on lis3dc it's reflected in the rate.
-So handle this nicely by just waiting a safe time, and then using the
-device as normally.
-
-Bugzilla: 785814
-Upstream-status: ??
-
-Signed-off-by: ??ric Piel
- drivers/misc/lis3lv02d/lis3lv02d.c | 16
- 1 file changed, 8 insertions(+), 8 deletions(-)
-
-diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
-index fb8705fc3aca..50c2b93c1273 100644
a/drivers/misc/lis3lv02d/lis3lv02d.c
-+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
-@@ -216,7 +216,8 @@ static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, int
*x, int *y, int *z)
- /* conversion btw sampling rate and the register values */
- static int lis3_12_rates[4] = {40, 160, 640, 2560};
- static int lis3_8_rates[2] = {100, 400};
--static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000};
-+/* LIS3DC: 0 = power off, above 9 = undefined */
-+static int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000,
-1, -1, -1, -1, -1, -1};
- static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
-
- /* ODR is Output Data Rate */
-@@ -231,12 +232,11 @@ static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
- return lis3->odrs[(ctrl >> shift)];
- }
-
--static int lis3lv02d_get_pwron_wait(struct lis3lv02d *lis3)
-+static int lis3lv02d_wait_pwron(struct lis3lv02d *lis3)
- {
- int div = lis3lv02d_get_odr(lis3);
--
-- if (WARN_ONCE(div == 0, "device returned spurious data"))
-- return -ENXIO;
-+ if (div <= 0)
-+ div = 1; /* maximum delay */
-
- /* LIS3 power on delay is quite long */
- msleep(lis3->pwron_delay / div);
-@@ -303,7 +303,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3, s16
results[3])
-
- lis3->read(lis3, ctlreg, );
- lis3->write(lis3, ctlreg, (reg | selftest));
-- ret = lis3lv02d_get_pwron_wait(lis3);
-+ ret = lis3lv02d_wait_pwron(lis3);
- if (ret)
- goto fail;
-
-@@ -314,7 +314,7 @@ static int lis3lv02d_selftest(struct lis3lv02d *lis3, s16
results[3])
-
- /* back to normal settings */
- lis3->write(lis3, ctlreg, reg);
-- ret = lis3lv02d_get_pwron_wait(lis3);
-+ ret = lis3lv02d_wait_pwron(lis3);
- if (ret)
- goto fail;
-
-@@ -434,7 +434,7 @@ int lis3lv02d_poweron(struct lis3lv02d *lis3)
- }
- }
-
-- err = lis3lv02d_get_pwron_wait(lis3);
-+ err = lis3lv02d_wait_pwron(lis3);
- if (err)
- return err;
-
--
2.21.0
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[PATCH 0/9] Clean up some old patches post F31
I'd like to drop a bunch of patches Fedora has been carrying since forever. Most of these are fairly minor tweaks most people forgot we had and nobody cares about. My motivation is both in the spirit of cleaning up and also to better align Fedora + RHEL (I had a talk about this at Flock, video should be up soon). If someone wants to make an effort at upstreaming any of these, feel free to do so but I really think most of these are cruft. Thanks, Laura Laura Abbott (9): Drop namespaces config tweak Drop cpumask auto select patch Drop scsi warning patch Remove ancient ath9k workaround Drop old lis3 patch Remove some old modalias adjustments Remove old keyboard logging patch Remove patch for GCC VTA Remove crash driver Kbuild-Add-an-option-to-enable-GCC-VTA.patch | 94 --- ath9k-rx-dma-stop-check.patch | 38 - .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- crash-driver.patch| 722 -- die-floppy-die.patch | 29 - input-kill-stupid-messages.patch | 30 - kernel.spec | 20 - ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 - lis3-improve-handling-of-null-rate.patch | 75 -- namespaces-no-expert.patch| 27 - no-pcspkr-modalias.patch | 22 - ...validate_disk-prevent-NULL-ptr-deref.patch | 39 - 12 files changed, 1 insertion(+), 1131 deletions(-) delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch delete mode 100644 ath9k-rx-dma-stop-check.patch delete mode 100644 crash-driver.patch delete mode 100644 die-floppy-die.patch delete mode 100644 input-kill-stupid-messages.patch delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch delete mode 100644 lis3-improve-handling-of-null-rate.patch delete mode 100644 namespaces-no-expert.patch delete mode 100644 no-pcspkr-modalias.patch delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch -- 2.21.0 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Certificate used to sign Fedora kernels for UEFI Secure Boot?
On 8/14/19 8:35 AM, Paul Moore wrote: On Tue, Aug 13, 2019 at 2:03 PM Kevin Fenzi wrote: On 8/12/19 8:35 AM, Josh Boyer wrote: On Mon, Aug 12, 2019 at 11:23 AM Paul Moore wrote: On Fri, Aug 9, 2019 at 8:31 AM Paul Moore wrote: Hello all, I'm not sure if this is the place for this, but if not perhaps you could point me in the right direction? I'm looking for the certificate associated with the key used to sign the Fedora kernels for UEFI Secure Boot. What little information I've found indicates that it should be part of the "shim" package sources, Well, you likely want to look at the pesign package for the signing information, but the cert isn't in there either. It's in smart cards attached to kernel builder machines. When the kernel builds on those the spec sees that and uses pesign to sign them, otherwise it uses a 'test' cert to sign things. May I ask why you want the cert? I'm working on extensions to tboot to support kernel signatures instead of hashes. Not wanting to reinvent the wheel I figured I would reuse the signed PECOFF format used by UEFI Secure Boot; the Fedora kernels are one of the kernels I've been using for testing. While it is still a work in progress, I will be presenting on this topic next week at LSS-NA. but it isn't there, and looking back and random points in it's history I can't seem to find it. I've found the CA used to sign this mystery certificate, but not the kernel's signing certificate. Any help you can provide would be appreciated. For reference, this is the certificate I'm looking for: Signer #0: Subject: /CN=Fedora Secure Boot Signer Issuer : /CN=Fedora Secure Boot CA Serial : 9976F70F ... and no, I'm obviously not asking for the private key, just an authoritative source for the public key certificate :) We don't have one currently, because I guess we didn't think this would be of use to anyone. If there is some use case for it to be published, we can do so... It seems like one would want to publish the certificates used to sign their kernel images, at the very least publish the CA if not the entire chain. Outside the kernel image itself, the only place I could find the "CN=Fedora Secure Boot CA" was in the signing request for the UEFI shim; I couldn't find the "CN=Fedora Secure Boot Signer" anywhere but the kernel image. Since I'm just doing dev/test at the moment I extracted the signing cert from the kernel image and I'm using that, but that isn't a good/general solution for a number of reasons. FWIW, once I have something that is working properly and suitable for upstreaming (it is still a prototype) I plan to work on getting it merged into the tboot upstream. However, regardless of my work on tboot, I think it would be nice to be able to verify a kernel signature without relying on the certificate chain stored within the kernel. I'm going to be at LSS-NA next week as well. I'll take notes on your presentation :) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] enable NVRAM driver on ppc
On 7/26/19 5:07 AM, Dan Horák wrote: NVRAM is enabled by default in the mainline kernel on all ppc machines. Related: #1732612 --- configs/fedora/generic/powerpc/CONFIG_NVRAM | 1 + kernel-ppc64le-debug.config | 2 +- kernel-ppc64le.config | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) create mode 100644 configs/fedora/generic/powerpc/CONFIG_NVRAM diff --git a/configs/fedora/generic/powerpc/CONFIG_NVRAM b/configs/fedora/generic/powerpc/CONFIG_NVRAM new file mode 100644 index 0..a296f9134 --- /dev/null +++ b/configs/fedora/generic/powerpc/CONFIG_NVRAM @@ -0,0 +1 @@ +CONFIG_NVRAM=y diff --git a/kernel-ppc64le-debug.config b/kernel-ppc64le-debug.config index 6d5a7c928..b2537db5d 100644 --- a/kernel-ppc64le-debug.config +++ b/kernel-ppc64le-debug.config @@ -3629,7 +3629,7 @@ CONFIG_NVME_TARGET_RDMA=m CONFIG_NVME_TARGET_TCP=m CONFIG_NVME_TCP=m # CONFIG_NVM is not set -# CONFIG_NVRAM is not set +CONFIG_NVRAM=y # CONFIG_NXP_TJA11XX_PHY is not set # CONFIG_OCFS2_DEBUG_FS is not set # CONFIG_OCFS2_DEBUG_MASKLOG is not set diff --git a/kernel-ppc64le.config b/kernel-ppc64le.config index a06cc62d2..7a96e9b5f 100644 --- a/kernel-ppc64le.config +++ b/kernel-ppc64le.config @@ -3608,7 +3608,7 @@ CONFIG_NVME_TARGET_RDMA=m CONFIG_NVME_TARGET_TCP=m CONFIG_NVME_TCP=m # CONFIG_NVM is not set -# CONFIG_NVRAM is not set +CONFIG_NVRAM=y # CONFIG_NXP_TJA11XX_PHY is not set # CONFIG_OCFS2_DEBUG_FS is not set # CONFIG_OCFS2_DEBUG_MASKLOG is not set I folded this into today's rawhide build. You should see this in kernel-5.3.0-0.rc1.git4.1.fc31 Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [fedora-arm] Re: [Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
On 7/23/19 4:19 AM, Jon Masters wrote: On 7/19/19 1:09 PM, Jon Masters wrote: On 7/4/19 6:12 PM, Jon Masters wrote: I think we have identified the root cause of the 32-bit builder issue. Many thanks to Paul and Peter for assistance in debugging. Here's my write-up, and we'll work with the vendor on a suitable mitigation to workaround any errata: https://medium.com/@jonmasters_84473/debugging-a-32-bit-fedora-arm-builder-issue-73295d7d673d The hardware vendor have reproduced what I believe to be an errata. Meanwhile, I've made a test kernel that forces CONFIG_HIGHPTE to off: https://koji.fedoraproject.org/koji/taskinfo?taskID=36328838 With this kernel, you still get LPAE but leaf level PTEs are not allocated from high memory any longer. This is because I believe the errata to be caused by stage 1 page table walks in the guest trapping to stage 2 (hypervisor) for e.g. Access bit updates on the host. When those occur, I believe there is a truncation of the guest IPA (guest memory) address to 32-bits, but only for page table entry walks. Normal translation faults I think are unaffected by this (TBC). Normally, we don't allocate PGDs (high level page table pieces) from high memory (we allocate those from kernel memory caches) but we DO allocate PTEs specifically from what might be high memory. Except when we force CONFIG_HIGHPTE to off. The patch I'm using is attached. It's currently being tested. If it works, I'm curious for input on temporarily carrying this in Fedora. In theory it means an LPAE system could starve for PTEs if it has many many processes running, but in practice I'm willing to bet LPAE is mostly used by Fedora for the 32-bit builders and that few people would actually complain if we did this. This stayed up for 3+ days. Eventually, there were a couple of faults that I thought were a problem but it turns out that they weren't and just generated noise on the host kernel log. So it looks good to go with the hack that I proposed and that's going to be in Fedora's 5.2 kernel. Detail: The host saw a couple of exits due to speculative page walks in the guest. It hit my previous logic due to S1 PTW but this time the HPFAR was correct vs what we would expect due to the 32-bit range limit. [359524.820107] JCM: WARNING: Mismatched FIPA and PA translation detected! [359524.899630] JCM: Hyper faulting far: 0x40163000 [359524.955044] JCM: Guest faulting far: 0xb6dbbf48 (gfn: 0x4016) [359525.025047] JCM: Guest TTBCR: 0xb5023500, TTBR0: 0x4c99ca80 [359525.092963] JCM: Guest PGD address: 0x4c99ca90 [359525.147312] JCM: Guest PGD: 0x58bf7003 [359525.193319] JCM: Guest PMD address: 0x58bf7db0 [359525.247671] JCM: Guest PMD: 0x40163003 [359525.293678] JCM: Guest PTE address: 0x40163dd8 [359525.348030] JCM: Guest PTE: 0x42367508fdf [359525.401338] JCM: Manually translated as: 0xb6dbbf48->0x367508000 [359525.474465] JCM: Faulting IPA page: 0x40163000 [359525.528814] JCM: Faulting PTE page: 0x40163000 [359525.583166] JCM: *** debugging data *** [359525.630215] JCM: FAR_EL2: 0xb6dbbf48 [359525.674133] JCM: HPFAR_EL2: 0x401630 [359525.718052] JCM: ESR_EL2: 0x828b [359525.761972] JCM: FAR_EL1: 0x4f2e50005b89b4 [359525.812149] JCM: ESR_EL1: 0x20b [359525.850852] JCM: *** debugging data *** [359525.897899] JCM: Fault occurred while performing S1 PTW -fixing [359525.969985] JCM: corrected fault_ipa: 0x40163000 [359526.026423] JCM: Corrected gfn: 0x4016 [359526.072427] JCM: handle access fault [359526.116347] JCM: ret: 0x1 You can see the FAR reported pfn 4016 and that's what we expected, so the above was just noise in my test kernel on the host monitoring a bit too carefully and not needing to actually fix anything this time. Jon. Peter applied the workaround on rawhide https://src.fedoraproject.org/rpms/kernel/c/d7341fee1c2697ae60db6fe23edc60ab55a59668?branch=master I can see about bringing it into F29/F30/stabilization if Peter doesn't get to it first. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 5.3.0-rc kernel-headers in rawhide and mass rebuild
On 7/18/19 3:37 PM, Florian Weimer wrote: Do you plan to leave in the -rc kernel headers for the mass rebuild? We see some rather odd issues with it when building glibc, and have trouble getting glibc ready for the mass rebuild. Thanks, Florian Yes, I screwed those up. https://koji.fedoraproject.org/koji/taskinfo?taskID=36328729 should be corrected, if not let me know. If you're still having problems, I can have file a request to have all the bad kernel-headers untagged from the buildroot. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: remove CONFIG_ASIX_PHY
On 7/10/19 2:49 PM, Paul Bolle wrote:
The Kconfig symbol ASIX_PHY was renamed to AX88796B_PHY in v5.2-rc6, see
upstream commit a9520543b123 ("net: phy: rename Asix Electronics PHY
driver"). CONFIG_AX88796B_PHY is already used in the configuration generation
system, so we can safely remove CONFIG_ASIX_PHY from that system.
Thanks, applied!
Signed-off-by: Paul Bolle
---
Bravely untested!
configs/fedora/generic/CONFIG_ASIX_PHY | 1 -
kernel-aarch64-debug.config| 1 -
kernel-aarch64.config | 1 -
kernel-armv7hl-debug.config| 1 -
kernel-armv7hl-lpae-debug.config | 1 -
kernel-armv7hl-lpae.config | 1 -
kernel-armv7hl.config | 1 -
kernel-i686-debug.config | 1 -
kernel-i686.config | 1 -
kernel-ppc64le-debug.config| 1 -
kernel-ppc64le.config | 1 -
kernel-s390x-debug.config | 1 -
kernel-s390x.config| 1 -
kernel-x86_64-debug.config | 1 -
kernel-x86_64.config | 1 -
15 files changed, 15 deletions(-)
delete mode 100644 configs/fedora/generic/CONFIG_ASIX_PHY
diff --git a/configs/fedora/generic/CONFIG_ASIX_PHY
b/configs/fedora/generic/CONFIG_ASIX_PHY
deleted file mode 100644
index 37bb545c7379..
--- a/configs/fedora/generic/CONFIG_ASIX_PHY
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_ASIX_PHY is not set
diff --git a/kernel-aarch64-debug.config b/kernel-aarch64-debug.config
index 09b0dc7b4848..3d34488611bc 100644
--- a/kernel-aarch64-debug.config
+++ b/kernel-aarch64-debug.config
@@ -380,7 +380,6 @@ CONFIG_ARM_TEGRA_DEVFREQ=m
CONFIG_ARM_TIMER_SP804=y
CONFIG_ARMV8_DEPRECATED=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m
CONFIG_ASYNC_RAID6_TEST=m
diff --git a/kernel-aarch64.config b/kernel-aarch64.config
index 25398e15cccf..a7a56d219249 100644
--- a/kernel-aarch64.config
+++ b/kernel-aarch64.config
@@ -380,7 +380,6 @@ CONFIG_ARM_TEGRA_DEVFREQ=m
CONFIG_ARM_TIMER_SP804=y
CONFIG_ARMV8_DEPRECATED=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m
CONFIG_ASYNC_RAID6_TEST=m
diff --git a/kernel-armv7hl-debug.config b/kernel-armv7hl-debug.config
index ba671f3c3ac6..2af4b888be95 100644
--- a/kernel-armv7hl-debug.config
+++ b/kernel-armv7hl-debug.config
@@ -374,7 +374,6 @@ CONFIG_ARM_VIRT_EXT=y
CONFIG_ARM=y
CONFIG_ARM_ZYNQ_CPUIDLE=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m
CONFIG_ASYNC_RAID6_TEST=m
diff --git a/kernel-armv7hl-lpae-debug.config b/kernel-armv7hl-lpae-debug.config
index 06b928317038..6acc262c514a 100644
--- a/kernel-armv7hl-lpae-debug.config
+++ b/kernel-armv7hl-lpae-debug.config
@@ -361,7 +361,6 @@ CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=m
CONFIG_ARM_VIRT_EXT=y
CONFIG_ARM=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m
CONFIG_ASYNC_RAID6_TEST=m
diff --git a/kernel-armv7hl-lpae.config b/kernel-armv7hl-lpae.config
index b9c5c1d4d64c..3e4f2009ea57 100644
--- a/kernel-armv7hl-lpae.config
+++ b/kernel-armv7hl-lpae.config
@@ -361,7 +361,6 @@ CONFIG_ARM_VEXPRESS_SPC_CPUFREQ=m
CONFIG_ARM_VIRT_EXT=y
CONFIG_ARM=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m
CONFIG_ASYNC_RAID6_TEST=m
diff --git a/kernel-armv7hl.config b/kernel-armv7hl.config
index 10da3c33de83..cf36f416d78d 100644
--- a/kernel-armv7hl.config
+++ b/kernel-armv7hl.config
@@ -374,7 +374,6 @@ CONFIG_ARM_VIRT_EXT=y
CONFIG_ARM=y
CONFIG_ARM_ZYNQ_CPUIDLE=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE=m
CONFIG_ASYNC_RAID6_TEST=m
diff --git a/kernel-i686-debug.config b/kernel-i686-debug.config
index 5a2cf9ca31f0..78f81dca88ef 100644
--- a/kernel-i686-debug.config
+++ b/kernel-i686-debug.config
@@ -253,7 +253,6 @@ CONFIG_ARCH_MULTIPLATFORM=y
CONFIG_ARM64_ERRATUM_858921=y
CONFIG_ARM_PTDUMP_DEBUGFS=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASUS_LAPTOP=m
CONFIG_ASUS_NB_WMI=m
CONFIG_ASUS_WIRELESS=m
diff --git a/kernel-i686.config b/kernel-i686.config
index 20bb2ce2bdb2..f73340f85459 100644
--- a/kernel-i686.config
+++ b/kernel-i686.config
@@ -252,7 +252,6 @@ CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCNET is not set
CONFIG_ARM64_ERRATUM_858921=y
# CONFIG_AS3935 is not set
-# CONFIG_ASIX_PHY is not set
CONFIG_ASUS_LAPTOP=m
CONFIG_ASUS_NB_WMI=m
CONFIG_ASUS_WIRELESS=m
diff --git a/kernel-ppc64le-debug.config b/kernel-ppc64le-debug.config
index 16409acf7e02..2cdc0886ef5b 100644
--- a/kernel-ppc64le-debug.config
+++ b/kernel-ppc64le-debug.config
@@ -197,7 +197,6 @@
Re: Enable CONFIG_RC_XBOX_DVD ?
On 7/8/19 9:20 AM, Bastien Nocera wrote: Hey, Would it be possible to enable the CONFIG_RC_XBOX_DVD kernel config, as a module, so that they can be used with Fedora? While the device itself might look like it isn't compatible with anything but an original XBox: https://retro.poromagia.com/media/images/products/2018/06/Xbox-DVD-Movie-Playback-Kit-1-175047.JPG It can be plugged into any machine with USB easily, with a very cheap adapter: https://www.ebay.com/itm/273293737952 Cheers (I have 5 of those on my desk as we speak) ___ I enabled this on rawhide. (I think this was going into stabilization as well?) Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Can Fedora enable CONFIG_DETECT_HUNG_TASK ?
On 5/18/19 11:48 AM, Alan Jenkins wrote: Hi I was surprised to realize that Fedora kernels do not enable CONFIG_DETECT_HUNG_TASK. Is there any reason why it should not enable it? Fedora kernels appear to be an outlier here, v.s. RHEL, Debian, Ubuntu and SUSE. I'm not taking a postion on whether ABRT needs to report hung tasks. If ABRT needs explicit support to report them, that could be added later. We only need to be confident that ABRT isn't going to something we don't want it to. When the kernel detects all of userspace is hung, this could provide useful console logs on Fedora Server, other non-GUI installs, or expert users who resort to serial or network console logging. When the hang is more specific, seeing the hung task in the kernel log is a nice and quick pointer towards the problem. I recently wrote some advice which mentioned the hung task detector. I observer that it is one of a set of handy crash/hang messages in the kernel.[1] [1] https://unix.stackexchange.com/questions/518554/debian-stretch-vm-becomes-quasi-unresponsive-every-few-days/ It seems undesirable for Fedora to disable this type of message. Especially considering Fedora's quick turnover of kernels, and exposure to exciting new bugs :-). I haven't checked if it is enabled in Rawhide, but I feel like it should be enabled for all Fedora kernels. Thanks for the kernels :-) Alan > Say Y here to enable the kernel to detect "hung tasks", which are bugs that cause the task to be stuck in uninterruptible "D" state indefinitely. > > When a hung task is detected, the kernel will print the current stack trace (which you should report), but the task will stay in uninterruptible state. If lockdep is enabled then all held locks will also be reported. This feature has negligible overhead. (This option is not a sophisticated lock cycle detector. It is just a simple timeout. The upstream default timeout is 2 minutes. Once a (default) 10 hung task messages have been logged, the kernel stops logging them). We do have this on in the debug version of the kernel but not the regular version. I think this is something we set a while ago but never really thought about again. My one hesitation about enabling this would be that certain devices might be particularly prone to hanging and this could create a lot of noise for us to sort through. That said, I think this could be a good candidate for turning on in rawhide so it gets enabled in F31. If nobody raises any serious objections, I'll see about turning it on in rawhide. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] kernel-tools.spec: Adding libbpf package
On 5/16/19 2:42 PM, Jiri Olsa wrote: On Wed, Apr 03, 2019 at 06:38:38PM +, Jeremy Cline wrote: Hi Jiri, On 4/2/19 6:35 AM, Jiri Olsa wrote: hi, please consider attached change that adds libbpf sub package to be generated within kernel-tools spec. We need libbpf in a separate package, starting with basic files, some more might come later if there's a need. thanks, jirka --- I've applied this and rebuilt kernel-tools for Rawhide as kernel-tools-5.1.0-0.rc3.git0.2.fc31. hi, it'd be great to have libbpf for Fedora 30 as well, I have scratch build in here: https://koji.fedoraproject.org/koji/taskinfo?taskID=34883714 but I had to add 2 patches on top of v5.0 I assume Fedora 30 will stay on v5.0 .. is there some policy on adding this to Fedora 30? Fedora 30 will get rebased to 5.1 which should be happening sometime next week. We're pretty flexible with what we let into releases so I think it's fine to go in, unless Jeremy sees some issue. Thanks, Laura thanks, jirka ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
please remember to test F28 kernels
F28 is seeing a pretty big fall off in karma for new kernels. This is somewhat expected as we move towards F30 release. If you happen to have an F28 system around, please remember to test and give karma. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Rebase plans for kernel 5.0
Hi, As you probably have seen, kernel 5.0 was released last night. This has been built in rawhide. We'll be following the usual rebase procedure for f29 and f28: Around the time when 5.0.2 or 5.0.3 is released, that kernel will go into f29. f28 will be rebased shortly afterwards. We don't have any control over when upstream will release a stable kernel but best guess would be that f29 will get 5.0 by early to mid April. f30 is building 5.0 right now and will be getting the usual stable updates as they come out. I'll also be doing a rebase on the stabilization branch and will be doing builds in the kernel-stabilization copr. If you want early access to 5.0, I recommend just using the f30 builds (if you find bugs, please report them so we can get them fixed) Thanks, Laura P.S. If you are using F28, please make sure to keep giving those kernels karma in bodhi. We're seeing a fall off in testing. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: kernel bug triage cc list
On 2/25/19 1:42 PM, Chris Murphy wrote: Hi, Reading this https://fedoraproject.org/wiki/KernelBugTriage#Triage_Quickstart Is it possible to get bugzi...@colorremedies.com added to distribution whenever a bug is set to CC fedora-kernel-bt...@fedoraproject.org ? Thanks, No objections here. It's managed by an ansible playbook so someone who has access to the playbook (jcline) can make the change and it will get automatically updated. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On 2/19/19 10:47 AM, Dulaney wrote: On Gearr 18, 2019 aig 12:26:04f -0800, sgrìobh Laura Abbott: Yes, that was the case I was concerned about with gcc being updated. I guess the case would be where the kernel gets built with a different gcc that isn't yet on a local system. Doing a batched bodhi update could fix this for stable releases but we don't have that on rawhide. Requiring the sync also seems like a pain to deal with. Laura So, just out of curiosity, why can't these be in their own rpm(s) that get updated every time gcc does? If I'm reading you correctly, the gcc modules are dependent on gcc, not the kernel features on specific versions of the gcc modules. No, these plugins are tied to the kernel itself and can be updated with each kernel version. They need to exist in the kernel spec file at kernel build time. They aren't dependent on the gcc version per se but they need to get rebuilt each time there is a new gcc. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Help remove scriptlets from the kernel?
At DevConf a few weeks ago, Stephen Gallagher and Will Woods gave a talk about removing rpm scriptlets. The recording hasn't been uploaded yet but the slides are available https://schd.ws/hosted_files/devconfcz2019/bc/scriptlet-reform-school-3.pdf The kernel uses a few scriptlets at the moment which will need to be cleaned up, most likely replaced with file triggers. We'll certainly be looking at this but if anyone is super excited about cleaning up packaging, this could be a good project (and much appreciated!) Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On 2/15/19 3:47 AM, Florian Weimer wrote: * Laura Abbott: I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel since I've heard some people express interest in stackleak (I'm interested as well). a gcc plugin gets built as an .so file for use during compilation. This means we need to package this .so file as part of kernel-devel for building external modules. This is easy to do but it also now introduces a tighter restriction on the toolchain used for building modules since gcc will refuse to load a plugin and fail to build the module if the versions don't match. Arguably, there's always been a requirement to use the same toolchain version but there may have been some flexibility for forcing it. Can anyone see major problems with requiring the same toolchain version for building external modules as the kernel? If those kernel modules happen to build userspace components as well (and use the right build flags), then they have such a toolchain dependency already, indirectly through the annobin plugin. The main caveat I see is that it is tricky to handle the version constraints correctly (both in the plugin and at the RPM level). For a long time, the annobin constraints were too tight. Most modules are probably not going to be compiling userspace components so I'm not too concerned there. Thanks for the pointer to annobin though, I hadn't thought about how to actually specify the requirement in the rpm file. I'm not sure if this example convinces me I should do gcc plugins or it's not worth the hassle. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On 2/14/19 4:19 PM, stan wrote: On Thu, 14 Feb 2019 15:09:04 -0800 Laura Abbott wrote: Can anyone see major problems with requiring the same toolchain version for building external modules as the kernel? If gcc is updated between Fedora kernel versions and someone wants to build a module, it would build but be unuseable? If that is true, then gcc updates should just be released at the same time as a kernel built with them to finesse the issue. I suspect that this would be a rare issue in practice. Oops, I forgot about rpmfusion, where they do build modules, and akmod which builds modules automatically when a new kernel is released. That would make it more likely to occur, I think. Yes, that was the case I was concerned about with gcc being updated. I guess the case would be where the kernel gets built with a different gcc that isn't yet on a local system. Doing a batched bodhi update could fix this for stable releases but we don't have that on rawhide. Requiring the sync also seems like a pain to deal with. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
toolchain requirements for external kernel modules
I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel since I've heard some people express interest in stackleak (I'm interested as well). a gcc plugin gets built as an .so file for use during compilation. This means we need to package this .so file as part of kernel-devel for building external modules. This is easy to do but it also now introduces a tighter restriction on the toolchain used for building modules since gcc will refuse to load a plugin and fail to build the module if the versions don't match. Arguably, there's always been a requirement to use the same toolchain version but there may have been some flexibility for forcing it. Can anyone see major problems with requiring the same toolchain version for building external modules as the kernel? Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: re-enable CONFIG_JUMP_LABEL on s390x
On 2/11/19 1:57 PM, Dan Horák wrote: Hi, the root cause of https://marc.info/?t=15482482101=1=2 was fixed in gcc trunk (only) and it's now available in gcc-9.0.1-0.4.fc30. Something like the patch bellow is needed, but things get complicated, because the new constraint won't be available in gcc < 9 (afaik). A scratch build succeeded - https://koji.fedoraproject.org/koji/taskinfo?taskID=32736584 What I changed - updated 0001-s390-jump_label-Correct-asm-contraint.patch and added as Patch5xx - reverted the *config* part of 1b48caa (Disable CONFIG_JUMP_LABEL on s390x) diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h index e2d3e6c43395..41dabfd8518d 100644 --- a/arch/s390/include/asm/jump_label.h +++ b/arch/s390/include/asm/jump_label.h @@ -22,7 +22,7 @@ static inline bool arch_static_branch(struct static_key *key, bool branch) ".long0b-.,%l[label]-.\n" ".quad%0-.\n" ".popsection\n" - : : "X" (&((char *)key)[branch]) : : label); + : : "jdd" (&((char *)key)[branch]) : : label); return false; label: return true; @@ -36,7 +36,7 @@ static inline bool arch_static_branch_jump(struct static_key *key, bool branch) ".long0b-.,%l[label]-.\n" ".quad%0-.\n" ".popsection\n" - : : "X" (&((char *)key)[branch]) : : label); + : : "jdd" (&((char *)key)[branch]) : : label); return false; label: return true; With regards, Dan Thanks for following up. I committed the proposal from https://marc.info/?l=linux-kernel=154937077018072=2 and reenabled CONIFG_JUMP_LABEL on today's -rc6 build. I'm guessing that patch will get committed so I suggest we watch that and continue to follow up upstream. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Backporting some patches to use i915.fastboot=1 by default
On 1/25/19 12:43 AM, Hans de Goede wrote: Hi, To complete flickerfree boot support and remove the last modeset on systems using an Intel iGPU, I've been working with i915 upstream to make i915.fastboot=1 the default, this is part of: https://fedoraproject.org/wiki/Changes/FlickerFreeBoot I've just gotten agreement on a patch for this and a Reviewed-by for that patch. That patch enables 915.fastboot=1 by default on Skylake (gen9) and newer Intel graphics. I would like to cherry-pick this patch and some small related i915 bugfixes into the Fedora 5.0.0 kernel. This is only intended for rawhide / F30, I will add a note to rebase-notes that the patch flipping the default for gen9+ should be dropped for f29 and older (the bug fixes can stay). I would like to add these patches to the current rawhide kernel soon, so that this get as much testing as possible. Is that ok with you (the Fedora kernel team) ? Regards, Hans No objections from me. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
s390x kernel disabled on Fedora rawhide
gcc9 exposed an underlying issue with some inline asm on s390x. I've emailed upstream about the issue but it's still not fixed. In the interest of continuing to test kernels, I've disabled this arch in rawhide kernels for now. I'll be keeping an eye on this and plan to turn this arch back on as soon as I can. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 2/2] Don't require python3 for a string replace
On 1/15/19 1:44 AM, pa...@fliagreco.com.ar wrote:
From: Pablo Greco
---
kernel.spec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel.spec b/kernel.spec
index 280..25ad968 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1228,7 +1228,7 @@ BuildKernel() {
# make sure EXTRAVERSION says what we want it to say
# Trim the release if this is a CI build, since KERNELVERSION is limited
to 64 characters
-ShortRel=$(python3 -c "import re; print(re.sub(r'\.pr\.[0-9A-Fa-f]{32}', '',
'%{release}'))")
+ShortRel=$(perl -e "print \"%{release}\" =~ s/\.pr\.[0-9A-Fa-f]{32}//r")
perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION =
-${ShortRel}.%{_target_cpu}${Flav}/" Makefile
# if pre-rc1 devel kernel, must fix up PATCHLEVEL for our versioning scheme
So I was seeing this cause a build failure when I tried a scratch build
https://koji.fedoraproject.org/koji/taskinfo?taskID=32051959
I've been having problems sometimes with line endings so it might have been
a problem with how I applied the patch but did this work for you?
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: add arm file for CONFIG_PCI_MESON
On 1/12/19 3:13 AM, Paul Bolle wrote:
Commit c9c254b74995 ("minor Arm config tweaks") set CONFIG_PCI_MESON to
'y' for all shipped arm and aarch64 .config files. It didn't add the
corrresponding change to the configuration generation directory. Do so
now.
Signed-off-by: Paul Bolle
---
configs/fedora/generic/arm/CONFIG_PCI_MESON | 1 +
1 file changed, 1 insertion(+)
create mode 100644 configs/fedora/generic/arm/CONFIG_PCI_MESON
diff --git a/configs/fedora/generic/arm/CONFIG_PCI_MESON
b/configs/fedora/generic/arm/CONFIG_PCI_MESON
new file mode 100644
index ..2c5ba5ddf5f8
--- /dev/null
+++ b/configs/fedora/generic/arm/CONFIG_PCI_MESON
@@ -0,0 +1 @@
+CONFIG_PCI_MESON=y
Peter corrected this already.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] configs: Correct four non-standard filenames
On 1/12/19 9:37 AM, Paul Bolle wrote:
These non-standard filenames have no effect on the build, but should
still be fixed since they could be confusing (to people and scripts).
Signed-off-by: Paul Bolle
---
...FIG_ALTERA_PR_IP_CORE_PLAT=n => CONFIG_ALTERA_PR_IP_CORE_PLAT} | 0
configs/fedora/generic/{CONFIG_B53_SERDES=n => CONFIG_B53_SERDES} | 0
.../{CONFIG_FPGA_MGR_ZYNQ_FPGA=n => CONFIG_FPGA_MGR_ZYNQ_FPGA}| 0
.../x86/{CONFIG_SENSORS_APPLESMC=m => CONFIG_SENSORS_APPLESMC}| 0
4 files changed, 0 insertions(+), 0 deletions(-)
rename configs/fedora/generic/{CONFIG_ALTERA_PR_IP_CORE_PLAT=n =>
CONFIG_ALTERA_PR_IP_CORE_PLAT} (100%)
rename configs/fedora/generic/{CONFIG_B53_SERDES=n => CONFIG_B53_SERDES}
(100%)
rename configs/fedora/generic/{CONFIG_FPGA_MGR_ZYNQ_FPGA=n =>
CONFIG_FPGA_MGR_ZYNQ_FPGA} (100%)
rename configs/fedora/generic/x86/{CONFIG_SENSORS_APPLESMC=m =>
CONFIG_SENSORS_APPLESMC} (100%)
diff --git a/configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT=n
b/configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT
similarity index 100%
rename from configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT=n
rename to configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT
diff --git a/configs/fedora/generic/CONFIG_B53_SERDES=n
b/configs/fedora/generic/CONFIG_B53_SERDES
similarity index 100%
rename from configs/fedora/generic/CONFIG_B53_SERDES=n
rename to configs/fedora/generic/CONFIG_B53_SERDES
diff --git a/configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA=n
b/configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA
similarity index 100%
rename from configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA=n
rename to configs/fedora/generic/CONFIG_FPGA_MGR_ZYNQ_FPGA
diff --git a/configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC=m
b/configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC
similarity index 100%
rename from configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC=m
rename to configs/fedora/generic/x86/CONFIG_SENSORS_APPLESMC
Applied. Thanks again for the cleanup!
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/3] Kconfig symbol cleanup for v5.0-rc1
On 1/11/19 6:55 AM, Paul Bolle wrote: This short series cleans up all references to Kconfig symbols that have no effect on the build. This series is way too boring to review. But it can be tested by comparing the generated .config files (in the BUILD directory) before and after this series. These generated .config files should not change. Unless I made a mistake, that is. Anyhow, review and/or comments are, as always, appreciated. A build run on Fedora's build farm would be nice too. (I don't have access to that system.) But if I'm right that build should show no differences whatsoever. Nothing changed after running ./build_configs.sh so I went ahead and applied these to rawhide. It should show up in tomorrow's build. Thanks for taking the time to clean this up. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/3] Kconfig symbol cleanup for v5.0-rc1
On 1/11/19 7:16 AM, Paul Bolle wrote: Peter Robinson schreef op vr 11-01-2019 om 15:04 [+]: On Fri, Jan 11, 2019 at 2:56 PM Paul Bolle wrote: configs/fedora/generic/CONFIG_RTC | 1 - I'm pretty sure RTC is still a very valid option. Upstream says: depends on ALPHA Yes, that looks like the ancient RTC driver which is different from drivers/rtc/ .../fedora/generic/CONFIG_TCG_TIS_ST33ZP24| 1 - And that looks relevant. Well, Fedora's .configs only have # CONFIG_TCG_TIS_ST33ZP24_I2C is not set and/or # CONFIG_TCG_TIS_ST33ZP24_SPI is not set so it seems nothing in the 14 builds cares about CONFIG_TCG_TIS_ST33ZP24. Yes, CONFIG_TCG_TIS_ST33ZP24 is a symbol that only gets selected, it's not actually one we can configure. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 1/2] Enable CONFIG_NET_SCH_ETF
On 12/28/18 1:34 AM, Artem Bityutskiy wrote: Hello folks, is there anything I can do for this patch-set to get maintainers' attention? Thanks! In the future, please wait a longer time before asking about the status, especially given this was over a holiday break. I applied the patch to rawhide so you should see it in the next few days. On Thu, 2018-12-20 at 11:47 +0200, Artem Bityutskiy wrote: From: Artem Bityutskiy Enable the ETF queuing discipline (qdisc) as a module, similar to many other qdiscs that we have enabled as modules. ETF stands for Earliest TxTime first and it enables applications to schedule network packets to be sent in the future. Signed-off-by: Artem Bityutskiy .. snip ... ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On 12/11/18 3:48 AM, Alan Jenkins wrote: Hi mattdm suggested the upcoming scheduler change should be discussed here.[1] I might not have enough time to talk details at the moment, but I noticed this is coming up relatively soon. This is what I understand so far about the decision. Thanks for all the software, Alan [1] https://unix.stackexchange.com/questions/483881/what-does-fedora-workstation-29-use-as-the-default-i-o-scheduler ## CFQ is scheduled for removal Jens Axboe is planning to remove the CFQ I/O scheduler in 4.21. That is, CFQ is part of the "legacy" single-queue block layer, which is going to be removed for ease of maintenance.[2] Axboes last comment on this timing was made *after* the fix for data corruption on MQ. I.e. the data corruption covered by the recent thread on this list. *Obligatory disclaimer*. Read the paragraph above, and consider waiting for the next stable kernel update, before you test MQ (including BFQ) on your own machine :-). [2] "It's definitely still going" - Jens Abxoe. https://bugzilla.kernel.org/show_bug.cgi?id=201685#c279 ## The kernel wants us to choose our new default For devices which have only one hardware queue, the new upstream default is mq-deadline. Going from CFQ to mq-deadline is a significant change. For example, the deadline scheduler does not support ionice. The alternative to the MQ deadline scheduler will be BFQ.[3][4] Upstream discussed this, and the powers that be (mostly Axboe :-) are explicitly expecting us (downstreams) to make this decision.[5] [3] BFQ: http://algo.ing.unimo.it/people/paolo/disk_sched/description.php [4] https://unix.stackexchange.com/questions/375600/how-to-enable-and-use-the-bfq-scheduler [5] "I'd prefer if the distros would lead the way on this, as theyare the ones that will most likely see the most bug reports" - Jens Axboe, https://www.spinics.net/lists/linux-block/msg31062.html ## Arguments for (or against) BFQ? Paolo Valente kindly wrote an informative response, which I will copy in to a separate message. The following is my very limited first impression. Personally I lean towards BFQ by default. It appears nominated as the successor to CFQ, I think it's worthy as such, and it makes distinct improvements of it's own. I would recommend it with more confidence if I understood how the improvements work :-). The deadline scheduler probably isn't a *complete* disaster. Ubuntu ran with the deadline scheduler for a while.[6] I haven't checked whether they changed the tuning knobs though! RHEL7 defaults to CFQ for SATA drives. This is notable given that it recommends avoiding (or tuning) CFQ on basically any other server hardware (and specifically to avoid it on hardware RAID).[7] I've tried BFQ on my laptops hard drive (not SSD). It has some associated tests for responsiveness (the "S" tests). I don't have a real-world feel for it, but I agree the test numbers are an impressive improvement over CFQ. I don't have results for the S tests on the deadline scheduler. I did note the eponymous "deadline" for sync reads has a default of 500 ms. The other test I have, is that "deadline" doesn't match CFQ's level of fairness for reads v.s. writes, even with the recent addition of WBT. Neither approached what I would actually call fairness. BFQ did.[8] This is due to BFQ's "compensations" for device writeback caching and NCQ. And allegedly for Linux writeback. These extra compensations are the part I don't understand, so far.[9] [6] https://askubuntu.com/questions/784442/why-does-ubuntu-16-04-set-all-drive-io-schedulers-to-deadline [7] RHEL7 IO schedulers: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/chap-red_hat_enterprise_linux-performance_tuning_guide-storage_and_file_systems#sect-Red_Hat_Enterprise_Linux-Performance_Tuning_Guide-Considerations-IO_Schedulers [8] I tried to closely match the test from the cover letters from the WBT patch series. I don't have detailed statistics, but I believe deadline+WBT was less fair than CFQ. It was definitely not more fair. https://unix.stackexchange.com/questions/483269/determine-the-specific-benefit-of-writeback-throttling-config-wbt [9] https://groups.google.com/forum/#!topic/bfq-iosched/yjZDn_HnLIc Thanks for starting this discussion. Based on this thread and other discussions, I'm going to see about enabling BFQ for 4.21. Once 4.21-rc1 comes out (i.e. almost all configs should be in) we can review the settings and see if anything needs to be adjusted. If I get some time before then (i.e. before I leave for holiday) I'll see if I can change the defaults. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
Re: ext4 file system corruption -> https://bugzilla.kernel.org/show_bug.cgi?id=201685
On 12/3/18 8:46 AM, Reindl Harald wrote: Am 03.12.18 um 17:42 schrieb Laura Abbott: On 12/2/18 6:20 AM, Reindl Harald wrote: how does Fedora think to handle https://bugzilla.kernel.org/show_bug.cgi?id=201685 4.18.20 is the last 4.18.x and happily at least 4.18.20 from F27 runs fine on F28 systems but given that bug upgrade to 4.19.x seems to be just a lottery with your data - on some or even many systems all seems to be fine BUT when you are affected and nobody until now knows the root cause honestly the rebase to 4.19 was too fast to start with! WHY did that rebase happen at all? kernel-4.19.2-200.fc28 jcline 2018-11-15 01:34:18 bug reported: 2018-11-13 19:42:20 UTC and yes i had that bugreport in my inbox just because i have subscribed to filesystem / raid related mailing lists and the word "crazy" appeared in my mind when i saw the rebase two days later because i expect that downstream maintainers at least have the same lists subscribed ordinary users have We're working with the upstream maintainers to narrow down the problem. At least on Fedora we haven't seen any reports of corruption reported on our bugzilla which is a useful data point for the upstream maintainers. We'll keep you updated if we find anything. here you have the first Fedora user upstream https://bugzilla.kernel.org/show_bug.cgi?id=201685#c198 There's now a fix proposed upstream https://bugzilla.kernel.org/show_bug.cgi?id=201685#c255 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: ext4 file system corruption -> https://bugzilla.kernel.org/show_bug.cgi?id=201685
On 12/2/18 6:20 AM, Reindl Harald wrote: how does Fedora think to handle https://bugzilla.kernel.org/show_bug.cgi?id=201685 4.18.20 is the last 4.18.x and happily at least 4.18.20 from F27 runs fine on F28 systems but given that bug upgrade to 4.19.x seems to be just a lottery with your data - on some or even many systems all seems to be fine BUT when you are affected and nobody until now knows the root cause honestly the rebase to 4.19 was too fast to start with! WHY did that rebase happen at all? kernel-4.19.2-200.fc28 jcline 2018-11-15 01:34:18 bug reported: 2018-11-13 19:42:20 UTC and yes i had that bugreport in my inbox just because i have subscribed to filesystem / raid related mailing lists and the word "crazy" appeared in my mind when i saw the rebase two days later because i expect that downstream maintainers at least have the same lists subscribed ordinary users have We're working with the upstream maintainers to narrow down the problem. At least on Fedora we haven't seen any reports of corruption reported on our bugzilla which is a useful data point for the upstream maintainers. We'll keep you updated if we find anything. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 0/3] Fix all Kconfig "override" warnings
On 11/13/18 8:57 AM, Paul Bolle wrote:
For some time now the build generates a number of override warnings,
like this one:
[...]:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state
These warnings are triggered when the build uses a .config that has
more than one option set in a Kconfig "choice". But the kernel build
system will only allow one option per "choice".
This small series fixes all current warnings. It doesn't change the
final .configs that the kernel build system will use. (That was my goal
for this series.) So this series should only result in a quieter build.
I'd really appreciate any testing to uncover whether I missed something.
I'm behind due to conference travel but I'm very happy to see this
getting fixed. I'll make sure to take a look at this if someone
else doesn't get to it first.
Thanks,
Laura
Paul Bolle (3):
configs: correct cpu accounting configuration
configs: correct memory configuration
configs: use CONFIG_UNWINDER_ORC only in x86/x86_64
configs/fedora/generic/CONFIG_FLATMEM_MANUAL | 1 -
configs/fedora/generic/CONFIG_VIRT_CPU_ACCOUNTING_NATIVE | 2 +-
.../fedora/generic/powerpc/CONFIG_VIRT_CPU_ACCOUNTING_NATIVE | 1 +
configs/fedora/generic/s390x/CONFIG_TICK_CPU_ACCOUNTING | 1 +
.../fedora/generic/s390x/CONFIG_VIRT_CPU_ACCOUNTING_NATIVE | 1 +
configs/fedora/generic/x86/x86_64/CONFIG_TICK_CPU_ACCOUNTING | 1 +
configs/fedora/generic/{ => x86/x86_64}/CONFIG_UNWINDER_ORC | 0
kernel-aarch64-debug.config | 4 +---
kernel-aarch64.config| 4 +---
kernel-armv7hl-debug.config | 4 +---
kernel-armv7hl-lpae-debug.config | 4 +---
kernel-armv7hl-lpae.config | 4 +---
kernel-armv7hl.config| 4 +---
kernel-i686-debug.config | 3 +--
kernel-i686.config | 3 +--
kernel-ppc64le-debug.config | 2 --
kernel-ppc64le.config| 2 --
kernel-s390x-debug.config| 4 +---
kernel-s390x.config | 4 +---
kernel-x86_64-debug.config | 5 ++---
kernel-x86_64.config | 5 ++---
21 files changed, 19 insertions(+), 40 deletions(-)
delete mode 100644 configs/fedora/generic/CONFIG_FLATMEM_MANUAL
create mode 100644
configs/fedora/generic/powerpc/CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
create mode 100644 configs/fedora/generic/s390x/CONFIG_TICK_CPU_ACCOUNTING
create mode 100644
configs/fedora/generic/s390x/CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
create mode 100644
configs/fedora/generic/x86/x86_64/CONFIG_TICK_CPU_ACCOUNTING
rename configs/fedora/generic/{ => x86/x86_64}/CONFIG_UNWINDER_ORC (100%)
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH 1/2] Disable kernel-headers only in Fedora
On 10/11/2018 05:58 AM, pa...@fliagreco.com.ar wrote:
From: Pablo Greco
---
kernel.spec | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel.spec b/kernel.spec
index 311ef4c..e90a714 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -125,8 +125,10 @@ Summary: The Linux kernel
%define debugbuildsenabled 0
# Kernel headers are being split out into a separate package
+%if 0%{?fedora}
%define with_headers 0
%define with_cross_headers 0
+%endif
%if %{with_verbose}
%define make_opts V=1
Thanks, I applied both of the patches to rawhide.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option
On 10/02/2018 08:18 AM, Lennart Poettering wrote: On Di, 02.10.18 14:34, Hans de Goede (hdego...@redhat.com) wrote: Ok fair enough. Keeping it easy for users to try out hibernate is a valid argument. This is just weird. Why would GNOME expose a button to regular user that reads "hey, press me, please use this feature, but it's not going to work, and nobody is going to help you with it or fix bugs, kthxbye". That's just awful UI. Quite frankly, this is quite ridiculous. GNOME is not the only user of this, we shouldn't expose crap that doesn't work in the UI, regardless what the UI looks like. GNOME has every right to assume that what the underlying layers advertise works. And when it doesn't then the underlying layers should stop advertising this. If the kernel folks apprently are not willing to clean this up, nor stop advertising its availability, then I guess we can mask this out in the systemd RPM, but what a mess, now systemd.rpm suddenly becomes the dumping ground for policy decisions when kernel code is good enough and when it isn't, and when the kernel maintainers want to support something or not. I think we're stuck between two competing goals of Fedora: give users as many features as possible vs. having those features be stable. In the kernel we've tended to err on the side of allowing as many options as possible and just not giving support. The big hammer of disabling hibernation doesn't differentiate between cases where hibernate is fundamentally broken and may never work (hardware or firmware issues) vs. might just need some quirks. Is there more information the kernel could expose to allow a more informed decision about whether we should allow hibernate as an option to the user? Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option
On 10/02/2018 09:16 AM, Bastien Nocera wrote: - Original Message - On Di, 02.10.18 10:16, Bastien Nocera (bnoc...@redhat.com) wrote: Until the kernel can use a dedicated partition for hibernation, which would fix the majority of problems users can encounter, we're just offering more sharp edges with which to cut themselves. As I understand the problems have more to do with hardware combinations, and driver code not getting things right, the actual serialization of stuff is fine and unproblematic... There's problems with: - not having enough swap space available at a particular instant - swap being encrypted and not allowing restore because the keys aren't there anymore - swap not being encrypted, which could leak information down the line - resume= not being there in the default parameters, so dracut needing to rewrite the initrd before hibernation is considered done (?) If the drivers being broken were the only problem, then reporting bugs upstream for those drivers would help, just in the same way it helped for suspend 10 years ago. In my experience, the problem isn't so much with specific drivers, and more with the whole infrastructure, whether in the kernel, user-space, or a combination of both. This is the real objection I have: hibernation ultimately has many different parts and just disabling at the kernel level misses some important pieces. It's not clear to me if just allowing users to enable kernel support on the command line will be enough to have a good end user experience. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Disabling kernel's hibernate support by default, allow re-enabling it with a kernel cmdline option
On 10/02/2018 08:12 AM, Lennart Poettering wrote: Can you give examples of other kernel subsystems that are also advertised as available by the Fedora kernel, and part of the core kernel RPM but are of this "tech preview" kind? Another example would be kexec. The Fedora kernel nominally supports this feature but it requires some setup and tends to be finicky to set up. We'd certainly take patches to fix it and we've started to get more engaged with the kexec team to make sure it works but ultimately it's best effort. We also have the various wireless drivers which get a good amount of support from various developers but ultimately if some particular hardware configuration doesn't work quite right there's not a lot we can do. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Headsup: Adding "efi/x86: Call efi_parse_options() from efi_main()" to F29+ kernels
On 09/13/2018 06:25 AM, Hans de Goede wrote: Hi, I've been getting some reports that the kernel is not fully quiet / the boot is not fully smooth / flickerfree when using secure boot. This is fixed by this patch: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit/?id=ecb77f61f10b36476133e31cdc001892b5463b90 I believe that this patch is safe, so I plan to add it as downstream patch to the F29+ kernels for now. But this is early boot code so you never know. Hence the heads-up, if there are mysterious boot failures this might be the culprit (it would be weird if it is, but you never know). Regards, Hans Thanks for the heads up Hans. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 4.18 Rebase plans
On 08/14/2018 09:14 AM, Laura Abbott wrote: Hi, As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was built for rawhide yesterday. We will be following roughly the same rebase schedule as in the past. F28 will get the rebase first, typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter. My best guess for when this would happen would be middle of September. As always, we'll keep you updated on any new developments. Thanks, Laura P.S. As a general reminder, if you like F27 please remember to give karma to kernels. The kernel is now in testing for F28. Please test and give karma as I would like to push very soon. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 4.18 Rebase plans
On 08/29/2018 01:05 PM, Jason L Tibbitts III wrote: "LA" == Laura Abbott writes: LA> My current plan is to push the F28 rebase early next week. If you LA> get a chance, please test the F29 kernel or the package in the LA> kernel-stabilization COPR. I thought we weren't doing kernel-stabilization this time around because the F29 kernels were sufficient, but looking now I see it's there (though the 4.18.5 build failed). I didn't end up pushing anything to the kernel-stabilization branch but I did use the stabilization repo to test the actual rebased versions since the work looks slightly different between a straight F29 branch and a rebase (dropping some patches and config options) I've been running F29 kernels (on my F28 desktop) since 4.18.0 showed up there and everything has been well. Currently running kernel-4.18.5-300.fc29 from https://koji.fedoraproject.org/koji/buildinfo?buildID=1139115 with no issues at all. I just had to do this: Oh I missed that. It looks like it was an infra problem. I'll keep an eye out when I do the final rebase. mkdir kernel; cd kernel koji download-build -a x86_64 kernel-4.18.5-300.fc29 dnf update *rpm and reboot into the new kernel. Excellent, thanks for your report and support as always ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 4.18 Rebase plans
On 08/17/2018 06:57 AM, Laura Abbott wrote: On 08/14/2018 09:14 AM, Laura Abbott wrote: Hi, As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was built for rawhide yesterday. We will be following roughly the same rebase schedule as in the past. F28 will get the rebase first, typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter. My best guess for when this would happen would be middle of September. As always, we'll keep you updated on any new developments. Thanks, Laura P.S. As a general reminder, if you like F27 please remember to give karma to kernels. 4.18.2 is nominally expected to be released this weekend but stable updates have been accelerated due to needing to get L1TF fixes out. At the very least we need to wait until the merge window closes and the test day happens before pushing the rebase. F29 will be up to date for anyone who wants to test that kernel. My current plan is to push the F28 rebase early next week. If you get a chance, please test the F29 kernel or the package in the kernel-stabilization COPR. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: 4.18 Rebase plans
On 08/14/2018 09:14 AM, Laura Abbott wrote: Hi, As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was built for rawhide yesterday. We will be following roughly the same rebase schedule as in the past. F28 will get the rebase first, typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter. My best guess for when this would happen would be middle of September. As always, we'll keep you updated on any new developments. Thanks, Laura P.S. As a general reminder, if you like F27 please remember to give karma to kernels. 4.18.2 is nominally expected to be released this weekend but stable updates have been accelerated due to needing to get L1TF fixes out. At the very least we need to wait until the merge window closes and the test day happens before pushing the rebase. F29 will be up to date for anyone who wants to test that kernel. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/23Y4OVEAIGER7K344XWGMHU5LN2WYZVY/
Re: 4.18 Rebase plans
On 08/16/2018 05:27 AM, Hans de Goede wrote: Hi, On 14-08-18 18:14, Laura Abbott wrote: Hi, As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was built for rawhide yesterday. We will be following roughly the same rebase schedule as in the past. F28 will get the rebase first, typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter. My best guess for when this would happen would be middle of September. As always, we'll keep you updated on any new developments. FYI, there seems to be a problem with 4.18 as a virtualbox guest, sometimes when the user resizes the vm-window the contents of the vm Windows stop updating (when running a GUI) until the next resize. This is probably an issue in the vboxvideo driver, triggered by changes in 4.18 elsewhere. I've looking into this on my to do list. Thanks for the report. I'll check back before doing the push if I don't hear anything before that. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/NJD37WF2LOAJ5XGNOXDCKFXOU6FAEFEV/
Re: Kernel lockdown patch & IPAddressAllow/IPAddressDeny systemd feature with Secure Boot
On 08/15/2018 07:10 PM, Alexei Starovoitov wrote: On Tue, Aug 14, 2018 at 07:14:00AM -0700, Andrew Lutomirski wrote: [Removed Fedora devel list because it's subscriber-only] On Aug 8, 2018, at 12:29 AM, Peter Robinson wrote: Probably a good idea to cc: this to the kernel list :-) I suspect it's intentional but with the planned changes for iptables etc to be backed by bpf in the upstream kernel sometime in the future it's likely going to need to be reviewed. I thought this got covered in review. I think this part of lockdown needs to get reverted or fixed ASAP. I don't see lockdown in Linus's tree. Is this fedora only issue? The entire lockdown/secure boot series is out of tree at the moment. We're working to get it included. If you search LWN, you can find some articles explaining the long saga of the patch series. (I definitely brought up multiple issues with the bpf lockdown stuff. It's clearly extremely broken right now in the "new kernel breaks *current* Linux distro" sense.) +1 Yes, we need to review what exactly is in Fedora. It's the merge window so this is a good time to do that anyway. We're still playing catch up after Flock in Dresden last week. Can you file a bugzilla for tracking so we don't forget? Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/TDNMHIVEAKJHCYD4ZTDLRA6LW42CATGQ/
Re: something is wrong with the Fedora "l1tf" patches
On 08/15/2018 01:21 PM, Reindl Harald wrote: * Di Aug 14 2018 Justin M. Forbes - 4.17.14-101 - Fix "Foreshadow" CVE-2018-3620 CVE-2018-3646 (rhbz 1585005 1615998) - CentOS 6: 2.6.32-754.3.5.el6.x86_64 [root@honeypot:~]$ grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load fences /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Retpoline with unsafe module(s), IBPB - CentOS 7: 3.10.0-862.11.6.el7.x86_64 [root@hosting:~]$ grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load fences, __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full retpoline - Fedora 27/28: 4.17.14-(1|2)01.fc2(7|8).x86_64 [root@master:~]$ grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW There were .202 and .102 versions, please check those ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/K72FLGX5DC2U76KEKOX2W3DJO7MUB3IA/
4.18 Rebase plans
Hi, As you probably saw, 4.18 was released on Sunday. The 4.18 kernel was built for rawhide yesterday. We will be following roughly the same rebase schedule as in the past. F28 will get the rebase first, typically around 4.18.2 or 4.18.3 followed by F27 shortly thereafter. My best guess for when this would happen would be middle of September. As always, we'll keep you updated on any new developments. Thanks, Laura P.S. As a general reminder, if you like F27 please remember to give karma to kernels. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/MZWKW26B2BJODY6GWZZSHA4EQK6E4UEH/
Re: Adding deferred fbcon console takeover to the Fedora kernels
On 07/30/2018 08:18 AM, Hans de Goede wrote: Hi, On 02-07-18 13:55, Hans de Goede wrote: Hi All, On 28-06-18 16:19, Hans de Goede wrote: Hi All, Good news on the patch to make the loglevel for quiet configurable, this has been accepted into -next now. I plan to add this to the Fedora kernels soonish and set the quiet loglevel to 3 as discussed earlier. Today another related patch-set got merged, see the last 3 commits here: https://github.com/bzolnier/linux/commits/ib-fbdev-drm-v4.19-deferred-console-takeover I would also like to add these 3 patches to the Fedora 4.18 kernel (for F29+). The end goal here is a boot where the firmware shows its boot graphics and these stay in place for a couple of seconds until the GUI loads and the GUI then smoothly takes over the framebuffer without any disruptions. See here for an example of what this looks like on my main workstation: https://fedorapeople.org/~jwrdegoede/flickerfree-videos/workstation-normal.webm Shim has already been modified to leave the framebuffer as setup by the firmware intact and patches for grub have been merged, but not yet build for F29+. Combined with the hidden grub menu feature for F29: https://fedoraproject.org/wiki/Changes/HiddenGrubMenu This means that the framebuffer is still showing the boot graphics (e.g. vendor logo) when the kernel loads. Without the "deferred fbcon console takeover" patches the fbcon will takeover from dummycon as the console driver as soon as the efifb registers itself as a fbdev, clearing the screen to black. breaking the desired boot experience. The deferred console takeover patches make the fbcon code delay taking over as the console until the first character is output on the console. I've tested this code with the following scenarios: 1) Remove quiet from the kernel commandline -> fbcon binds right away because messages are logged to the dummycon before efifb loads 2) Mess up the root= kernel argument -> As soon as dracut prints its timeout message for finding the rootfs, fbcon binds and shows the timeout message 3) Detailed view in plymouth mode (press ESC to show boot msg) -> plymouth retains drm master rights on /dev/dri/card? while it tries to show the details. The blocks fbcon accessing the fbdev device registered by the kms driver, so nothing will be shown until plymouth exits (and releases the drm-master rights). This really is a plymouth bug, I've submitted plymouth patches fixing this here: https://bugs.freedesktop.org/show_bug.cgi?id=107047 I got an ack from Ray for these patches and for adding these patches to the Fedora plymouth package as downstream patches (until the next upstream release). A new plymouth package fixing this is building now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1102343 I discussed adding these patches to the 4.18 / rawhide kernel with Laura off-list and she said this was ok. So I've just pushed the patches and the matching Kconfig changes. Regards, Hans s390 didn't seem to work: https://koji.fedoraproject.org/koji/taskinfo?taskID=28719549 In function 'strncat', inlined from 'iscsit_ta_authentication' at drivers/target/iscsi/iscsi_target_tpg.c:639:3: ./include/linux/string.h:313:10: warning: '__builtin_strncat' specified bound 1 equals source length [-Wstringop-overflow=] return __builtin_strncat(p, q, count); ^~ In function 'strncat', inlined from 'iscsit_ta_authentication' at drivers/target/iscsi/iscsi_target_tpg.c:640:3: ./include/linux/string.h:313:10: warning: '__builtin_strncat' specified bound 4 equals source length [-Wstringop-overflow=] return __builtin_strncat(p, q, count); ^~ ERROR: "dummycon_unregister_output_notifier" [drivers/video/fbdev/core/fb.ko] undefined! ERROR: "dummycon_register_output_notifier" [drivers/video/fbdev/core/fb.ko] undefined! make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 Looks like they might be missing EXPORT_SYMBOLS? I'm going to disable this on s390 for now. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/4QQWHS56PQ45BXIVJB7E7S7IPCV6MH7L/
Re: src.rpm for latest kernel in koji fails to build with weird errors about config mismatches
On 07/30/2018 09:02 AM, stan wrote: I downloaded the src.rpm from koji, and then used rpm -ivh to install it into the ~/rpmbuild tree. Expanded the src with rpmbuild -bp kernel.spec I used the last build config file to run make oldconfig with no errors or additions. Then I copied that config to the local config file so it would become the actual config during build. Then just a build with rpmbuild -bb kernel.spec I don't see where any config files that weren't in the src.rpm could come from, as the BUILD directory is recreated every time the -bb command is run. I have some other kernel-4.xx files in there from earlier builds, but that has never been a problem before. What is the difference between where 'fedpkg prep' gets its *.config files and the *.config files in the src.rpm? I'm pretty sure it's that last 'make oldconfig' step which is screwing things up and shouldn't be necessary. The checks that are failing are designed to catch differences between what fedora has set in the kernel- fragments and what gets generated after a "make oldconfig". I don't know why copying back again wouldn't work but the script is not perfect and I generally tell people to turn off the checks if they are building with local changes anyway. Is there a reason you need to do the last "make oldconfig" and copy step? You are duplicating what the kernel build process will do with the configs anyway. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/O3DMKAW26C2OGQO7UNSOAXD2MFGC3AWY/
Re: src.rpm for latest kernel in koji fails to build with weird errors about config mismatches
On 07/29/2018 10:43 AM, stan wrote:
On Sun, 29 Jul 2018 10:12:04 -0700
stan wrote:
Hi,
I build the kernel every few weeks from the koji rawhide src.rpm for
the latest kernel version. This has been working fine for the 4.18
kernels until the latest version. Since I'm only building locally for
x86_64, I change the nobuildarches to
%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64
ppc64le
That has worked previously, but no longer seems to be effective. I
can't see any reason it shouldn't work. There's been the major change
of no longer creating header files in the kernel package, but that
doesn't seem to impact this. Anyway, I see
[snip]
In case it has any bearing, I built, and installed, the kernel-headers
package successfully by pruning the arches to x86 only, and renaming
the tar.xz source to have the same name as the kernel I built. I did
it after rebooting into the new kernel, in case there were any
dependences for the headers. I'm not sure if that matters or not, but
it worked this way.
I'm not seeing this on my machine locally with a quick 'fedpkg prep'.
This is the change I made
diff --git a/kernel.spec b/kernel.spec
index 85bb6fa1..c105d3b2 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -327,7 +327,8 @@ Summary: The Linux kernel
# Which is a BadThing(tm).
# We only build kernel-headers on the following...
-%define nobuildarches i386
+# %define nobuildarches i386
+%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
%ifarch %nobuildarches
%define with_up 0
It seems like something picked up an old kernel configuration settings.
Can you be more explicit about what steps you did to get the failing
setup?
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/B6GOOGF6UJEJPSGEPAWEIVE5QBGK7GN6/
Re: [help] where is git tree of upstream source of the kernel ?
On 07/23/2018 11:15 AM, Josh Boyer wrote:
On Mon, Jul 23, 2018 at 12:06 PM Laura Abbott wrote
On 07/22/2018 12:12 PM, stan wrote:
On Sun, 22 Jul 2018 18:49:36 +0100
Sérgio Basto wrote:
Hello , I need bisect kernel between kernel 4.15-git1 and 4.15.0-git2
where I find a git tree with these commits (patch-4.14-git1.xz to
patch-4.14-git2.xz) ?
this request is related with my nvidia that starts to fail since
kernels 4.15.0 [1]
[1]
https://bugs.freedesktop.org/show_bug.cgi?id=105319#c21
I think this is the definitive git repository for the linux kernel.
Can't advise you on how to find what you are looking for, though.
https://github.com/torvalds/linux
That's going to be a mirror, the official official repository is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
To your actual question, if you look at the commits in
the fedora src git where those files were added, you'll see
a commit hash in the commit message, so in this case it's
1a5d24760948 ("Linux v4.14-104-g1e19bded7f5d") and
2ef4e8028f50 ("Linux v4.14-2229-g894025f24bd0") . The
part after the g is the hash in the kernel.org tree
$ git log --oneline 1e19bded7f5d..894025f24bd0 | wc -l
2125
It's kind of a pain to figure out. I'd welcome suggestions
about how to make this easier.
Could use the exploded tree and just do: git checkout kernel-, as
each build has a corresponding tag.
josh
That's a good suggestion (exploded tree is at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/)
although that still leaves the question of figuring out the base
to pass to git bisect. Maybe git is smart enough to do the right
thing with the patches on top?
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/5TNWXSI5Q2DRU7CSTCSPUX374ZVX2WMQ/
Re: [help] where is git tree of upstream source of the kernel ?
On 07/22/2018 12:12 PM, stan wrote:
On Sun, 22 Jul 2018 18:49:36 +0100
Sérgio Basto wrote:
Hello , I need bisect kernel between kernel 4.15-git1 and 4.15.0-git2
where I find a git tree with these commits (patch-4.14-git1.xz to
patch-4.14-git2.xz) ?
this request is related with my nvidia that starts to fail since
kernels 4.15.0 [1]
[1]
https://bugs.freedesktop.org/show_bug.cgi?id=105319#c21
I think this is the definitive git repository for the linux kernel.
Can't advise you on how to find what you are looking for, though.
https://github.com/torvalds/linux
That's going to be a mirror, the official official repository is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
To your actual question, if you look at the commits in
the fedora src git where those files were added, you'll see
a commit hash in the commit message, so in this case it's
1a5d24760948 ("Linux v4.14-104-g1e19bded7f5d") and
2ef4e8028f50 ("Linux v4.14-2229-g894025f24bd0") . The
part after the g is the hash in the kernel.org tree
$ git log --oneline 1e19bded7f5d..894025f24bd0 | wc -l
2125
It's kind of a pain to figure out. I'd welcome suggestions
about how to make this easier.
Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/6A35L4IHBLO6LK32P7UL4ZCB6XMGIY67/
parallel debuginfo for kernel (plus hardening flags)
Hi, The kbuild kernel maintainer has accepted the last changes needed for unique build ids upstream so I went ahead and applied the series to rawhide. This means that parallel debuginfo should actually work for future kernel builds. As part of this change, I also enabled the hardening flags for the few userspace binaries that get shipped with kernel-devel. I don't expect either of these changes to break anything but as always if you find any issues, please file a bug. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/BKROOJAT5KGIR27ISQZJDS5VVF57LYY5/
Requests for kernel related quick-docs?
Hi, If you haven't seen it, Fedora has a new documentation project called quick-docs to move information off the wiki, https://docs.fedoraproject.org/quick-docs/en-US/index.html We've started moving some of the kernel information there. Any requests for kernel related items you'd like documented? You're welcome to write docs yourself as well. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/E7X32J67XOUEFXZ66JXLFGZLMM3H7XXL/
Re: Duplicate touchpads on XPS 13
On 05/24/2018 04:13 PM, Timur Kristóf wrote: Hi, On the XPS 13 9360 and 9370 xinput sees two touchpads instead of one: ⎡ Virtual core pointerid=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4[slave pointer (2)] ⎜ ↳ DELL07E6:00 06CB:76AF Touchpad id=12[slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=17[slave pointer (2)] dmesg also gives me the following: [1.429811] psmouse serio1: synaptics: Your touchpad (PNP: DLL07e6 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-in...@vger.kernel.org. The Dell one is the real touchpad, the other one is an artifact of the psmouse driver. Weird touchpad freezes and jittering issues can be observed when both of these devices are there. The general advice on the web is to blacklist the psmouse driver. (This is also published by Dell as a .deb package which contains a config file doing just this.) However, on Fedora I cannot blacklist the psmouse driver because it is compiled built-in instead of as a module. Could you guys change the Fedora kernel config to compile it as a module instead? Thanks & best regards, Timur So assuming nobody else has objections, I think it's okay to at least try this on rawhide and see if it uncovers any other problems. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/K2UQC5W6SWXYZDMCIYMYVPCPOW7CNWH5/
Re: Bluetooth keyboard makes the cursor disappear
On 05/28/2018 06:17 AM, Michael Hill wrote: Using Rawhide, with kernel Version : 4.17.0 Release : 0.rc6.git3.1.fc29 (also 0.rc6.git2.1.fc29) Architecture: x86_64 and libinput Version : 1.10.901 Release : 1.fc29 my ThinkPad Bluetooth keyboard causes the cursor to disappear or become unresponsive. On Wayland, after activating the shell overview, the cursor vanishes. I can get it back by disabling Bluetooth from the system menu and (seemingly) switching to a console and back. On X, the keyboard works until I touch the trackpoint. The cursor flies to the shell hot corner, lights up Activities without opening the overview, and stays. My laptop trackpoint or a USB mouse can then be used to move the cursor. Here's what dmesg says: [91490.366114] usb 2-7: new full-speed USB device number 7 using xhci_hcd [91490.493583] usb 2-7: New USB device found, idVendor=8087, idProduct=0a2a, bcdDevice= 0.01 [91490.493589] usb 2-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [91490.510181] Bluetooth: hci0: read Intel version: 370810011003110e00 [91490.510625] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq [91490.807247] Bluetooth: hci0: Intel firmware patch completed and activated [91491.018110] Bluetooth: hci0: last event is not cmd complete (0x0f) [91508.126555] lenovo 0005:17EF:6048.0008: unknown main item tag 0x0 [91508.127308] input: ThinkPad Compact Bluetooth Keyboard with TrackPoint as /devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/bluetooth/hci0/hci0:256/0005:17EF:6048.0008/input/input26 [91508.129208] lenovo 0005:17EF:6048.0008: input,hidraw2: BLUETOOTH HID v3.09 Keyboard [ThinkPad Compact Bluetooth Keyboard with TrackPoint] on a4:02:b9:6d:5e:bf [91589.456678] usb 2-7: USB disconnect, device number 7 Does this sound like a kernel bug? Mike Possibly. The best thing to do is file a bugzilla for tracking if you haven't already. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/LOHEVYQI5UBF4RZBULAAFQRMLURZVP7Q/
Re: Feature request: improved build-id generation
ArOn 03/16/2018 11:37 AM, Cary Coutant wrote: Then I'm stating my case poorly. I want a way to inject additional data into the has computation. At one point, we proposed doing this via a linker- or assembler-oriented extra "salt" parameter, which would be hashed into the buildid. This would most naturally be a n-v-r-a string, so the build is reproducible. Such a salt could be naturally injected via an environment variable set by rpmbuild. https://bugzilla.redhat.com/show_bug.cgi?id=1002341 (salt!) https://bugzilla.redhat.com/show_bug.cgi?id=1550152 (life without salt) I don't have a problem with adding a --build-id-salt="some arbitrary string" option, and I think "salt" is exactly the right term for this. I'd much prefer providing that than having you use a linker script. (I'm somewhat puzzled that you find the linker script option less objectionable than an object file with a note section.) As Nick said earlier, it's not that we don't care about your feature request. I simply wanted to explore the options, and I gave you a couple of options that require no new features at all. My other comments have been about the unnecessary conflating of a new option like --build-id-salt with the choice of hashing algorithm. At least in the kernel we already have the infrastructure for customizations to linker scripts so it's fairly easy to expand on that. I have a prototype which should work, I just need to clean it up for review to see if it's feasible to merge vs. adding a --build-id-salt option. Thanks, Laura -cary ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Feature request: improved build-id generation
On 03/15/2018 06:32 AM, Nick Clifton wrote:
Hi Mark,
That might be an interesting alternative. Could you use this for e.g.
inserting a .comment section fragment with an unique (version) string?
That would be stripped away, but should still count for the build-id
hash calculation.
If you know the value you want to store ahead of time, then it is easy:
% cat comment.t
SECTIONS
{
.comment (INFO) :
{
BYTE (0x12);
BYTE (0x34);
BYTE (0x56);
BYTE (0x78);
}
}
% gcc hello.c -Wl,comment.t
% readelf -x.comment a.out
Hex dump of section '.comment':
0x 4743433a 2028474e 55292037 2e332e31 GCC: (GNU) 7.3.1
0x0010 20323031 38303133 30202852 65642048 20180130 (Red H
0x0020 61742037 2e332e31 2d322900 4743433a at 7.3.1-2).GCC:
0x0030 2028474e 55292037 2e322e31 20323031 (GNU) 7.2.1 201
0x0040 37303931 35202852 65642048 61742037 70915 (Red Hat 7
0x0050 2e322e31 2d322900 12345678 .2.1-2)..4Vx
(Note how the value has been appended to the .comment section).
Unfortunately the linker does not have a STRING() operator to insert
ascii codes into a section, so you have to construct the bytes by
hand. Eg:
% cat comment.t
SECTIONS
{
.comment (INFO) :
{
BYTE (0x41);
BYTE (0x42);
BYTE (0x43);
BYTE (0x00);
}
}
% gcc hello.c -Wl,comment.t
% readelf -p.comment a.out
String dump of section '.comment':
[ 0] GCC: (GNU) 7.3.1 20180130 (Red Hat 7.3.1-2)
[2c] GCC: (GNU) 7.2.1 20170915 (Red Hat 7.2.1-2)
[58] ABC
A simple perl or python script could be used to create the comment.t
linker script fragment.
Cheers
Nick
I think this approach looks promising. I'm going to see about prototyping
this approach.
Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
proper debuginfo for embedded vDSO
Hi, The kernel still doesn't have 100% parallel debuginfo because we can't update the vDSO binary embedded in the the image. I'd like to see about updating debugedit to be smart enough to do the recalculation of the buildid for both the vmlinux and the embedded vDSO. I'd like to avoid too tight a coupling between the kernel and debugedit so if we want/need to change how the vDSO is generated it won't break too many things. My idea is to stick the location of the vDSO in an ELF note so debugedit knows where to look. As long as the kernel can generate this section correctly, debugedit can find the embedded build-id and update accordingly. Obviously this would need approval from a wider audience but I'm looking to get some early feedback before I spend too much time prototyping something that has no chance of going anywhere. Thoughts? Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
