kernel July 2013

kernel@lists.fedoraproject.org

29 participants
25 discussions

CONFIG_X86_INTEL_PSTATE on F18?
by Reindl Harald 05 Jul '13

05 Jul '13

is there a plan to enable "CONFIG_X86_INTEL_PSTATE" for F18 kernels or will only F19 get this feature which is a nice thing on Intel Sabdy Brdige/Ivy Bridge? [harry@srv-rhsoft:~]$ cat /boot/config-3.9.9-200.fc18.x86_64 | grep PSTATE # CONFIG_X86_INTEL_PSTATE is not set [root@rawhide ~]# cat /boot/config-3.10.0-1.fc20.x86_64 | grep PSTATE CONFIG_X86_INTEL_PSTATE=y

2 2

FYI: 3.9.9-200.fc18.x86_64 works fine
by Reindl Harald 04 Jul '13

04 Jul '13

besides that "3.9.9-100.fc17.x86_64" works fine at least as VMware guest i can confirm 3.9.9-200.fc18.x86_64 working on the hardware below as homeserver * iptables NAT (LAN/WAN/WLAN/Bridge) * openVPN gateway to company * two WLAN AP's * VMware Workstation NAT * services like httpd/dbmail/postfix/mariadb __________________________________________ [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.57 __________________________________________ [harry@srv-rhsoft:~]$ lspci 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: Atheros Communications Inc. AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01) 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection __________________________________________ [harry@srv-rhsoft:~]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz stepping : 9 microcode : 0x17 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6784.45 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:

1 0

Kernel testing on GA Releases.
by Jóhann B. Guðmundsson 03 Jul '13

03 Jul '13

I'm not sure if you guys are aware of this but a lot of reporters test and run development and more recent kernels then those that are available via the usual GA update mechanism and recent changes [1] which introduce hard dependency on dracut and systemd versions on kernel installs are preventing the ability for reporters to either a) enable fedora-rawhide-kernel-nodebug.repo or b) manually install specific kernel release from koji and test more recent kernels on already existing GA releases. If we now have hard dependency's on specific dracut/systemd versions we need to start looking into sync-ing kernel/dracut/systemd releases better in GA ( arguably the entire base/core stack but that's a topic for a later time) or back port the necessary bits that the kernel install requires into the kernel/systemd/dracut releases in GA. JBG [1]. --> Processing Dependency: dracut >= 027 for package: kernel-3.10.0-1.fc20.x86_64 --> Finished Dependency Resolution Error: Package: kernel-3.10.0-1.fc20.x86_64 (/kernel-3.10.0-1.fc20.x86_64) Requires: systemd >= 203-2 Installed: systemd-201-2.fc18.7.x86_64 (@updates-testing) systemd = 201-2.fc18.7 Available: systemd-195-15.fc18.x86_64 (fedora) systemd = 195-15.fc18 Error: Package: kernel-3.10.0-1.fc20.x86_64 (/kernel-3.10.0-1.fc20.x86_64) Requires: dracut >= 027 Installed: dracut-024-25.git20130205.fc18.x86_64 (@updates) dracut = 024-25.git20130205.fc18 Available: dracut-024-18.git20130102.fc18.x86_64 (fedora) dracut = 024-18.git20130102.fc18 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

5 6

dkms + kmp
by Jóhann B. Guðmundsson 03 Jul '13

03 Jul '13

Now after FESCO granted resurrection and enable by default of DKMS I've been researching and scratching my head bit over this one what 5 years ago LF created working group with representatives from Novell, RH, Canonical,Dell and IBM which comes up with kmp The outcome of this is amongst other things... * kmp rpm macros [1] * Jockey [2] * driver db spec being created [1] Suse rejects dkms inclusion in the distribution [4] Comment from S.O in that suse request "The linux foundation has dedicated a workgroup <http://www.linuxfoundation.org/en/Driver_Backport> to this topic. In this workgroup we have active Novell, RH, canonical and dell and IBM. We have agreed to focus our energies for the distributions to precompiled modules, as that is the only means to assert predictable behaviour in case of kernel updates. Without that, a recompile may (and sometimes will) fail. depending on the module this will leave the system in a non-bootable state. For that reason we've identified dkms as a a great tool help with the backport and developer build of backported modules, or modules that are on their way into mainline, still, but we've also concluded that source distribution to end users does more harm than good to Linux distribution users as a failing kernel update is hard to recover from. The workgroup has agreed to develop a simple standard format to feed driver tarballs and backport patches into dkms, and that can indeed be used to automate the build, but we believe it should be used in something like the build service, not on the end user system, to avoid unexpected, hard to recover from failures after kernel updates." "we believe it should be used in something like the build service, not on the end user system, to avoid unexpected, hard to recover from failures after kernel updates." This indicates that we should not be shipping dkms et all so does anyone know anything about the current status on this in the working group? What our ( project ) status is in this? What the way forward is supposed to be? JBG 1. http://www.linuxfoundation.org/collaborate/workgroups/driver-backport/kmp_m… 2. https://launchpad.net/jockey 3. http://www.linuxfoundation.org/collaborate/workgroups/driver-backport/onlin… 4. https://features.opensuse.org/305148

2 3

Re: Kernel testing on GA Releases.
by Jóhann B. Guðmundsson 02 Jul '13

02 Jul '13

On 07/02/2013 12:29 PM, Josh Boyer wrote: > On Tue, Jul 02, 2013 at 10:07:06AM +0000, "Jóhann B. Guðmundsson" wrote: >> I'm not sure if you guys are aware of this but a lot of reporters >> test and run development and more recent kernels then those that are >> available via the usual GA update mechanism and recent changes [1] >> which introduce hard dependency on dracut and systemd versions on >> kernel installs are preventing the ability for reporters to either >> a) enable fedora-rawhide-kernel-nodebug.repo or b) manually install > Can you elaborate on "reporters"? As in media reporters? If so, I'm > pretty sure we don't want them running rawhide nodebug kernels on older > releases. > We in QA community usually call the individuals that test and file bug reports "reporters" but since you guys are trying to handle your own QA coverage you might call them something else and based on your response you seem to be not interesting in have people test kernel on GA release ahead of time or are planning to handle that differently in your own process otherwise this being broken would have mattered the kernel community. JBG

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel July 2013