CONFIG_X86_INTEL_PSTATE on F18?
by Reindl Harald
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
10 years, 9 months
FYI: 3.9.9-200.fc18.x86_64 works fine
by Reindl Harald
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:
10 years, 9 months
Kernel testing on GA Releases.
by Jóhann B. Guðmundsson
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
10 years, 9 months
dkms + kmp
by Jóhann B. Guðmundsson
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...
2. https://launchpad.net/jockey
3.
http://www.linuxfoundation.org/collaborate/workgroups/driver-backport/onl...
4. https://features.opensuse.org/305148
10 years, 9 months
Re: Kernel testing on GA Releases.
by Jóhann B. Guðmundsson
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
10 years, 9 months