kernel January 2014

kernel@lists.fedoraproject.org

25 participants
31 discussions

Are f21 kernels expected to work on f20 systems with nouveau right now?
by Bruno Wolff III 15 Jan '14

15 Jan '14

Kernels after 3.13-rc7 are not booting on an F20 i686 machine with an NV28 with a traceback in the nouveau code. I am wondering if there is some nouveau related change that would make this expected or if I should file a bug on this?

3 7

[PATCH] Drop stable_rc macros
by Josh Boyer 15 Jan '14

15 Jan '14

We never use the stable_rc mechanism. It just adds clutter to the spec and in the rare case where we grab patches from a stable RC we've just applied them via ApplyPatch. Get rid of it. --- kernel.spec | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/kernel.spec b/kernel.spec index 87639cc..574ce19 100644 --- a/kernel.spec +++ b/kernel.spec @@ -47,16 +47,10 @@ Summary: The Linux kernel # Do we have a -stable update to apply? %define stable_update 0 -# Is it a -stable RC? -%define stable_rc 0 # Set rpm version accordingly %if 0%{?stable_update} %define stablerev %{stable_update} %define stable_base %{stable_update} -%if 0%{?stable_rc} -# stable RCs are incremental patches, so we need the previous stable patch -%define stable_base %(echo $((%{stable_update} - 1))) -%endif %endif %define rpmversion 3.%{base_sublevel}.%{stable_update} @@ -136,12 +130,7 @@ Summary: The Linux kernel # pkg_release is what we'll fill in for the rpm Release: field %if 0%{?released_kernel} -%if 0%{?stable_rc} -%define stable_rctag .rc%{stable_rc} -%define pkg_release 0%{stable_rctag}.%{fedora_build}%{?buildid}%{?dist} -%else %define pkg_release %{fedora_build}%{?buildid}%{?dist} -%endif %else @@ -512,10 +501,6 @@ Source2001: cpupower.config %define stable_patch_00 patch-3.%{base_sublevel}.%{stable_base}.xz Patch00: %{stable_patch_00} %endif -%if 0%{?stable_rc} -%define stable_patch_01 patch-3.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.xz -Patch01: %{stable_patch_01} -%endif # non-released_kernel case # These are automagically defined by the rcrev and gitrev values set up @@ -1143,9 +1128,6 @@ cd linux-%{KVERREL} %if 0%{?stable_base} ApplyPatch %{stable_patch_00} %endif -%if 0%{?stable_rc} -ApplyPatch %{stable_patch_01} -%endif # Drop some necessary files from the source dir into the buildroot cp $RPM_SOURCE_DIR/config-* . -- 1.8.4.2

3 4

Re: [PATCH] Drop buildid macros
by Josh Boyer 14 Jan '14

14 Jan '14

On Mon, Jan 13, 2014 at 6:00 PM, Jarod Wilson <jarod(a)redhat.com> wrote: > On Mon, Jan 13, 2014 at 05:43:45PM -0500, Josh Boyer wrote: >> On Mon, Jan 13, 2014 at 5:25 PM, Jarod Wilson <jarod(a)redhat.com> wrote: >> > On Mon, Jan 13, 2014 at 04:07:06PM -0500, Josh Boyer wrote: >> >> On Mon, Jan 13, 2014 at 3:53 PM, Paul Bolle <pebolle(a)tiscali.nl> wrote: >> >> > Josh Boyer schreef op ma 13-01-2014 om 15:41 [-0500]: >> >> >> As far as I know, nobody actually uses buildid to differentiate between >> >> >> kernel builds. >> >> > >> >> > Well, I do! >> >> >> >> OK, so it would be fairer to say "it is infrequently used". :) >> > >> > Its actually used on a very regular basis by some folks for one-off >> > builds. However, said folks are pretty much all internal to Red Hat, doing >> > RHEL builds. For example, I craft a test build via 'make rh-srpm >> > BUIDLID=".test_foo"', which subs in the BUILDID value for the buildid bit >> > in the spec file. We can of course just graft that back in when RHEL8 >> > branches from Fedora <20 + mumble> in the future. But I personally like >> > having the "edit this" part on its own line as its own thing regardless. >> > You can have a spec file patch or script that does it much more simply >> > than if you have to worry about other things that might be in the var >> > you want to tweak. >> >> OK, I guess I'll just drop this one. So much for low-hanging fruit. > > Note: the variant of the buildid stuff in the fedora spec looks far more > complicated than what is in the rhel7 spec. There are only 2 lines of spec > goo with buildid on them. I'd certainly endorse a patch that stripped out > all the extraneous crap. All I really need is: > > # % define buildid .local > > and > > %define pkg_release %{fedora_build}%{?buildid}%{?dist} Yeah, I'll look into that. >> As an aside, some of the other changes I'm playing with to split up >> the kernel packaging so the cloud people get a tiny kernel to install >> are much more invasive. In terms of RHEL<mumble> they'll be a much >> bigger impact. They will likely need to be adopted in RHEL land >> eventually and not reverted/replaced. I will, of course, post them >> first because I'd like review for a bunch of different reasons. I've >> already posted this on some of the other discussions, but the general >> premise is splitting it into kernel-core and kernel-drivers packages. > > Heh, history repeats itself, somewhat (kernel, kernel-unsupported). Just > kernel-core and kernel-drivers or perhaps kernel-core, > kernel-network-drivers, kernel-storage-drivers, etc? (and with a "kernel" > meta-package that requires all of them). Variations on the theme, but yes. I have kernel-core and kernel-drivers working for the ultimately simplistic cases with the kernel meta-package requiring both of them. Where it currently breaks is flavors, which winds up with e.g. kernel-debug-core, kernel-debug-drivers, but no kernel-debug meta-package. I just haven't gotten back to it yet. Once I get them working, the real "fun" is going to be getting the content of those packages settled. I'm sure kernel-core is going to have to be more than just the contents of /boot, which is all it is in my initial test runs right now (with -drivers being the /lib/module/ content). For that though, I'm waiting on the cloud people to tell me what they need other than "uh... small!" josh

1 1

kernel.spec: drop superfluous call of headers_check
by Paul Bolle 14 Jan '14

14 Jan '14

Josh, Here's a possible cleanup of kernel.spec. It also addresses one of my pet peeves: headers_check is run twice when building the kernel rpms. See, CONFIG_HEADERS_CHECK is already set to "y" in config-generic. But there are also a few lines in kernel.spec where headers_check is invoked again. And, as far as I can see grep -q exist hdrwarnings.txt will never match. Perhaps it made sense to grep for exist in the past, I don't know. Or was it intended to grep for an error message? But errors are not directed to hdrwarnings.txt. Entirely untested patch, by the way. Paul Bolle -------->8------- kernel.spec | 9 --------- 1 file changed, 9 deletions(-) diff --git a/kernel.spec b/kernel.spec index a83abb0..09967a0 100644 --- a/kernel.spec +++ b/kernel.spec @@ -1844,15 +1844,6 @@ cd linux-%{KVERREL} # Install kernel headers make ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr headers_install -# Do headers_check but don't die if it fails. -make ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr headers_check \ - > hdrwarnings.txt || : -if grep -q exist hdrwarnings.txt; then - sed s:^$RPM_BUILD_ROOT/usr/include/:: hdrwarnings.txt - # Temporarily cause a build failure if header inconsistencies. - # exit 1 -fi - find $RPM_BUILD_ROOT/usr/include \ $ -name .install -o -name .check -o \ -name ..install.cmd -o -name ..check.cmd $ | xargs rm -f -- 1.8.4.2

2 1

[PATCH] Drop upstream_branch related spec stuffs
by Josh Boyer 14 Jan '14

14 Jan '14

We haven't set using_upstream_branch to 1 since we started using git. Almost 7 years is a long time to carry something around we aren't using. Drop the upstream_branch stuff. --- kernel.spec | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/kernel.spec b/kernel.spec index a83abb0..fb65acb 100644 --- a/kernel.spec +++ b/kernel.spec @@ -208,16 +208,6 @@ Summary: The Linux kernel %if %{nopatches} %define with_bootwrapper 0 %define variant -vanilla -%else -%define variant_fedora -fedora -%endif - -%define using_upstream_branch 0 -%if 0%{?upstream_branch:1} -%define stable_update 0 -%define using_upstream_branch 1 -%define variant -%{upstream_branch}%{?variant_fedora} -%define pkg_release 0.%{fedora_build}%{upstream_branch_tag}%{?buildid}%{?dist} %endif %if !%{debugbuildsenabled} @@ -383,7 +373,7 @@ Summary: The Linux kernel # Should make listnewconfig fail if there's config options # printed out? -%if %{nopatches}%{using_upstream_branch} +%if %{nopatches} %define listnewconfig_fail 0 %else %define listnewconfig_fail 1 @@ -572,10 +562,6 @@ Patch00: patch-3.%{base_sublevel}-git%{gitrev}.xz %endif %endif -%if %{using_upstream_branch} -### BRANCH PATCH ### -%endif - # we also need compile fixes for -vanilla Patch04: compile-fixes.patch @@ -1021,14 +1007,12 @@ ApplyPatch() if [ ! -f $RPM_SOURCE_DIR/$patch ]; then exit 1 fi -%if !%{using_upstream_branch} if ! grep -E "^Patch[0-9]+: $patch\$" %{_specdir}/${RPM_PACKAGE_NAME%%%%%{?variant}}.spec ; then if [ "${patch:0:8}" != "patch-3." ] ; then echo "ERROR: Patch $patch not listed as a source patch in specfile" exit 1 fi fi 2>/dev/null -%endif case "$patch" in *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; @@ -1191,10 +1175,6 @@ ApplyPatch %{stable_patch_00} ApplyPatch %{stable_patch_01} %endif -%if %{using_upstream_branch} -### BRANCH APPLY ### -%endif - # Drop some necessary files from the source dir into the buildroot cp $RPM_SOURCE_DIR/config-* . cp %{SOURCE15} . -- 1.8.4.2

3 5

[net-wireless] rtl8187l issues
by Priscila Veiga 14 Jan '14

14 Jan '14

Hello kernel-list :) I have tried with AWUS036H (usb-wifi) that uses driver rtl8187 in F19 and F20 (kernel-3.11 until 3.12.6) but the card stops working (I still need to generate a dump, yeah) after 10 or 15 minutes (it hangs and disconnect). Using airodump-ng I notice no beacons are got, unless of my own bssid. I tested kali-linux (that is debian) and the card works pretty well. I compared the driver provided by RealTek ( http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=1&PFid… ) and Red Hat ( https://access.redhat.com/knowledge/sources/source_rpms/kernel-2.6.32-358.2… ) and there seems to be differences since the beginning. As far I was able to check the Fedora and RHEL drivers are the same. Debian seems use the one provided by RealTek but already compiled (of course). If you google you will notice this issue (no beacons) is reported since 2010. Someone already was able to make rtl8187l work in Fedora? How? Our driver is old? Is the same provided by RealTek or we would need a backport? Speaking about "backport" I tried use backports ( http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ ) but no luck too. I didn't investigated why once Fedora was not working before anyway. Any feedback, comments, words, are welcome. Thanks! Priscila Veiga priscila(a)redhat.com

3 3

Re: [PATCH] Drop buildid macros
by Josh Boyer 13 Jan '14

13 Jan '14

On Mon, Jan 13, 2014 at 5:25 PM, Jarod Wilson <jarod(a)redhat.com> wrote: > On Mon, Jan 13, 2014 at 04:07:06PM -0500, Josh Boyer wrote: >> On Mon, Jan 13, 2014 at 3:53 PM, Paul Bolle <pebolle(a)tiscali.nl> wrote: >> > Josh Boyer schreef op ma 13-01-2014 om 15:41 [-0500]: >> >> As far as I know, nobody actually uses buildid to differentiate between >> >> kernel builds. >> > >> > Well, I do! >> >> OK, so it would be fairer to say "it is infrequently used". :) > > Its actually used on a very regular basis by some folks for one-off > builds. However, said folks are pretty much all internal to Red Hat, doing > RHEL builds. For example, I craft a test build via 'make rh-srpm > BUIDLID=".test_foo"', which subs in the BUILDID value for the buildid bit > in the spec file. We can of course just graft that back in when RHEL8 > branches from Fedora <20 + mumble> in the future. But I personally like > having the "edit this" part on its own line as its own thing regardless. > You can have a spec file patch or script that does it much more simply > than if you have to worry about other things that might be in the var > you want to tweak. OK, I guess I'll just drop this one. So much for low-hanging fruit. As an aside, some of the other changes I'm playing with to split up the kernel packaging so the cloud people get a tiny kernel to install are much more invasive. In terms of RHEL<mumble> they'll be a much bigger impact. They will likely need to be adopted in RHEL land eventually and not reverted/replaced. I will, of course, post them first because I'd like review for a bunch of different reasons. I've already posted this on some of the other discussions, but the general premise is splitting it into kernel-core and kernel-drivers packages. josh

1 0

Backport request for Toshiba AC100 on ARM
by Nicolas Chauvet 13 Jan '14

13 Jan '14

Hello, I need few commits scheduled for 3.14 to be backported into 3.13 Fedora kernel. This is needed to fully support the Toshiba AC100 device on Fedora ARM. I haven't found the ref for some swarren commit, but they are marked as APPLIED, so they will probably hit linux-next soon. - Select the right RTC linux-next: 553c0a200e2082686fd9b829b77f7df6ebae14e9 - Simple-panel driver linux-next: 280921de7241ee63184c8baa89ec3fe0122dedb3 linux-next: 210fcd9d9cf1ad6ebfae3b46b457e602c8f8cdc2 http://nv-tegra.nvidia.com/gitweb/?p=user/swarren/linux-2.6.git;a=commitdif… http://nv-tegra.nvidia.com/gitweb/?p=user/swarren/linux-2.6.git;a=commitdif… Adds: DRM_PANEL boot and DRM_PANEL_SIMPLE tristate - Misc fix http://nv-tegra.nvidia.com/gitweb/?p=user/swarren/linux-2.6.git;a=commitdif… I plan to use a rawhidenodebug repo to compose a fedora 20 remix. Then hopefully everything should be in for fedora 21. Thx Nicolas (kwizart)

3 2

[PATCH] Enable SGI UV systems.
by Prarit Bhargava 10 Jan '14

10 Jan '14

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1051284 Set CONFIG_X86_UV to 'y' and CONFIG_UV_MMTIMER to 'm' for large SGI boxes. These settings will enable the booting of more than 16 processors. Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> Cc: glaubitz(a)physik.fu-berlin.de Cc: jwboyer(a)redhat.com --- config-x86_64-generic | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/config-x86_64-generic b/config-x86_64-generic index 15ad1cd..0bb4160 100644 --- a/config-x86_64-generic +++ b/config-x86_64-generic @@ -6,7 +6,8 @@ CONFIG_64BIT=y CONFIG_GENERIC_CPU=y # CONFIG_X86_VSMP is not set -# CONFIG_X86_UV is not set +CONFIG_X86_UV=y +CONFIG_UV_MMTIMER=m CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_AMD_NUMA=y -- 1.8.3.1

2 1

[PATCH] config-generic: disable aic94xx driver
by Paul Bolle 08 Jan '14

08 Jan '14

aic94xx is unmaintained upstream. It's not even possible to get a buildtime warning fixed. No-one seems to be using it. Disable this driver. Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- 0) Bravely untested. 1) aic94xx is "maintainerless": https://lkml.org/lkml/2012/10/29/215 2) Three attempts to get its buildtime warning fixed: - https://lkml.org/lkml/2013/2/20/478 - https://lkml.org/lkml/2012/9/25/265 (I've carried that patch locally ever since) - https://lkml.org/lkml/2012/1/30/445 3) There's exactly one report in bugzilla (for the Fedora product and the kernel component) where someone has actually loaded this driver. But the hard drive involved was actually broken: https://bugzilla.redhat.com/show_bug.cgi?id=848798 ! This suggests there are simply no Fedora users for this driver. config-generic | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/config-generic b/config-generic index 1bb85ed..67b0d28 100644 --- a/config-generic +++ b/config-generic @@ -437,8 +437,7 @@ CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set -CONFIG_SCSI_AIC94XX=m -# CONFIG_AIC94XX_DEBUG is not set +# CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_ADVANSYS is not set CONFIG_SCSI_BFA_FC=m CONFIG_MEGARAID_NEWGEN=y -- 1.8.4.2

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2014