kernel October 2011

kernel@lists.fedoraproject.org

16 participants
18 discussions

Rawhide kernel rebased to 3.2
by Josh Boyer 27 Oct '11

27 Oct '11

The rawhide kernel has been rebased to the initial wave of commits that will eventually become Linux 3.2. I haven't built the kernel in koji yet, but I will probably do so tomorrow or Monday, depending on how well a local build works when I test it. There was a large driver movement in the ethernet drivers that caused a bunch of config option changes. I think I got them all right and we should still have all of the ethernet drivers we had enabled before still being built. However, if you upgrade and notice a driver you were using is now missing please file a bug and let us know! Aside from the ethernet driver movement, there are of course a wide variety of changes and fixes coming in. The linux-next tree for 3.2 submission was the second largest ever, weighing in around 11,000 commits that need to get merged. This is mostly due to the kernel.org compromise causing the 3.1 release to drag on. Fortunately, Linus is being a bit of a stickler on what he will pull for 3.2 for a variety of reasons. Hopefully that helps us as we continue to bring in snapshots of the merge. Hang on, it might be a bit of a bumpy ride :). josh

1 0

kernel 3.1 on F15
by Genes MailLists 24 Oct '11

24 Oct '11

Question: Is there any problem with compiling the F16 3.1 kernel source (together with new grubby) on F15 - and installing them? What about kernel-tools - I note it adds cpupower things which don't seem to be on F15 - any issues here or could there be problems with cpuspeed stuff? perf is now in kernel-tools which I assume is fine. Thanks ... gene

2 3

[PATCH] Add patch to let watchdog and perf work on Pentium4s (rhbz 713675)
by Don Zickus 19 Oct '11

19 Oct '11

Not sure what the patch prefence is for the mailing list. This patch applies to the fedpkg kernel git tree. Better changelog below. Waiting on test feedback. Cheers, Don --- kernel.spec | 2 + x86-p4-make-watchdog-and-perf-work-together.patch | 267 +++++++++++++++++++++ 2 files changed, 269 insertions(+), 0 deletions(-) create mode 100644 x86-p4-make-watchdog-and-perf-work-together.patch diff --git a/kernel.spec b/kernel.spec index 176dbfc..f6eccf6 100644 --- a/kernel.spec +++ b/kernel.spec @@ -649,6 +649,7 @@ Patch12016: disable-i8042-check-on-apple-mac.patch Patch12023: ums-realtek-driver-uses-stack-memory-for-DMA.patch Patch12024: usb-add-quirk-for-logitech-webcams.patch Patch12025: crypto-register-cryptd-first.patch +Patch12026: x86-p4-make-watchdog-and-perf-work-together.patch # Runtime power management Patch12203: linux-2.6-usb-pci-autosuspend.patch @@ -1240,6 +1241,7 @@ ApplyPatch add-appleir-usb-driver.patch ApplyPatch ums-realtek-driver-uses-stack-memory-for-DMA.patch ApplyPatch usb-add-quirk-for-logitech-webcams.patch ApplyPatch crypto-register-cryptd-first.patch +ApplyPatch x86-p4-make-watchdog-and-perf-work-together.patch # rhbz#605888 ApplyPatch dmar-disable-when-ricoh-multifunction.patch diff --git a/x86-p4-make-watchdog-and-perf-work-together.patch b/x86-p4-make-watchdog-and-perf-work-together.patch new file mode 100644 index 0000000..9ef049b --- /dev/null +++ b/x86-p4-make-watchdog-and-perf-work-together.patch @@ -0,0 +1,267 @@ +BZ https://bugzilla.redhat.com/show_bug.cgi?id=713675 + +Let nmi watchdog and perf work together on a P4. Combination of the following 3.1 +upstream commits (the second commit reverts the first one). + +commit 1880c4ae182afb5650c5678949ecfe7ff66a724e +Author: Cyrill Gorcunov <gorcunov(a)gmail.com> +Date: Thu Jun 23 16:49:18 2011 +0400 + + perf, x86: Add hw_watchdog_set_attr() in a sake of nmi-watchdog on P4 + + Due to restriction and specifics of Netburst PMU we need a separated + event for NMI watchdog. In particular every Netburst event + consumes not just a counter and a config register, but also an + additional ESCR register. + + Since ESCR registers are grouped upon counters (i.e. if ESCR is occupied + for some event there is no room for another event to enter until its + released) we need to pick up the "least" used ESCR (or the most available + one) for nmi-watchdog purposes -- so MSR_P4_CRU_ESCR2/3 was chosen. + + With this patch nmi-watchdog and perf top should be able to run simultaneously. + + Signed-off-by: Cyrill Gorcunov <gorcunov(a)openvz.org> + CC: Lin Ming <ming.m.lin(a)intel.com> + CC: Arnaldo Carvalho de Melo <acme(a)redhat.com> + CC: Frederic Weisbecker <fweisbec(a)gmail.com> + Tested-and-reviewed-by: Don Zickus <dzickus(a)redhat.com> + Tested-and-reviewed-by: Stephane Eranian <eranian(a)google.com> + Signed-off-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl> + Link: http://lkml.kernel.org/r/20110623124918.GC13050@sun + Signed-off-by: Ingo Molnar <mingo(a)elte.hu> + +commit f91298709790b9a483752ca3c967845537df2af3 +Author: Cyrill Gorcunov <gorcunov(a)openvz.org> +Date: Sat Jul 9 00:17:12 2011 +0400 + + perf, x86: P4 PMU - Introduce event alias feature + + Instead of hw_nmi_watchdog_set_attr() weak function + and appropriate x86_pmu::hw_watchdog_set_attr() call + we introduce even alias mechanism which allow us + to drop this routines completely and isolate quirks + of Netburst architecture inside P4 PMU code only. + + The main idea remains the same though -- to allow + nmi-watchdog and perf top run simultaneously. + + Note the aliasing mechanism applies to generic + PERF_COUNT_HW_CPU_CYCLES event only because arbitrary + event (say passed as RAW initially) might have some + additional bits set inside ESCR register changing + the behaviour of event and we can't guarantee anymore + that alias event will give the same result. + + P.S. Thanks a huge to Don and Steven for for testing + and early review. + + Acked-by: Don Zickus <dzickus(a)redhat.com> + Tested-by: Steven Rostedt <rostedt(a)goodmis.org> + Signed-off-by: Cyrill Gorcunov <gorcunov(a)openvz.org> + CC: Ingo Molnar <mingo(a)elte.hu> + CC: Peter Zijlstra <a.p.zijlstra(a)chello.nl> + CC: Stephane Eranian <eranian(a)google.com> + CC: Lin Ming <ming.m.lin(a)intel.com> + CC: Arnaldo Carvalho de Melo <acme(a)redhat.com> + CC: Frederic Weisbecker <fweisbec(a)gmail.com> + Link: http://lkml.kernel.org/r/20110708201712.GS23657@sun + Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> + + +diff --git a/arch/x86/include/asm/perf_event_p4.h b/arch/x86/include/asm/perf_event_p4.h +index 56fd9e3..4d86c86 100644 +--- a/arch/x86/include/asm/perf_event_p4.h ++++ b/arch/x86/include/asm/perf_event_p4.h +@@ -102,6 +102,14 @@ + #define P4_CONFIG_HT (1ULL << P4_CONFIG_HT_SHIFT) + + /* ++ * If an event has alias it should be marked ++ * with a special bit. (Don't forget to check ++ * P4_PEBS_CONFIG_MASK and related bits on ++ * modification.) ++ */ ++#define P4_CONFIG_ALIASABLE (1 << 9) ++ ++/* + * The bits we allow to pass for RAW events + */ + #define P4_CONFIG_MASK_ESCR \ +@@ -123,6 +131,31 @@ + (p4_config_pack_escr(P4_CONFIG_MASK_ESCR)) | \ + (p4_config_pack_cccr(P4_CONFIG_MASK_CCCR)) + ++/* ++ * In case of event aliasing we need to preserve some ++ * caller bits otherwise the mapping won't be complete. ++ */ ++#define P4_CONFIG_EVENT_ALIAS_MASK \ ++ (p4_config_pack_escr(P4_CONFIG_MASK_ESCR) | \ ++ p4_config_pack_cccr(P4_CCCR_EDGE | \ ++ P4_CCCR_THRESHOLD_MASK | \ ++ P4_CCCR_COMPLEMENT | \ ++ P4_CCCR_COMPARE)) ++ ++#define P4_CONFIG_EVENT_ALIAS_IMMUTABLE_BITS \ ++ ((P4_CONFIG_HT) | \ ++ p4_config_pack_escr(P4_ESCR_T0_OS | \ ++ P4_ESCR_T0_USR | \ ++ P4_ESCR_T1_OS | \ ++ P4_ESCR_T1_USR) | \ ++ p4_config_pack_cccr(P4_CCCR_OVF | \ ++ P4_CCCR_CASCADE | \ ++ P4_CCCR_FORCE_OVF | \ ++ P4_CCCR_THREAD_ANY | \ ++ P4_CCCR_OVF_PMI_T0 | \ ++ P4_CCCR_OVF_PMI_T1 | \ ++ P4_CONFIG_ALIASABLE)) ++ + static inline bool p4_is_event_cascaded(u64 config) + { + u32 cccr = p4_config_unpack_cccr(config); +diff --git a/arch/x86/kernel/cpu/perf_event_p4.c b/arch/x86/kernel/cpu/perf_event_p4.c +index ead584f..0c4071a 100644 +--- a/arch/x86/kernel/cpu/perf_event_p4.c ++++ b/arch/x86/kernel/cpu/perf_event_p4.c +@@ -556,11 +556,92 @@ static __initconst const u64 p4_hw_cache_event_ids + }, + }; + ++/* ++ * Because of Netburst being quite restricted in now ++ * many same events can run simultaneously, we use ++ * event aliases, ie different events which have the ++ * same functionallity but use non-intersected resources ++ * (ESCR/CCCR/couter registers). This allow us to run ++ * two or more semi-same events together. It is done ++ * transparently to a user space. ++ * ++ * Never set any cusom internal bits such as P4_CONFIG_HT, ++ * P4_CONFIG_ALIASABLE or bits for P4_PEBS_METRIC, they are ++ * either up-to-dated automatically either not appliable ++ * at all. ++ * ++ * And be really carefull choosing aliases! ++ */ ++struct p4_event_alias { ++ u64 orig; ++ u64 alter; ++} p4_event_aliases[] = { ++ { ++ /* ++ * Non-halted cycles can be substituted with ++ * non-sleeping cycles (see Intel SDM Vol3b for ++ * details). ++ */ ++ .orig = ++ p4_config_pack_escr(P4_ESCR_EVENT(P4_EVENT_GLOBAL_POWER_EVENTS) | ++ P4_ESCR_EMASK_BIT(P4_EVENT_GLOBAL_POWER_EVENTS, RUNNING)), ++ .alter = ++ p4_config_pack_escr(P4_ESCR_EVENT(P4_EVENT_EXECUTION_EVENT) | ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, NBOGUS0)| ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, NBOGUS1)| ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, NBOGUS2)| ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, NBOGUS3)| ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, BOGUS0) | ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, BOGUS1) | ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, BOGUS2) | ++ P4_ESCR_EMASK_BIT(P4_EVENT_EXECUTION_EVENT, BOGUS3))| ++ p4_config_pack_cccr(P4_CCCR_THRESHOLD(15) | P4_CCCR_COMPLEMENT | ++ P4_CCCR_COMPARE), ++ }, ++}; ++ ++static u64 p4_get_alias_event(u64 config) ++{ ++ u64 config_match; ++ int i; ++ ++ /* ++ * Probably we're lucky and don't have to do ++ * matching over all config bits. ++ */ ++ if (!(config & P4_CONFIG_ALIASABLE)) ++ return 0; ++ ++ config_match = config & P4_CONFIG_EVENT_ALIAS_MASK; ++ ++ /* ++ * If an event was previously swapped to the alter config ++ * we should swap it back otherwise contnention on registers ++ * will return back. ++ */ ++ for (i = 0; i < ARRAY_SIZE(p4_event_aliases); i++) { ++ if (config_match == p4_event_aliases[i].orig) { ++ config_match = p4_event_aliases[i].alter; ++ break; ++ } else if (config_match == p4_event_aliases[i].alter) { ++ config_match = p4_event_aliases[i].orig; ++ break; ++ } ++ } ++ ++ if (i >= ARRAY_SIZE(p4_event_aliases)) ++ return 0; ++ ++ return config_match | ++ (config & P4_CONFIG_EVENT_ALIAS_IMMUTABLE_BITS); ++} ++ + static u64 p4_general_events[PERF_COUNT_HW_MAX] = { + /* non-halted CPU clocks */ + [PERF_COUNT_HW_CPU_CYCLES] = + p4_config_pack_escr(P4_ESCR_EVENT(P4_EVENT_GLOBAL_POWER_EVENTS) | +- P4_ESCR_EMASK_BIT(P4_EVENT_GLOBAL_POWER_EVENTS, RUNNING)), ++ P4_ESCR_EMASK_BIT(P4_EVENT_GLOBAL_POWER_EVENTS, RUNNING)) | ++ P4_CONFIG_ALIASABLE, + + /* + * retired instructions +@@ -1120,6 +1201,8 @@ static int p4_pmu_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign + struct p4_event_bind *bind; + unsigned int i, thread, num; + int cntr_idx, escr_idx; ++ u64 config_alias; ++ int pass; + + bitmap_zero(used_mask, X86_PMC_IDX_MAX); + bitmap_zero(escr_mask, P4_ESCR_MSR_TABLE_SIZE); +@@ -1128,6 +1211,17 @@ static int p4_pmu_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign + + hwc = &cpuc->event_list[i]->hw; + thread = p4_ht_thread(cpu); ++ pass = 0; ++ ++again: ++ /* ++ * Aliases are swappable so we may hit circular ++ * lock if both original config and alias need ++ * resources (MSR registers) which already busy. ++ */ ++ if (pass > 2) ++ goto done; ++ + bind = p4_config_get_bind(hwc->config); + escr_idx = p4_get_escr_idx(bind->escr_msr[thread]); + if (unlikely(escr_idx == -1)) +@@ -1141,8 +1235,17 @@ static int p4_pmu_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign + } + + cntr_idx = p4_next_cntr(thread, used_mask, bind); +- if (cntr_idx == -1 || test_bit(escr_idx, escr_mask)) +- goto done; ++ if (cntr_idx == -1 || test_bit(escr_idx, escr_mask)) { ++ /* ++ * Probably an event alias is still available. ++ */ ++ config_alias = p4_get_alias_event(hwc->config); ++ if (!config_alias) ++ goto done; ++ hwc->config = config_alias; ++ pass++; ++ goto again; ++ } + + p4_pmu_swap_config_ts(hwc, cpu); + if (assign) -- 1.7.6.4

3 4

reduce the number of radeon lockup reports
by Dave Jones 18 Oct '11

18 Oct '11

Dave, we discussed this on irc a week or so ago. The traces we get from the kernel like https://bugzilla.redhat.com/attachment.cgi?id=498312 aren't particularly useful, as we don't have any information on _why_ the chip locked up, or even the last commands that caused it. So this diff replaces the WARN so that we stop getting a backtrace. This should stop abrt from automatically filing these bugs. Is this palatable for upstream, or something you'd rather we just carry in Fedora ? Dave diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 7fd4e3e..a488b50 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -263,7 +263,7 @@ retry: */ if (seq == rdev->fence_drv.last_seq && radeon_gpu_is_lockup(rdev)) { /* good news we believe it's a lockup */ - WARN(1, "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n", + printk(KERN_WARNING "GPU lockup (waiting for 0x%08X last fence id 0x%08X)\n", fence->seq, seq); /* FIXME: what should we do ? marking everyone * as signaled for now

1 0

Summary: Fedora Kernel Team Meeting Oct 14, 2011
by Josh Boyer 14 Oct '11

14 Oct '11

=========================================== #fedora-meeting: Fedora Kernel Team meeting =========================================== Meeting started by jwb at 17:59:59 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-10-14/fedora-kernel-te… . Meeting summary --------------- * Init (jwb, 18:00:36) * Overview (jwb, 18:04:19) * F14 is approaching EOL, so focus is on security bugs or low-hanging fruit (jwb, 18:06:12) * F15 has 459 bugs open, mostly in suspend/backlight/acpi issues (jwb, 18:11:49) * IDEA: Possibly do a targeted F15 kernel bug day (jwb, 18:12:05) * New abrt update should help with improved reports (jwb, 18:13:41) * Will update F15 to 2.6.40.7 when 3.0.7 stable release comes out. Stay on -stable until just after F16 is released (jwb, 18:16:07) * ACTION: jwb will work on sending the small set of F15 patches to the stable maintainers where applicable (jwb, 18:16:57) * F15 will likely stay with the 2.6.4x naming scheme until EOL (e.g. 2.6.41 for 3.1, etc) (jwb, 18:21:27) * ACTION: davej will work on patch to lower impact of gpu lockup bugs and try to get upstream (davej, 18:22:55) * F16 has a small number of bugs. Nothing particularly block-worthy. Expect more after release (jwb, 18:25:47) * Rawhide isn't being focused on much due to F16. Some of the bugs in rawhide are likely present in F16 as well and should get assigned back to f16 as they are found. (jwb, 18:32:09) * Biggest change pending for rawhide is possibly creating a lesser used module subpackage (jwb, 18:32:56) * Q&A/Open (jwb, 18:35:41) * IDEA: Possibly build kernel and kernel-vanilla in rawhide (jwb, 18:46:18) Meeting ended at 18:51:45 UTC. Action Items ------------ * jwb will work on sending the small set of F15 patches to the stable maintainers where applicable * davej will work on patch to lower impact of gpu lockup bugs and try to get upstream Action Items, by person ----------------------- * davej * davej will work on patch to lower impact of gpu lockup bugs and try to get upstream * jwb * jwb will work on sending the small set of F15 patches to the stable maintainers where applicable People Present (lines said) --------------------------- * jwb (65) * davej (57) * cebbert (17) * tibbs (8) * brunowolff (6) * verdurin (6) * daumas (4) * zodbot (4) * nirik (1) * kylem (1)

1 0

Re:Everything you need and in time! Wow!
by nayan kumar 14 Oct '11

14 Oct '11

...I want to help you with your infernal ache. I know the place where you can buy the best drugs. http://www.clubmedian.hu/com.friend.php?enyahoo_id=62j9

1 0

(no subject)
by nayan kumar 10 Oct '11

10 Oct '11

.Do you want to be a sex-machine? http://lelunapark.com/com.friend.php?xID=37si9

1 0

Re: Fedora kernel bug day.
by Dave Jones 05 Oct '11

05 Oct '11

Some details about the triage day we are holding tomorrow. Where: #fedora-kernel on irc.freenode.net When: October 6th 2011 What: The primary focus is going to be on getting things in the best shape possible for Fedora 16's release. However there are some useful things that can be done for all releases. * Fedora 14 At this point in 14's lifecycle, many open bugs are not going to be fixed, due to the amount of work necessary to identify and backport individual fixes. Because of this, identifying open bugs that are still relevant on 15/16 is important, so we don't perpetually have to keep dragging these bugs forward every release. * Fedora 15 F15 bugs that are likely to affect F16 are obviously of importance, so triage assistance on those bugs is useful. If a bug is confirmed to be still present in Fedora 16, add 'F16' to the whiteboard field. * Fedora 16: With the release of the F16 beta, the primary focus will be to make sure the existing bugs are all properly assigned, and triaged. * Rawhide: At the moment, Rawhide is essentially in-sync with F16. The main difference is that Rawhide kernels have debugging enabled by default, whereas F16 doesn't (except for the kernel-debug builds). Because F16 is the upcoming release, we're focusing there but bugs found in Rawhide will likely still occur in F16 as well. However, there are a number of 'perpetual' bugs that are stuck in rawhide (especially Feature requests and WIP items) and those should probably be avoided for now. When in doubt, focus on F16. General info: * See https://fedoraproject.org/wiki/KernelTriage for further 'howto' info. * Of particular importance are bugs that will prevent installation, break networking, or cause system hangs. These bugs should be marked as blocking the f16blocker bug. To do this, you can use the 'f16blocker' alias or the actual bug number 713568. Confirm in IRC before adding them to the tracker bug. If you don't have the Bugzilla powers to add them to the tracker bug, ask in IRC and someone else will be able to do it for you. * Bugs that aren't serious enough to be blockers but might warrant special effort to fix might be added to the F16-accepted tracker (bug number 713566). Again, check in the channel before adding a bug to this tracker. Useful links: All open f14 kernel bugs: http://bit.ly/nmkC8m All open f15 kernel bugs: http://bit.ly/pIpDdM All open f16 kernel bugs: http://bit.ly/ouhRBY

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel October 2011