kernel February 2016

kernel@lists.fedoraproject.org

8 participants
8 discussions

[PATCH] Enable VIDEO_GO7007 as module
by Nicolas Chauvet 03 Mar '16

03 Mar '16

This driver can be used in some usb encoder devices. http://www.linuxtv.org/wiki/index.php/Go7007 The related firmware files are in linux-firmware for some time. The driver has left staging since few release, but I'm fine if this is enabled in linux kernel 4.5 and later. --- config-generic | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/config-generic b/config-generic index 9eef876..1cfcfab 100644 --- a/config-generic +++ b/config-generic @@ -3410,6 +3410,10 @@ CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m CONFIG_VIDEO_CX231XX_RC=y +CONFIG_VIDEO_GO7007=m +CONFIG_VIDEO_GO7007_USB=m +CONFIG_VIDEO_GO7007_LOADER=m +CONFIG_VIDEO_GO7007_USB_S2250_BOARD=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_IVTV=m @@ -3422,6 +3426,7 @@ CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m +CONFIG_VIDEO_SAA7134_GO7007=m CONFIG_VIDEO_SAA7134_RC=y CONFIG_VIDEO_SOLO6X10=m CONFIG_VIDEO_USBVISION=m @@ -5560,7 +5565,6 @@ CONFIG_STAGING_MEDIA=y # CONFIG_VIDEO_DT3155 is not set # CONFIG_TI_ST is not set # CONFIG_FB_XGI is not set -# CONFIG_VIDEO_GO7007 is not set # CONFIG_I2C_BCM2048 is not set # CONFIG_DT3155 is not set # CONFIG_PRISM2_USB is not set -- 1.7.2.1

2 1

Re: our chat in #fedora-kernel
by Josh Boyer 29 Feb '16

29 Feb '16

On Sun, Feb 28, 2016 at 12:24 PM, Corey Sheldon <sheldon.corey(a)gmail.com> wrote: > Josh, > Adding the Fedora kernel list on CC. > Been updating my blog with news of the respins Southern_Gentlemen > (fas: jbwillia) makes when new kernels make it to updates, like > 4.4.2-301 did last night. > > > Both for personal knowledge and per requests for a more 'snapshot'-ish > changelog I am looking to get a effective .diff changelog since the > last kernel. "The last kernel" is kind of the weird part here. For Fedora, that can mean anything between simply another build of the existing major version with a minor fix included, to a whole kernel version rebase. We'll try and cover all the cases, but as usual the answer is never the same or any particular kernel. > As I understand the work flow being: > > old kernel foo has features / fixes /etc > > > > new kernel bar > > since last re-spin with kernel foo this re-spin has updates from > %date and the following fixes / patches which I presume would have ofc > those in rpm -qp --changelog %bar.src.rpm. Correct. > However is there a place I could link to or parse for a more thorough > %changelog ? without having to parse the entire creation spec file and / > or hoping it has build version marked in the spec file? The spec file doesn't have what you're looking for. The changelog in the spec file is the only place we log any kind of description and it's kept intentionally terse. Now, if you can determine the old and new versions then there are a few things you can do. I'll give some examples. For things like kernel-4.3.6 -> 4.4.2, that would be a major version rebase. As Laura said in the channel yesterday, the kernelnewbies.org site usually has a decent writeup of features and major fixes for each major kernel version. You can find the latest at the site Laura linked to, or all their writeups at http://kernelnewbies.org/LinuxVersions. For things like kernel-4.4.2-300 -> 4.4.2-301, the changelog is going to have a list of the stuff that is specifically interesting to Fedora. That is simply a build of the existing upstream kernel, with some changes we've added. For a bump like 4.4.2 -> 4.4.3, there really isn't a good answer. That is an upstream stable kernel release. There are bugfixes all over the kernel tree, sometimes numbering in the hundreds of commits. There may be some bug numbers listed in the RPM changelog that an upstream stable release fixes, and we'll note that in the RPM changelog if so. For the most part though, this is simply "more fixes". I hope that helps. If you have any further questions, please let us know. josh

1 0

[PATCH] Fix boot on jetson-tk1 related to platform_nouveau
by Nicolas Chauvet 25 Feb '16

25 Feb '16

Patch is reported at http://marc.info/?l=linux-tegra&m=145633528825832&w=2 This will fix boot on kernel 4.3+ as experienced with fedora kernel 4.3.5 Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c29f7cc0 [00000000] *pgd=00000000 Internal error: Oops: 205 [#1] SMP ARM Modules linked in: gpio_keys(+) phy_tegra_usb(+) ahci_tegra libahci_platform nouveau(+) rtc_tegra i2c_algo_bit i2c_tegra tegra_drm ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm host1x mmc_block sdhci_tegra sdhci_pltfm sdhci mmc_core CPU: 2 PID: 318 Comm: systemd-udevd Not tainted 4.4.2-300.fc23.armv7hl+lpae #1 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) task: edc67500 ti: c28ae000 task.ti: c28ae000 PC is at __list_del_entry+0x40/0x94 LR is at list_del+0xc/0x1c pc : [<c035b498>] lr : [<c035b4f8>] psr: 80010013 sp : c28afd08 ip : 00000020 fp : c28aff58 r10: c242d488 r9 : 0000001b r8 : c0b4d528 r7 : c28afd6c r6 : ffffffff r5 : c28afd6c r4 : c288b02c r3 : c288b02c r2 : 00000000 r1 : 00000000 r0 : c288b02c Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5387d Table: 829f7cc0 DAC: 55555555 Process systemd-udevd (pid: 318, stack limit = 0xc28ae220) --- drm-nouveau-platform-fix_deferred_probe.patch | 114 +++++++++++++++++++++++++ kernel.spec | 3 + 2 files changed, 117 insertions(+), 0 deletions(-) create mode 100644 drm-nouveau-platform-fix_deferred_probe.patch diff --git a/drm-nouveau-platform-fix_deferred_probe.patch b/drm-nouveau-platform-fix_deferred_probe.patch new file mode 100644 index 0000000..36aeb91 --- /dev/null +++ b/drm-nouveau-platform-fix_deferred_probe.patch @@ -0,0 +1,114 @@ +From: Thierry Reding <thierry.reding(a)gmail.com> +To: Ben Skeggs <bskeggs(a)redhat.com> +Cc: Alexandre Courbot <gnurou(a)gmail.com>, + Nicolas Chauvet <kwizart(a)gmail.com>, + dri-devel(a)lists.freedesktop.org, + linux-tegra(a)vger.kernel.org +Subject: [PATCH] drm/nouveau: platform: Fix deferred probe +Date: Wed, 24 Feb 2016 18:34:43 +0100 +Message-Id: <1456335283-22097-1-git-send-email-thierry.reding(a)gmail.com> +X-Mailer: git-send-email 2.7.1 + +From: Thierry Reding <treding(a)nvidia.com> + +The error cleanup paths aren't quite correct and will crash upon +deferred probe. + +Cc: stable(a)vger.kernel.org # v4.3+ +Signed-off-by: Thierry Reding <treding(a)nvidia.com> +--- + drivers/gpu/drm/nouveau/nouveau_platform.c | 2 +- + drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 40 ++++++++++++++++------ + 2 files changed, 30 insertions(+), 12 deletions(-) + +diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c b/drivers/gpu/drm/nouveau/nouveau_platform.c +index 8a70cec59bcd..2dfe58af12e4 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_platform.c ++++ b/drivers/gpu/drm/nouveau/nouveau_platform.c +@@ -24,7 +24,7 @@ + static int nouveau_platform_probe(struct platform_device *pdev) + { + const struct nvkm_device_tegra_func *func; +- struct nvkm_device *device; ++ struct nvkm_device *device = NULL; + struct drm_device *drm; + int ret; + +diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +index 7f8a42721eb2..e7e581d6a8ff 100644 +--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +@@ -252,32 +252,40 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func, + + if (!(tdev = kzalloc(sizeof(*tdev), GFP_KERNEL))) + return -ENOMEM; +- *pdevice = &tdev->device; ++ + tdev->func = func; + tdev->pdev = pdev; + tdev->irq = -1; + + tdev->vdd = devm_regulator_get(&pdev->dev, "vdd"); +- if (IS_ERR(tdev->vdd)) +- return PTR_ERR(tdev->vdd); ++ if (IS_ERR(tdev->vdd)) { ++ ret = PTR_ERR(tdev->vdd); ++ goto free; ++ } + + tdev->rst = devm_reset_control_get(&pdev->dev, "gpu"); +- if (IS_ERR(tdev->rst)) +- return PTR_ERR(tdev->rst); ++ if (IS_ERR(tdev->rst)) { ++ ret = PTR_ERR(tdev->rst); ++ goto free; ++ } + + tdev->clk = devm_clk_get(&pdev->dev, "gpu"); +- if (IS_ERR(tdev->clk)) +- return PTR_ERR(tdev->clk); ++ if (IS_ERR(tdev->clk)) { ++ ret = PTR_ERR(tdev->clk); ++ goto free; ++ } + + tdev->clk_pwr = devm_clk_get(&pdev->dev, "pwr"); +- if (IS_ERR(tdev->clk_pwr)) +- return PTR_ERR(tdev->clk_pwr); ++ if (IS_ERR(tdev->clk_pwr)) { ++ ret = PTR_ERR(tdev->clk_pwr); ++ goto free; ++ } + + nvkm_device_tegra_probe_iommu(tdev); + + ret = nvkm_device_tegra_power_up(tdev); + if (ret) +- return ret; ++ goto remove; + + tdev->gpu_speedo = tegra_sku_info.gpu_speedo_value; + ret = nvkm_device_ctor(&nvkm_device_tegra_func, NULL, &pdev->dev, +@@ -285,9 +293,19 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func, + cfg, dbg, detect, mmio, subdev_mask, + &tdev->device); + if (ret) +- return ret; ++ goto powerdown; ++ ++ *pdevice = &tdev->device; + + return 0; ++ ++powerdown: ++ nvkm_device_tegra_power_down(tdev); ++remove: ++ nvkm_device_tegra_remove_iommu(tdev); ++free: ++ kfree(tdev); ++ return ret; + } + #else + int +-- +2.7.1 diff --git a/kernel.spec b/kernel.spec index a5a6997..edbb653 100644 --- a/kernel.spec +++ b/kernel.spec @@ -604,6 +604,9 @@ Patch646: HID-sony-do-not-bail-out-when-the-sixaxis-refuses-th.patch #rhbz 1288684 Patch647: 0001-vsock-Fix-blocking-ops-call-in-prepare_to_wait.patch +# Fix nouveau on arm for 4.3+ +Patch658: drm-nouveau-platform-fix_deferred_probe.patch + # END OF PATCH DEFINITIONS %endif -- 1.7.2.1

2 2

Re: 4.4 rebase coming to F23 soon
by Xose Vazquez Perez 25 Feb '16

25 Feb '16

JÃ³hann_B._GuÃ°mundsson wrote: > Arguably the regression in 4.4 with drm/i915 that causes screen > flickering in dual monitor setups needs to be looked at before this gets > released since it will get tiresome quite quickly for end users trying > to do some work when suddenly one of the screen turns itself off and > then on again. I don't see any related patch in Greg's stable-queue for 4.4: https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/q… PD: the performance of HyperKitty is really awful!

3 2

4.4 rebase coming to F23 soon
by Laura Abbott 25 Feb '16

25 Feb '16

Hi, 4.4.2 is currently building and should be in updates-testing soon. As usual, please test and give karma appropriately (negative karma for new issues, not existing issues). Thanks, Laura

4 5

conntrack: generic helper won't handle protocol 132. Please consider loading the specific helper module.
by Reindl Harald 23 Feb '16

23 Feb '16

i see such messages in dmesg repeatly on several machines most likely some form of attacks since it affects in random intervals any machine with a public IP and seems to be pretty new at all why is there no source IP logged? [501585.285984] conntrack: generic helper won't handle protocol 132. Please consider loading the specific helper module. sctp 132 SCTP # Stream Control Transmission Protocol

1 0

[PATCH] Add kernel-cross-headers subpackage
by Josh Boyer 11 Feb '16

11 Feb '16

The kernel-headers package it primarily used in Fedora to build the toolchain components. This works fine for native builds, but we do not have cross-architecture headers available. That means that the cross compiler toolchains we have can only be built without headers and therefore are only useful for building the kernel. Given that Fedora does not allow cross-compiling of it's packages, that hasn't been a problem to date. However, the toolchains might be used by application developers to build their own software. Providing the ability to build cross toolchains that offer glibc as well may benefit these users. This provides a kernel-cross-headers package that will at least allow this possibility. --- kernel.spec | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/kernel.spec b/kernel.spec index 5578b2c..5253426 100644 --- a/kernel.spec +++ b/kernel.spec @@ -90,6 +90,7 @@ Summary: The Linux kernel %define with_debug %{?_without_debug: 0} %{?!_without_debug: 1} # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} +%define with_cross_headers %{?_without_cross_headers: 0} %{?!_without_cross_headers: 1} # perf %define with_perf %{?_without_perf: 0} %{?!_without_perf: 1} # tools @@ -227,6 +228,7 @@ Summary: The Linux kernel %ifarch noarch %define with_up 0 %define with_headers 0 +%define with_cross_headers 0 %define with_tools 0 %define with_perf 0 %define all_arch_configs kernel-%{version}-*.config @@ -291,6 +293,7 @@ Summary: The Linux kernel # just like we used to only build them on i386 for x86 %ifnarch armv7hl %define with_headers 0 +%define with_cross_headers 0 %define with_perf 0 %define with_tools 0 %endif @@ -649,6 +652,17 @@ header files define structures and constants that are needed for building most standard programs and are also needed for rebuilding the glibc package. +%package cross-headers +Summary: Header files for the Linux kernel for use by cross-glibc +Group: Development/System +%description cross-headers +Kernel-cross-headers includes the C header files that specify the interface +between the Linux kernel and userspace libraries and programs. The +header files define structures and constants that are needed for +building most standard programs and are also needed for rebuilding the +cross-glibc package. + + %package bootwrapper Summary: Boot wrapper files for generating combined kernel + initrd images Group: Development/System @@ -1738,6 +1752,33 @@ find $RPM_BUILD_ROOT/usr/include \ %endif +%if %{with_cross_headers} +mkdir -p $RPM_BUILD_ROOT/usr/tmp-headers +make ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr/tmp-headers headers_install_all + +find $RPM_BUILD_ROOT/usr/tmp-headers/include \ + $ -name .install -o -name .check -o \ + -name ..install.cmd -o -name ..check.cmd $ | xargs rm -f + +# Copy all the architectures we care about to their respective asm directories +for arch in arm arm64 powerpc s390 x86 ; do +mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include +mv $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-${arch} $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/asm +cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-generic $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/. +done + +# Remove the rest of the architectures +rm -rf $RPM_BUILD_ROOT/usr/tmp-headers/include/arch* +rm -rf $RPM_BUILD_ROOT/usr/tmp-headers/include/asm-* + +# Copy the rest of the headers over +for arch in arm arm64 powerpc s390 x86 ; do +cp -a $RPM_BUILD_ROOT/usr/tmp-headers/include/* $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/. +done + +rm -rf $RPM_BUILD_ROOT/usr/tmp-headers +%endif + %if %{with_perf} # perf tool binary and supporting scripts/binaries %{perf_make} DESTDIR=$RPM_BUILD_ROOT lib=%{_lib} install-bin install-traceevent-plugins @@ -1924,6 +1965,12 @@ fi /usr/include/* %endif +%if %{with_cross_headers} +%files cross-headers +%defattr(-,root,root) +/usr/*-linux-gnu/include/* +%endif + %if %{with_bootwrapper} %files bootwrapper %defattr(-,root,root) -- 2.5.0

1 1

build regression from c153693: Simplify module TOC handling
by Peter Robinson 10 Feb '16

10 Feb '16

Hi Alan, Your patch for "powerpc: Simplify module TOC handling" is causing the Fedora ppc64le to fail to build with depmod failures. Reverting the commit fixes it for us on rawhide. We're getting the out put below, full logs at [1]. Let me know if you have any other queries. Regards, Peter [1] http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/5115/3125115/build.l… + depmod -b . -aeF ./System.map 4.5.0-0.rc2.git0.1.fc24.ppc64le Depmod failure + '[' -s depmod.out ']' + echo 'Depmod failure' + cat depmod.out depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/platforms/powernv/opal-prd.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/platforms/pseries/pseries_energy.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/platforms/pseries/hvcserver.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/kvm/kvm.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/kvm/kvm-pr.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/arch/powerpc/kvm/kvm-hv.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/kernel/rcu/rcutorture.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/kernel/trace/ring_buffer_benchmark.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/kernel/torture.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/fs/nfs_common/nfs_acl.ko needs unknown symbol .TOC. depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.5.0-0.rc2.git0.1.fc24.ppc64le/./lib/modules/4.5.0-0.rc2.git0.1.fc24.ppc64le/kernel/fs/nfs_common/grace.ko needs unknown symbol .TOC.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel February 2016