kernel December 2013

kernel@lists.fedoraproject.org

18 participants
17 discussions

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

04 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

Supporting Allwinner ARM SoCs in Fedora 21+ kernels
by Hans de Goede 03 Feb '14

03 Feb '14

Hi All, As you probably know in my spare time I'm working on Linux Allwinner SoC support. We (the linux-sunxi community) are currently making good progress on getting Allwinner SoCs supported in the upstream kernel. It looks like the majority of it will land in 3.14 and 3.15. As such I believe the time has come to start supporting Allwinner SoCs with the official Fedora kernels ootb for F-21. I've written a Feature page for this, which you can find here: https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport This will likely require carrying some kernel patches for 1-2 kernel releases, until all the necessary bits for headless operation have landed upstream. As always I'm willing to put my time were my work is, and I'll maintain these patches for as long as necessary. To give you an idea of where things are going, here is a break down of the tree I'm currently using for testing and development, see: https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel This branch contains 3.13-rc5 + the following, which should all go upstream for 3.14: https://github.com/mripard/linux/commits/sunxi-clk-for-3.13 https://github.com/mripard/linux/commits/sunxi-drivers-for-3.14 https://github.com/mripard/linux/commits/sunxi-core-for-3.14 https://github.com/mripard/linux/commits/sunxi-dt-for-3.14 sunxi-bits of: https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/… Emilio's "[PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support" series + the following which is not quite ready for 3.14 yet, but people are working hard to get it ready so hopefully we will see some of it in 3.14, and the rest should make 3.15: Emilio's sunxi-clk branch: patches not part of the above set David's and mine sunxi-mmc work Chen's gmac work Oliver's ahci work Arokux' ehci work mripard's "ARM: sunxi: Add A31 High Speed Timer Support" series wens' "v2 of A20 external output clock support patch series" hansg's resistive touchscreen controller driver (rtp) including temp sensor support Of the above list, we should at a minimum carry the mmc, gmac (gigabit nic) and ahci patches if those don't get upstream in time. USB support would also be very nice, but is not a must have. The last 3 patch-sets we don't need. Regards, Hans

2 6

mmap_min_addr
by Eric Paris 06 Jan '14

06 Jan '14

I notice that on x86_64 we set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_LSM_MMAP_MIN_ADDR=65536 I think we should be defaulting the DAC based protection to 64k as well (or dropping the LSM value to 4k). I guess the Kconfig default is 4k but testing when we wrote this feature said ia64, ppc64 and x86 could safely be 64k arm and maybe others should only be 32k If it is safe to run with SELinux enforcing 64k it should be safe to run with root/non-root enforcing 64k...

2 1

Rawhide nodebug and 3.12 kernels heads up!
by Justin Forbes 23 Dec '13

23 Dec '13

Many of you have been using the Rawhide Nodebug repository to test the 3.12 stable kernels while we got Fedora 20 out the door. We really appreciate the feedback from those who have tested. This is a heads up that in one week (December 25th) the rawhide nodebug repository will return to tracking rawhide and the 3.13 development cycle. Both Fedora 19 and Fedora 20 have the most recent 3.12.5 kernel submitted for updates-testing. If you wish to remain on rawhide nodebug and test development kernels, we really appreciate it. If you wish to remain on a 3.12 kernel, now is the time to disable the rawhide-nodebug repository. To do so, simply flip the value for enabled from 1 to 0 in /etc/yum.repos.d/fedora-rawhide-kernel-nodebug.repo. Thanks, Justin

3 2

3.12.6-200.fc19.x86_64: stacktrace on HP Elite 8300
by Reindl Harald 23 Dec '13

23 Dec '13

Hi i recently installed the latest kernel-build from today not i could say anything doe not work but maybe it's worth to look at the dmesg-stacktrace at the bottom of my message, from my little understanding it looks soundcard-related, however, MPD is playing music fine -> no visible regressions as far as i can say WLAN, network, firewall, services are all fine too ________________________________________________________________________________________ [root@srv-rhsoft:~]$ smbios-sys-info Libsmbios version: 2.2.28 Product Name: HP Compaq Elite 8300 CMT Vendor: Hewlett-Packard BIOS Version: K01 v02.90 ________________________________________________________________________________________ 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) 00:1f.0 ISA bridge: Intel Corporation Q77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 Network controller: Qualcomm Atheros AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01) 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection ________________________________________________________________________________________ [ 3.837956] e1000e 0000:00:19.0 eth0: registered PHC clock [ 3.838025] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 24:be:05:1a:c0:27 [ 3.838133] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection [ 3.838231] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 0100FF-0FF [ 3.838309] ------------[ cut here ]------------ [ 3.838382] WARNING: CPU: 1 PID: 423 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0() [ 3.838425] snd_hda_intel 0000:00:1b.0: irq 43 for MSI/MSI-X [ 3.838491] list_del corruption. prev->next should be ffff8804060e2ba0, but was ffffffff81c98690 [ 3.838600] Modules linked in: coretemp snd_hda_intel(+) ath snd_hda_codec i2c_algo_bit snd_hwdep crct10dif_pclmul mac80211 drm_kms_helper crc32_pclmul snd_seq drm cfg80211 usb_storage e1000e(+) crc32c_intel hp_wmi snd_seq_device iTCO_wdt iTCO_vendor_support i2c_i801 ghash_clmulni_intel sparse_keymap snd_pcm rfkill snd_page_alloc snd_timer microcode i2c_core ptp snd lpc_ich pps_core wmi serio_raw video mfd_core shpchp soundcore raid1 raid10 [ 3.839691] CPU: 1 PID: 423 Comm: systemd-udevd Not tainted 3.12.6-200.fc19.x86_64 #1 [ 3.839758] Hardware name: Hewlett-Packard HP Compaq Elite 8300 CMT/3396, BIOS K01 v02.90 07/16/2013 [ 3.839868] 0000000000000009 ffff8804068eda98 ffffffff81662651 ffff8804068edae0 [ 3.840004] ffff8804068edad0 ffffffff810691dd ffff8804060e2ba0 ffff8804060e2bb8 [ 3.840187] ffff8804060e2bb8 0000000000000000 ffffffffa01a8c00 ffff8804068edb30 [ 3.840323] Call Trace: [ 3.840387] [<ffffffff81662651>] dump_stack+0x45/0x56 [ 3.840453] [<ffffffff810691dd>] warn_slowpath_common+0x7d/0xa0 [ 3.840519] [<ffffffff8106924c>] warn_slowpath_fmt+0x4c/0x50 [ 3.840584] [<ffffffff8131aaa1>] __list_del_entry+0xa1/0xd0 [ 3.840648] [<ffffffff8131aadd>] list_del+0xd/0x30 [ 3.840713] [<ffffffff8132ee8c>] pinctrl_free+0xbc/0xe0 [ 3.840777] [<ffffffff8132f940>] ? pinctrl_put+0x30/0x30 [ 3.840842] [<ffffffff8132eec7>] pinctrl_release+0x17/0x20 [ 3.840906] [<ffffffff8132f969>] devm_pinctrl_release+0x29/0x30 [ 3.840972] [<ffffffff814029ca>] devres_release+0x2a/0x50 [ 3.841037] [<ffffffff8132f6d3>] devm_pinctrl_put+0x23/0x40 [ 3.841150] [<ffffffff81417e5e>] pinctrl_bind_pins+0xae/0x220 [ 3.841237] [<ffffffff813ff4ca>] driver_probe_device+0x6a/0x3a0 [ 3.841325] [<ffffffff813ff8d3>] __driver_attach+0x93/0xa0 [ 3.841396] [<ffffffff813ff840>] ? __device_attach+0x40/0x40 [ 3.841463] [<ffffffff813fd3a3>] bus_for_each_dev+0x63/0xa0 [ 3.841528] [<ffffffff813fef3e>] driver_attach+0x1e/0x20 [ 3.841593] [<ffffffff813feab0>] bus_add_driver+0x200/0x2d0 [ 3.841658] [<ffffffffa01b4000>] ? 0xffffffffa01b3fff [ 3.841722] [<ffffffff813fff14>] driver_register+0x64/0xf0 [ 3.841786] [<ffffffffa01b4000>] ? 0xffffffffa01b3fff [ 3.841851] [<ffffffff8133a74c>] __pci_register_driver+0x4c/0x50 [ 3.841921] [<ffffffffa01b4041>] e1000_init_module+0x41/0x1000 [e1000e] [ 3.841988] [<ffffffff810020f2>] do_one_initcall+0xf2/0x1a0 [ 3.842069] [<ffffffff81054533>] ? set_memory_nx+0x43/0x50 [ 3.842176] [<ffffffff810d687d>] load_module+0x1b9d/0x2640 [ 3.842248] [<ffffffff810d2a30>] ? store_uevent+0x40/0x40 [ 3.842341] [<ffffffff810d7496>] SyS_finit_module+0x86/0xb0 [ 3.842417] [<ffffffff816716a9>] system_call_fastpath+0x16/0x1b [ 3.842492] ---[ end trace 27592ade283d040b ]--- [ 3.842571] pcieport 0000:00:1c.4: driver skip pci_set_master, fix it!

1 0

static dtb location
by Dennis Gilmore 18 Dec '13

18 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Back in August I started a thread[1] on the cross-distro list at linaro on standardising the location of dtb files. While tehre was not a lot fo input there was a consensus to use /boot/dtb/ as the location. since the dtb generation is still tied to kernel building. I would like to have us have the most recently installed kernel link its dtb directory to /boot/dtb/ I am working on a change for Fedora 21 to get u-boot that we provide loading the dtb automatically and there is no way that ive worked out to have u-boot work out the path as they exist today. I realise its not perfect and may cause issues if you try to boot an older kernel. I would like some feedback on how best to implement it so I can go off and write some patches for review. Thanks in advance Dennis [1] http://lists.linaro.org/pipermail/cross-distro/2013-August/000463.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSsi8MAAoJEH7ltONmPFDR66gP/j9K3yCZ+8OLJB/6ymhQkGzq fgSsmJPawEI+yVaqm0yqcn3+4lSsYG1H5HLxkuAR7/v3li3ap5GrE8WIM4MGI5A9 Pjr4QF4ycnqbVqSPPFs7O3AzI11+Ys21UmfSAqfJtaGp5nXk4wGndb1D1H5qcQCV sPLefgGoEpaf5juHwy/nNWdMml0q2VNUESPs0p5chgw4sFpzQKWdVwAhiP8+v8cY 03dqTsZsLNCwJweo4W+j+5IhQNiJciP7arxJC9IGireArCrlO29/d7Zcq1+NwLrG Zb1j91tGoEstr5/EW0OWUw9zZQ5JM2f8dDnz4VplAT8N7iMBPE4XbtALbBINDTLw FkEa1DfBCQnPahGs9JMFMqvte1GyN2XU+eX6wRGiO/rbCAp7ahhOPema7pTkppu0 MjzX8+ZWZVkcjJ8GtHRBbaz10/6hbsJaSO7Ai6C/Om4P4XUl6GOZQ4nLOqAbNGGs KIkj8SA4Oa+sNSKJfEvHBUXpim2Tanv3HpeQzqup2XF0PkIVTNn/9wrGNg7FUfyW F7OPAreg0Pk76x19QWmV036kS45QUSADRv06zCJfSCxw3S1cr4TYnYRcegwwMvyA 1WMw9DpEvLNyg6cuezNfeP50IMeVWD/SL3tjxG8qG88ogfISBuYtrwECovZERKrZ /gAevyTWsHNeSmUI0Tao =ke// -----END PGP SIGNATURE-----

3 3

NUMA, migrate/N, and tuned-adm
by David Timothy Strauss 16 Dec '13

16 Dec '13

We're running Fedora 19 with the 3.11.10-200.fc19.x86_64 kernel (just the normal RPM) on large servers (128GB RAM over two NUMA regions, each with one hex-core processor) with a large number of processes (more than 700, a couple hundred of which are active fairly frequently). We encounter situations where there system gets overwhelmed with migrate/N tasks from the kernel, based on what we've seen in top. Here's what we've tried: * tuned-adm on latency-performance and virtual-host profiles * kernel.sched_migration_cost_ns=5000000 (which tuned will do for those profiles in v3.3/Fedora 20) * numad Here's what we've used for analysis: * powertop * top/htop * perf record -a -g * SystemTap with code to print out migrations occurring * numatop All we know is that the migration storms correlate with concurrent Chef runs verifying/configuring containers on the system. Obviously, Chef invokes many things. But, most of the migrations we see are for Chef, the Ruby interpreter, the sh interpreter, and Munin. Responsiveness returns to normal after SystemTap reports a large set of chef-solo migrations, presumably at their completion. David Strauss Pantheon Systems Fedora Server Working Group

1 1

Fedora Kernel Meeting Minutes for 2013-12-13
by Josh Boyer 13 Dec '13

13 Dec '13

============================== #fedora-meeting: Fedora Kernel ============================== Meeting started by jwb at 19:01:13 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-12-13/fedora_kernel.20… . Meeting summary --------------- * init (jwb, 19:01:37) * release overview (jwb, 19:03:29) * F18-F20 all on 3.11.10(ish) Rawhide on 3.13-rc3(ish) (jwb, 19:07:24) * 3.12 rebase (jwb, 19:08:10) * F18 will not get a 3.12 rebase. critical security fixes only until EOL (jwb, 19:16:12) * F19-F20 will get 3.12 rebase in updates-testing very soon (jwb, 19:16:27) * rawhide-nodebug will go back to tracking rawhide (jwb, 19:17:36) * ACTION: jforbes to give 1 week warning for nodebug when 3.12 hits updates-testing (jwb, 19:17:53) * Removal of kernel-doc (jwb, 19:19:19) * LINK: http://kojipkgs.fedoraproject.org//packages/kernel/3.13.0/0.rc3.git4.1.fc21… (jwb, 19:21:37) * kernel-doc subpackage brings in asciidoc and xmlto, which bloat the BuildRequires for the kernel significantly (jwb, 19:24:34) * ACTION: jwb to drop kernel-doc subpackage (jwb, 19:24:44) * Open Floor (jwb, 19:27:22) * Trinity (jwb, 19:28:41) * MMAP rework in trinity is surfacing a number of new bugs. Hopefully this helps clear up some weird MM bugs we've seen in the past (jwb, 19:31:53) * probably upstream trinity release next week (jwb, 19:37:15) * Open Floor (jwb, 19:37:56) Meeting ended at 19:46:07 UTC. Action Items ------------ * jforbes to give 1 week warning for nodebug when 3.12 hits updates-testing * jwb to drop kernel-doc subpackage Action Items, by person ----------------------- * jforbes * jforbes to give 1 week warning for nodebug when 3.12 hits updates-testing * jwb * jwb to drop kernel-doc subpackage * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jwb (95) * davej (30) * jforbes (28) * nirik (19) * zodbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Agenda for today's Kernel meeting
by Josh Boyer 13 Dec '13

13 Dec '13

Here's a brief agenda for today's meeting. If you have something you'd like to add, please reply and we'll throw it on. 1) Release overview 2) 3.12 rebase for F20-F18 3) Removal of kernel-doc 4) Open Floor

1 0

[PATCH 0/2] MODSIGN: Support MOKx
by Lee, Chun-Yi 13 Dec '13

13 Dec '13

It's base on the kernel patches of Fedora 20. This patch set add the support to MODSIGN mechanism for revoke kernel module by hash or public key. As MokListRT, EFI bootloader(e.g. shim) should maintain the MokListXRT container the format the same with dbx. The patches will check the hash of kernel module before load it. Lee, Chun-Yi (2): MODSIGN: check hash of kernel module in blacklist MODSIGN: load hash blacklist of modules from MOKx include/linux/efi.h | 12 ++++ kernel/modsign_uefi.c | 150 +++++++++++++++++++++++++++++++++++++++++++++- kernel/module-internal.h | 14 ++++ kernel/module.c | 9 +++- kernel/module_signing.c | 79 ++++++++++++++++++++++++ 5 files changed, 261 insertions(+), 3 deletions(-)

4 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel December 2013