Re: [OS-BUILD PATCH 0/3] Add clang config framework

2023-10-01 Thread stan via kernel
On Fri, 29 Sep 2023 19:31:19 -
"Don Zickus (via Email Bridge)"  wrote:

> From: Don Zickus on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2654#note_1584466006
> 
> Resolving the thread as it appears stan agreed with Jan's reply below.

I thought about responding to your email, but decided it would be
unnecessary traffic / noise.  Apologies, I didn't mean to disrupt your
work, just clarify what was happening as it seemed it would affect me.
But, it doesn't, so I am a happy camper.
___
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 PATCH 0/3] Add clang config framework

2023-09-28 Thread stan via kernel
On Wed, 27 Sep 2023 19:26:25 -
"Jan Stancek (via Email Bridge)"  wrote:

> From: Jan Stancek on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2654#note_1581215345
> 
> Yes, that shouldn't change. I was talking about copy of the file
> created during build, which is immediately copied again to
> partial-kernel-local*. SOURCE3001 still refers to "kernel-local" in
> SOURCES, so for users nothing should change.

Thanks for clarifying.
___
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 PATCH 3/3] Add clang config framework

2023-09-27 Thread stan via kernel
On Wed, 27 Sep 2023 09:11:32 -
"Jan Stancek (via Email Bridge)"  wrote:

> From: Jan Stancek on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2654#note_1580183896
> 
> kernel-local appears unused now, so maybe these 3 lines could be
> turned into: ```
> cp %{SOURCE3001} kernel-local partial-kernel-local-snip.config
> cp %{SOURCE3001} kernel-local partial-kernel-local-debug-snip.config
> ```
> ?

I build custom kernels using the rpmbuild method, and I still use the
kernel-local file to override default configuration settings with my
local settings.  Would that still work with your proposed change?  Is
there a workaround that *would* work with your proposed change?  e.g.
instead of kernel-local, I use partial-kernel-local-snip.config,
copying my custom .config from make menuconfig to
SOURCES/partial-kernel-local-snip.config instead of
SOURCES/kernel-local.
___
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 6.5 and fedora 37, not a great combination

2023-07-27 Thread stan via kernel
Hi,
I build custom kernels from the fedora srpms.  I built a couple of 6.5
kernels, rc0 and rc2, on fedora 37 and both worked, but had the same
problems intermittently.  Sometimes disk mounting would fail on boot,
and sometimes disk unmounting, and stopping other services would fail on
shutdown.  I attribute this to the fact that 6.5 build requires
systemd-udev > 252.1 and I was overriding it to the latest version in
fedora 37, 251-13.  I don't know if 6.5 is on the schedule for f37
before EOL, but if it is I think that systemd would have to be updated
in order to avoid problems.  Seems easier to just not put 6.5 on fedora
37.
___
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: What is the current procedure to patch the kernel in the spec file?

2023-05-31 Thread stan via kernel
On Wed, 31 May 2023 13:43:44 -0500
Justin Forbes  wrote:

> apply it in some manner. While we used to have a weird git routine
> that set everything up as a git tree and did git am using the
> manifest, that was a lot of unnecessary overhead, and of little value
> when most development is done in the source tree now.

I forgot to thank you for this.  I built patches under that system, and
I agree that it was a very involved procedure.
___
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: What is the current procedure to patch the kernel in the spec file?

2023-05-31 Thread stan via kernel
On Wed, 31 May 2023 14:51:54 -0400
Prarit Bhargava  wrote:

> Just curious ... Is there a reason you don't want to commit the
> change and then build?

If I understand what you are asking correctly, I am building from
the srpm, so I don't have a git repository to commit the change to.  I
haven't used mock to build a kernel, but I think if I was, I could do
exactly that, and of course that would be the way to go.  I haven't
switched because I have been building kernels this way for so long that
I hardly have to think about it, and using mock would require me to go
through a learning curve.  
___
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: What is the current procedure to patch the kernel in the spec file?

2023-05-31 Thread stan via kernel
On Wed, 31 May 2023 13:43:44 -0500
Justin Forbes  wrote:

> Patch2: just adds it to the file manifest for the srpm.  You have to
> apply it in some manner. While we used to have a weird git routine
> that set everything up as a git tree and did git am using the
> manifest, that was a lot of unnecessary overhead, and of little value
> when most development is done in the source tree now.
> You need another line in the spec:
> 
> ApplyOptionalPatch 0001-my_custom_change.patch

Thanks, that is exactly what I was looking for.

> Of note, the linux-kernel-test.patch is also meant to facilitate
> people doing quick builds with a patch in dist-git.   You could 'cat
> 0001-my_custom_change.patch > linux-kernel-test.patch' and not have to
> touch the spec at all.

I eventually figured that out.  :-)
___
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


Solved: Re: What is the current procedure to patch the kernel in the spec file?

2023-05-31 Thread stan via kernel
Figured it out.

On Wed, 31 May 2023 11:10:01 -0700
stan via kernel  wrote:
> spec file directly.  Can anyone point me to the current procedure?

It is easy to do from the spec file.  Just put the patch in the
Patch99: linux-kernel-test.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


What is the current procedure to patch the kernel in the spec file?

2023-05-31 Thread stan via kernel
It has been ages since I wanted to patch the kernel when I built a
custom kernel.  I tried putting the patch in the spec file where the
other patches were, but it doesn't apply.  There is no error, or even
indication that it saw the patch, so I am obviously doing it
incorrectly.

I'm building the kernel from the srpm using rpmbuild.  It builds fine
when unpatched.  I can, of course, just untar the kernel tar file,
apply the patch, and tar it.  But, it should be simple to do from the
spec file directly.  Can anyone point me to the current procedure?

Here is what is in the spec file:
```
## Patches needed for building this package

%if !%{nopatches}

Patch1: patch-%{patchversion}-redhat.patch
Patch2: 0001-my_custom_change.patch
%endif
# empty final patch to facilitate testing of kernel patches
Patch99: linux-kernel-test.patch
```

I tried it outside the if, still didn't work:
```
## Patches needed for building this package

%if !%{nopatches}

Patch1: patch-%{patchversion}-redhat.patch
%endif
Patch2: 0001-my_custom_change.patch
# empty final patch to facilitate testing of kernel patches
Patch99: linux-kernel-test.patch
```

Here is the output with this version in the spec file.

+ ApplyOptionalPatch patch-6.4-redhat.patch
+ local patch=patch-6.4-redhat.patch
+ shift
+ '[' '!' -f /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch ']'
++ wc -l /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch
++ awk '{print $1}'
+ local C=2978
+ '[' 2978 -gt 9 ']'
+ ApplyPatch patch-6.4-redhat.patch
+ local patch=patch-6.4-redhat.patch
+ shift
+ '[' '!' -f /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch ']'
+ case "$patch" in
+ git --work-tree=. apply
+ ApplyOptionalPatch linux-kernel-test.patch
+ local patch=linux-kernel-test.patch
+ shift
+ '[' '!' -f /home/stan/rpmbuild/SOURCES/linux-kernel-test.patch ']'
++ wc -l /home/stan/rpmbuild/SOURCES/linux-kernel-test.patch

It finds the Patch99 patch which is empty, and in
~/rpmbuild/SOURCE like my patch, so why isn't it finding my patch?

Thanks for any help.
___
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: Is there a change to the way that /proc/sys works? It doesn't seem to allow updates anymore.

2023-05-26 Thread stan via kernel
On Fri, 26 May 2023 13:24:04 -0700
stan via kernel  wrote:

> On Fri, 26 May 2023 12:36:18 -0700
> stan via kernel  wrote:
> 
> > I compile a custom kernel (currently 6.4 rc1), and I have
> > CONFIG_PROC_SYSCTL=y
> > set in the configuration.  I run a program that gathers entropy from
> > the atmosphere and feeds it into the kernel entropy pool via the
> > public kernel interface.  When I start the program, I want to change
> > the thresholds for entropy because there is no longer any shortage
> > of entropy, so I want it to be kept full (4096).  I do that using
> > /usr/bin/echo 3967 > /proc/sys/kernel/random/write_wakeup_threshold
> > I haven't checked in a while using
> > cat /proc/sys/kernel/random/entropy_avail
> > It used to hover around 4030 or so.  But now the
> > write_wakeup_threshold is 256, and the amount of entropy is 256, and
> > no changes are possible.
> > 
> > Have there been recent changes to the kernel random generation
> > process? Has this been deprecated or restricted?  
> 
> It seems that this is a known issue, and I am not the only one
> affected.  It is
> discussed in the link
> below.
> https://github.com/nhorman/rng-tools/issues/173

I see this from the author of LRNG.
"The following patch set provides a different approach to /dev/random
which is called Linux Random Number Generator (LRNG) to collect entropy
within the Linux kernel. It provides the same API and ABI and can be
used as a drop-in replacement."

Obviously, the last sentence is false, since it caused the user input
of entropy to the kernel to fail, because it changed the process.
It removed the two proc/sys values as having any relevance.  I'll have
to see if I can ditch this LRNG since I don't need it, and from the
thread above, it doesn't seem like it will work for individuals wanting
to add entropy.

I completely missed any discussion of this.  It's too bad the author
didn't add it in a way that didn't interfere with existing
functionality.
___
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: Is there a change to the way that /proc/sys works? It doesn't seem to allow updates anymore.

2023-05-26 Thread stan via kernel
On Fri, 26 May 2023 12:36:18 -0700
stan via kernel  wrote:

> I compile a custom kernel (currently 6.4 rc1), and I have
> CONFIG_PROC_SYSCTL=y
> set in the configuration.  I run a program that gathers entropy from
> the atmosphere and feeds it into the kernel entropy pool via the
> public kernel interface.  When I start the program, I want to change
> the thresholds for entropy because there is no longer any shortage of
> entropy, so I want it to be kept full (4096).  I do that using
> /usr/bin/echo 3967 > /proc/sys/kernel/random/write_wakeup_threshold
> I haven't checked in a while using
> cat /proc/sys/kernel/random/entropy_avail
> It used to hover around 4030 or so.  But now the
> write_wakeup_threshold is 256, and the amount of entropy is 256, and
> no changes are possible.
> 
> Have there been recent changes to the kernel random generation
> process? Has this been deprecated or restricted?

It seems that this is a known issue, and I am not the only one
affected.  It is
discussed in the link
below.
https://github.com/nhorman/rng-tools/issues/173
___
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


Is there a change to the way that /proc/sys works? It doesn't seem to allow updates anymore.

2023-05-26 Thread stan via kernel
I compile a custom kernel (currently 6.4 rc1), and I have
CONFIG_PROC_SYSCTL=y
set in the configuration.  I run a program that gathers entropy from
the atmosphere and feeds it into the kernel entropy pool via the public
kernel interface.  When I start the program, I want to change the
thresholds for entropy because there is no longer any shortage of
entropy, so I want it to be kept full (4096).  I do that using
/usr/bin/echo 3967 > /proc/sys/kernel/random/write_wakeup_threshold
I haven't checked in a while using
cat /proc/sys/kernel/random/entropy_avail
It used to hover around 4030 or so.  But now the
write_wakeup_threshold is 256, and the amount of entropy is 256, and
no changes are possible.

Have there been recent changes to the kernel random generation process?
Has this been deprecated or restricted?
___
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: Error when trying to install local custom build of kernel 6.3 rc4. Can't find kernel-libs

2023-04-02 Thread stan via kernel
On Sun, 2 Apr 2023 08:53:35 -0700
stan  wrote:

> I compiled the 6.3 rc4 kernel without problems.  But, when I tried to
> install the resulting rpms I got the error,
> Nothing provides kernel-libs =
> 6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37 needed by
> kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64
> 
> I looked around in koji, and there is no kernel package that provides
> this library.  
> 
> Here are the rpms I was trying to install.
> kernel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-modules-extra-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-tools-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-tools-libs-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-devel-matched-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-headers-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-uki-virt-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-modules-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> rtla-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> kernel-modules-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
> 
> Is it possible that the library it was looking for is
> kernel-tools-libs instead of kernel-libs?  That is, there was a typo
> in the requires.  I didn't find it in the kernel.spec file.  Maybe the
> kernel-tools.spec file?  I didn't look there.
> 
> 
I think I found the issue.  This is in the kernel.spec file, 
Requires: %{package_name}-libs = %{version}-%{release}  <<<<-
Provides: %{package_name}-tools-devel
%description -n %{package_name}-tools-libs-devel
This package contains the development files for the tools/ directory
from the kernel source.

I didn't take into account that it might be a macro when I searched
before.
___
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


Error when trying to install local custom build of kernel 6.3 rc4. Can't find kernel-libs

2023-04-02 Thread stan via kernel
I compiled the 6.3 rc4 kernel without problems.  But, when I tried to
install the resulting rpms I got the error,
Nothing provides kernel-libs =
6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37 needed by
kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64

I looked around in koji, and there is no kernel package that provides
this library.  

Here are the rpms I was trying to install.
kernel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-modules-extra-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-tools-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-tools-libs-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-devel-matched-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-tools-libs-devel-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-headers-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-uki-virt-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-modules-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
rtla-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm
kernel-modules-core-6.3.0-0.rc4.20230331git62bad54b26db.39.20230402.fc37.x86_64.rpm

Is it possible that the library it was looking for is
kernel-tools-libs instead of kernel-libs?  That is, there was a typo in
the requires.  I didn't find it in the kernel.spec file.  Maybe the
kernel-tools.spec file?  I didn't look there.

___
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: Building custom kernel using rpmbuild with spec file gives error on cpufreq.h Is it meaningful?

2023-03-06 Thread stan via kernel
On Sun, 5 Mar 2023 21:46:41 -0600
Justin Forbes  wrote:
 
> More detail on this is in
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1903 but
> for Fedora, we ship cpufreq.h in kernel-tools, not kernel-headers.

Thanks!
___
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


Building custom kernel using rpmbuild with spec file gives error on cpufreq.h Is it meaningful?

2023-03-05 Thread stan via kernel
Hi,
I just built a kernel from the 6.2.2 fc37 src.rpm.  It built fine, but
at the end there was a missing file warning for cpufreq.h.  I build the
header files when building the kernel, so I would think that would be
included in them.

The error:
+ exit 0
File not found: 
/home/stan/rpmbuild/BUILDROOT/kernel-6.2.2-300.20230305.fc37.x86_64/usr/include/cpufreq.h
absolute symlink: /lib/modules/6.2.2-300.20230305.fc37.x86_64/build -> 
/usr/src/kernels/6.2.2-300.20230305.fc37.x86_64

The second one is always there, a warning about a workaround as I
understand it.

I find this in the SPEC file:
%if %{with_headers}
%files headers
/usr/include/*
%exclude %{_includedir}/cpufreq.h
%endif

When I search the BUILD tree I find:
./linux-6.2.2-300.20230305.fc37.x86_64/include/linux/cpufreq.h
./linux-6.2.2-300.20230305.fc37.x86_64/include/linux/sched/cpufreq.h

It seems that these are there but the above stanza in the SPEC file is
excluding them.  Is there a reason?  Is it harmless? 

There is another cpufreq.h present, 
./linux-6.2.2-300.20230305.fc37.x86_64/tools/power/cpupower/lib/cpufreq.h
but I am not building tools, so it is probably being ignored.  Do I
have to build tools to pick this up?

Thanks.
___
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 PATCH] redhat: Test tmp file before deleting

2022-11-08 Thread stan via kernel
On Mon, 07 Nov 2022 17:59:40 -
"Prarit Bhargava (via Email Bridge)"  wrote:

Thanks.
___
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 PATCH] redhat: Test tmp file before deleting

2022-11-08 Thread stan via kernel
On Mon, 07 Nov 2022 18:41:00 -
"Herton R. Krzesinski (via Email Bridge)"  wrote:

> From: Herton R. Krzesinski on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2135#note_1162936472
> 
> Wouldn't it be better to just use ```rm -f``` instead of adding the
> if?

Good point.
___
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


Possible error in the 6.1 rc3 kernel spec file

2022-11-07 Thread stan via kernel
Hi,
I built the 6.1 rc3 kernel over the weekend, and on the first build it
failed.  The error was this line in the spec file:
# Remove large intermediate files we no longer need to save space
# rm vmlinux.o .tmp_vmlinux.btf
The error was that the [a path in tmp I don't remember]/.tmp_vmlinux.btf
file did not exist. There was no complaint about the vmlinux.o file.
As you can see, because of the helpful comment, I knew that it was only
a space issue, so I just commented the line and everything built
successfully after that.

Perhaps this should be protected with 
if [-f .tmp_vmlinux.btf]
  rm .tmp_vmlinux.btf
fi
?

I know it won't matter to the stock fedora kernel (it has to be
general), but I used the new fixed number of cpus setting, after
editing the config file to change the setting (from 8 to 6), and it is
working fine.  Just in case anyone else wants to try it.
___
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: [PATCH 0/3] pre-generated initrd and unified kernels

2022-09-01 Thread stan via kernel
On Thu, 1 Sep 2022 16:24:17 +0200
Gerd Hoffmann  wrote:

> Wouldn't be different than local builds today, unified kernels are not
> special and the signing process will work the same way it works for
> non-unified kernels.
> 
> Essentially you have the options to either sign your custom kernel
> with your own keys (and add them to the uefi/shim key database) or
> turn off secure boot.

Thanks.
___
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: [PATCH 0/3] pre-generated initrd and unified kernels

2022-08-31 Thread stan via kernel
On Wed, 31 Aug 2022 14:46:15 +0200
Gerd Hoffmann  wrote:
 
> Here is a little patch series to kick off a discussion on
> pre-generated initrd images and unified kernels.  Lets start with a
> description of the patches:
> 
>   Patch #1 adds a dracut config file, targeting virtual machines.
> Given that most physical machines have either sata or nvme disks
> these days it probably boots most physical systems too.
> 
>   Patch #2 adds a sub-package with an initrd image.
> 
>   Patch #3 adds a sub-package with an unified kernel.
> 
> The goal is to move away from initrd images being generated on the
> installed machine.  They are generated while building the kernel
> package instead.  Main motivation for this move is to make the distro
> more robust and more secure.

A worthy goal.
 
> Comments?  Reviews?  Suggestions?

How will this impact people who build a custom kernel locally?  Will
it still be possible?
___
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: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-08-02 Thread stan via kernel
On Tue, 26 Jul 2022 15:27:40 -0700
stan  wrote:

> > https://bugzilla.redhat.com/show_bug.cgi?id=2109194  

I updated this with my latest update on resolving the problem.

> But I have no idea where to begin looking for such a change.

The latest stock fedora kernel for rawhide, 5.19.0-65.fc37.x86_64, exhibits the 
same problem as I reported above, except now the library that can't be found is 
libsystemd-core-251-3-2.fc37.so.
$ ls -nZ /usr/lib/systemd/libsystemd-core-251.3-2.fc37.so
-rwxr-xr-x. 1 0 0 system_u:object_r:lib_t:s0 2126024 Jul 23 03:09 
/usr/lib/systemd/libsystemd-core-251.3-2.fc37.so
And the system has a panic and hangs.

I have tried all sorts of ways to rebuild the initramfs, that haven't
worked, mentioned in the bugzilla.  Same result, a brief read of the
disk and then a hang with a blank screen.

I've also been trying to create a kernel that doesn't require an
initramfs to boot, but the Fedora kernels have the initramfs hard
coded.  I moved the initramfs, thinking it would try the kernel if
there was no initramfs, but it turns out that the kernel builds in a
rudimentary backup initramfs, and it is invoked instead of just
directly booting the kernel.

Meanwhile the kernel I built and installed on 20220703 continues to
boot and run flawlessly, thank goodness.

All of the above with the latest updates in rawhide applied.  There are
still some issues with erlang* and wx*, but I don't think they would
impact this problem.
___
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: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-26 Thread stan via kernel
On Wed, 20 Jul 2022 09:00:06 -0700
stan  wrote:

> On Wed, 20 Jul 2022 08:19:17 -0700
> stan via kernel  wrote:
> 
> > configuration options have changed.  I think I will be opening a
> > bugzilla against dracut, just to get their input.  
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2109194

The mass rebuild is finished, and ~4500 packages updated on my rawhide
system.  I rebuilt the kernel, and reinstalled it, and the initramfs is
still significantly smaller than the working versions, and it still
doesn't boot with an immediate hang after trying to read the disk.

I downgraded both dracut and systemd to versions that worked, and they
still didn't build a valid initramfs.  I think that lets them off the
hook.  It has to be a configuration change they are responding to.  But
I have no idea where to begin looking for such a change.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Error during compile of 5.19 rc7 kernel, seems to be bad name.

2022-07-24 Thread stan via kernel
While compiling the latest kernel (which still wouldn't boot, working
on it), I got the following warning message:

Makefile.config:778: No libcrypto.h found, disables jitted code injection, 
please install openssl-devel or libssl-dev
fatal: not a git repository (or any of the parent directories): .git
... repeats about 20 times

I *do* have openssl-devel installed, but there is no libcrypto.h under
/usr/include.  There is a crypto.h at
/usr/include/openssl/crypto.h
I am thinking that this is an error in the makefile, the name changed
out from under it.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-20 Thread stan via kernel
On Wed, 20 Jul 2022 08:19:17 -0700
stan via kernel  wrote:

> configuration options have changed.  I think I will be opening a
> bugzilla against dracut, just to get their input.

https://bugzilla.redhat.com/show_bug.cgi?id=2109194
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-20 Thread stan via kernel
On Tue, 19 Jul 2022 15:36:09 -0700
stan via kernel  wrote:
 
> I downgraded dracut to a version (56) before the problem, and rebuilt
> the initramfs for the local rc7 build.  It still failed to boot with
> the same symptom.  So, I think that lets dracut off the hook.
> Something else has changed that is causing the problem.  A
> configuration setting?  A library it is using?
> 
> Hundreds of packages have changed in the last few weeks.

I unpacked the rc4 initramfs that works, and the rc7 initramfs that
doesn't work, and there are a few differences in permissions.  As you
can see from this sample, the group and world readable permissions have
been removed from several items in the newer dracut.  These are from
dracut version 57, but they were also there when using the dracut
version 56 to create a new initramfs.  It looks like some configuration
options have changed.  I think I will be opening a bugzilla against
dracut, just to get their input.

d
1c1
< Image: 
/boot/initramfs-5.19.0-0.rc4.20220701gita175eca0f3d7.36.20220703.fc37.x86_64.img:
 48M
---
> Image: /boot/initramfs-5.19.0-0.rc7.53.20220719.fc37.x86_64.img: 32M
3c3
< Version: dracut-056-2.fc37
---
> Version: dracut-057-1.fc37
37,57c37,57
< drwxr-xr-x  12 root root0 Apr 19 16:17 .
< crw-r--r--   1 root root   5,   1 Apr 19 16:17 dev/console
< crw-r--r--   1 root root   1,  11 Apr 19 16:17 dev/kmsg
< crw-r--r--   1 root root   1,   3 Apr 19 16:17 dev/null
< crw-r--r--   1 root root   1,   8 Apr 19 16:17 dev/random
< crw-r--r--   1 root root   1,   9 Apr 19 16:17 dev/urandom
< lrwxrwxrwx   1 root root7 Apr 19 16:17 bin -> usr/bin
< drwxr-xr-x   2 root root0 Apr 19 16:17 dev
< drwxr-xr-x  13 root root0 Apr 19 16:17 etc
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/authselect
< -rw-r--r--   1 root root  703 Apr 19 16:17 
etc/authselect/nsswitch.conf
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/cmdline.d
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/conf.d
< -rw-r--r--   1 root root  124 Apr 19 16:17 etc/conf.d/systemd.conf
< drwxr-xr-x   7 root root0 Apr 19 16:17 etc/dbus-1
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/dbus-1/interfaces
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/dbus-1/services
< -rw-r--r--   1 root root  838 Mar 10 02:47 etc/dbus-1/session.conf
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/dbus-1/session.d
< -rw-r--r--   1 root root  833 Mar 10 02:47 etc/dbus-1/system.conf
< drwxr-xr-x   2 root root0 Apr 19 16:17 etc/dbus-1/system.d
---
> drwxr-xr-x  12 root root0 Jul 18 04:21 .
> crw---   1 root root   5,   1 Jul 18 04:21 dev/console
> crw---   1 root root   1,  11 Jul 18 04:21 dev/kmsg
> crw---   1 root root   1,   3 Jul 18 04:21 dev/null
> crw---   1 root root   1,   8 Jul 18 04:21 dev/random
> crw---   1 root root   1,   9 Jul 18 04:21 dev/urandom
> lrwxrwxrwx   1 root root7 Jul 18 04:21 bin -> usr/bin
> drwxr-xr-x   2 root root0 Jul 18 04:21 dev
> drwxr-xr-x  13 root root0 Jul 18 04:21 etc
> drwxr-xr-x   2 root root0 Jul 18 04:21 etc/authselect
> -rw-r--r--   1 root root  703 Jul 18 04:21 
> etc/authselect/nsswitch.conf
> drwx--   2 root root0 Jul 18 04:21 etc/cmdline.d
> drwx--   2 root root0 Jul 18 04:21 etc/conf.d
> -rw---   1 root root  124 Jul 18 04:21 etc/conf.d/systemd.conf
> drwxr-xr-x   7 root root0 Jul 18 04:21 etc/dbus-1
> drwxr-xr-x   2 root root0 Jul 18 04:21 etc/dbus-1/interfaces
> drwxr-xr-x   2 root root0 Jul 18 04:21 etc/dbus-1/services
> -rw-r--r--   1 root root  838 Jul 12 09:59 etc/dbus-1/session.conf
> drwxr-xr-x   2 root root0 Jul 18 04:21 etc/dbus-1/session.d
> -rw-r--r--   1 root root  833 Jul 12 09:59 etc/dbus-1/system.conf
> drwxr-xr-x   2 root root0 Jul 18 04:21 etc/dbus-1/system.d
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-19 Thread stan via kernel
On Tue, 19 Jul 2022 15:06:38 -0700
stan via kernel  wrote:

> You are right.  I took an older kernel, regenerated the initramfs, and
> it failed.  The size of the initramfs was drastically smaller (~ 1/2)
> than the original, as it is for the latest rc7 kernels that fail as
> well (~ 3/4 of older 5.19 kernels).
> 
> What is my next step?  Open a bugzilla against dracut? Or is there a
> setting I can pass to dracut that will fix this?

I downgraded dracut to a version (56) before the problem, and rebuilt
the initramfs for the local rc7 build.  It still failed to boot with
the same symptom.  So, I think that lets dracut off the hook.
Something else has changed that is causing the problem.  A
configuration setting?  A library it is using?

Hundreds of packages have changed in the last few weeks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Fw: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-19 Thread stan via kernel
Forgot to copy the list.

I think I am going to downgrade dracut to an older version that doesn't
have problems.  I have the latest release, installed today, and it
exhibited the problem.

Begin forwarded message:

Date: Tue, 19 Jul 2022 14:56:56 -0700
From: stan 
To: Justin Forbes 
Subject: Re: Latest rawhide kernel,
kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but
won't boot


On Tue, 19 Jul 2022 16:01:55 -0500
Justin Forbes  wrote:

> It sounds like you are not so far off.  This doesn't seem to be a
> kernel issue at all though. To verify, take a known good kernel, save
> a copy of the initramfs for that one somewhere, and then regenerate
> the initramfs and try to boot it. I am guessing it will fail in the
> same way with a new initramfs.  

You are right.  I took an older kernel, regenerated the initramfs, and
it failed.  The size of the initramfs was drastically smaller (~ 1/2)
than the original, as it is for the latest rc7 kernels that fail as well
(~ 3/4 of older 5.19 kernels).

What is my next step?  Open a bugzilla against dracut? Or is there a
setting I can pass to dracut that will fix this?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-19 Thread stan via kernel
On Tue, 19 Jul 2022 13:43:37 -0700
stan  wrote:

> Both the fedora stock 5.19 rc7 kernel and the locally built version
> still fail in the same way.  The error message from the stock kernel
> is the same, except the text of the message is corrected to have a
> period instead of a dash.  The problem could be in something the
> libsystemd-core library is calling, but I don't know how to get to
> that.  Or maybe the original error is completely unrelated, and the
> error message is for a subsequent problem caused by the original
> error.

A further thought.  Could this be caused by inconsistencies in the
packages on the system?  At the last dnf update today, there were 115
package conflicts preventing updates.  Maybe an update after the mass
rebuild will fix this issue, as everything should then be in sync.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-19 Thread stan via kernel
On Mon, 18 Jul 2022 11:57:08 -0700
stan via kernel  wrote:

> Found the problem.  There is a mismatch in the file name.
> The kernel should be looking for 
> /usr/lib/systemd/libsystemd-core-251.3-1.fc37.so
> not 
> /usr/lib/systemd/libsystemd-core-251-3-1.fc37.so
> Note the dash instead of a period in front of the 3 in the library
> name the kernel is searching for.  Typo!

Both the fedora stock 5.19 rc7 kernel and the locally built version
still fail in the same way.  The error message from the stock kernel is
the same, except the text of the message is corrected to have a period
instead of a dash.  The problem could be in something the
libsystemd-core library is calling, but I don't know how to get to
that.  Or maybe the original error is completely unrelated, and the
error message is for a subsequent problem caused by the original error.

What would be the way to get more information?

> Resolving this will probably resolve all my issues.

It seems I was foolishly optimistic.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-18 Thread stan via kernel
On Mon, 18 Jul 2022 08:45:07 -0500
Justin Forbes  wrote:

> There were unfortunately some corner cases with retbleed mitigation
> that simply did not work. Most of those should have been worked out
> over the past week, but due to the way the embargo was done, there was
> a whole lot of testing that just couldn't happen before the code was
> merged.  As this is your rebuild, the first thing I would do is see if
> the proper fedora build boots on this system, and I would not work
> with anything pre rc7 at this point. Doing so ensures that you are
> missing valid fixes.  If the fedora build boots and your build does
> not, that is an interesting case to investigate.  If the fedora build
> does not, that should be filed as a bug and figured out as 5.19 will
> be the F37 kernel.

The issue started with the rc5 kernels.  I installed and tried to boot
the stock fedora 5.19 fc6 kernel, and it also failed, but fortunately it
panicked and wrote messages to the console. The error is strange. All
of the following was on one line, wrapped here
/init error while loading shared libraries
libsystemd-core-251-3-1.fc37.so cannot open shared object file:
no such file or directory.

But I have systemd-251.3-1.fc37.x86_64 installed, and the file
/usr/lib/systemd/libsystemd-core-251.3-1.fc37.so
exists.

Found the problem.  There is a mismatch in the file name.
The kernel should be looking for 
/usr/lib/systemd/libsystemd-core-251.3-1.fc37.so
not 
/usr/lib/systemd/libsystemd-core-251-3-1.fc37.so
Note the dash instead of a period in front of the 3 in the library
name the kernel is searching for.  Typo!

Resolving this will probably resolve all my 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-18 Thread stan via kernel
On Sun, 17 Jul 2022 11:40:14 -0700
stan  wrote:

> Hi,
> 
> When I built the
> kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm
> using rpmbuild, it builds without any error, but fails to boot.  The
> rc4 kernel with the same configuration with one exception runs fine.
> 
> The exception is the new automatic timing mitigation configuration
> option.  I turned it off, single user, no internet facing services,
> amd cpu (as i understand it, has vulnerabilities, but fewer).  So, no
> complaints from the build process, but the kernel looks like it is
> going to boot (the drive light comes on), and then it just stops with
> a blank screen.  Nothing in the journal since it fails at the start.
> 
> I'll be building the rc6 kernel with the new option enabled to see if
> that fixes things, but the kernel should still run even if the
> automatic mitigation is turned off.  Should I open a bugzilla for
> this?

kernel-5.19.0-0.rc5.20220708gite8a4e1c1bb69.44.fc37.src.rpm also fails
with the same symptoms.  Doesn't have the automatic mitigation option,
so that isn't the cause of the failure.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-17 Thread stan via kernel
On Sun, 17 Jul 2022 11:40:14 -0700
stan  wrote:
 
> I'll be building the rc6 kernel with the new option enabled to see if
> that fixes things, but the kernel should still run even if the
> automatic mitigation is turned off.  Should I open a bugzilla for
> this?

I built a kernel with the automatic mitigation turned on, same behavior.

I then commented out all the rtla related code in the spec file, and
turned off the mitigation, and still the same behavior.

The only other change I see is removing cpufreq.h from the headers, but
I don't think that would cause an error.

So, stumped.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-17 Thread stan via kernel
On Sun, 17 Jul 2022 11:40:14 -0700
stan  wrote:

> Hi,
> 
> When I built the
> kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm
> using rpmbuild, it builds without any error, but fails to boot.  The
> rc4 kernel with the same configuration with one exception runs fine.
> 
> The exception is the new automatic timing mitigation configuration
> option.  I turned it off, single user, no internet facing services,
> amd cpu (as i understand it, has vulnerabilities, but fewer).  So, no
> complaints from the build process, but the kernel looks like it is
> going to boot (the drive light comes on), and then it just stops with
> a blank screen.  Nothing in the journal since it fails at the start.
> 
> I'll be building the rc6 kernel with the new option enabled to see if
> that fixes things, but the kernel should still run even if the
> automatic mitigation is turned off.  Should I open a bugzilla for
> this?

I checked the difference in the spec files, and I see that the
following has been added.  Perhaps it is the issue?

> BuildRequires: libtracefs-devel
1035a1037,1045
> %package -n rtla
> Summary: RTLA: Real-Time Linux Analysis tools 
> %description -n rtla
> The rtla tool is a meta-tool that includes a set of commands that
> aims to analyze the real-time properties of Linux. But, instead of
> testing Linux as a black box, rtla leverages kernel tracing
> capabilities to provide precise information about the properties
> and root causes of unexpected results.
> 
2313a2324,2326
> pushd tools/tracing/rtla
> %{tools_make}
> popd
2587a2601,2610
> pushd tools/tracing/rtla/
> %{tools_make} DESTDIR=%{buildroot} install
> rm -f %{buildroot}%{_bindir}/osnoise
> rm -f %{buildroot}%{_bindir}/timerlat
> (cd %{buildroot}
> 
> ln -sf rtla ./%{_bindir}/osnoise
> ln -sf rtla ./%{_bindir}/timerlat
> )
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot

2022-07-17 Thread stan via kernel
Hi,

When I built the
kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm
using rpmbuild, it builds without any error, but fails to boot.  The
rc4 kernel with the same configuration with one exception runs fine.

The exception is the new automatic timing mitigation configuration
option.  I turned it off, single user, no internet facing services, amd
cpu (as i understand it, has vulnerabilities, but fewer).  So, no
complaints from the build process, but the kernel looks like it is
going to boot (the drive light comes on), and then it just stops with a
blank screen.  Nothing in the journal since it fails at the start.

I'll be building the rc6 kernel with the new option enabled to see if
that fixes things, but the kernel should still run even if the
automatic mitigation is turned off.  Should I open a bugzilla for this?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Getting 'modpost: "cc_mkenc" [...] undefined!' when compiling out of tree kernel module

2022-06-09 Thread stan via kernel
> On Thu, Jun 9, 2022 at 3:39 AM Mauro Moltrasio 
> wrote:

> > Does anyone know if this is something I'm only getting? Is there a
> > work around to get these builds working again?

An involved workaround would be to build the kernel locally patched to
include the module you want to build, I think.  My reasoning is that
the cc_mkenc would be available because it is being used to build the
existing kernel modules.

Justin will be able to validate whether this is true.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally

2022-04-13 Thread stan via kernel
On Wed, 13 Apr 2022 13:25:44 -0500
Justin Forbes  wrote:
 
> There is no change in the build process, this is just a thing that
> pops up from time to time during the merge window, not incredibly
> often.  Basically the problem is a merge comes in for kernel tools
> which both adds something to a uapi header, and adds code in
> kernel-tools which uses that new thing.   Because tools are using the
> userspace headers installed on the system, you are trying to build the
> 5.18 kernel tools using 5.17 kernel headers.  In this case, it was
> upstream commit a1a5cfe70cd29 but this is not the first time it has
> happened. When building kernel-headers as a separate package, it
> becomes easy to build the new headers, which can then be installed to
> build kernel-tools. If you are building everything all together, you
> need to edit the spec to skip that failing tool, or turn off
> kernel-tools all together. Then you will get a kernel-headers package
> that you can install and build.

That makes sense, thanks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally

2022-04-13 Thread stan via kernel
On Tue, 12 Apr 2022 15:23:47 -0500
Justin Forbes  wrote:
 
> And now you see why kernel-headers is a separate package for Fedora,
> you can't build the tools without installed kernel headers from the
> same kernel.  For a quick work around, install
> kernel-headers-5.18.0-0.rc2.git0.1.fc37

I'm also building the header package for the kernel at the same time as
the tools, and this has worked without issue before 5.18.  That is, when
a new kernel version came out, I just built kernel, tools, and headers
as usual, and never had a problem.  There must have been some change in
the build process with the introduction of 5.18.

Thanks for the workaround.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally

2022-04-12 Thread stan via kernel
On Mon, 11 Apr 2022 10:53:54 -0500
Justin Forbes  wrote:
> Coming soon to the kernel-ark repo, but the fix is easy in the spec:
> 
> diff --git a/kernel.spec b/kernel.spec
> index fb67ab956..515942496 100755
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -2249,7 +2249,7 @@ chmod +x
> tools/power/cpupower/utils/version-gen.sh %{make}
> CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3" popd
> pushd tools/arch/x86/intel_sdsi
> -   %{make}
> +   %{tools_make}
> popd
>  %endif
>  %endif

Thanks.  That got me further, but I then hit another error.

+ popd
+ pushd tools/iio/
+ /usr/bin/make V=1 'HOSTCFLAGS=-O2  -fexceptions -g
  -grecord-gcc-switches -pipe -Wall -Werror=format-security
  -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
  -fstack-protector-strong
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
  -fasynchronous-unwind-tables -fstack-clash-protection
  -fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed
  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
  
-Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
  'CFLAGS=-O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall
  -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
  -Wp,-D_GLIBCXX_ASSERTIONS
  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
  -fstack-protector-strong
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
  -fasynchronous-unwind-tables -fstack-clash-protection
  -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
  
-Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
  V=1
iio_utils.c: In function 'iioutils_break_up_name':
iio_utils.c:65:15: warning: implicit declaration of function 'asprintf'; did 
you mean 'vsprintf'? [-Wimplicit-function-declaration]
   65 | ret = asprintf(generic_name, "%s_%s", prefix, working);
  |   ^~~~
  |   vsprintf
iio_event_monitor.c:71:10: error: 'IIO_EV_TYPE_MAG_REFERENCED' undeclared here 
(not in a function); did you mean 'IIO_EV_TYPE_MAG_ADAPTIVE'?
   71 | [IIO_EV_TYPE_MAG_REFERENCED] = "mag_referenced",
  |  ^~
  |  IIO_EV_TYPE_MAG_ADAPTIVE
iio_event_monitor.c:71:10: error: array index in initializer not of integer type
iio_event_monitor.c:71:10: note: (near initialization for 'iio_ev_type_text')
iio_event_monitor.c: In function 'main':
iio_event_monitor.c:353:23: warning: implicit declaration of function 
'asprintf'; did you mean 'vsprintf'? [-Wimplicit-function-declaration]
  353 | ret = asprintf(&chrdev_name, "/dev/iio:device%d", 
dev_num);
  |   ^~~~
  |   vsprintf
make[1]: *** 
[/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/linux-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64/tools/build/Makefile.build:97:
 iio_event_monitor.o] Error 1
make: *** [Makefile:48: iio_event_monitor-in.o] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.X2X12m (%build)
Bad exit status from /var/tmp/rpm-tmp.X2X12m (%build)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally

2022-04-11 Thread stan via kernel
On Mon, 11 Apr 2022 07:23:39 -0500
Justin Forbes  wrote:

> I am guessing this is because you turned on a build of kernel-tools
> with it? libnl3 is only needed for kernel tools (the intel_sdsi build
> is also kernel-tools only).  

Yeah, I build kernel-tools so that everything is aligned.  But I have
been building with kernel-tools all along without issue.  Must be
something new in 5.18 (this is my first build of a 5.18 kernel).

> As to the issues with intel_sdsi, Today
> would be the first fedora build, so I have not looked at what the
> issues might be.  It looks like it failed Friday for the same reason
> in the ELN build though.  I had not even checked, as the 5.17.2 builds
> and the 5.16.19 builds and resulting activities kept me busy.  Perhaps
> Prarit might have some insight?

I look forward to the analysis, and a fix. :-)

Thanks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Fw: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally

2022-04-10 Thread stan via kernel
So, I responded and forgot to forward to the list.
Fixing.

Begin forwarded message:

Date: Sun, 10 Apr 2022 18:59:24 -0700
From: stan 
To: Sérgio Basto 
Subject: Re:
kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to
build locally


On Sun, 10 Apr 2022 23:06:24 +0100
Sérgio Basto  wrote:

> On Sun, 2022-04-10 at 13:35 -0700, stan via kernel wrote:  
> > /usr/bin/ld: /tmp/cc6wxoxI.o: relocation R_X86_64_32 against
> > `.rodata.str1.1' can not be used when making a PIE object; recompile
> > with -fPIE
> 
> Relocation R_X86_64_PC32 against undefined symbol , usually happens
> when LDFLAGS are set with hardening and CFLAGS not . An usually
> happens when configure.ac override all system flags with
> CFLAGS="something" you need change it to CFLAGS+="something"
> https://stackoverflow.com/a/69005262/778517  

Thanks.  I would never have figured that out.  Or, at least it would
have taken a long time.

> maybe is an effect of
> https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck have
> you tried %undefine _auto_set_build_flags ?
>   
I'm using the default in the kernel spec, as far as I know.  Which
should be the rh flags with all hardening.

+ CFLAGS='-O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall
  -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
  -Wp,-D_GLIBCXX_ASSERTIONS
  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
  -fstack-protector-strong
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
  -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'

+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
  
-Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'

This is a typical compilation stanza from the build:

gcc -Wp,-MMD,arch/x86/realmode/.init.o.d -nostdinc -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/compiler-version.h
-include ./include/linux/kconfig.h -include
./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./=
-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE <---
-Werror=implicit-function-declaration -Werror=implicit-int
-Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
-mno-red-zone -mcmodel=kernel -Wno-sign-compare
-fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races
-Wframe-larger-than=2048 -fstack-protector-strong
-Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable
-Wno-unused-const-variable -fomit-frame-pointer
-ftrivial-auto-var-init=zero -fno-stack-clash-protection
-fzero-call-used-regs=used-gpr -fno-inline-functions-called-once
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign
-Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow
-Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than
-fno-strict-overflow -fno-stack-check -fconserve-stack
-Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned
-fplugin=./scripts/gcc-plugins/randomize_layout_plugin.so
-fplugin=./scripts/gcc-plugins/stackleak_plugin.so -DRANDSTRUCT_PLUGIN
-DSTACKLEAK_PLUGIN -fplugin-arg-stackleak_plugin-track-min-size=100
-fplugin-arg-stackleak_plugin-arch=x86
-DKBUILD_MODFILE='"arch/x86/realmode/init"' -DKBUILD_BASENAME='"init"'
-DKBUILD_MODNAME='"init"' -D__KBUILD_MODNAME=kmod_init -c -o
arch/x86/realmode/init.o arch/x86/realmode/init.c

Could the -fno-PIE be the culprit?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally

2022-04-10 Thread stan via kernel
Information.

I'm building a custom kernel from the src.rpm tuned to my system.  The
last 5.17 kernel built just fine.  However, this 5.18 kernel fails with
the following error.

+ popd
+ pushd tools/arch/x86/intel_sdsi
+ /usr/bin/make V=1 'HOSTCFLAGS=-O2  -fexceptions -g -grecord-gcc-switches 
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
-fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 
-Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
/usr/bin/ld: /tmp/cc6wxoxI.o: relocation R_X86_64_32 against `.rodata.str1.1' 
can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
make: *** [Makefile:13: intel_sdsi] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.cIdvtt (%build)
Bad exit status from /var/tmp/rpm-tmp.cIdvtt (%build)

I have the new option CONFIG_X64_X32_ABI disabled, and I am wondering
if it is related to that.  I'm not sure why intel_sdsi is even being
processed, since I don't have an intel CPU, and have intel related
CONFIG options disabled in the kernel-local file. Is this an error in
the SPEC file?

And a note.  The   rpmbuild -bp kernel.spec   command ran without error,
but after I had configured the kernel-local file, and ran 
rpmbuild -bb kernel.spec
it complained about a missing package, libnl3-devel.  I would have
thought that would be picked up by the -bp command when it expanded the
source.  Am I wrong, and this is normal behavior?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Fedora kernel emails: too much or just right?

2022-02-09 Thread stan via kernel
On Tue, 8 Feb 2022 14:24:22 -0500
Donald Zickus  wrote:

> Hi,
> 
> It has been awhile since we changed how this mailing list is used.  As
> folks have noticed, we have increased traffic significantly over the
> past couple of years to reflect the activity Red Hat developers are
> performing on the Fedora kernel.
> 
> My question to this list is around the thoughts of this activity:
> * Is there too much noise?  Should we throttle back?
> * is the volume ok?  Folks have good filters?
> * Other suggestions on how we use this list?
> 
> Trying to continue to make this mailing list useful.
> 
> Thanks for any feedback!

I don't really have a dog in the fight, but I like reading the
subject lines to see what is coming down the pipe for the kernel.  The
thing that I find annoying about the messages is how succinct they are.
 If someone is involved with the change, they probably just need the
slight reminder.  But for everyone else it would be good to have a
little more flesh on the bones.  Even in the body of the message there
is no explanation of the purpose of the change other than the brief
note.

I see the same thing in rpm package descriptions (sometimes).  e.g.
the package description for libfoo says "this is a library for package
foo."  And in the kernel help messages during configuration (sometimes).
e.g. the latest 5.17 kernel has something called straight line
synchronization. But the description doesn't really explain what that
is.  I haven't got around to looking it up online yet. 

Should you change?  Maybe not, maybe the time developers would spend
upgrading the messages just isn't worth the hit to their productivity
for the few consumers who aren't involved that read the messages.

Anyhow, I'm fine with the level of messages in the kernel list.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on

2022-02-08 Thread stan via kernel
On Mon, 7 Feb 2022 15:40:54 -0700
stan via kernel  wrote:

> On Mon, 7 Feb 2022 07:42:54 -0600
> Justin Forbes  wrote:
> 
> > Oh, no, the patches are in the src rpm and dist-git, they just are
> > not in the os-build branch of kernel-ark yet, which is what most
> > people building custom kernels are working with.  Apologies, I did
> > not know you were working from the srpm.  
> 
> I just tried with the latest 5.17, the rc3 src.rpm.  And it had all
> the same errors as the rc2 src.rpm.  If the patches are applied, why
> is the build still showing infinite recursion errors?  And it still
> complains that libperf-jvmti.so is missing when it wants to install it
> into an rpm.  I don't think the patches are in the source.  Is there
> something else I need to do? 

gcc was updated to gcc-12.0.1-0.6.fc36.x86_64 and the 5.17 rc3 kernel
src.rpm now builds and creates packages.  This is with warnings as
errors turned off, and the ssl and infinite recursion warnings are
still there. However, the kernel is running fine, as far as I can tell.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on

2022-02-07 Thread stan via kernel
On Mon, 7 Feb 2022 07:42:54 -0600
Justin Forbes  wrote:

> Oh, no, the patches are in the src rpm and dist-git, they just are not
> in the os-build branch of kernel-ark yet, which is what most people
> building custom kernels are working with.  Apologies, I did not know
> you were working from the srpm.

I just tried with the latest 5.17, the rc3 src.rpm.  And it had all the
same errors as the rc2 src.rpm.  If the patches are applied, why is
the build still showing infinite recursion errors?  And it still
complains that libperf-jvmti.so is missing when it wants to install it
into an rpm.  I don't think the patches are in the source.  Is there
something else I need to do? 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on

2022-02-06 Thread stan via kernel
On Sun, 6 Feb 2022 15:25:28 -0600
Justin Forbes  wrote:

> Always best to check kernel-ark's "include in releases" tag to find
> out if anything is required for it to build that haven't been merged
> yet because review was not finished:
> 
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests?scope=all&state=opened&label_name[]=Include%20in%20Releases
> 
> There are 2 patches required to properly build with gcc 12, both have
> been submitted upstream.

Thanks for both the information and the link.  I'm not completely clear
on what is happening, but I think you added the patches manually to
build the 5.17 rc2 Fedora kernel so they are not in the src.rpm.  I
would have to add them to the spec myself for the kernel 5.17 rc2 to
build properly with gcc 12.  And once they are accepted upstream, they
will be included in the src.rpm. Is that correct?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on

2022-02-06 Thread stan via kernel
On Sun, 6 Feb 2022 11:53:28 -0700
stan via kernel  wrote:

> When I turned off warnings as errors, the kernel compiled
> successfully. This is not a problem in the 5.16 series, they compile
> cleanly with warnings as errors turned on.

The kernel compiled cleanly with all the warnings, but when it was
writing the rpm packages it failed with
File not found: 
/home/stan/rpmbuild/BUILDROOT/kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.20220206.fc36.x86_64/usr/lib64/libperf-jvmti.so

I can't find any reason why this would be true.  When I compare a
spec file that worked to the latest spec file, they appear to be
identical in dealing with libperf-jvmti.so.  And the source for the
library is there under ./tools/perf/jvmti/libjvmti.c   I did find that
there was a switch, NO_JVMTI that would turn building this off.  Has
that been enabled in 5.17 kernels?

I'm building tools and perf and headers as part of the custom kernel so
everything is in sync when I install.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on

2022-02-06 Thread stan via kernel
Hi,

I'm on rawhide with latest updates, except for some that have package
version conflicts.  But, the latest gcc and glibc packages.

First, when I was configuring, (make menuconfig), even though it
said that sysfb and sysfb-simplefb were in /drivers/firmware, they
weren't there. They took the setting from the last 5.16 kernel config
that I used as a template.

Then, when I tried to compile the 5.17 kernel from
kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm
it failed because I had warnings as errors, and the kernel warned about
ssh version being deprecated for openssl 3. e.g.
scripts/sign-file.c: In function 'read_private_key':
scripts/sign-file.c:142:17: warning: 'ENGINE_load_builtin_engines' is 
deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
  142 | ENGINE_load_builtin_engines();
  | ^~~

There were also warnings about an infinite recursion error on the
header files because of memcmp, memcpy and memset.  This is puzzling to
me since the kernel compiled just fine in koji. Did it use different
header files? And aren't all header files protected from being read
more than once?  Or are Fedora kernels compiled with warnings as errors
turned off? e.g.
./include/linux/fortify-string.h:269:16: note: in expansion of macro 
'__underlying_memcmp'
  269 | return __underlying_memcmp(p, q, size);
  |^~~
In file included from ./include/linux/string.h:253,
 from ./include/linux/bitmap.h:11,
 from ./include/linux/cpumask.h:12,
 from ./arch/x86/include/asm/cpumask.h:5,
 from ./arch/x86/include/asm/msr.h:11,
 from ./arch/x86/include/asm/processor.h:22,
 from ./arch/x86/include/asm/timex.h:5,
 from ./include/linux/timex.h:65,
 from ./include/linux/time32.h:13,
 from ./include/linux/time.h:60,
 from ./include/linux/stat.h:19,
 from ./include/linux/module.h:13,
 from init/do_mounts.c:2:
./include/linux/fortify-string.h: In function 'strncpy':
./include/linux/fortify-string.h:51:24: warning: infinite recursion detected 
[-Winfinite-recursion]
   51 | __FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t 
size)
  |^~~

When I turned off warnings as errors, the kernel compiled successfully.
This is not a problem in the 5.16 series, they compile cleanly with
warnings as errors turned on.

Anyway, I am attaching the error output from the attempt with warnings
as errors.


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Can you point me to documentation of the kernel spec file?

2021-08-08 Thread stan via kernel
On Sun, 08 Aug 2021 14:13:08 +0200
Benjamin Kircher  wrote:

[lots of good information snipped]

Thanks for taking the time to do this.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-08-05 Thread stan via kernel
On Thu, 05 Aug 2021 02:33:57 -
"Sampson Fung"  wrote:

> rpm -qa and dnf list installed return the same result.

Thanks for the info, looks like you are in business.

> Regarding the kernel.spec issue, I reported it as 
> https://bugzilla.redhat.com/show_bug.cgi?id=1990129
> 
> Change the below from 1 to 0 allow rpmbuild to finish building the
> kernel RPM packages.
> 
> diff kernel.spec.dist  kernel.spec.works 
> 202c202
> < %define with_configchecks %{?_without_configchecks:0}
> %{?!_without_configchecks:1} ---
> > %define with_configchecks %{?_without_configchecks:0}
> > %{?!_without_configchecks:0}  

It might get accepted, though the policy of the fedora kernel team has
been that anyone who builds their own kernels is on their own.  It
makes sense because there are so many combinatorial possibilities.
But maybe it has changed. 

> If I want to learn how to read kernel.spec, where should I start?

Well, the first thing is to understand the spec file organization.

https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/sect-Packagers_Guide-Creating_a_Basic_Spec_File.html

I'm not aware of any spec file documentation specific to the kernel.  I
think it is institutional awareness within the fedora kernel team.  You
can create a new thread here on the kernel list with something like
"can you point me to documentation of the kernel spec file" as the
subject, and maybe someone with more knowledge than me will give you
links to such documentation, if it exists.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-08-04 Thread stan via kernel
On Wed, 04 Aug 2021 19:35:20 -
"Sampson Fung"  wrote:

> Finally!
[snip] 
> I got:
> $ ls -lsh
> total 97M
>  68K -rw-rw-r--. 1 fcc fcc  66K Aug  5 03:00
> kernel-5.13.6-200.0805.fc34.x86_64.rpm 38M -rw-rw-r--. 1 fcc fcc  38M
> Aug  5 03:00 kernel-core-5.13.6-200.0805.fc34.x86_64.rpm 15M
> -rw-rw-r--. 1 fcc fcc  15M Aug  5 03:00
> kernel-devel-5.13.6-200.0805.fc34.x86_64.rpm 42M -rw-rw-r--. 1 fcc
> fcc  42M Aug  5 03:00 kernel-modules-5.13.6-200.0805.fc34.x86_64.rpm
> 2.3M -rw-rw-r--. 1 fcc fcc 2.3M Aug  5 03:00
> kernel-modules-extra-5.13.6-200.0805.fc34.x86_64.rpm 272K -rw-rw-r--.
> 1 fcc fcc 272K Aug  5 03:00
> kernel-modules-internal-5.13.6-200.0805.fc34.x86_64.rpm
> 
> After doing `rpm -ivh kernel-5* kernel-core-5* kernel-modules-5*
> kernel-devel-5*`, it booted OK.

Good job.

I think it would be better to use  dnf -C install  so that the package
manager knows about the packages in its database.  It is possible that
it will refresh its database from the rpm database, though it didn't in
the past.  If you do a  dnf list installed kernel\* , are your new
packages in the list. 

Anyway, all's well that ends well.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-08-04 Thread stan via kernel
On Wed, 04 Aug 2021 02:18:55 -
"Sampson Fung"  wrote:

> The second run is much faster.
> 
> build_output:
> http://cwillu.com:8080/112.119.240.206/7
> 
> error_output:
> http://cwillu.com:8080/112.119.240.206/8
> 
> kernel.spec:
> http://cwillu.com:8080/112.119.240.206/9

My builds choke if I have this uncommented, but yours obviously need it.
#config(noreplace) /etc/modprobe.d/*-blacklist.conf\
Change it to:
%config(noreplace) /etc/modprobe.d/*-blacklist.conf\

On the plus side, you are almost there.  The file checking only occurs
as the rpms are being created.  The compile successfully completed.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-08-03 Thread stan via kernel
On Tue, 03 Aug 2021 17:02:34 -
"Sampson Fung"  wrote:

> After installation of the reported dependency issues, building can
> proceed without the previous error.

Excellent!

> A million thanks!

You're welcome.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-08-03 Thread stan via kernel
On Tue, 03 Aug 2021 07:00:56 -
"Sampson Fung"  wrote:

This all looks OK.

Here is my relevant error output from the configuration step.

+ cp /home/stan/rpmbuild/SOURCES/generate_all_configs.sh .
+ cp /home/stan/rpmbuild/SOURCES/merge.pl .
+ cp /home/stan/rpmbuild/SOURCES/kernel-local .
+ VERSION=5.14.0
+ ./generate_all_configs.sh fedora 0
+ for i in kernel-5.14.0-x86_64*.config
+ mv kernel-5.14.0-x86_64.config kernel-5.14.0-x86_64.config.tmp
+ ./merge.pl /home/stan/rpmbuild/SOURCES/kernel-local 
kernel-5.14.0-x86_64.config.tmp
+ rm kernel-5.14.0-x86_64.config.tmp
+ cp /home/stan/rpmbuild/SOURCES/process_configs.sh .
+ OPTS=
+ ./process_configs.sh kernel 5.14.0
/home/stan/rpmbuild/BUILD/kernel-5.14-rc3-38-g4010a528219e/linux-5.14.0-0.rc3.20210728git4010a528219e.32.20210731.fc35.x86_64/configs/kernel-5.14.0-x86_64.config.orig:4950:warning:
 override: PSTORE_LZ4HC_COMPRESS_DEFAULT changes choice state
+ cp /home/stan/rpmbuild/SOURCES/update_scripts.sh .
+ RPM_SOURCE_DIR=/home/stan/rpmbuild/SOURCES
+ ./update_scripts.sh fedora
+ cd ..
+ find . '(' -name '*.orig' -o -name '*~' ')' -delete

Here is your error output, as you also posted, but here unwrapped
because replying wrapped it.

+ cp /home/fcc/rpmbuild/SOURCES/generate_all_configs.sh .
+ cp /home/fcc/rpmbuild/SOURCES/merge.pl .
+ cp /home/fcc/rpmbuild/SOURCES/kernel-local .
+ VERSION=5.14.0
+ ./generate_all_configs.sh fedora 1
+ for i in kernel-5.14.0-x86_64*.config
+ mv kernel-5.14.0-x86_64-debug.config kernel-5.14.0-x86_64-debug.config.tmp
+ ./merge.pl /home/fcc/rpmbuild/SOURCES/kernel-local 
kernel-5.14.0-x86_64-debug.config.tmp
+ rm kernel-5.14.0-x86_64-debug.config.tmp
+ for i in kernel-5.14.0-x86_64*.config
+ mv kernel-5.14.0-x86_64.config kernel-5.14.0-x86_64.config.tmp
+ ./merge.pl /home/fcc/rpmbuild/SOURCES/kernel-local 
kernel-5.14.0-x86_64.config.tmp
+ rm kernel-5.14.0-x86_64.config.tmp
+ cp /home/fcc/rpmbuild/SOURCES/process_configs.sh .
+ OPTS=
+ OPTS=' -w -n -c'
+ ./process_configs.sh -w -n -c kernel 5.14.0
error: Bad exit status from /var/tmp/rpm-tmp.yeTFEV (%prep)

Your output has an extra for loop.  I'm not sure where that comes from.
 The OPTS line is also different when you run process_configs.sh  

I ran a diff between your spec file and mine, and I found that there
were setting changes that I have that you do not have.  That first one
looks like the culprit.

%define with_configchecks %{?_without_configchecks:0} 
%{?!_without_configchecks:0}

%define with_headers 1

%define with_perf 1

%define with_tools 1

# bpftool btf dump file vmlinux format c > 
$RPM_BUILD_ROOT/$DevelDir/vmlinux.h

#config(noreplace) /etc/modprobe.d/*-blacklist.conf\

Try these, and see if they work for you.  If they don't, I can post the
spec file and the kernel-local I use.  The kernel-local is tuned to my
hardware, so won't build a system you want, but they can show if what
works here works there.  I don't think it will be necessary, I think it
is the configchecks setting above that is causing the problem.  I
should have thought of it, but I have been setting it for years, so
it's on autopilot.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-07-30 Thread stan via kernel
On Fri, 30 Jul 2021 12:07:19 -0700
stan  wrote:

> On Thu, 29 Jul 2021 14:55:25 -
> "Sampson Fung"  wrote:
> 
> > both reads like 11.1.1 to me.  I did  cp .config as kernel-local
> > after make menuconfig.  After rm -rf ~/rpmbuild and start over, exit
> > with same error.  
 
> If I get time I'll try to reproduce the issue.  It has to be something
> simple, a switch or configuration option, I *think*.
> 

I looked at the output from a successful kernel build (under
~/rpmbuild/BUILD/kernel []/linux []) here using rpmbuild.  I checked for
the error message you received. This is the output.

configs/kernel-5.14.0-x86_64.config:CONFIG_GCC_VERSION=20
configs/kernel-local:CONFIG_GCC_VERSION=110101
configs/kernel-5.14.0-armv7hl-lpae.config:CONFIG_GCC_VERSION=20
configs/kernel-5.14.0-aarch64.config:CONFIG_GCC_VERSION=20
configs/kernel-5.14.0-ppc64le.config:CONFIG_GCC_VERSION=20
configs/kernel-5.14.0-i686.config:CONFIG_GCC_VERSION=20
configs/kernel-5.14.0-armv7hl.config:CONFIG_GCC_VERSION=20
configs/kernel-5.14.0-s390x.config:CONFIG_GCC_VERSION=20
include/config/auto.conf:CONFIG_GCC_VERSION=110101
include/generated/autoconf.h:#define CONFIG_GCC_VERSION 110101
kernel/config_data:CONFIG_GCC_VERSION=110101

So the compiler version set in the kernel-local is overriding the
default.   Can you do a grep on your kernel-local to be sure it has the
version set as above.  It should be in ~/rpmbuild/SOURCES/
grep -i -e 'config_gcc_version' ~/rpmbuild/SOURCES/kernel-local

You could also run the grep I did to see what it shows, in 
~/rpmbuild/BUILD/kernel []/linux []
grep -i -r -e 'config_gcc_version' * | less
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-07-30 Thread stan via kernel
On Thu, 29 Jul 2021 14:55:25 -
"Sampson Fung"  wrote:

> both reads like 11.1.1 to me.  I did  cp .config as kernel-local
> after make menuconfig.  After rm -rf ~/rpmbuild and start over, exit
> with same error.

I agree, the gcc version isn't the problem.  I suggest you turn on
verbose in the spec file,
# verbose build, i.e. no silent rules and V=1
%define with_verbose %{?_with_verbose:1} %{?!_with_verbose:  1}

It is set to 0 as default.

You might as well make the other changes to the spec file at the same
time.

Then run the rpmbuild as

rpmbuild -bb kernel.spec  > build_output  2> error_output

If they aren't too large, could you attach them to an email (< 30k?).
If they are too large, could you put them on fedora paste (Fedora
Pastebin at http://paste.fedoraproject.org) and provide a link. I think
fedora has fpaste to do that easily, you might have to install it.

There can be errors further back, or at least warnings, so they may
point to the problem.

If I get time I'll try to reproduce the issue.  It has to be something
simple, a switch or configuration option, I *think*.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-07-28 Thread stan via kernel
On Wed, 28 Jul 2021 00:25:42 -

I see you got the other method working, so you really don't need this,
but I'll comment just in case someone else reads this in the far
future.  :-)

"Sampson Fung"  wrote:

> I got "user mockbuild does not exist - using root"
> 
> $ rpm -ivh kernel-5.13.5-200.fc34.src.rpm 
> Updating / installing...
>1:kernel-5.13.5-200.fc34   warning: user mockbuild does
> not exist - using root warning: user mockbuild does not exist - using
> root warning: user mockbuild does not exist - using root

Harmless.

> >  Edit the kernel.spec  
> file and uncomment the #define line and add something like 20210727 to
> distinguish this kernel from repository kernel.
> 
> I find at line 107: # define .local, after un-comment it:
> $ rpmbuild -bp kernel.spec
> error: line 107: Unknown tag: define buildid .local
> Thus I undo and continue.

It has to be 
%define buildid .local
Note the % sign in front of the define, it matters.

> > rpmbuild -bb kernel.spec  
> Exit with error:
> 
> Processing
> /home/fcc/rpmbuild/BUILD/kernel-5.13.5/linux-5.13.5-200.fc34.x86_64/configs/kernel-5.13.5-s390x.config
> ... done Processing
> /home/fcc/rpmbuild/BUILD/kernel-5.13.5/linux-5.13.5-200.fc34.x86_64/configs/kernel-5.13.5-x86_64-debug.config
> ... Error: Mismatches found in configuration files Found
> CONFIG_CC_VERSION_TEXT="gcc (scripts/dummy-tools/gcc)" after
> generation, had CONFIG_CC_VERSION_TEXT="gcc (GCC) 11.1.1 20210531
> (Red Hat 11.1.1-3)" in Source tree Found CONFIG_GCC_VERSION=20
> after generation, had CONFIG_GCC_VERSION=110101 in Source tree Found
> CONFIG_AS_VERSION=25000 after generation, had CONFIG_AS_VERSION=23501
> in Source tree Found CONFIG_LD_VERSION=25000 after generation, had
> CONFIG_LD_VERSION=23501 in Source tree error: Bad exit status from
> /var/tmp/rpm-tmp.wCoe4b (%prep)
> 
> 
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.wCoe4b (%prep)

You can try the below.  It will show whether the installed gcc on your
system is the same as the config files are expecting.

What is the output of rpm -q gcc?
What is the output of grep -i cc_version
/home/fcc/rpmbuild/BUILD/kernel-5.13.5/linux-5.13.5-200.fc34.x86_64/configs/kernel-5.13.5-x86_64-debug.confiG
?
Are they different?  I think that creating the
~/rpmbuild/SOURCES/kernel-local file will fix this.

You can turn off debug config in the kernel.spec file.  Set the switch
to 0 as it is set below.
# kernel-debug
%define with_debug %{?_without_debug: 0} %{?!_without_debug: 0}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 0}

You might as well turn off PAE as well as you don't need it.
# kernel PAE (only valid for ARM (lpae))
%define with_pae   %{?_without_pae:   0} %{?!_without_pae:   0}

You can also turn off the build of architectures that you are not
interested in. Add the last line to your spec (it won't be there).
%define nobuildarches i386 i686 %{arm}
%endif
%define nobuildarches i386 i686 ppc64 s390x %{arm} %{power64} aarch64 ppc64le

That should get you a little further, if the other method doesn't work
out.  It is more user friendly than this technique, which is a lot more
manual. Probably why it was replaced.

I recommend you put your effort into getting the other method working.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: fedpkg clone -a kernel failed

2021-07-27 Thread stan via kernel
On Tue, 27 Jul 2021 01:41:58 -
"Sampson Fung"  wrote:

> I am trying to build custom kernel on Fedora-34 following this
> quick-doc
> https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/
> 
> I got error:
> # fedpkg clone -a kernel
> Cloning into 'kernel'...
> remote: Enumerating objects: 2656, done.
> remote: Counting objects: 100% (2656/2656), done.
> remote: Compressing objects: 100% (926/926), done.
> fetch-pack: unexpected disconnect while reading sideband packet 
> fatal: early EOF
> fatal: fetch-pack: invalid index-pack output
> Could not execute clone: Failed to execute command.

This is an old and deprecated way to do this.

You can also build using the src.rpm from here
https://koji.fedoraproject.org/koji/packageinfo?packageID=8
run in /home/[your home] 
rpmdev-setuptree 
to create the rpmbuild heirarchy.  Then run, as *user* (important)
rpm -ivh [kernel*src.rpm]
to install the src.rpm in the rpmbuild heirarchy.  Edit the kernel.spec
file and uncomment the #define line and add something like 20210727 to
distinguish this kernel from repository kernel.
Run rpmbuild -bp kernel.spec
in the SPECS directory of the rpmbuild heirarchy to expand the src.rpm
Switch to ~/rpmbuild/BUILD/kernel[]/linux[]  Then cp a
/boot/config-[] of a kernel to ./.config and run 
make oldconfig
Then run 
makemenuconfig
and make the changes to the kernel configuration that you want in your
custom kernel.  Save them.  Then cp the .config file to a local config
to override the defaults.
cp ./.config ~/rpmbuild/SOURCES/kernel-local
Switch back to ~/rpmbuild/SPECS and run
rpmbuild -bb kernel.spec
The output rpms will be in ~/rpmbuild/RPMS/x86_64.  Run 
dnf -C install $(ls *.rpm) 
in that directory to install them.
Seems complicated, but really isn't.  If you are going to do this a
lot, you could set up a screen instance to have access to all the 
directories needed just by using Ctrl-A [#] to make it easier.

This does not sign the kernel so it can be booted via UEFI secure boot.
So, you either have to turn that off in the BIOS when running it, or
create your own signing key and sign it using pesign.  I recommed the
former for a one off.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


SOLVED: 5.14 stable in rc1 and edid problem fixed Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13

2021-07-15 Thread stan via kernel
The rc1 series of 5.14 kernels do not have the lockups and failed boots.


On Thu, 15 Jul 2021 12:03:10 -0700
stan via test  wrote:

> This is a custom kernel boot message series:
> 
> Jul 15 11:44:57 fedora kernel: [drm] Loading CAICOS
> Microcode Jul 15 11:44:57 fedora kernel: radeon :01:00.0: Direct
> firmware load for radeon/CAICOS_pfp.bin failed with error -2 Jul 15
> 11:44:57 fedora kernel: ni_cp: Failed to load firmware
> "radeon/CAICOS_pfp.bin" Jul 15 11:44:57 fedora kernel:
> [drm:evergreen_init [radeon]] *ERROR* Failed to load firmware! Jul 15
> 11:44:57 fedora kernel: radeon :01:00.0: Fatal error during GPU
> init Jul 15 11:44:57 fedora kernel: [drm] radeon: finishing device.
> Jul 15 11:44:57 fedora kernel: [drm] radeon: ttm finalized Jul 15
> 11:44:57 fedora kernel: radeon: probe of :01:00.0 failed with
> error -2

The problem was that firmware is now compressed, and there is a
configuration option to allow that so it is decoded before being sent
to the device. I didn't have that option set, so the compressed firmware
failed to load because it was compressed when the device was expecting
valid binary.  No gpu device, no scan of the EDID.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13

2021-07-15 Thread stan via kernel
On Sun, 11 Jul 2021 12:46:28 -0700
stan  wrote:

> Unfortunately, it doesn't boot correctly because it fails to get the
> edid from the monitor.  The rest of boot goes off without a hitch, I
> can login (without seeing anything) and run commands.  When I get to
> X, it is in some sort of vga mode with large text and flaky colors
> and it is very fragile and hangs after a short time.  But I can
> switch from there to a virtual console, login as root, and shutdown
> normally. 
> 
> The Fedora rawhide kernels do not have this issue. I can see them
> probe the EDID in the messages, whereas the custom kernel doesn't.
> The custom kernel built with this config file had no problem booting
> into this same hardware configuration with a 5.10 kernel, so
> something has changed in the settings for getting edid between then
> and 5.14.
> 
> Anyone have a suggestion for where the problem might be?

I think I have found the problem.  After many failed attempts to set
configuration options.  :-)

It seems that the custom kernel fails to load microcode that is
required.  Has this mechanism changed in recent kernels?  Is there a
way to fix this?  I never had to worry about microcode in the past.

This is a fedora stock kernel boot message series:

Jul 15 11:48:34 fedora kernel: [drm] radeon kernel modesetting enabled.
Jul 15 11:48:34 fedora kernel: radeon :01:00.0: vgaarb: deactivate vga 
console
Jul 15 11:48:34 fedora kernel: Console: switching to colour dummy device 80x25
Jul 15 11:48:34 fedora kernel: [drm] initializing kernel modesetting (CAICOS 
0x1002:0x6779 0x174B:0xE164 0x00).
Jul 15 11:48:34 fedora kernel: ATOM BIOS: C26401
Jul 15 11:48:34 fedora kernel: radeon :01:00.0: VRAM: 1024M 
0x - 0x3FFF (1024M used)
Jul 15 11:48:34 fedora kernel: radeon :01:00.0: GTT: 1024M 
0x4000 - 0x7FFF
Jul 15 11:48:34 fedora kernel: [drm] Detected VRAM RAM=1024M, BAR=256M
Jul 15 11:48:34 fedora kernel: [drm] RAM width 64bits DDR
Jul 15 11:48:34 fedora kernel: [drm] radeon: 1024M of VRAM memory ready
Jul 15 11:48:34 fedora kernel: [drm] radeon: 1024M of GTT memory ready.
Jul 15 11:48:34 fedora kernel: [drm] Loading CAICOS Microcode
Jul 15 11:48:34 fedora kernel: [drm] Internal thermal controller without fan 
control
Jul 15 11:48:34 fedora kernel: [drm] radeon: dpm initialized

This is a custom kernel boot message series:

Jul 15 11:44:57 fedora kernel: [drm] radeon kernel modesetting enabled.
Jul 15 11:44:57 fedora kernel: radeon :01:00.0: vgaarb: deactivate vga 
console
Jul 15 11:44:57 fedora kernel: Console: switching to colour dummy device 240x68
Jul 15 11:44:57 fedora kernel: [drm] initializing kernel modesetting (CAICOS 
0x1002:0x6779 0x174B:0xE164 0x00).
Jul 15 11:44:57 fedora kernel: ATOM BIOS: C26401
Jul 15 11:44:57 fedora kernel: radeon :01:00.0: VRAM: 1024M 
0x - 0x3FFF (1024M used)
Jul 15 11:44:57 fedora kernel: radeon :01:00.0: GTT: 1024M 
0x4000 - 0x7FFF
Jul 15 11:44:57 fedora kernel: [drm] Detected VRAM RAM=1024M, BAR=256M
Jul 15 11:44:57 fedora kernel: [drm] RAM width 64bits DDR
Jul 15 11:44:57 fedora kernel: [drm] radeon: 1024M of VRAM memory ready
Jul 15 11:44:57 fedora kernel: [drm] radeon: 1024M of GTT memory ready.
Jul 15 11:44:57 fedora kernel: [drm] Loading CAICOS Microcode
Jul 15 11:44:57 fedora kernel: radeon :01:00.0: Direct firmware load for 
radeon/CAICOS_pfp.bin failed with error -2
Jul 15 11:44:57 fedora kernel: ni_cp: Failed to load firmware 
"radeon/CAICOS_pfp.bin"
Jul 15 11:44:57 fedora kernel: [drm:evergreen_init [radeon]] *ERROR* Failed to 
load firmware!
Jul 15 11:44:57 fedora kernel: radeon :01:00.0: Fatal error during GPU init
Jul 15 11:44:57 fedora kernel: [drm] radeon: finishing device.
Jul 15 11:44:57 fedora kernel: [drm] radeon: ttm finalized
Jul 15 11:44:57 fedora kernel: radeon: probe of :01:00.0 failed with error 
-2

Thanks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13

2021-07-12 Thread stan via kernel
On Mon, 12 Jul 2021 01:11:42 -0600
Chris Murphy  wrote:

> You might ask in #fedora-kernel but my two cents is I generally don't
> file bugs on rawhide kernels in the RHBZ. Instead I try to figure out
> what part of the kernels is blowing up, and use a current version of
> the MAINTAINERS file [1] to figure out where to send an email: I'm
> expecting X, I'm seeing Y, here's a dmesg. In short.
> 
> There's a ton of changes happening in the rc0 kernels, they aren't
> release candidates yet. The merge window just closed, and it's 7-8
> weeks of stabilization. You can expect to be asked to bisect if it
> sounds like a regression; and to test a patch. If you can't, just say
> so.
> 
> Branch is in about 4 weeks [2]. We will see current rawhide become
> Fedora 35, which looks like it'll be kernel 4.14-rc5 by then. Any sort
> of show stopper type bugs I'll file in RHBZ with a URL pointing to the
> email I started with the upstream maintainers of the problem driver or
> kernel component. That's because these bugs are potentially release
> blocking bugs that'll need to get fixed before either the beta or
> final milestone. And for that I use the blockerbugs app [3] to propose
> it.
> 
> 
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?h=v5.14-rc1
> 
> [2]
> https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
> 
> [3]
> https://qa.fedoraproject.org/blockerbugs/propose_bug

Thanks! 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13

2021-07-11 Thread stan via kernel
On Sun, 11 Jul 2021 06:22:51 -0700
stan via test  wrote:

> I normally run custom compiled rawhide kernels tuned to my hardware.
> In those I turn debugging off.  I haven't been able to build one for
> 5.14 yet because of a problem in the build process.  I will try again
> with the 20210709 kernel because it seems the fix for the error is in
> that package.

I was able to compile a custom kernel with the 20200709 kernel src.rpm
package.  So the perf fix is working; the link that used to cause an
error now causes a warning,
warning: absolute symlink: 
/lib/modules/5.14.0-0.rc0.20210709gitf55966571d5e.14.20210711.fc35.x86_64/build 
-> /usr/src/kernels/5.14.0-0.rc0.20210709gitf55966571d5e.14.20210711.fc35.x86_64

Unfortunately, it doesn't boot correctly because it fails to get the
edid from the monitor.  The rest of boot goes off without a hitch, I
can login (without seeing anything) and run commands.  When I get to X,
it is in some sort of vga mode with large text and flaky colors and it
is very fragile and hangs after a short time.  But I can switch from
there to a virtual console, login as root, and shutdown normally. 

The Fedora rawhide kernels do not have this issue. I can see them
probe the EDID in the messages, whereas the custom kernel doesn't.  The
custom kernel built with this config file had no problem booting into
this same hardware configuration with a 5.10 kernel, so something has
changed in the settings for getting edid between then and 5.14.

Anyone have a suggestion for where the problem might be?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13

2021-07-10 Thread stan via kernel
On Fri, 9 Jul 2021 06:38:08 -0700
stan via kernel  wrote:

> I have an install of rawhide.  It is updated to latest packages in
> rawhide.  One of those packages is the new 5.14 kernel.  It mostly
> works, but I have seen three freezes during boot.  Two of them just
> stopped after a screen update from systemd, but one of them (the
> latest) said something about a deadlock involving console and cpu.  I
> had to reboot, and the journal was corrupted, so I lost the message.
> 
> I have also had several (less than 5) freezes while going about normal
> business.  No consistency, they just happen.
> 
> It is early in the development cycle for 5.14, so these will probably
> go away, but I wanted the issue to be raised and noted.

I installed the latest kernel today, 
Name: kernel
Version : 5.14.0
Release : 0.rc0.20210708gite9f1cbc0c411.13.fc35
and it has issues.  It boots successfully to multiuser, but when I try
to start X, it freezes the machine.

I've attached oops from journalctl during boot.  I don't know if they
are the problem, but they probably shouldn't be happening.  Should I
open a bug for this?

Trace from successful boot, but starting X froze the system.

Jul 10 17:30:02 fedora kernel: ---[ end trace 13973a84f8ee267e ]---
Jul 10 17:30:02 fedora kernel: softirqs last disabled at (869): 
[] __irq_exit_rcu+0xec/0x110
Jul 10 17:30:02 fedora kernel: softirqs last  enabled at (1102): 
[] __irq_exit_rcu+0xec/0x110
Jul 10 17:30:02 fedora kernel: hardirqs last disabled at (1172): 
[] console_unlock+0x40c/0x5e0
Jul 10 17:30:02 fedora kernel: hardirqs last  enabled at (1167): 
[] console_unlock+0x4c1/0x5e0
Jul 10 17:30:02 fedora kernel: irq event stamp: 1161
Jul 10 17:30:02 fedora kernel:  ret_from_fork+0x22/0x30
Jul 10 17:30:02 fedora kernel:  ? set_kthread_struct+0x40/0x40
Jul 10 17:30:02 fedora kernel:  kthread+0x149/0x170
Jul 10 17:30:02 fedora kernel:  rtThreadNativeMain+0x1b/0x20 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  rtThreadMain+0x3e/0x90 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  ? VBoxHost_RTThreadSleepNoLog+0x40/0x40 
[vboxdrv]
Jul 10 17:30:02 fedora kernel:  supdrvTscDeltaThread+0x3ad/0x5e0 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  ? destroy_timer_on_stack+0x20/0x20
Jul 10 17:30:02 fedora kernel:  supdrvTscMeasureDeltaOne+0x3b6/0x450 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  ? 
supdrvTscMeasureDeltaCallbackUnwrapped.isra.0+0xa70/0xa70 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  VBoxHost_RTMpOnPair+0x147/0x230 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  ? 
supdrvTscMeasureDeltaCallbackUnwrapped.isra.0+0xa70/0xa70 [vboxdrv]
Jul 10 17:30:02 fedora kernel:  ? rtmpLinuxWrapper+0x30/0x30 [vboxdrv]
Jul 10 17:30:02 fedora kernel: Call Trace:
Jul 10 17:30:02 fedora kernel: CR2: 55b95932b000 CR3: 000110c9a000 CR4: 
000406e0
Jul 10 17:30:02 fedora kernel: CS:  0010 DS:  ES:  CR0: 80050033
Jul 10 17:30:02 fedora kernel: FS:  () 
GS:99c12ea0() knlGS:
Jul 10 17:30:02 fedora kernel: R13: a8e881ef3db0 R14: 0004 R15: 

Jul 10 17:30:02 fedora kernel: R10: 9476db5b R11:  R12: 

Jul 10 17:30:02 fedora kernel: RBP: a8e881ef3e08 R08:  R09: 
99be335cea10
Jul 10 17:30:02 fedora kernel: RDX: a8e881ef3db0 RSI: 0001 RDI: 
99be335cea10
Jul 10 17:30:02 fedora kernel: RAX: 0001 RBX: c0c4c9b0 RCX: 
0001
Jul 10 17:30:02 fedora kernel: RSP: 0018:a8e881ef3d28 EFLAGS: 00010202
Jul 10 17:30:02 fedora kernel: Code: ff ff 0f 0b e9 c8 fe ff ff 65 8b 05 63 fe 
e5 6b a9 ff ff ff 7f 0f 85 8e fe ff ff 65 8b 05 dd 0a e6 6b 85 c0 0f 84 7f fe 
ff ff <0f> 0b 44 3b 35 74 f2 0b 02 0f 82 7d fe ff ff 0f 0b e9 76 fe ff ff
Jul 10 17:30:02 fedora kernel: RIP: 0010:smp_call_function_many_cond+0x1c7/0x3c0
Jul 10 17:30:02 fedora kernel: Hardware name: To be filled by O.E.M. To be 
filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014
Jul 10 17:30:02 fedora kernel: CPU: 4 PID: 5905 Comm: iprt-VBoxTscThr Tainted: 
G   OE- ---  
5.14.0-0.rc0.20210708gite9f1cbc0c411.13.fc35.x86_64 #1
Jul 10 17:30:02 fedora kernel:  acpi_cpufreq binfmt_misc zram ip_tables 
crct10dif_pclmul crc32_pclmul radeon crc32c_intel ghash_clmulni_intel 
i2c_algo_bit serio_raw drm_ttm_helper ttm sp5100_tco hid_microsoft ff_memless 
drm_kms_helper cec
 hid_microsoft ff_memless drm r8169 wmi fuse ecryptfs i2c_dev [last unloaded: 
ipmi_msghandler]
Jul 10 17:30:02 fedora kernel: Modules linked in: vboxdrv(OE) xt_CHECKSUM 
xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref 
nf_conntrack_tftp nft_counter bridge stp llc nft_fib_inet nft_fib_ipv4 
nft_fib_ipv6 
 nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 
nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack 
nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink sunrpc

The 5.14 kernel in rawhide seems to be unstable, having lockups and failed boots, didn't occur with 5.13

2021-07-09 Thread stan via kernel
I have an install of rawhide.  It is updated to latest packages in
rawhide.  One of those packages is the new 5.14 kernel.  It mostly
works, but I have seen three freezes during boot.  Two of them just
stopped after a screen update from systemd, but one of them (the
latest) said something about a deadlock involving console and cpu.  I
had to reboot, and the journal was corrupted, so I lost the message.

I have also had several (less than 5) freezes while going about normal
business.  No consistency, they just happen.

It is early in the development cycle for 5.14, so these will probably go
away, but I wanted the issue to be raised and noted.

I had no issues whatsoever with the 5.13 kernels.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel 5.14 spec file problems, one solved, one unresolved, help

2021-07-08 Thread stan via kernel
On Wed, 7 Jul 2021 15:55:15 -0500
Justin Forbes  wrote:

> No, BTF debuginfo is set on regular kernels as well. Are you building
> this on a rawhide system? My build/test system here is F34, but with
> bpftool-5.13.0-1.fc35.x86_64 (rebuilt against F34) it seems to pass
> fine on this.  I got the same error that you did when I was running an
> older version of kernel-tools.  In your particular user case though,
> you can comment out that line. The vmlinux.h created there is only
> used in 2 instances, where kernel-tools is built separately from the
> kernel, and when cross compiling the kernel (because tools have to be
> built native).

Yes, on rawhide, running under the Fedora 5.14 kernel I am trying to
custom build. Great, that is simple and straightforward.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel 5.14 spec file problems, one solved, one unresolved, help

2021-07-07 Thread stan via kernel
On Wed, 7 Jul 2021 10:04:07 -0700
stan via kernel  wrote:

> On Wed, 7 Jul 2021 10:21:01 -0500
> Justin Forbes  wrote:
> 
> > 
> > bpftool is a builreq, the failure there has to do with where you are
> > building it. You need bpftool from 5.13 to build a 5.14 snapshot.
> > The error is unclear, but that is the solution.  This is actually a
> > very useful bit in that we will use that vmlinux.h to build
> > kernel-tools for Fedora. It is built in kernel for ELN.  As I
> > rebase stable Fedora to 5.13, it will require a prebuild of
> > kernel-tools for 5.13 followed by the kernel build.  
> 
> I have bpftool-5.13.0-1.fc35.x86_64 installed, and that seems to have
> satisfied the buildrequire.  I am also building perf, tools,
> headers, and devel, so that everything is in sync with the custom
> kernel.  That used to work fine as late as 5.10 kernels.  So, my
> takeaway is that this has changed, and I now need to enable the build
> of vmlinux.h.
> 
> The error message I received was that bpftool could not find BFT.  I
> infer from your response that turning on the build of bpf will remedy
> that.

It doesn't.  Here is the output of a compile with bpf turned on
everywhere.  It shows the creation of the link that causes the problem
of an upackaged file being packaged, and then the failure to build
vmlinux.h using bpftool.

+ cp certs/signing_key.pem certs/signing_key.pem.sign
+ cp certs/signing_key.x509 certs/signing_key.x509.sign
+ mkdir -p 
/home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/usr/src/kernels
+ mv 
/home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/lib/modules/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/build
 
/home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64//usr/src/kernels/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64
+ ln -sf 
/usr/src/kernels/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64 
/home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/lib/modules/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/build
+ bpftool btf dump file vmlinux format c
Error: failed to load BTF from vmlinux: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.Zt6DVC (%build)
Bad exit status from /var/tmp/rpm-tmp.Zt6DVC (%build)

I have debug builds turned off.  Are they required for bpftool to work?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: kernel 5.14 spec file problems, one solved, one unresolved, help

2021-07-07 Thread stan via kernel
On Wed, 7 Jul 2021 10:21:01 -0500
Justin Forbes  wrote:

> 
> bpftool is a builreq, the failure there has to do with where you are
> building it. You need bpftool from 5.13 to build a 5.14 snapshot.  The
> error is unclear, but that is the solution.  This is actually a very
> useful bit in that we will use that vmlinux.h to build kernel-tools
> for Fedora. It is built in kernel for ELN.  As I rebase stable Fedora
> to 5.13, it will require a prebuild of kernel-tools for 5.13 followed
> by the kernel build.

I have bpftool-5.13.0-1.fc35.x86_64 installed, and that seems to have
satisfied the buildrequire.  I am also building perf, tools,
headers, and devel, so that everything is in sync with the custom
kernel.  That used to work fine as late as 5.10 kernels.  So, my
takeaway is that this has changed, and I now need to enable the build
of vmlinux.h.

The error message I received was that bpftool could not find BFT.  I
infer from your response that turning on the build of bpf will remedy
that.

> Would need to know what link this is. I know perf messed up the
> makefile and created a link in the wrong place. We don't package this
> link, but our command to remove it wasn't looking in the right place.
> Rather than fix this in spec, I sent a fix upstream which is applied
> and waiting for the next Linus perf pull.
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1237 but
> you shouldn't be hitting that at all if you are doing a fedora build
> which doesn't build perf.  If it isn't that, let me know what it
> actually is, since I am not seeing it in rawhide builds.

But as I say above, I *am* building perf.  So, this solves the second
problem.  I can wait for a fedora kernel that has the fix, or I can try
to apply that patch manually.

The main reason I'm doing this is that the Fedora kernel has the
configuration option for the rtl2832 module turned on.  That is to use
it for its intended purpose, as a tuner, and that is reasonable.  But, I
use an rtl2832 as a source of atmospheric entropy.  My daemon can't
acquire it unless the rtl2832 is free, which it isn't with a stock
Fedora kernel.  The slimmed down size and reduced attack surface are
just bonuses of building the custom kernel.

Thanks for your help.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


kernel 5.14 spec file problems, one solved, one unresolved, help

2021-07-07 Thread stan via kernel
Hi,
I'm building the 5.14 kernel from 
kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.fc35.src.rpm
I've run into two issues.

The first is to do with bpftool.  I see in the comments that it is
supposed to be disabled in Fedora.  But, it still has a buildrequires:,
and there is a segment of code that is not protected even if bpftool is
turned off.

%ifnarch armv7hl
# Generate vmlinux.h and put it to kernel-devel path
bpftool btf dump file vmlinux format c > $RPM_BUILD_ROOT/$DevelDir/vmlinux.h
%endif

Because bpftool is turned off, this chokes.

The second is to do with a symbolic link.


# Move the devel headers out of the root file system
mkdir -p $RPM_BUILD_ROOT/usr/src/kernels
mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir

# This is going to create a broken link during the build, but we don't use
# it after this point.  We need the link to actually point to something
# when kernel-devel is installed, and a relative link doesn't work across
# the F17 UsrMove feature.
ln -sf $DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build

The comment says that symbolic link should not matter, but rpmbuild
complains that files are being packaged that are not registered (?,
from memory).  Building something else right now, but if you need the
exact error message, I can regenerate it later.  This code is in
prior kernel spec files without problems.  It seems that something
is being more assiduous now.  I've tried various things to work around
this, but they haven't worked.  I guess that is because I don't really
understand why this symbolic link is being created.  What is your
suggestion for how to fix this?

Finally, I've built the kernel successfully several times while testing
my fixes.  I've noticed that ccache is not being used; it is rebuilding
everything every time.  Since I'm building a kernel customized to my
hardware, that isn't so onerous.  But, how would I enable ccache so
that rebuilds are basically copy operations?

Thanks for any help.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [OS-BUILD PATCHv2] [redhat] spec: package decompressor vmlinux for s390

2021-02-09 Thread stan via kernel
On Tue, 9 Feb 2021 17:49:50 +0100
Patrick Talbert  wrote:

> On Tue, Feb 9, 2021 at 5:11 PM stan via kernel
>  wrote:
> >
> > On Tue, 09 Feb 2021 05:57:45 -
> > cki-git...@redhat.com wrote:
> >  
> > > From: CKI KWF Bot on gitlab.com
> > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504695499
> > >
> > > Acked-by: Justin Forbes 
> > > (via approve button)  
> >
> > """
> > From: CKI KWF Bot on gitlab.com
> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504694117
> >
> > Acked-by: Don Zickus 
> > (via approve button)
> > """
> >
> > Why am I seeing hundreds of the same messages like above from the
> > cki bot?  They are identical except for the timestamp.  Could
> > someone please fix this.  
> 
> It should no longer be occurring. I apologize for the spam.
> 
> One of the gitlab api endpoints used by our webhooks was returning an
> unexpected error and it was not being handled appropriately.
> 
> As soon as I realized it I stopped the webhook and have since pushed a
> fix so the exception is handled. We've also opened an issue with
> Gitlab to understand why the error was being returned by the API at
> all..
> 
> https://gitlab.com/cki-project/kernel-webhooks/-/issues/79

Thanks, both for your *very* fast fix, and for your response.  It
sounds like my response was noise also, since you had already
fixed things.  :-)
___
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: [OS-BUILD PATCHv2] [redhat] spec: package decompressor vmlinux for s390

2021-02-09 Thread stan via kernel
On Tue, 09 Feb 2021 05:57:45 -
cki-git...@redhat.com wrote:

> From: CKI KWF Bot on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504695499
> 
> Acked-by: Justin Forbes 
> (via approve button)

"""
From: CKI KWF Bot on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883#note_504694117

Acked-by: Don Zickus 
(via approve button)
"""

Why am I seeing hundreds of the same messages like above from the cki
bot?  They are identical except for the timestamp.  Could someone
please fix this.

Date: Tue, 09 Feb 2021 05:47:38 -
Date: Tue, 09 Feb 2021 05:57:45 -
Date: Tue, 09 Feb 2021 06:07:49 -
Date: Tue, 09 Feb 2021 06:17:55 -
etc.
___
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.10.11 overwrote my private UEFI key

2021-02-01 Thread stan via kernel
Hi,

I compile a custom kernel from the Fedora src.rpm.  When I compiled the
5.10.11 kernel, it overwrote my private key when I installed it.  The
last 5.10 kernel I compiled and installed, 5.10.4, did not.  I don't
expect any kind of fix since it is a custom compile, just putting this
out there as a data point in case anyone else runs into this and is
scratching their head.
___
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: virtual console scroll back isn't working anymore, I think it started with 5.10

2020-12-11 Thread stan via kernel
On Fri, 11 Dec 2020 14:09:40 -0500
Chuck Anderson  wrote:

> On Fri, Dec 11, 2020 at 11:44:54AM -0700, stan via kernel wrote:
> > The scrollback in the virtual consoles has stopped working for me.
> > I think, but am not sure, that this started with the 5.10 series of
> > kernels.  Is this a regression, or did the kernel developers disable
> > this deliberately for some reason?  
> 
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-Drops-Soft-Scrollback

Thanks!
___
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


virtual console scroll back isn't working anymore, I think it started with 5.10

2020-12-11 Thread stan via kernel
Hi,

The scrollback in the virtual consoles has stopped working for me.  I
think, but am not sure, that this started with the 5.10 series of
kernels.  Is this a regression, or did the kernel developers disable
this deliberately for some reason?

Thanks.
___
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: enrollment to the mailing list

2020-11-17 Thread stan via kernel
On Tue, 17 Nov 2020 15:55:29 +0200
"Claudio @ Gmail"  wrote:

> Please add my email (cchin...@gmail.com) to your mailing list.

I don't think this will work without some manual intervention. The
usual way to do this is to go to 

https://lists.fedoraproject.org/admin/lists/kernel.lists.fedoraproject.org/

and use the signup form at the bottom.
___
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.9.300 spec file has missing executable gpio-watch in tools file section

2020-10-26 Thread stan via kernel
On Mon, 26 Oct 2020 14:01:31 -0500
Justin Forbes  wrote:

> Right, the 5.9 development kernel was built from rawhide, which does
> include these things because ELN needs them. The 5.9.0-300 is in a
> stable branch where all of that is stripped. I don't just copy the
> spec back to old releases, I only move bring back patches, configs,
> and filter changes generally.

Thanks for the explanation.
___
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.9.300 spec file has missing executable gpio-watch in tools file section

2020-10-26 Thread stan via kernel
On Mon, 26 Oct 2020 10:54:12 -0500
Justin Forbes  wrote:

> It shouldn't be a merge request anyway, kernel-5.9.0-300 has
> nothing to do  
> with ark.  It is based on the F32 spec, with most of the RHELisms
> stripped out. Anything relating to the build of kernel-tools is
> bitrot because Fedora doesn't build kernel-tools from the kernel srpm
> or kernel.spec. This will likely change with the 5.10 rebases as we
> move to a src-git model, though still entirely possible that stable
> updates will fail on tools because we just don't build it.
> kernel-tools.spec is the appropriate place to build gpio-watch in
> Fedora.

OK, I only mentioned it because the last 5.9 development kernel didn't
have the issue.  From what you say above I think that is because
development kernels and stable kernels use different spec files, right?
I like to update everything in synch, kernel, headers, tools, etc.
whether they need it or not.  I guess I'll have to start building them
separately from the src.rpms if the kernel spec gets too out of date.

Thanks.
___
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.9.300 spec file has missing executable gpio-watch in tools file section

2020-10-26 Thread stan via kernel
On Mon, 26 Oct 2020 11:49:48 -0400
Brian Masney  wrote:

> Hi Stan,
> 
> I don't see a patch attached. There is also no [PATCH] subject prefix
> so the patch wasn't automatically converted to a merge request.

When I look at the list mail, neither do I.  But when I look at the
mail in my sent folder, the patch is attached.  So, either my mail
server dropped it, or the mailing list did.  I suspect the mail server,
zoho, though I think I've successfully sent attachments in the past.

Here it is:

--- kernel.spec 2020-10-25 14:40:29.715787846 -0700
+++ kernel.spec 2020-10-25 14:06:16.766496187 -0700
@@ -2795,10 +2795,11 @@ fi
 %{_bindir}/iio_generic_buffer
 %{_bindir}/lsiio
 %{_bindir}/lsgpio
 %{_bindir}/gpio-hammer
 %{_bindir}/gpio-event-mon
+%{_bindir}/gpio-watch
 %{_mandir}/man1/kvm_stat*
 %{_bindir}/kvm_stat
 
 %if %{with_debuginfo}
 %files -f kernel-tools-debuginfo.list -n kernel-tools-debuginfo
___
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.9.300 spec file has missing executable gpio-watch in tools file section

2020-10-25 Thread stan via kernel
The src.rpm for kernel 5.9.300 failed to build rpms because gpio-watch
was not included in the files section of the spec file.  Putting it
there allowed the kernel rpms to build.  I've attached a patch file.

___
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


Solved? Re: System no longer distributes load to multiple cores for long running task

2020-10-16 Thread stan via kernel
On Mon, 21 Sep 2020 12:06:27 -0700
stan  wrote:

> It's been a while (6 months?) since I ran a python program that uses a
> 100% cpu core for hours.  The last time I ran it, the task would
> migrate from core to core to core, every second or so.  I could see
> it doing so in the various tops.
> 
> Now, it runs on only one core, and doesn't move.
> 
> This is more efficient from a computing perspective because there
> aren't as many task switches, but it means that the core that is
> running gets very hot.  Since the rest of the cores are idle, I would
> like to switch back to the previous behavior for this reason.  Can
> someone tell me how?

A quick follow-up:  I am running kernel 5.9 rc8 and this seems to be
working again.  I see the single python task switching cores
approximately every 5 - 10 seconds; perfect!
___
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


header mismatch between tools and kernel in 5.9 rc8

2020-10-11 Thread stan via kernel
Hi,
Just a heads up that there is a header file mismatch between the tools
and kernel includes in 5.9 rc8.  Building from the src.rpm I get this
error.

Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h'
differs from latest version at 'include/uapi/linux/perf_event.h'

The difference between the two files is a single line:


< #define PERF_MEM_SNOOPX_SHIFT 38
---
> #define PERF_MEM_SNOOPX_SHIFT 37

$ diff -U5 -p tools/include/uapi/linux/perf_event.h 
include/uapi/linux/perf_event.h

--- tools/include/uapi/linux/perf_event.h   2020-10-05 11:54:20.0 
-0700
+++ include/uapi/linux/perf_event.h 2020-10-05 11:54:20.0 -0700
@@ -1194,11 +1194,11 @@ union perf_mem_data_src {
 #define PERF_MEM_SNOOP_HITM0x10 /* snoop hit modified */
 #define PERF_MEM_SNOOP_SHIFT   19
 
 #define PERF_MEM_SNOOPX_FWD0x01 /* forward */
 /* 1 free */
-#define PERF_MEM_SNOOPX_SHIFT  38
+#define PERF_MEM_SNOOPX_SHIFT  37
 
 /* locked instruction */
 #define PERF_MEM_LOCK_NA   0x01 /* not available */
 #define PERF_MEM_LOCK_LOCKED   0x02 /* locked transaction */
 #define PERF_MEM_LOCK_SHIFT24

I'm not sure which is the correct version, but once I know I can fix
this with a patch (the above will work), but is there a better way?  I
realize that the Fedora kernel no longer builds tools directly, but
could you make this change there?

Thanks.
___
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: Problem building kernel 5.9 rc6 from src.rpm when perf enabled, looks to be a script error, a typo

2020-09-29 Thread stan via kernel
On Tue, 29 Sep 2020 06:57:07 -0500
Justin Forbes  wrote:

> This is a copy paste error.  Building tools is broken in F33/rawhide
> due to LTO.  That should fix it, though I don't always add it to test
> and see where we are.  You happened to catch a time when I copied too
> much.  Sorry about that.  I never noticed it because we don't build
> tools as part of the kernel.spec for Fedora, and you can't find it
> because it went away the next day automatically. The spec is generated
> without that line at all.

Thanks for the explanation.
___
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


Problem building kernel 5.9 rc6 from src.rpm when perf enabled, looks to be a script error, a typo

2020-09-28 Thread stan via kernel
I sent part of this to the devel list by mistake, correcting and
sending to the kernel list.

Hi,

When building the kernel with perf enabled from the src.rpm
kernel-5.9.0-0.rc6.20200925git171d4ff79f96.17.fc34.src.rpm
I get an error.  There seems to be an error in one of the build
scripts.  This was not a problem in src.rpm for
kernel-5.9.0-0.rc4.20200911git581cb3a26baf.8.fc34.src.rpm

The error seems to be in a script, and looks like a typo,
+ +# perf
/var/tmp/rpm-tmp.bbuLwN: line 499: +#: command not found
error: Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)
Bad exit status from /var/tmp/rpm-tmp.bbuLwN (%build)

When I look in that temporary file, I find this, with the error line
marked by << error:

###
# DO it...
###

# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT/usr/libexec

cd linux-5.9.0-0.rc6.20200925git171d4ff79f96.17.20200927.fc31.x86_64





BuildKernel bzImage arch/x86/boot/bzImage 1

+# perf    error
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh

  /usr/bin/make -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}"
  LDFLAGS="-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld"  -C tools/perf V=1
  NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1
  HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=/usr
  PYTHON=/usr/bin/python3 DESTDIR=$RPM_BUILD_ROOT all

That is in the spec file, but the error isn't in the spec file.
It doesn't have the + in front of the # in the spec file.

###
# DO it...
###

# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT%{_libexecdir}

cd linux-%{KVERREL}


%if %{with_debug}
BuildKernel %make_target %kernel_image %{_use_vdso} debug
%endif

%if %{with_zfcpdump}
BuildKernel %make_target %kernel_image %{_use_vdso} zfcpdump
%endif

%if %{with_pae}
BuildKernel %make_target %kernel_image %{use_vdso} lpae
%endif

%if %{with_up}
BuildKernel %make_target %kernel_image %{_use_vdso}
%endif

%global perf_make \
  %{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" 
%{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 
WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 
NO_BIONIC=1 prefix=%{_prefix} PYTHON=%{__python3}
%if %{with_perf}
+%global _lto_cflags %{nil}
# perf
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh
%{perf_make} DESTDIR=$RPM_BUILD_ROOT all
%endif

%global tools_make \
  %{make} CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" V=1


Thanks for any insight.
___
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: System no longer distributes load to multiple cores for long running task

2020-09-24 Thread stan
On Thu, 24 Sep 2020 06:42:00 -0500
Justin Forbes  wrote:

> On Thu, Sep 24, 2020 at 6:35 AM Florian Weimer 
> wrote:
> >
> > * Justin Forbes:
> >  
> > > On Thu, Sep 24, 2020 at 4:34 AM Florian Weimer
> > >  wrote:  
> > >>
> > >> * Chris Murphy:
> > >>  
> > >> > On Wed, Sep 23, 2020 at 1:44 PM stan  wrote:
> > >> >
> > >> > For what it's worth, gmail puts your emails into spam because
> > >> > of the your domain's DMARC policy:
> > >> >
> > >> >
> > >> > Authentication-Results: mx.google.com;
> > >> >arc=fail (body hash mismatch);  
> > >>
> > >> That's a Fedora mailing list configuration issue.  It alters the
> > >> body.
> > >>
> > >> These days, mailing lists need to be configured in such a way
> > >> that they do not add such footers (adding headers is generally
> > >> fine). 
> > >
> > > I don't see any option to change that in the list settings.  
> >
> > As a user/subscriber?  Yes, I think it's a list administrator
> > setting. 
> 
> No, as an admin.  I am the admin. There are options for modifying
> headers, nothing for the footer/body.

I am able to post to the users and devel list with the same email
address, so it must be possible.
___
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: System no longer distributes load to multiple cores for long running task

2020-09-24 Thread stan
On Wed, 23 Sep 2020 22:20:14 -0600
Chris Murphy  wrote:

> On Wed, Sep 23, 2020 at 1:44 PM stan  wrote:
> 
> For what it's worth, gmail puts your emails into spam because of the
> your domain's DMARC policy:
> 
> 
> Authentication-Results: mx.google.com;
>arc=fail (body hash mismatch);
>spf=pass (google.com: domain of
> kernel-boun...@lists.fedoraproject.org designates 38.145.60.11 as
> permitted sender)
> smtp.mailfrom=kernel-boun...@lists.fedoraproject.org;
>dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE)
> header.from=zoho.com

Thanks for the explanation! 
___
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 reply Re: System no longer distributes load to multiple cores for long running task

2020-09-24 Thread stan via kernel
On Thu, 24 Sep 2020 09:17:22 -0700
stan via kernel  wrote:

> This is a test reply to see if the setting change worked.  Will post
> whether I receive the email or not.  I am assuming that 1 hr is enough
> time to propagate the change.

I received the message, so it worked, but I see by Jiri's response that
this causes problems for other list members.  Maybe there is the better
way he suggested?
___
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


Test reply Re: System no longer distributes load to multiple cores for long running task

2020-09-24 Thread stan via kernel
On Thu, 24 Sep 2020 10:51:25 -0500
Justin Forbes  wrote:

> On Thu, Sep 24, 2020 at 9:47 AM Kevin Fenzi  wrote:

> > You may be looking for the DMARC Mitigations section under
> > 'settings' in the admin interface?
> >
> > Both devel and users have that set to:
> >
> > "Replace From with list address"
> >  
> 
> Just enabled that setting for kernel.  We will see how it goes.
> 
> Thanks!

This is a test reply to see if the setting change worked.  Will post
whether I receive the email or not.  I am assuming that 1 hr is enough
time to propagate the change.
___
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: System no longer distributes load to multiple cores for long running task

2020-09-23 Thread stan
On Wed, 23 Sep 2020 12:44:45 -0700
stan  wrote:

> On Wed, 23 Sep 2020 12:08:22 +
> "Gregorio ."  wrote:
> 
> > You can manually set the CPU affinity (see taskset utility) to
> > decide the core(s) where to run your process, even if it is already
> > running.  

The plot thickens.  I am running a background compile using clang / rust
restricted to 2 cores, and I see that it in fact behaves exactly as I
remember.  The tasks switch between cores regularly.  Perhaps I am
remembering incorrectly what happens with python scripts, and they have
always remained locked on a single core.  But I don't think so.  I'll
keep following up with my plan.
___
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: System no longer distributes load to multiple cores for long running task

2020-09-23 Thread stan
On Wed, 23 Sep 2020 12:08:22 +
"Gregorio ."  wrote:

> You can manually set the CPU affinity (see taskset utility) to decide
> the core(s) where to run your process, even if it is already running.

I can see how that would work as a manual intervention.  But this used
to happen automatically as the default for the system.  I've been
trying to research this but most of the web articles available are
about sharing a single core, and ensuring a fair allocation of that
core's resources to several tasks.  This kind of task migration to
random cores while the task is running when there isn't resource
contention does not seem to get much mention.  

The kernel documentation has the same bias.  My plan right now is to
compile an older kernel, say 5.5 or 5.6 where this was working by
default, and see if it is still working.  If it is, then it is a kernel
change.  If it isn't, then something changed in the Fedora
configuration.  That will narrow down where I have to look.

I'm probably not searching correctly because I have only a vague
understanding of the terminology used for scheduling tasks.  And the
interaction of the scheduler and NUMA.  When I search the kernel
mailing list, the problem isn't a lack of matches, but an overwhelming
number of matches.  This seems to be a very active area of development.

In the end, I might just have to live with it, and use your suggestion
to manually shift the task when I am present and think about it.  Maybe
it isn't really an issue, but it seems to me that for the CPU core in
question, it is a lot like over-clocking it.

Thanks for your reply.  It gave me another thread to pull.
___
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


System no longer distributes load to multiple cores for long running task

2020-09-21 Thread stan
Hi,

It's been a while (6 months?) since I ran a python program that uses a
100% cpu core for hours.  The last time I ran it, the task would migrate
from core to core to core, every second or so.  I could see it doing so
in the various tops.

Now, it runs on only one core, and doesn't move.

This is more efficient from a computing perspective because there
aren't as many task switches, but it means that the core that is
running gets very hot.  Since the rest of the cores are idle, I would
like to switch back to the previous behavior for this reason.  Can
someone tell me how?

Thanks.

PS I'm copying devel in case this isn't a kernel issue, and also
because my posts to the kernel list just seem to disappear into the
ether.
___
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: Who knows how to configure mock to build the kernel locally?

2020-07-15 Thread stan
On Wed, 15 Jul 2020 17:01:07 -
"Mikhail Gavrilov"  wrote:

> Who knows how to configure mock to build the kernel locally?
> I need to test some upstream patches, but I discovered that
> currently, I could not build kernel locally because of pesign not
> working in the mock environment. I do not want to use koji because I
> have enough power PC at home with Ryzen 3950X. Here I filled bug
> report https://bugzilla.redhat.com/show_bug.cgi?id=1855836 but no one
> answers me.

I build a custom kernel, and sign it using pesign with a locally
generated key, but using rpmbuild, not mock. However, what isn't clear
from your description, and my unfamiliarity with the mock build
process, is whether you have a local signing key installed in your EFI
public key database.  If you don't, I don't think it can work.  The
private key that kernels are signed with when they are official Fedora
kernels resides on the Fedora infrastructure. It is *not* going to be
transferred to your local machine as that would be a severe security
breach (it would no longer be a valid private key).  So, I think you
need to create a key pair on your local machine, and install the public
key in the EFI database on your local machine.
___
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 a custom kernel with 5.8 rc2 fails with error

2020-06-26 Thread stan
On Fri, 26 Jun 2020 21:34:27 +0200
Ondrej Mosnacek  wrote:

> Apparently you are not the only one hitting this problem:
> https://lore.kernel.org/lkml/20200609202134.GA1105@sol.localdomain/
> Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around
> it (but hopefully the guys will fix it in a better way eventually).
> 
> It wasn't really hard to find the thread:
> 1. `git blame kernel/smp.c` to find which commit introduced the lines
> that throw the error.
> 2. The commit message has a helpful link to the original patch
> submission in the LKML archives.
> 3. Clicked the third reply (longest subthread) to the patch itself and
> read the rest of the replies in the thread.
> 4. Bingo ;-)

And like others in the above thread, when I turn off
CONFIG_GCC_PLUGIN_RANDSTRUCT, compilation succeeds.
___
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 a custom kernel with 5.8 rc2 fails with error

2020-06-26 Thread stan
On Fri, 26 Jun 2020 21:34:27 +0200
Ondrej Mosnacek  wrote:

> Apparently you are not the only one hitting this problem:
> https://lore.kernel.org/lkml/20200609202134.GA1105@sol.localdomain/
> Seems you need to turn off CONFIG_GCC_PLUGIN_RANDSTRUCT to work around
> it (but hopefully the guys will fix it in a better way eventually).
> 
> It wasn't really hard to find the thread:
> 1. `git blame kernel/smp.c` to find which commit introduced the lines
> that throw the error.
> 2. The commit message has a helpful link to the original patch
> submission in the LKML archives.
> 3. Clicked the third reply (longest subthread) to the patch itself and
> read the rest of the replies in the thread.
> 4. Bingo ;-)

Thank you!  I never even thought to do a search.  I just presumed it
was something I had done, especially since the rawhide builds were
succeeding (which in fact I had, just a long time ago).  They must have
that CONFIG_GCC_PLUGIN_RANDSTRUCT turned off.
___
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 a custom kernel with 5.8 rc2 fails with error

2020-06-26 Thread stan
On Fri, 26 Jun 2020 13:36:26 -0500
Justin Forbes  wrote:

> I am not sure, I haven't tried building on f31, but it does build fine
> on f32.  Given that the kernels gcc targets are much lower than what
> we are shipping anywhere in Fedora, I would not expect that to be the
> case, but it could be a bug.

Thanks, a bug after all this time, while possible, seems unlikely; I'll
just keep plugging away at it, trying with newer kernel packages, and
by changing the new configuration options in various patterns.  Maybe
I'll do some diffs of the 5.7 and 5.8 files that are implicated to see
if anything has changed.
___
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 a custom kernel with 5.8 rc2 fails with error

2020-06-26 Thread stan
On Fri, 26 Jun 2020 12:17:29 -0500
Justin Forbes  wrote:

> What changes are you making to your custom build?  This is not
> something we are hitting in rawhide.

Extensive.  It is tuned for my hardware, and turns off anything that
isn't necessary.  But I didn't change any options from what worked
with 5.7.  There were new configuration options with 5.8 that I left
turned off; maybe it was one of them, though none of them had anything
to do with smp that I could determine.

I was afraid it might be something like this, but was hoping that you
would be aware of some obvious change to the kernel that would cause
this.  Could it be related to the switch to the later version of gcc in
rawhide?  i.e.  new flags not recognized by my older version of gcc are
causing the problem.
___
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


Building a custom kernel with 5.8 rc2 fails with error

2020-06-26 Thread stan
I sent the message below to the kernel list on Wednesday, and have not
seen it on the list yet.  So I am copying Justin, who I expect would be
the person that would answer this question if possible, and resending
it in case it somehow got lost in the data center move.

Hi,

I am trying to build a custom kernel from the src.rpm for 5.8.0.0.rc2
(kernel-5.8.0-0.rc2.20200623gitdd0d718152e4.1.fc33.src.rpm) on FC31, and
it fails with the following error.  I've tried two candidates so far,
and both failed (0622, 0623).  The same configuration works on 5.7
kernels.

Can you provide any insight, or a workaround?


In file included from ./arch/x86/include/asm/atomic.h:5,
 from ./include/linux/atomic.h:7,
 from ./include/linux/llist.h:51,
 from ./include/linux/irq_work.h:5,
 from kernel/smp.c:10:
kernel/smp.c: In function 'smp_init':
./include/linux/compiler.h:392:38: error: call to
  '__compiletime_assert_156' declared with attribute error:
  BUILD_BUG_ON failed: offsetof(struct task_struct,
  wake_entry_type) - offsetof(struct task_struct, wake_entry) !=
  offsetof(struct __call_single_data, flags) - offsetof(struct
  __call_single_data, llist) 392 |  _compiletime_assert(condition,
  msg, __compiletime_assert_, __COUNTER__) |
^ ./include/linux/compiler.h:373:4: note: in
  definition of macro '__compiletime_assert' 373 |prefix ##
  suffix();\ |^~ ./include/linux/compiler.h:392:2:
  note: in expansion of macro '_compiletime_assert' 392 |
  _compiletime_assert(condition, msg, __compiletime_assert_,
  __COUNTER__) |  ^~~
  ./include/linux/build_bug.h:39:37: note: in expansion of macro
  'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg)
  compiletime_assert(!(cond), msg) |
   ^~ ./include/linux/build_bug.h:50:2: note:
  in expansion of macro 'BUILD_BUG_ON_MSG' 50 |
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) |
   ^~~~ kernel/smp.c:687:2: note: in expansion of macro
  'BUILD_BUG_ON' 687 |  BUILD_BUG_ON(offsetof(struct task_struct,
  wake_entry_type) - offsetof(struct task_struct, wake_entry) != |
  ^~~~ make[1]: *** [scripts/Makefile.build:281:
  kernel/smp.o] Error 1 make[1]: *** Waiting for unfinished jobs
___
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


Building a custom kernel with 5.8 rc2 fails with error

2020-06-24 Thread stan
Hi,

I am trying to build a custom kernel from the src.rpm for 5.8.0.0.rc2
(kernel-5.8.0-0.rc2.20200623gitdd0d718152e4.1.fc33.src.rpm) on FC31, and
it fails with the following error.  I've tried two candidates so far,
and both failed (0622, 0623).  The same configuration works on 5.7
kernels.

Can you provide any insight, or a workaround?


In file included from ./arch/x86/include/asm/atomic.h:5,
 from ./include/linux/atomic.h:7,
 from ./include/linux/llist.h:51,
 from ./include/linux/irq_work.h:5,
 from kernel/smp.c:10:
kernel/smp.c: In function 'smp_init':
./include/linux/compiler.h:392:38: error: call to
  '__compiletime_assert_156' declared with attribute error:
  BUILD_BUG_ON failed: offsetof(struct task_struct,
  wake_entry_type) - offsetof(struct task_struct, wake_entry) !=
  offsetof(struct __call_single_data, flags) - offsetof(struct
  __call_single_data, llist) 392 |  _compiletime_assert(condition,
  msg, __compiletime_assert_, __COUNTER__) |
^ ./include/linux/compiler.h:373:4: note: in
  definition of macro '__compiletime_assert' 373 |prefix ##
  suffix();\ |^~ ./include/linux/compiler.h:392:2:
  note: in expansion of macro '_compiletime_assert' 392 |
  _compiletime_assert(condition, msg, __compiletime_assert_,
  __COUNTER__) |  ^~~
  ./include/linux/build_bug.h:39:37: note: in expansion of macro
  'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg)
  compiletime_assert(!(cond), msg) |
   ^~ ./include/linux/build_bug.h:50:2: note:
  in expansion of macro 'BUILD_BUG_ON_MSG' 50 |
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) |
   ^~~~ kernel/smp.c:687:2: note: in expansion of macro
  'BUILD_BUG_ON' 687 |  BUILD_BUG_ON(offsetof(struct task_struct,
  wake_entry_type) - offsetof(struct task_struct, wake_entry) != |
  ^~~~ make[1]: *** [scripts/Makefile.build:281:
  kernel/smp.o] Error 1 make[1]: *** Waiting for unfinished jobs
___
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: [ARK PATCH 2/2] x86, hypervisor: Update hypervisor macro for rh_check_supported

2020-05-14 Thread stan
On Thu, 14 May 2020 20:20:52 -
GitLab Bridge on behalf of dzickusrh  wrote:

> From: Don Zickus 
> 
> Upstream status: RHEL only
> 
> The variable x86_hyper_type is hidden behind a macro and not available
> when guest mode is not config'd enabled.
> 
> Update to use hypervisor_is_type() macro, available since

Thanks for fixing this.
___
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: RHEL-specific patches in Fedora (non ELN) (was: Re: Building custom kernel from src.rpm fails for kernel 5.7)

2020-05-13 Thread stan
On Tue, 12 May 2020 11:21:59 -0500
Justin Forbes  wrote:

> The ELN kernel does build with them enabled.  The original build
> failure here was due to one not being wrapped, and it should be fixed.

After I saw this, I pulled the latest src.rpm from koji, rc7, and tried
building it.  I still had to patch it for the original error, though
after that it built successfully, and is now running.  Is that because
the fix is still in the pipeline and hadn't yet made it into rc7?

Thanks.
___
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 from src.rpm fails for kernel 5.7

2020-05-11 Thread stan
On Mon, 11 May 2020 14:20:35 -0400
Don Zickus  wrote:

> Odd, the ELN build didn't fail for that reason.
> 
> You should able to wrap rh_check_supported() with 
> 
> #ifdef CONFIG_RHEL_DIFFERENCES
> ...
> #endif
> 
> (as I am pretty sure your config has the disabled)

It does.

> OR
> 
> s/x86_hyper_type !=
> X86_HYPER_NATIVE/!hypervisor_is_type(X86_HYPER_NATIVE)/

I saw that, but I wasn't familiar enough with what is going on to know
if that would only take me down the rabbit hole because something else
was missing because of the failed extern definition of x86_hyper_native.
___
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 from src.rpm fails for kernel 5.7

2020-05-11 Thread stan
On Mon, 11 May 2020 09:44:54 -0700
stan  wrote:

> On Mon, 11 May 2020 11:30:26 -0500
> Justin Forbes  wrote:
> 
> > when building the kernel with multiple threads, it is entirely
> > possible that the failure happens in one thread, but the remaining
> > threads make noise while they continue their current task. The error
> > can end up a good bit higher in the build log. It is best to look
> > through the entire log.  The current 5.7 kernels do have some
> > changes to support GCC 10, but they should continue to build fine
> > on F31 as well, and the ELN builds of these kernels are doing
> > headers and tools as well, so the spec should be working with that
> > now.  
> 
> Thank you, I'll look into that.

This is the actual error.

arch/x86/kernel/setup.c: In function 'rh_check_supported':
arch/x86/kernel/setup.c:824:11: error: 'x86_hyper_type' undeclared (first use 
in this function); did you mean 'x86_hyper_init'?
  824 |  guest = (x86_hyper_type != X86_HYPER_NATIVE || 
boot_cpu_has(X86_FEATURE_HYPERVISOR));
  |   ^~
  |   x86_hyper_init
arch/x86/kernel/setup.c:824:11: note: each undeclared identifier is reported 
only once for each function it appears in
At top level:
arch/x86/kernel/setup.c:820:13: warning: 'rh_check_supported' defined but not 
used [-Wunused-function]
  820 | static void rh_check_supported(void)
  | ^~
make[2]: *** [scripts/Makefile.build:267: arch/x86/kernel/setup.o] Error 1
make[1]: *** [scripts/Makefile.build:488: arch/x86/kernel] Error 2
make: *** [Makefile:1732: arch/x86] Error 2
make: *** Waiting for unfinished jobs
___
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


  1   2   >