✅ PASS (3/297 SKIPPED): Test report for 6.0.12-300.fc37 (fedora-37)
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project
Kernel information:
Brew / Koji Task ID: 95095340
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/62626
One or more kernel tests failed:
We also see the following known issues which are not related to your
changes:
Issue: Storage block - storage fio numa: Performance comparison:
min:40535 * 1.15 < max:81259
URL: https://bugzilla.redhat.com/show_bug.cgi?id=2032094
Affected tests:
x86_64 - Storage - block - storage fio numa
Issue: NFS Connectathon: SELinux prevents rpcbind
URL:
https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/1284
Affected tests:
aarch64 - NFS Connectathon
s390x - NFS Connectathon
x86_64 - NFS Connectathon
Issue: avc: denied { sys_admin } for pid=674004
comm="systemd-gpt-aut" capability=21
scontext=system_u:system_r:systemd_gpt_generator_t:s0
tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
permissive=0
URL: https://bugzilla.redhat.com/show_bug.cgi?id=2083900
Affected tests:
aarch64 - Networking MACsec: sanity
aarch64 - Networking cki netfilter test
aarch64 - ALSA PCM loopback test
aarch64 - Storage - SCSI VPD
ppc64le - Networking MACsec: sanity
ppc64le - Networking cki netfilter test
ppc64le - ALSA PCM loopback test
x86_64 - Networking MACsec: sanity
x86_64 - Networking cki netfilter test
x86_64 - ALSA PCM loopback test
x86_64 - Storage - SCSI VPD
Issue: Networking MACsec: sanity: Cannot find device "dummy0"
URL:
https://gitlab.com/redhat/centos-stream/tests/kernel/kernel-tests/-/issues/1306
Affected tests:
aarch64 - Networking MACsec: sanity
ppc64le - Networking MACsec: sanity
x86_64 - Networking MACsec: sanity
Issue: xfstests - _check_xfs_filesystem: filesystem on /dev/nvme0n1p4
is inconsistent (r)
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1989409
Affected tests:
aarch64 - xfstests - btrfs
If you find a failure unrelated to your changes, please ask the test maintainer
to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
__
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thursday, December 8, 2022, Daniel P. Berrangé wrote: > On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote: > > On Thursday, December 8, 2022, Adam Williamson < > adamw...@fedoraproject.org> > > wrote: > > > > > On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote: > > > > > > > > I've done a few passes, dropping a bunch of older firmware upstream > > > > that are no longer supported in any stable kernel release, also a > > > > bunch of de-dupe and linking of files rather than shipping of > multiple > > > > copies of the same firmware. It's improved things a bit, > unfortunately > > > > a lot of the dead firmware was tiny compared to say average modern > > > > devices like GPUs or WiFI. > > > > > > > > The problem with a lot of the firmware, and with the new nvidia "open > > > > driver" which shoves a lot of stuff into firmware in order to have an > > > > upstreamable driver apparently the firmwares there are going to be > > > > 30+Mb each, is that they're needed to bring up graphics/network etc > to > > > > even just install so I don't know how we can get around this and > still > > > > have a device work enough to be able to install the needed firmware > > > > across the network. > > > > > > > > Ideas on how to solve that problem welcome. > > > > > > Sorry if this is way off, but - do we need the GPU firmwares to run a > > > graphical install on the fallback path, just using the framebuffer set > > > up by the firmware? How crazy would it be to just do that - ship the > > > installer env with no GPU firmware? > > > > > > That would be very crazy, as you will have a degraded user experience > > (laggy UI, wrong resolution, ...) to save a couple of megabytes that are > a > > non issue for today's hardware. > > Please bear in mind the difference between bare metal and virtual > machines. The bare metal machine may have 32 GB of RAM, making a > 800 MB install image a non-issue. For a public cloud virtual machine > though, this could bump your VM sizing up 1 level from 2 GB quota > to a 4 GB RAM quota, with correspondingly higher price point. Now > most people probably don't run the installer in a public cloud, > preferring pre-built disk images. Even in a local machine though, > you may be using most of your 32 GB of RAM for other things (well > firefox/chrome), so allowing extra for the VM is not without > resource cost. If we could figure out a way to knock a few 100 MB > off the installer RAM requirements that is valuable. > > The problem I see here is not the presence of the firmware on the image, but the fact that it seems to be loaded into memory despite not being used. > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/ > dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/ > dberrange :| > ___ > 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 > Do not reply to spam, report it: https://pagure.io/fedora- > infrastructure/new_issue > ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote: > On Thursday, December 8, 2022, Adam Williamson > wrote: > > > On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote: > > > > > > I've done a few passes, dropping a bunch of older firmware upstream > > > that are no longer supported in any stable kernel release, also a > > > bunch of de-dupe and linking of files rather than shipping of multiple > > > copies of the same firmware. It's improved things a bit, unfortunately > > > a lot of the dead firmware was tiny compared to say average modern > > > devices like GPUs or WiFI. > > > > > > The problem with a lot of the firmware, and with the new nvidia "open > > > driver" which shoves a lot of stuff into firmware in order to have an > > > upstreamable driver apparently the firmwares there are going to be > > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > > even just install so I don't know how we can get around this and still > > > have a device work enough to be able to install the needed firmware > > > across the network. > > > > > > Ideas on how to solve that problem welcome. > > > > Sorry if this is way off, but - do we need the GPU firmwares to run a > > graphical install on the fallback path, just using the framebuffer set > > up by the firmware? How crazy would it be to just do that - ship the > > installer env with no GPU firmware? > > > That would be very crazy, as you will have a degraded user experience > (laggy UI, wrong resolution, ...) to save a couple of megabytes that are a > non issue for today's hardware. Please bear in mind the difference between bare metal and virtual machines. The bare metal machine may have 32 GB of RAM, making a 800 MB install image a non-issue. For a public cloud virtual machine though, this could bump your VM sizing up 1 level from 2 GB quota to a 4 GB RAM quota, with correspondingly higher price point. Now most people probably don't run the installer in a public cloud, preferring pre-built disk images. Even in a local machine though, you may be using most of your 32 GB of RAM for other things (well firefox/chrome), so allowing extra for the VM is not without resource cost. If we could figure out a way to knock a few 100 MB off the installer RAM requirements that is valuable. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thursday, December 8, 2022, Adam Williamson wrote: > On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote: > > > > I've done a few passes, dropping a bunch of older firmware upstream > > that are no longer supported in any stable kernel release, also a > > bunch of de-dupe and linking of files rather than shipping of multiple > > copies of the same firmware. It's improved things a bit, unfortunately > > a lot of the dead firmware was tiny compared to say average modern > > devices like GPUs or WiFI. > > > > The problem with a lot of the firmware, and with the new nvidia "open > > driver" which shoves a lot of stuff into firmware in order to have an > > upstreamable driver apparently the firmwares there are going to be > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > even just install so I don't know how we can get around this and still > > have a device work enough to be able to install the needed firmware > > across the network. > > > > Ideas on how to solve that problem welcome. > > Sorry if this is way off, but - do we need the GPU firmwares to run a > graphical install on the fallback path, just using the framebuffer set > up by the firmware? How crazy would it be to just do that - ship the > installer env with no GPU firmware? That would be very crazy, as you will have a degraded user experience (laggy UI, wrong resolution, ...) to save a couple of megabytes that are a non issue for today's hardware. > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > desktop mailing list -- desk...@lists.fedoraproject.org > To unsubscribe send an email to desktop-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/desktop@ > lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora- > infrastructure/new_issue > ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > Hi folks! Today I woke up and found > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me > down a bit of an "installer environment size" rabbit hole. snip > Why does this matter? Well, the images being large is moderately > annoying in itself just in terms of transfer times and so on. But more > importantly, AIUI at least, the entire installer environment is loaded > into RAM at startup - it kinda has to be, we don't have anywhere else > to put it. The bigger it is, the more RAM you need to install Fedora. > The size of the installer environment (for which the size of the > network install image is more or less a perfect proxy) is one of the > two key factors in this, the other being how much RAM DNF uses during > package install. Is there something that can be done to optimize the RAM usage, in spite of the large installer env size ? If we're installing off DVD media, it shouldn't be required to pull all of the content into RAM, since it can be fetched on demand from the media. IOW, 99% of the firmware never need leave the ISO, so shouldn't matter if firmware is GBs in size [1] if we never load it off the media. Same for languages, only the one we actually want to use should ever get into RAM. If we're installing off a network source, we need to pull content into RAM, but that doesn't mean we should pull everything in at once upfront. Is it possible to delay pulling in non-NIC firmware until we have a NIC configured, and just rely on the basic generic framebuffer setup by UEFI/BIOS until we get far enugh to pull in video card firmware ? For localization, is it possible to split the localization into per-language bundles, and delay loading off the network until we know what language we want to load, instead of pre-loading all languages ? With regards, Daniel [1] Yes, I know it matters for user media download size in reality -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv3 0/2] redhat/configs: aarch64: reorganize tegra configs to common dir
From: pbrobinson on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2172#note_1201655743 LGTM ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 8, 2022 at 12:42 AM Adam Williamson wrote: > > Hi folks! Today I woke up and found > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me > down a bit of an "installer environment size" rabbit hole. > > As of today, with that new dep in webkitgtk, Rawhide's network install > images are 703M in size. Here's a potted history of network install > image sizes: > > Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M) > Fedora 13: 208M > Fedora 17: 162M (last "old UI") > Fedora 18: 294M (first "new UI") > Fedora 23: 415M > Fedora 28: 583M > Fedora 33: 686M > Fedora 37: 665M > Fedora Rawhide: 703M > > The installer does not really do much more in Rawhide than it did in > FC8. Even after the UI rewrite in F18, we were only at 294M. Now the > image is well over 2x as big and does...basically the same. > > Why does this matter? Well, the images being large is moderately > annoying in itself just in terms of transfer times and so on. But more > importantly, AIUI at least, the entire installer environment is loaded > into RAM at startup - it kinda has to be, we don't have anywhere else > to put it. The bigger it is, the more RAM you need to install Fedora. > The size of the installer environment (for which the size of the > network install image is more or less a perfect proxy) is one of the > two key factors in this, the other being how much RAM DNF uses during > package install. > > So, I did a bit of poking about into *what* is taking up all that > space. There's a variety of answers, but there's two major culprits: > > 1. firmware > 2. yelp (which pulls in webkitgtk and its deps) > > I've been using du and baobab (the GNOME visual disk usage analyzer, > which is great) to examine the filesystems, but I ran a couple of test > builds to confirm these suspects, especially after the impact of > compression (it's hard to check the *compressed* size of things in the > installer environment directly). > > I did a scratch build of lorax which does not pull in firmware > packages, and had openQA build a netinst using that lorax. It came out > at 489M - 214M smaller than current netinsts, a size we last managed in > Fedora 26. I did a scratch build of anaconda with its requirement of > yelp dropped (which would break help pages), and built a netinst with > that; it came out at 662M - 41M smaller than current images. I haven't > run a combined test yet, but it ought to come out around 448M, around > the size of Fedora 24. > > Even then we'd still be about 50% larger than the Fedora 18 image, for > not really any added functionality. > > I've moaned about the sheer amount and size of firmware blobs in other > forums before, but 214M compressed is *really* obnoxious. We must be > able to do something to clean this up (further than it's already > cleaned up - this is *after* we dropped low-hanging fruit like > enterprise switch 'firmwares' and garbage like that; most of the > remaining size seems to be huge amounts of probably-very-similar > firmware files for AMD graphics adapters and Intel wireless adapters). > I know some folks were trying to work on this (there was talk that we > could drop quite a lot of files that would only be loaded by older > kernels no longer in Fedora); any news on how far along that effort is? I've done a few passes, dropping a bunch of older firmware upstream that are no longer supported in any stable kernel release, also a bunch of de-dupe and linking of files rather than shipping of multiple copies of the same firmware. It's improved things a bit, unfortunately a lot of the dead firmware was tiny compared to say average modern devices like GPUs or WiFI. The problem with a lot of the firmware, and with the new nvidia "open driver" which shoves a lot of stuff into firmware in order to have an upstreamable driver apparently the firmwares there are going to be 30+Mb each, is that they're needed to bring up graphics/network etc to even just install so I don't know how we can get around this and still have a device work enough to be able to install the needed firmware across the network. Ideas on how to solve that problem welcome. Peter ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
