Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels? Thanks.
poma
On Jan 30, 2014 12:12 PM, "poma" pomidorabelisima@gmail.com wrote:
Who builds these kernels?
We do. Specifically Justin.
Perhaps the better question is how can I actually find who builds these kernels? :)
Look at the change log?
And if any exists, where is a git repo for these kernels?
Just the fedora kernel git repo. Then they have "make release" run before the build.
josh
On 30.01.2014 18:19, Josh Boyer wrote:
On Jan 30, 2014 12:12 PM, "poma" pomidorabelisima@gmail.com wrote:
Who builds these kernels?
We do. Specifically Justin.
Thanks for that. ;)
Perhaps the better question is how can I actually find who builds these kernels? :)
Look at the change log?
I was thinking something like this, :)
- Fedora 20 $ rpm -qip kernel-3.12.8-300.fc20.x86_64.rpm | grep Signature Signature : RSA/SHA256, Fri 17 Jan 2014 04:14:00 PM CET, Key ID 2eb161fa246110c1 $ gpg --search-keys 2eb161fa246110c1 gpg: searching for "2eb161fa246110c1" from hkp server keys.gnupg.net (1) Fedora (20) fedora@fedoraproject.org 4096 bit RSA key 246110C1, created: 2013-05-16 Keys 1-1 of 1 for "2eb161fa246110c1". Enter number(s), N)ext, or Q)uit > 1 gpg: requesting key 246110C1 from hkp server keys.gnupg.net gpg: key 246110C1: "Fedora (20) fedora@fedoraproject.org" not changed gpg: Total number processed: 1 gpg: unchanged: 1
- Rawhide $ rpm -qip kernel-3.14.0-0.rc0.git13.1.fc21.x86_64.rpm | grep Signature Signature : (none)
- RawhideKernelNodebug $ rpm -qip kernel-3.14.0-0.rc0.git15.2.fc21.x86_64.rpm | grep Signature Signature : (none)
And if any exists, where is a git repo for these kernels?
Just the fedora kernel git repo. Then they have "make release" run before the build.
josh
All right! Thanks.
poma
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path? Thanks.
poma
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
josh
On 30.01.2014 20:04, Josh Boyer wrote:
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
josh
I presumed the whole story with the signing is a lot easier in the application. Bummer.
poma
On Thu, 30 Jan 2014 14:04:53 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
To clarify what Josh said:
rawhide _rpms_ are not signed. Only stable/branched Fedora versions currently get signed rpms.
rawhide kernel packages _are_ secure boot signed. (ie, they will work on a secure boot enabled machine).
rawhide nodebug packages are _not_ secure boot signed, as they are scratch builds and not built in the secure boot channel. They will not boot on a secure boot enabled machine.
At least this is my understanding.
kevin
On Thu, Jan 30, 2014 at 3:02 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 30 Jan 2014 14:04:53 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
To clarify what Josh said:
rawhide _rpms_ are not signed. Only stable/branched Fedora versions currently get signed rpms.
rawhide kernel packages _are_ secure boot signed. (ie, they will work on a secure boot enabled machine).
rawhide nodebug packages are _not_ secure boot signed, as they are scratch builds and not built in the secure boot channel. They will not boot on a secure boot enabled machine.
At least this is my understanding.
Yes! Thanks for the clarification.
josh
On Thu, Jan 30, 2014 at 9:02 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 30 Jan 2014 14:04:53 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
To clarify what Josh said:
rawhide _rpms_ are not signed [...]
Why?
On Fri, Jan 31, 2014 at 12:30:17AM +0100, drago01 wrote:
On Thu, Jan 30, 2014 at 9:02 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 30 Jan 2014 14:04:53 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
To clarify what Josh said:
rawhide _rpms_ are not signed [...]
Why?
Koji doesn't do auto-signing, people have suggested auto-signing isn't any better than not signing, the signing we do for releases is done in a manual fashion as a result, and the signing software is... fragile. I think that mostly sums it up.
Basically the churn of rawhide and the lack of automation makes it infeasible to really do.
josh
On Fri, 31 Jan 2014 00:30:17 +0100 drago01 drago01@gmail.com wrote:
On Thu, Jan 30, 2014 at 9:02 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 30 Jan 2014 14:04:53 -0500 Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 30, 2014 at 2:03 PM, poma pomidorabelisima@gmail.com wrote:
On 30.01.2014 18:19, Peter Robinson wrote:
On Thu, Jan 30, 2014 at 5:12 PM, poma pomidorabelisima@gmail.com wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels?
Generally it's jforbes. The config is basically the fedora kernel git repo with the debug options disabled.
Peter
So practically with the Rawhide "- Disable debugging options." stage, Rawhide & RawhideKernelNodebug are on the same path?
Yes.
Also, rawhide kernels from koji aren't signed either. Signing of RPMs is only done late in the release process, and for updates to a stable release.
To clarify what Josh said:
rawhide _rpms_ are not signed [...]
Why?
There's no gating of pakages into rawhide composes.
We could sign all of them, and 1 minute before the compose a new one could come along and go out unsigned. I like sleeping, so it's unlikely I would want to stay up until right before compose anyhow.
There's a pretty massive amount of change, so signing would take a while every day and could slow down signing for stable releases.
It would take up more storage to have signed copies of most rawhide packages.
If a package went out unsigned and got signed the next day it could cause yum weirdness. (checksum doesn't match)
I've thought about doing it anyhow, but then people will complain about some random unsigned packages. We also would need to resign everything at branch time anyhow.
(This is just off the top of my head, there may well be many other reasons, ask Dennis).
kevin
On Thu, 2014-01-30 at 18:12 +0100, poma wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels? Thanks.
'fedpkg clone kernel' gets you the repo.
Seriously, the entire process is: 'cp -r master nodebug; make release; fedpkg srpm' 'koji build --scratch rawhide '/path/to/srpm' Then the results are downloaded and put into a repository.
Justin
On 30.01.2014 19:58, Justin M. Forbes wrote:
On Thu, 2014-01-30 at 18:12 +0100, poma wrote:
Who builds these kernels? Perhaps the better question is how can I actually find who builds these kernels? :) And if any exists, where is a git repo for these kernels? Thanks.
'fedpkg clone kernel' gets you the repo.
Seriously, the entire process is: 'cp -r master nodebug; make release; fedpkg srpm' 'koji build --scratch rawhide '/path/to/srpm' Then the results are downloaded and put into a repository.
Justin
Hey maestro! Que pasa en su casa!? :)
Am hitting something with 3.14.0-0.rc0.git15.2.fc21.x86_64 so I called it "RawhideKernelNodebugNosignNoboot". :) Thanks for the explanation, though I didn't understand you. Haha I have to study this repo, uhuh.
poma
…
Am hitting something with 3.14.0-0.rc0.git15.2.fc21.x86_64 so I called it "RawhideKernelNodebugNosignNoboot". :)
This is what I thought,
A video mode, boot loader parameter i.e. "vga=" expressed in a decimal notation e.g. 773 is broken - the boot is stuck, however one expressed in a hexadecimal notation (starting with "0x") e.g. 0x305, no problemos at all. To be more precise, what is interesting in this story, is an erratic occurrence of this problem, e.g. - Rawhide's 3.14.0-0.rc0.git15.1.fc21.x86_64 - a decimal notation *sometimes* works - RawhideKernelNodebug's 3.14.0-0.rc0.git15.2.fc21.x86_64 - a decimal notation *never* works - Rawhide's 3.14.0-0.rc0.git17.1.fc21.x86_64 - a decimal notation *sometimes* works
poma
On 31.01.2014 11:47, poma wrote:
This is what I thought,
A video mode, boot loader parameter i.e. "vga=" expressed in a decimal notation e.g. 773 is broken - the boot is stuck, however one expressed in a hexadecimal notation (starting with "0x") e.g. 0x305, no problemos at all. To be more precise, what is interesting in this story, is an erratic occurrence of this problem, e.g.
- Rawhide's 3.14.0-0.rc0.git15.1.fc21.x86_64 - a decimal notation
*sometimes* works
- RawhideKernelNodebug's 3.14.0-0.rc0.git15.2.fc21.x86_64 - a decimal
notation *never* works
- Rawhide's 3.14.0-0.rc0.git17.1.fc21.x86_64 - a decimal notation
*sometimes* works
To complement and finish.
"The kernel hang/crash/stuck/whatnot during boot" is resolved with these two patches: - [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in numa_clear_kernel_node_hotplug(). http://marc.info/?l=linux-kernel&m=139089978307936&q=raw - [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when synchronizing nid to memblock.reserved. http://marc.info/?l=linux-kernel&m=139089984707944&q=raw
Tested via: - kernel-3.14.0-0.rc1.git0.2.fc21.x86_64.rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=496017 "Add NUMA oops patches" http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-1.patch http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-2.patch - my nodebug version, kernel-3.14.0-0.rc1.git0.4.fc21.x86_64.rpm
Both are PASSED.
Affected Fedora's kernels: - kernel-3.14.0-0.rc1.git0.1.fc21 - kernel-3.14.0-0.rc0.git19.1.fc21 - kernel-3.14.0-0.rc0.git18.1.fc21 - kernel-3.14.0-0.rc0.git17.1.fc21 http://koji.fedoraproject.org/koji/packageinfo?packageID=8
Badly affected was this card: Chipset: G98 (NV98) Family : NV50 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] [10de:06e4] (rev a1) Nouveau
While this one worked without problemos: !? Chipset: MCP79/MCP7A (NVAC) Family : NV50 NVIDIA Corporation ION VGA [10de:087d] (rev b1) Nouveau
Another notes. After the affected kernel hang at the very beginning of the loading/booting due to the mentioned application of the vesa mode, it was necessary to power off machine, otherwise correct kernels would become affected. Just to reset machine wasn't enough. At the end, even a hexadecimal notation became broken. :)
Ahoy folks! poma
More about this can be found here: - [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable. http://thread.gmane.org/gmane.linux.kernel/1634270 - [PATCH 0/2] numa, mem-hotplug: Fix array out of boundary in numa initialization. http://thread.gmane.org/gmane.linux.kernel/1636585
The TOG:
+---------------------------------------------------------+ | color | 800x600 | 1024x768 | 1280x1024 | | : |---------------+---------------+---------------| | depth | hex : dec | hex : dec | hex : dec | |---------+--------:------+--------:------+--------:------| | 256 | 0x303 : 771 | 0x305 : 773 | 0x307 : 775 | | 64k | 0x314 : 788 | 0x317 : 791 | 0x31A : 794 | | 16M | 0x315 : 789 | 0x318 : 792 | 0x31B : 795 | +---------------------------------------------------------+
On 05.02.2014 06:46, poma wrote:
On 31.01.2014 11:47, poma wrote:
This is what I thought,
A video mode, boot loader parameter i.e. "vga=" expressed in a decimal notation e.g. 773 is broken - the boot is stuck, however one expressed in a hexadecimal notation (starting with "0x") e.g. 0x305, no problemos at all. To be more precise, what is interesting in this story, is an erratic occurrence of this problem, e.g.
- Rawhide's 3.14.0-0.rc0.git15.1.fc21.x86_64 - a decimal notation
*sometimes* works
- RawhideKernelNodebug's 3.14.0-0.rc0.git15.2.fc21.x86_64 - a decimal
notation *never* works
- Rawhide's 3.14.0-0.rc0.git17.1.fc21.x86_64 - a decimal notation
*sometimes* works
To complement and finish.
"The kernel hang/crash/stuck/whatnot during boot" is resolved with these two patches:
- [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in
numa_clear_kernel_node_hotplug(). http://marc.info/?l=linux-kernel&m=139089978307936&q=raw
- [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when
synchronizing nid to memblock.reserved. http://marc.info/?l=linux-kernel&m=139089984707944&q=raw
Tested via:
kernel-3.14.0-0.rc1.git0.2.fc21.x86_64.rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=496017 "Add NUMA oops patches" http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-1.patch http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-2.patch
my nodebug version, kernel-3.14.0-0.rc1.git0.4.fc21.x86_64.rpm
Both are PASSED.
Affected Fedora's kernels:
- kernel-3.14.0-0.rc1.git0.1.fc21
- kernel-3.14.0-0.rc0.git19.1.fc21
- kernel-3.14.0-0.rc0.git18.1.fc21
- kernel-3.14.0-0.rc0.git17.1.fc21 http://koji.fedoraproject.org/koji/packageinfo?packageID=8
Badly affected was this card: Chipset: G98 (NV98) Family : NV50 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] [10de:06e4] (rev a1) Nouveau
While this one worked without problemos: !? Chipset: MCP79/MCP7A (NVAC) Family : NV50 NVIDIA Corporation ION VGA [10de:087d] (rev b1) Nouveau
Another notes. After the affected kernel hang at the very beginning of the loading/booting due to the mentioned application of the vesa mode, it was necessary to power off machine, otherwise correct kernels would become affected. Just to reset machine wasn't enough. At the end, even a hexadecimal notation became broken. :)
Ahoy folks! poma
More about this can be found here:
- [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting
kernel nodes to unhotpluggable. http://thread.gmane.org/gmane.linux.kernel/1634270
- [PATCH 0/2] numa, mem-hotplug: Fix array out of boundary in numa
initialization. http://thread.gmane.org/gmane.linux.kernel/1636585
The TOG:
+---------------------------------------------------------+ | color | 800x600 | 1024x768 | 1280x1024 | | : |---------------+---------------+---------------| | depth | hex : dec | hex : dec | hex : dec | |---------+--------:------+--------:------+--------:------| | 256 | 0x303 : 771 | 0x305 : 773 | 0x307 : 775 | | 64k | 0x314 : 788 | 0x317 : 791 | 0x31A : 794 | | 16M | 0x315 : 789 | 0x318 : 792 | 0x31B : 795 | +---------------------------------------------------------+
I think this is also interesting to note, referring to Dave's original report, - hang on early boot, numa init code stack overflow? http://thread.gmane.org/gmane.linux.kernel/1633909 if applied, 'earlyprintk=vga[,keep]', the affectness of the affected kernels is gone with the wind. :)
http://www.youtube.com/embed/l-ceg763Voc?rel=0&border=0&autoplay=1
poma
On 02/05/2014 07:51 PM, poma wrote:
On 05.02.2014 06:46, poma wrote:
On 31.01.2014 11:47, poma wrote:
This is what I thought,
A video mode, boot loader parameter i.e. "vga=" expressed in a decimal notation e.g. 773 is broken - the boot is stuck, however one expressed in a hexadecimal notation (starting with "0x") e.g. 0x305, no problemos at all. To be more precise, what is interesting in this story, is an erratic occurrence of this problem, e.g.
- Rawhide's 3.14.0-0.rc0.git15.1.fc21.x86_64 - a decimal notation
*sometimes* works
- RawhideKernelNodebug's 3.14.0-0.rc0.git15.2.fc21.x86_64 - a decimal
notation *never* works
- Rawhide's 3.14.0-0.rc0.git17.1.fc21.x86_64 - a decimal notation
*sometimes* works
To complement and finish.
"The kernel hang/crash/stuck/whatnot during boot" is resolved with these two patches:
- [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in
numa_clear_kernel_node_hotplug(). http://marc.info/?l=linux-kernel&m=139089978307936&q=raw
- [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when
synchronizing nid to memblock.reserved. http://marc.info/?l=linux-kernel&m=139089984707944&q=raw
Tested via:
kernel-3.14.0-0.rc1.git0.2.fc21.x86_64.rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=496017 "Add NUMA oops patches" http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-1.patch http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-2.patch
my nodebug version, kernel-3.14.0-0.rc1.git0.4.fc21.x86_64.rpm
Both are PASSED.
Affected Fedora's kernels:
- kernel-3.14.0-0.rc1.git0.1.fc21
- kernel-3.14.0-0.rc0.git19.1.fc21
- kernel-3.14.0-0.rc0.git18.1.fc21
- kernel-3.14.0-0.rc0.git17.1.fc21 http://koji.fedoraproject.org/koji/packageinfo?packageID=8
Badly affected was this card: Chipset: G98 (NV98) Family : NV50 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] [10de:06e4] (rev a1) Nouveau
While this one worked without problemos: !? Chipset: MCP79/MCP7A (NVAC) Family : NV50 NVIDIA Corporation ION VGA [10de:087d] (rev b1) Nouveau
Another notes. After the affected kernel hang at the very beginning of the loading/booting due to the mentioned application of the vesa mode, it was necessary to power off machine, otherwise correct kernels would become affected. Just to reset machine wasn't enough. At the end, even a hexadecimal notation became broken. :)
Ahoy folks! poma
More about this can be found here:
- [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting
kernel nodes to unhotpluggable. http://thread.gmane.org/gmane.linux.kernel/1634270
- [PATCH 0/2] numa, mem-hotplug: Fix array out of boundary in numa
initialization. http://thread.gmane.org/gmane.linux.kernel/1636585
The TOG:
+---------------------------------------------------------+ | color | 800x600 | 1024x768 | 1280x1024 | | : |---------------+---------------+---------------| | depth | hex : dec | hex : dec | hex : dec | |---------+--------:------+--------:------+--------:------| | 256 | 0x303 : 771 | 0x305 : 773 | 0x307 : 775 | | 64k | 0x314 : 788 | 0x317 : 791 | 0x31A : 794 | | 16M | 0x315 : 789 | 0x318 : 792 | 0x31B : 795 | +---------------------------------------------------------+
I think this is also interesting to note, referring to Dave's original report,
- hang on early boot, numa init code stack overflow? http://thread.gmane.org/gmane.linux.kernel/1633909
Hi Poma,
I'm sorry I didn't quite follow the original email. The above "stack overflow" problem has been fixed by the following patches, I think.
- [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in numa_clear_kernel_node_hotplug(). http://marc.info/?l=linux-kernel&m=139089978307936&q=raw - [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when synchronizing nid to memblock.reserved. http://marc.info/?l=linux-kernel&m=139089984707944&q=raw
Actually it was not stack overflow, but array index over boundary.
if applied, 'earlyprintk=vga[,keep]', the affectness of the affected kernels is gone with the wind. :)
I'm not quite familiar with this boot option. Are you saying with this boot option, the "stack overflow" like problem will go away ? Although it was not stack overflow.
http://www.youtube.com/embed/l-ceg763Voc?rel=0&border=0&autoplay=1
And sorry, what is this ?
Thanks.
poma
On 06.02.2014 02:04, Tang Chen wrote:
On 02/05/2014 07:51 PM, poma wrote:
On 05.02.2014 06:46, poma wrote:
On 31.01.2014 11:47, poma wrote:
This is what I thought,
A video mode, boot loader parameter i.e. "vga=" expressed in a decimal notation e.g. 773 is broken - the boot is stuck, however one expressed in a hexadecimal notation (starting with "0x") e.g. 0x305, no problemos at all. To be more precise, what is interesting in this story, is an erratic occurrence of this problem, e.g.
- Rawhide's 3.14.0-0.rc0.git15.1.fc21.x86_64 - a decimal notation
*sometimes* works
- RawhideKernelNodebug's 3.14.0-0.rc0.git15.2.fc21.x86_64 - a decimal
notation *never* works
- Rawhide's 3.14.0-0.rc0.git17.1.fc21.x86_64 - a decimal notation
*sometimes* works
To complement and finish.
"The kernel hang/crash/stuck/whatnot during boot" is resolved with these two patches:
- [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in
numa_clear_kernel_node_hotplug(). http://marc.info/?l=linux-kernel&m=139089978307936&q=raw
- [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when
synchronizing nid to memblock.reserved. http://marc.info/?l=linux-kernel&m=139089984707944&q=raw
Tested via:
kernel-3.14.0-0.rc1.git0.2.fc21.x86_64.rpm http://koji.fedoraproject.org/koji/buildinfo?buildID=496017 "Add NUMA oops patches" http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-1.patch http://pkgs.fedoraproject.org/cgit/kernel.git/plain/tang-numa-2.patch
my nodebug version, kernel-3.14.0-0.rc1.git0.4.fc21.x86_64.rpm
Both are PASSED.
Affected Fedora's kernels:
- kernel-3.14.0-0.rc1.git0.1.fc21
- kernel-3.14.0-0.rc0.git19.1.fc21
- kernel-3.14.0-0.rc0.git18.1.fc21
- kernel-3.14.0-0.rc0.git17.1.fc21 http://koji.fedoraproject.org/koji/packageinfo?packageID=8
Badly affected was this card: Chipset: G98 (NV98) Family : NV50 NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] [10de:06e4] (rev a1) Nouveau
While this one worked without problemos: !? Chipset: MCP79/MCP7A (NVAC) Family : NV50 NVIDIA Corporation ION VGA [10de:087d] (rev b1) Nouveau
Another notes. After the affected kernel hang at the very beginning of the loading/booting due to the mentioned application of the vesa mode, it was necessary to power off machine, otherwise correct kernels would become affected. Just to reset machine wasn't enough. At the end, even a hexadecimal notation became broken. :)
Ahoy folks! poma
More about this can be found here:
- [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting
kernel nodes to unhotpluggable. http://thread.gmane.org/gmane.linux.kernel/1634270
- [PATCH 0/2] numa, mem-hotplug: Fix array out of boundary in numa
initialization. http://thread.gmane.org/gmane.linux.kernel/1636585
The TOG:
+---------------------------------------------------------+ | color | 800x600 | 1024x768 | 1280x1024 | | : |---------------+---------------+---------------| | depth | hex : dec | hex : dec | hex : dec | |---------+--------:------+--------:------+--------:------| | 256 | 0x303 : 771 | 0x305 : 773 | 0x307 : 775 | | 64k | 0x314 : 788 | 0x317 : 791 | 0x31A : 794 | | 16M | 0x315 : 789 | 0x318 : 792 | 0x31B : 795 | +---------------------------------------------------------+
I think this is also interesting to note, referring to Dave's original report,
- hang on early boot, numa init code stack overflow? http://thread.gmane.org/gmane.linux.kernel/1633909
Hi Poma,
Ahoy!
I'm sorry I didn't quite follow the original email. The above "stack overflow" problem has been fixed by the following patches, I think.
- [PATCH 1/2] numa, mem-hotplug: Initialize numa_kernel_nodes in
numa_clear_kernel_node_hotplug(). http://marc.info/?l=linux-kernel&m=139089978307936&q=raw
- [PATCH 2/2] numa, mem-hotplug: Fix array index overflow when
synchronizing nid to memblock.reserved. http://marc.info/?l=linux-kernel&m=139089984707944&q=raw
In my case it's true.
Actually it was not stack overflow, but array index over boundary.
OK.
if applied, 'earlyprintk=vga[,keep]', the affectness of the affected kernels is gone with the wind. :)
I'm not quite familiar with this boot option. Are you saying with this boot option, the "stack overflow" like problem will go away ? Although it was not stack overflow.
Exactly. Without your two patches, i.e. /boot/extlinux/extlinux.conf … append … == OK … append … vga=773 == BROKEN … append … vga=773 earlyprintk=vga == OK … append … vga=773 earlyprintk=vga,keep == OK …
With your two patches, everything is OK.
https://www.kernel.org/doc/Documentation/kernel-parameters.txt earlyprintk= [X86, …] earlyprintk=vga … earlyprintk is useful when the kernel crashes before the normal console is initialized. It is not enabled by default because it has some cosmetic problems.
Append ",keep" to not disable it when the real console takes over. …
Actual breakage was introduced within this patch, i.e. a series of patches: http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.13-git17.xz/5c23515f7...
http://www.youtube.com/embed/l-ceg763Voc?rel=0&border=0&autoplay=1
And sorry, what is this ?
Bugs Bunny! :) What's up, doc?
poma
Hi Poma,
On 02/06/2014 02:56 PM, poma wrote: ......
Exactly. Without your two patches, i.e. /boot/extlinux/extlinux.conf … append … == OK … append … vga=773 == BROKEN … append … vga=773 earlyprintk=vga == OK … append … vga=773 earlyprintk=vga,keep == OK …
With your two patches, everything is OK.
OK. :)
https://www.kernel.org/doc/Documentation/kernel-parameters.txt earlyprintk= [X86, …] earlyprintk=vga … earlyprintk is useful when the kernel crashes before the normal console is initialized. It is not enabled by default because it has some cosmetic problems.
Append ",keep" to not disable it when the real console takes over.…
Actual breakage was introduced within this patch, i.e. a series of patches: http://pkgs.fedoraproject.org/repo/pkgs/kernel/patch-3.13-git17.xz/5c23515f7...
OK, I see. Thanks for the reply.
http://www.youtube.com/embed/l-ceg763Voc?rel=0&border=0&autoplay=1
And sorry, what is this ?
Bugs Bunny! :) What's up, doc?
Ha, I see. THX.
poma
kernel@lists.fedoraproject.org
-
drago01 -
Josh Boyer -
Justin Forbes -
Kevin Fenzi -
Peter Robinson -
poma -
Tang Chen