kernel January 2015

kernel@lists.fedoraproject.org

11 participants
18 discussions

Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede 29 Jul '15

29 Jul '15

Hi Josh, On 07/28/2014 07:04 PM, Josh Boyer wrote: > commit e6fe382d1d53d4cdf9b544729dc823d4eab0217c > Author: Josh Boyer <jwboyer(a)fedoraproject.org> > Date: Mon Jul 28 13:03:01 2014 -0400 > > Make sure acpi brightness_switch is disabled (like forever in Fedora) > > Upstream reverted the change to turn the ACPI brightness_switch_enabled > parameter off by default. Revert the revert so we go back to the state > Fedora has traditionally been in. Ack, I was planning on doing this myself but you beat me to it, thanks for taking care of this. Note that 3.17 will have this patch: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=… Which fixes the 2 steps being taken for one keypress problem while keeping the acpi brightness_switch behavior enabled, so that people who have an acpi-video controlled backlight and a userspace which does not do backlight control (e.g. windowmaker). So for 3.17 we should IMHO drop the revert-revert and stick with upstream behavior. Alternatively we could apply that patch now instead of the revert-revert. Regards, Hans

3 7

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 05 Jun '15

05 Jun '15

The other day I was running the stock fedora kernel on my ip forwarding setup, to see what the performance was, and the performance wasn't very good. system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad port 82580 adapters (12 ports). Traffic is bidirectional 64 byte packets being forwarded and received on each port, basically port to port routing. I am only using 12 flows currently. The driver is igb, and I am using an affinity script that lines up each pair of ports that are forwarding traffic into optimal configurations for cache locality. I am also disabling remote_node_defrag_ratio to stop cross node traffic. With the fedora default kernel from F14 it appears that CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if I stop iptables service. perf showed netfilter being prominent, and removing it gives me much higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a good thing to be able to disable netfilter if you want to? Jesse

5 9

Android Emulator not working with 3.18.3-201.fc21 and onwards
by Sudhir Khanger 07 Feb '15

07 Feb '15

Hello, Android Emulator has stopped working with kernel-3.18.3-201.fc21 and also kernel-3.18.4-201.fc21 from updates-testing. It is working fine on kernel-3.17.4-301.fc21.x86_64. Please see the logs. Not working - http://fpaste.org/179320/ Working - http://fpaste.org/179321/ -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.

2 2

Trouble cross compiling for powerpc
by Paul Bolle 02 Feb '15

02 Feb '15

I'm having trouble cross compiling on an up-to-date x64_64 F20 machine. make CROSS_COMPILE=powerpc64-linux-gnu- ARCH=powerpc drivers/dma/ppc4xx/adma.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh CC drivers/dma/ppc4xx/adma.o {standard input}: Assembler messages: {standard input}:4475: Error: junk at end of line: `1' {standard input}:4616: Error: junk at end of line: `1' {standard input}:4626: Error: junk at end of line: `1' {standard input}:4649: Error: junk at end of line: `1' make[1]: *** [drivers/dma/ppc4xx/adma.o] Error 1 make: *** [drivers/dma/ppc4xx/adma.o] Error 2 make CROSS_COMPILE=powerpc64-linux-gnu- ARCH=powerpc CFLAGS_adma.o="-S" drivers/dma/ppc4xx/adma.o CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh CC drivers/dma/ppc4xx/adma.o sed -n -e "4475p; 4616p; 4626p; 4649p" drivers/dma/ppc4xx/adma.o mfcr 10,1 mfcr 10,1 mfcr 10,1 mfcr 10,1 Anyone else seeing this? Is powerpc64-linux-gnu-gcc choking on the assembler it generates itself, or am I doing something wrong? Paul Bolle

3 6

Enable Baytrail devices in kernel builds
by Bastien Nocera 27 Jan '15

27 Jan '15

Hey, This driver, as discussed here: http://article.gmane.org/gmane.linux.kernel.input/35190 got merged last year. It's the driver for buttons integrated in Baytrail tablets, and should make power and volume buttons work on those devices. Furthermore, we should also enable the Baytrail SoC sound devices. There's a number of config items for this. You'll find both enablements in the ill-fated c72e049493b3f4f691a91722ae93f57a916d75b9 commit. Cheers

2 1

Uhhuh - Dazed and confused, but trying to continue :)
by poma 21 Jan '15

21 Jan '15

Salutem This happened only on thaw from S4 aka hibernate. What should be "strange power saving mode" these messages relate!? [ 208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0. [ 208.252991] Do you have a strange power saving mode enabled? [ 208.252992] Dazed and confused, but trying to continue 3.18.3-200.fc21.x86_64 poma

2 4

Enabling sun8i support in the Fedora kernels
by Hans de Goede 21 Jan '15

21 Jan '15

Hi, I noticed that sun8i support is not enabled in the rawhide arm kernels, sun8i / A23 is supported by upstream u-boot now, so it would be good to also enable it in the Fedora kernels, then Fedora should just work on A23 based devices. Regards, Hans

2 2

Re: Radeon driver with FC20 latest kernel update
by poma 20 Jan '15

20 Jan '15

On 20.01.2015 15:46, Andrew R Paterson wrote: > On Tuesday 20 January 2015 14:31:09 Andrew R Paterson wrote: >> On Tuesday 20 January 2015 15:10:15 poma wrote: >>> On 20.01.2015 14:44, Andrew R Paterson wrote: >>>> On Tuesday 20 January 2015 14:31:32 poma wrote: >>>>> On 20.01.2015 12:52, Andrew R Paterson wrote: >>>>>> Hi, >>>>>> I am running fedora 20 X86_64 >>>>>> >>>>>> I have an Intel Processor: >>>>>> Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz. >>>>>> >>>>>> I have an AMD radeon based GPU card : >>>>>> Advanced Micro Devices, Inc. [AMD/ATI] RV535 [Radeon X1650 PRO] >>>>>> (Secondary) >>>>>> (rev 9e) >>>>>> >>>>>> I have two monitors : >>>>>> ACER Technolgies – on DVI-0 (1920x1080) >>>>>> Viewsonic Corporation on DVI-1 (1920x1200) >>>>>> >>>>>> They are (were!) driven by the radeon module : >>>>>> >>>>>> lsmod :- >>>>>> ..... >>>>>> radeon 1496040 2 >>>>>> ..... >>>>>> i2c_algo_bit 13257 1 radeon >>>>>> ..... >>>>>> drm_kms_helper 89555 1 radeon >>>>>> ttm 80807 1 radeon >>>>>> ..... >>>>>> drm 296901 5 ttm,drm_kms_helper,radeon >>>>>> >>>>>> >>>>>> /var/log/messages shows: >>>>>> >>>>>> radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - >>>>>> 0x000000001FFFFFFF >>>>>> (512M used) >>>>>> radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF >>>>>> [drm] Detected VRAM RAM=512M, BAR=256M >>>>>> [drm] RAM width 128bits DDR >>>>>> >>>>>> X server log shows: >>>>>> >>>>>> [ 88.037] (II) Loader magic: 0x80dd00 >>>>>> [ 88.037] (II) Module ABI versions: >>>>>> [ 88.037] X.Org ANSI C Emulation: 0.4 >>>>>> [ 88.037] X.Org Video Driver: 14.1 >>>>>> [ 88.037] X.Org XInput driver : 19.2 >>>>>> [ 88.037] X.Org Server Extension : 7.0 >>>>>> [ 88.037] (II) xfree86: Adding drm device (/dev/dri/card0) >>>>>> [ 88.040] (--) PCI:*(0:1:0:0) 1002:71c1:174b:0840 rev 158, Mem @ >>>>>> 0xd0000000/268435456, 0xfdaf0000/65536, I/O @ 0x0000ae00/256, BIOS @ >>>>>> 0x????????/131072 >>>>>> [ 88.040] (--) PCI: (0:1:0:1) 1002:71e1:174b:0841 rev 158, Mem @ >>>>>> 0xfdae0000/65536, BIOS @ 0x????????/65536 >>>>>> .... >>>>>> .... >>>>>> [ 88.058] (II) modesetting: Driver for Modesetting Kernel Drivers: kms >>>>>> [ 88.058] (II) FBDEV: driver for framebuffer: fbdev >>>>>> [ 88.058] (II) VESA: driver for VESA chipsets: vesa >>>>>> [ 88.058] (++) using VT number 1 >>>>>> ..... >>>>>> ..... >>>>>> [ 88.059] (II) [KMS] Kernel modesetting enabled. >>>>>> [ 88.059] (WW) Falling back to old probe method for modesetting >>>>>> [ 88.059] (WW) Falling back to old probe method for fbdev >>>>>> [ 88.059] (II) Loading sub module "fbdevhw" >>>>>> [ 88.059] (II) LoadModule: "fbdevhw" >>>>>> [ 88.059] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so >>>>>> [ 88.060] (II) Module fbdevhw: vendor="X.Org Foundation" >>>>>> [ 88.060] compiled for 1.14.4, module version = 0.0.2 >>>>>> [ 88.060] ABI class: X.Org Video Driver, version 14.1 >>>>>> [ 88.060] (WW) Falling back to old probe method for vesa >>>>>> [ 88.060] (II) RADEON(0): Creating default Display subsection in >>>>>> Screen >>>>>> section >>>>>> "Default Screen Section" for depth/fbbpp 24/32 >>>>>> [ 88.060] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 >>>>>> [ 88.060] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 >>>>>> bpp >>>>>> pixmaps) >>>>>> [ 88.060] (==) RADEON(0): Default visual is TrueColor >>>>>> [ 88.060] (==) RADEON(0): RGB weight 888 >>>>>> [ 88.060] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) >>>>>> [ 88.060] (--) RADEON(0): Chipset: "ATI Radeon X1650" (ChipID = >>>>>> 0x71c1) >>>>>> ..... >>>>>> ________________________________________________ >>>>>> All worked well up to kernel 3.17.7-200.fc20.x86_64. >>>>>> ________________________________________________ >>>>>> >>>>>> The recent update to kernel 3.17.8-200.fc20.x86_64 >>>>>> results in radeon.ko failing to load. >>>>>> >>>>>> /var/log/messages shows: >>>>>> >>>>>> [drm:radeon_init] *ERROR* No UMS support in radeon module! >>>>>> >>>>>> %modrpobe radeon gives same message. >>>>>> >>>>>> My monitors are then in low res mirorred mode (ugh!) >>>>>> >>>>>> X server log shows: >>>>>> .... >>>>>> [ 13345.844] (II) Loader magic: 0x80dd00 >>>>>> [ 13345.844] (II) Module ABI versions: >>>>>> [ 13345.844] X.Org ANSI C Emulation: 0.4 >>>>>> [ 13345.844] X.Org Video Driver: 14.1 >>>>>> [ 13345.844] X.Org XInput driver : 19.2 >>>>>> [ 13345.844] X.Org Server Extension : 7.0 >>>>>> [ 13345.844] (II) xfree86: Adding drm device (/dev/dri/card0) >>>>>> [ 13345.844] setversion 1.4 failed >>>>>> [ 13345.848] (--) PCI:*(0:1:0:0) 1002:71c1:174b:0840 rev 158, Mem @ >>>>>> 0xd0000000/268435456, 0xfdaf0000/65536, I/O @ 0x0000ae00/256, BIOS @ >>>>>> 0x????????/131072 >>>>>> [ 13345.848] (--) PCI: (0:1:0:1) 1002:71e1:174b:0841 rev 158, Mem @ >>>>>> 0xfdae0000/65536, BIOS @ 0x????????/65536 >>>>>> ....... >>>>>> >>>>>> I understand UMS is User ModeSetting – which according to a quick >>>>>> browse >>>>>> of >>>>>> the source for the radeon module means CONFIG_DRM_RADEON_UMS is not >>>>>> set. >>>>>> Then I came across comments to the effect that this has been >>>>>> deprecated >>>>>> (a >>>>>> mysterious word akin to legal-speak!) presumably replaced by KMS. >>>>>> >>>>>> Has anybody got any clues how I can get the radeon driver loading and >>>>>> working again? >>>>>> Or even if its a bug whether it will soon be fixed? >>>>>> >>>>>> Many Thanks >>>>>> >>>>>> Andy >>>>> >>>>> $ grep modeset /etc/modprobe.d/* /proc/cmdline >>>> >>>> Hi poma, >>>> >>>> grep modeset /etc/modprobe.d/* = >>>> /etc/modprobe.d/radeon-kms.conf:options radeon modeset=0 >>>> >>>> grep modeset /proc/cmdline = >>>> nothing! >>>> >>>> Thanks >>> >>> # sed -i s/0/1/ /etc/modprobe.d/radeon-kms.conf >> >> Hi poma >> >> that did it thanks >> >> /etc/modprobe.d/radeon-kms.conf:options radeon modeset=1 >> >> I mind you I still get the initial: >> [drm:radeon_init] *ERROR* No UMS support in radeon module! >> And the plymouth splash screen goes from one mode to another and ain't what >> it used to be!) - but that doesn't matter. On loading, the kernel sorts >> things out. >> >> A assume if I now reboot into the previous kernel, that wont work - I'll >> just do it out of curiosity - but no probs - I'll now stick with >> 3.17.8-200.fc20.x86_64. >> See whether this can smooth plymouth # dracut -f --kver 3.17.8-300.fc21.x86_64 # reboot >> Thanks >> Andy > rebooted into previous kernel - no probs! > I assume thats because previous kernel supported both ums and kms???? > Regards > Andy > What is supported with certain version you can ask Alex Deucher at X.org ATI driver maintainers http://lists.x.org/mailman/listinfo/xorg-driver-ati Don't see any Fedora announcement related to it at https://admin.fedoraproject.org/updates/FEDORA-2015-0515/kernel-3.17.8-200.…

1 0

n_sectors mismatch - revalidation failed - resume S3
by poma 18 Jan '15

18 Jan '15

Salutem I saw a couple of open and closed reports as this is resolved, however here it is, only on resume from S3 aka suspend: [ 126.580725] ata1.00: n_sectors mismatch 1953525168 != 1953516911 [ 126.580732] ata1.00: old n_sectors matches native, probably late HPA lock, will try to unlock HPA [ 126.580737] ata1.00: revalidation failed (errno=-5) with 'libata.ignore_hpa=1' doesn't appear. 3.18.3-200.fc21.x86_64 poma Ref. https://www.kernel.org/doc/Documentation/kernel-parameters.txt libata.ignore_hpa= [LIBATA] Ignore HPA limit libata.ignore_hpa=0 keep BIOS limits (default) libata.ignore_hpa=1 ignore limits, using full disk

1 0

[PATCH] build fix 3.18.2-200.fc21(ppc, s390, aarch64)
by Jakub Cajka 15 Jan '15

15 Jan '15

Hello, in attachment is build fix(I'm not sure if kernel spec file formatting, patch numbering... is correct). Consists of upstream commit d47fb4ec7e101a63754939fa49d75fd7e81e94f8 "Build mic/mpssd only for x86_64", and replaced "MULTILIBDIR=..." with "lib=..." in spec file to reflect upstream change in /tools/perf/config/Makefile. I have made successful scratch build on s390 with these changes http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1696483. Failed builds: http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=288391 http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=256003 http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=296544 Could you please check this. Thanks Jakub Čajka

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2015