The driver match strategy was: - Match vendor/model/specifier/version of the unit directory. - If that was a miss, match vendor from the root directory and model/specifier/version of the unit directory. This was inconsistent whith how the modalias string was constructed until recently: - Take vendor/model from root directory and specifier/version from unit directory. It was also inconsistent with how it is done now: - Take vendor/model/specifier/version from the root ...

Do you see it without adding the "ftrace=nop"? The only thing that Interesting. Well, trace_module_get() is a TRACE_EVENT tracepoint. But should be disabled here. It may be something to do with DEFINE_TRACE. I've never seen it. Do you have a config you can send me. I can try it out. Thanks, -- Steve --

That bit needs commenting clearly or a WARN_ON() that p->signal->tty is NULL before the get otherwise when the assumption is broken the flaw will and a sig->tty = NULL assignment to trap races might not go amiss here perhaps ? --

One of my automated tests failed to boot cleanly. This is an 4-proc x86_64 server with 8 GB of RAM. When I repeated the test, it booted and ran successfully. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<(null)>] (null) PGD 0 Oops: 0010 [#1] SMP last sysfs file: /sys/block/sdb/removable CPU 3 Modules linked in: snd_seq_dummy tg3(+) libphy snd_seq_oss snd_seq_midi_event snd_seq ses enclosure snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore ...

Thanks. Yes, we shouldn't export __init functions, so the patch makes sense. BTW, you need to cc: one or more maintainers so that someone will merge your patches. They don't scan the mailing lists looking for patches to merge. -- ~Randy --

Signed-off-by: Rene Bolldorf <xsecute@googlemail.com> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index ddd55dc..a1f7d93 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2773,7 +2773,7 @@ int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type) /* Some architectures require additional programming to enable VGA */ static arch_set_vga_state_t arch_set_vga_state; -void __init pci_register_set_vga_state(arch_set_vga_state_t func) +void ...

Signed-off-by: Rene Bolldorf <xsecute@googlemail.com> diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c index 8d460ea..c89266b 100644 --- a/arch/x86/pci/legacy.c +++ b/arch/x86/pci/legacy.c @@ -36,7 +36,7 @@ int __init pci_legacy_init(void) return 0; } -void pcibios_scan_specific_bus(int busn) +void __devinit pcibios_scan_specific_bus(int busn) { int devfn; long node; --

Signed-off-by: Rene Bolldorf <xsecute@googlemail.com> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c index 42cdd73..16fa45b 100644 --- a/drivers/ata/ahci_platform.c +++ b/drivers/ata/ahci_platform.c @@ -164,7 +164,7 @@ static int __devexit ahci_remove(struct platform_device *pdev) return 0; } -static struct platform_driver ahci_driver = { +static struct platform_driver __refdata ahci_driver = { .probe = ahci_probe, .remove = ...

Updated memory.txt to be more consistent: s/swapiness/swappiness/ Signed-off-by: Greg Thelen <gthelen@google.com> --- Documentation/cgroups/memory.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index f8bc802..3a6aecd 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -340,7 +340,7 @@ Note: 5.3 swappiness Similar to /proc/sys/vm/swappiness, but ...

The logarithmic accumulation done in the timekeeping has some overflow protection that limits the max shift value. That means it will take more then shift loops to accumulate all of the cycles. This causes the shift decrement to underflow, which causes the loop to never exit. The simplest fix would be simply to do a: if (shift) shift--; However that is not optimal, as we know the cycle offset is larger then the interval << shift, the above would make shift drop to zero, then we would be ...

Hello, rt2500usb is broken since kernel 2.6.29. It has been discussed before but never solved: http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834 https://bugzilla.redhat.com/show_bug.cgi?id=484888 I have Asus WL-167G and it really does not work. Scanning works, association too but no packets can be sent (looks like receive works because tcpdump shows packets from other machines). DHCP fails (No DHCPOFFERS received). The problem is caused by this patch: rt2x00: Implement HW ...

Hi, did you actually remove the usb module and unloaded the module as well? you then need to load the module with the option, wait one sec and I think the HW encription did work in the past, but I'm unsure of the proper timeline. Luis Correia rt2x00 project admin --

* remove mm_types.h inclusion from sched.h * move init_mm declaration not to mm.h but to mm_types.h to overcome header loops on sparc64 * move mm_struct related stuff to mm.h * fix fallout Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- arch/blackfin/include/asm/mmu_context.h | 1 arch/blackfin/kernel/flat.c | 1 arch/s390/hypfs/inode.c | 1 arch/sparc/include/asm/pgtable_64.h | 1 ...

Commit-ID: 9c8c6bad3137112d2c7bf3d215b736ee4215fa74 Gitweb: http://git.kernel.org/tip/9c8c6bad3137112d2c7bf3d215b736ee4215fa74 Author: Cyrill Gorcunov <gorcunov@gmail.com> AuthorDate: Fri, 19 Mar 2010 00:12:56 +0300 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Thu, 18 Mar 2010 22:17:46 +0100 x86, perf: Fix few cosmetic dabs for P4 pmu (comments and constantify) - A few ESCR have escaped fixing at previous attempt. - p4_escr_map is read only, make it const. Nothing ...

So it's good enough to be in Fedora/RHEL but not good enough to be in upstream glibc? How is that possible? Isnt that a double standard? Upstream libc presence is really what is needed for an API to be ubiquitous to apps. That is what 'closes the loop' in the the positive feedback cycle loop and creates real back pressure and demand on the kernel to get its act together. Again, i state it for the third time, the KAIO situation is mostly the kernel's fault. But glibc is certainly not ...

There's a world of a difference between a fugly driver and a glibc patch. Also, we tend to upstream even fugly kernel drivers if they are important and I was there and extended/fixed bits of the kaio/libaio code when they were written so yes i already know something about it. To say that the glibc reaction was less than enthusiastic back then is a strong euphemism ;-) So after 8 years some of the bits made its way into Fedora/RHEL. I think this is a pretty good demonstration of the ...

[ Patch against https://www.linux-cr.org/redmine/tab/show/user-cr ] Make userspace use eclone to recreate all original checkpointed pids in nested pid namespaces. Yup, the kernel doesn't actually care about the vpids in all the child pid namespaces, they're actually just for us. We parse them to decide how to tell eclone to recreate the full hierarchical pid and pidns trees. Changelog: Mar 18: bump checkpoing image format version # Signed-off-by: Serge Hallyn <serue@us.ibm.com> --- ...

This is wrong, too. Once there is a kernel patch that has a reasonable syscall interface it's easy enough to hack up the glibc side. Don't try to artificially find an argument to support your thesis. If kernel developers always need an immediate itch which lives inside the kernel walls to make a change this is a failure of the kernel model and mustn't be "solved" by dragging ever more code into the kernel. Aside, you don't need a full-fledged glibc implementation for testing. Especially for AIO ...

Hello! This set has two patches, one from Lai Jiangshan that fixes RCU lockdep's rcu_read_lock_sched_held() to correctly interpret things like local_irq_disable() as starting a valid RCU-sched read-side critical section, and one from Alexey Dobriyan that removes several useless members of the RCU API. Thanx, Paul ------------------------------------------------------------------------ b/Documentation/DocBook/kernel-locking.tmpl | 8 -------- b/arch/powerpc/mm/pgtable.c ...

From: Alexey Dobriyan <adobriyan@gmail.com> call_rcu() will unconditionally reinitialize RCU head anyway. New users of these macros constantly appear, so remove them. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- ...

So your thought is to have rcu_do_batch() do something like the following? ... next = list->next; prefetch(next); list->next = RCU_HEAD_INIT_PTR; func = list->func; list->func = RCU_HEAD_INIT_PTR; func(list); ... /* touching anything referenced by "list" is use-after-free. */ Then have __call_rcu() do something like the following before initializing the ->func and ->next pointers: WARN_ON_ONCE(head->next != RCU_HEAD_INIT_PTR || head->func != ...

This does look attractive! RCU_HEAD() is identical in either case, so should be pulled out of the Would you be willing to add this to TINY_RCU as well? It would be under #ifdef, so would not affect the size of production builds. Thanx, Paul --

No functional changes. It doesn't matter which pointer we check under tasklist to ensure the task was not released, ->signal or ->sighand. But we are going to make ->signal refcountable, change the code to use ->sighand. Note: this code doesn't need this check and tasklist_lock at all, it should be converted to use lock_task_sighand(). And, the code under SIGNAL_STOP_STOPPED check looks wrong. Signed-off-by: Oleg Nesterov <oleg@redhat.com> --- arch/ia64/kernel/ptrace.c | 4 ++-- 1 ...

Another preparation to make task->signal immutable, this is the only necessary change outside of fork/exit pathes. Oleg. --

Bollocks. glibc would use (and is using) everything the kernel provides. We even have an implementation using the current AIO code. It only works in some situations but that's what the few users are OK with. Don't try to blame anyone but kernel people for the complete and utter failure of AIO in Linux. I don't know how often I've discussed design of a kernel interface with various kernel developers. Heck, whenever Zach Brown and I meet there never is a different topic. And following these ...

This patch series merges the fpu and simd exception handlers into one function. The only difference is where the status bits are read from. This also applies a fix for multiple simd exceptions that was already done for fpu. [PATCH 1/5] x86-32: Split cache flush handler from simd handler [PATCH 2/5] x86-32: Remove die_if_kernel() [PATCH 3/5] x86: Merge simd_math_error() into math_error() [PATCH 4/5] x86: Merge kernel_math_error() into math_error() [PATCH 5/5] x86-32: Don't set ignore_fpu_irq ...

Clean up the kernel exception handling and make it more similar to the other traps. Signed-off-by: Brian Gerst <brgerst@gmail.com> --- arch/x86/kernel/traps.c | 44 ++++++++++++++++---------------------------- 1 files changed, 16 insertions(+), 28 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 5628307..6384066 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -598,20 +598,6 @@ dotraplinkage void __kprobes do_debug(struct pt_regs ...

The only difference between FPU and SIMD exceptions is where the status bits are read from (cwd/swd vs. mxcsr). This also fixes the discrepency introduced by commit adf77bac, which fixed FPU but not SIMD. Signed-off-by: Brian Gerst <brgerst@gmail.com> --- arch/x86/include/asm/traps.h | 2 +- arch/x86/kernel/irqinit.c | 2 +- arch/x86/kernel/traps.c | 100 +++++++++++++---------------------------- 3 files changed, 34 insertions(+), 70 deletions(-) diff --git ...

We offer loan ranges from $10,000USD to (infinity. Terms and conditions apply) Apply now. --

The HPET driver parses ACPI _CRS data manually, but PNPACPI already does that, and it does a more complete job, so we can simplify the HPET driver quite a bit by taking advantage of that. Clemens, if you like these, will you take care of merging them, or do I need to shepherd them through some other path? Changes from v1 to v2: - Wrap PNP code in "#ifdef CONFIG_PNP" (Venki) - Fix leak when hpet_alloc() fails (Venki) --- Bjorn Helgaas (4): hpet: convert from ACPI to PNP ...

Bob Picco is no longer at HP. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> --- MAINTAINERS | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 47cc449..30ba4e9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2664,11 +2664,6 @@ HPET: x86_64 M: Vojtech Pavlik <vojtech@suse.cz> S: Maintained -HPET: ACPI -M: Bob Picco <bob.picco@hp.com> -S: Maintained -F: drivers/char/hpet.c - HPFS FILESYSTEM M: Mikulas Patocka ...

No functional change; hpet_is_known() only needs the physical address, so supplying that instead of the whole struct hpet_data makes the callers a little simpler. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> --- drivers/char/hpet.c | 14 +++++--------- 1 files changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c index 5cb05ed..d132fef 100644 --- a/drivers/char/hpet.c +++ ...

Acked-by: Venkatesh Pallipadi <venki@google.com> --

The clock used for printk.time=1 does not necessarily start running from zero. On such platforms the bootgraph does not work properly as the calculated boottime will be too long. To correct this, the patch modifies the script to accept only non-zero start times. This ensures the report contains entries only from the period when the clock was running. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> --- scripts/bootgraph.pl | 18 +++++++++++------- 1 files changed, 11 insertions(+), ...

Hi, I have a Dell PowerEdge 2900 reporting the loss of some memory at boot time. It runs Ubuntu Karmic kernel 2.6.31-19-server (internal name). The server is loaded with 42 GB of RAM but I get a little over 40GB, and the following message from dmesg after bootup accounting for the loss of RAM. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.31-19-server (buildd@crested) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ...

Rafael: Here's my updated version of your patch. It's meant as a replacement, rather than an additional patch. I used much of your text but I also altered a lot. And the new documentation describes the way things will be after Dominik Brodowski's change is added, rather than the way things are now. Attribution of authorship for changes like this is difficult; the existing conventions don't make allowance for patches with multiple authors. You'll have to figure out the right way to ...

Hi Grant, Yeah, they're plain duplications since you introduced dev.of_node. I wonder what was the problem with using dev.archdata.of_node? Why dev.of_node is better? Also, by using dev.of_node directly you have to introduce ugly #ifdefs in the non-OF code (as in i2c patch), which you don't need with transparent archdata and accessors, which you've just Thanks, -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

This series is also available in my git tree: git://git.secretlab.ca/git/linux-2.6 experimental-devicetree --

Currently, platforms using CONFIG_OF add a 'struct device_node *of_node' to dev->archdata. However, with CONFIG_OF becoming generic for all architectures, it makes sense for commonality to move it out of archdata and into struct device proper. This patch adds a struct device_node *of_node member to struct device and updates all locations which currently write the device_node pointer into archdata to also update dev->of_node. Subsequent patches will modify callers to use the archdata location ...

The following structure elements duplicate the information in 'struct device.of_node' and so are being eliminated. This patch makes all readers of the following elements use device.of_node instead. struct of_device.node struct dev_archdata.prom_node Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- arch/sparc/include/asm/fb.h | 2 +- arch/sparc/include/asm/floppy_64.h | 4 ++-- arch/sparc/include/asm/parport.h | 2 +- arch/sparc/kernel/auxio_64.c ...

The following structure elements duplicate the information in 'struct device.of_node' and so are being eliminated. This patch makes all readers of the following elements use device.of_node instead. struct of_device.node struct dev_archdata.of_node Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- arch/microblaze/kernel/of_device.c | 8 ++++---- arch/microblaze/kernel/of_platform.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git ...

The following structure elements duplicate the information in 'struct device.of_node' and so are being eliminated. This patches makes all readers of the following elements use device.of_node instead. struct dev_archdata.prom_node (sparc) struct dev_archdata.of_node (powerpc) struct of_device.node Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/ata/pata_macio.c | 2 +- drivers/ata/pata_mpc52xx.c | 10 ++++----- ...

Both dev_archdata.prom_node and of_device.node are duplications of the device.of_node value. This patch removes them. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- arch/sparc/include/asm/device.h | 15 --------------- arch/sparc/include/asm/of_device.h | 1 - arch/sparc/kernel/of_device_32.c | 2 -- arch/sparc/kernel/of_device_64.c | 2 -- arch/sparc/kernel/pci.c | 3 +-- 5 files changed, 1 insertions(+), 22 deletions(-) diff --git ...

On Thu, Mar 18, 2010 at 9:47 AM, Anton Vorontsov CONFIG_OF support is not going to be an arch-specific thing any longer. The code is being generalized, and I'm removing as many things as possible that arch code needs to add to enable CONFIG_OF. That includes the dev_archdata element. The impact of moving of_node from dev_archdata to device is pretty small anyway. Most current users are getting the device node from of_device.node instead of archdata. The number of dev_archdata users The ...

On Thu, 18 Mar 2010 09:22:39 -0600 Acked-by: Sean MacLennan <smaclennan@pikatech.com> --

Good catch, Thanks. g. --

Hi, When you try to execute an x86 binary on a x64 system, execve() returns ENOENT when ld-linux.so isn't found This just doesn't make any sense: $ ls -l -rwxr-xr-x 1 olaf olaf 560165 2010-03-18 15:21 xwis $ ./xwis -bash: ./xwis: No such file or directory Olaf --

From: Zhang, Yanmin <yanmin_zhang@linux.intel.com> Command 'perf stat' doesn't enable counters when collecting an existing (by -p) process or a system-wide statistics. Fix the issue. Change the condition of fork/exec subcommand. If there is a subcommand parameter, perf always fork/exec it. The usage example is: # perf stat -a sleep 10 So this command could collect statistics for 10 seconds precisely. User still could stop it by CTRL+C. Without the new capability, user could only use ...

Commit-ID: d6d901c23a9c4c7361aa901b5b2dda69703dd5e0 Gitweb: http://git.kernel.org/tip/d6d901c23a9c4c7361aa901b5b2dda69703dd5e0 Author: Zhang, Yanmin <yanmin_zhang@linux.intel.com> AuthorDate: Thu, 18 Mar 2010 11:36:05 -0300 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Thu, 18 Mar 2010 16:21:12 +0100 perf events: Change perf parameter --pid to process-wide collection instead of thread-wide Parameter --pid (or -p) of perf currently means a thread-wide collection. For exmaple, ...

From: Zhang, Yanmin <yanmin_zhang@linux.intel.com> 'perf record' starts counters before subcommand is execed, so the statistics is not precise because it includes data of some preparation steps. I fix it with the patch. In addition, Change the condition to fork/exec subcommand. If there is a subcommand parameter, perf always fork/exec it. The usage example is: # perf record -f -a sleep 10 So this command could collect statistics for 10 seconds precisely. User still could stop it by ...

Still no response to this problem and I still have it with 2.6.34-rc1-git6. I also upgraded to the latest 2402 motherboard BIOS. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks --

In order to parse a sample correctly based on the information requested via sample_type, the kernel needs to save each component in a known order. There is no type value saved with each component. The current convention is that each component is saved according to the order in enum perf_event_sample_format. But perf_output_sample() was not completely following this convention, thereby making samples impossible to parse without internal kernel knowledge. This patch puts things in the ...

This change adds a tracing_off_event() call to stop tracing on schedule bugs unless tracing_off=none was specified on the commandline. Signed-off-by: Chase Douglas <chase.douglas@canonical.com> --- kernel/sched.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index 150b698..bfe4f05 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -3589,6 +3589,8 @@ static noinline void __schedule_bug(struct task_struct *prev) { struct ...

[ Expanded the Cc list ] That's a bad name. It does not seem to be a mask but seems to be a control setting. Maybe call it tracing_event_off_ctrl ? --

The tracing_off_event() function calls tracing_off() to stop tracing when an event occurs. By default, only BUG-type events stop tracing, while WARNING type events do not. This is controlled through the tracing_off={none,warn,bug} commandline parameter. Call this function from bug and warning event handlers to enable a user to debug their kernel by starting a trace, hitting an event, and then retrieving trace info knowing that the trace was stopped right after the event was ...

Add missing selection of CUS package. Replace whitespace with tab. Signed-off-by: Thomas Weber <weber@corscience.de> --- arch/arm/mach-omap2/Kconfig | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..e776075 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -59,8 +59,9 @@ config MACH_OMAP3_BEAGLE select OMAP_PACKAGE_CBB config MACH_DEVKIT8000 - bool ...

Hi All, I had a look at the 2.6.32.10 stable patches. Had a comment on the 31st patch in the series: commit 7ef79e1045213953b87f45cf5993cc9c70c873ec Author: Stanislaw Gruszka <sgruszka@redhat.com> airo: fix setting zero length WEP key The linux-2.6 source has another patch that adds the following line: This is added through the commit 6510b8917948283005a125c8337d3312a8a0561c. This commit is missing in the 2.6.32.10 stable patches. I think it should be a part of stable ...

Hey, I've been looking at weird and wonderful ways to do scalable refcounting, for the vfs... Sadly, module refcounting doesn't fit my bill. But as far as I could see, it is racy. Can someone confirm that we do or do not have a race (and if so, whether this patch would solve it?) Race described in the comment below. Thanks, Nick Index: linux-2.6/include/linux/module.h =================================================================== --- linux-2.6.orig/include/linux/module.h +++ ...

i tried it on a Pentium-D box, and it works pretty well: rhea:/home/mingo/tip> perf stat -a sleep 1 Performance counter stats for 'sleep 1': 2003.237268 task-clock-msecs # 2.000 CPUs 11 context-switches # 0.000 M/sec 2 CPU-migrations # 0.000 M/sec 174 page-faults # 0.000 M/sec 47361 cycles # 0.024 M/sec (scaled from 52.83%) 430 ...

Add cache events in p4 PMU. Move the HT bit setting code from p4_pmu_event_map to p4_hw_config. So the cache events can get HT bit set correctly. Tested on my P4 desktop, below 6 cache events work. L1-dcache-load-misses LLC-load-misses dTLB-load-misses dTLB-store-misses iTLB-loads iTLB-load-misses Signed-off-by: Lin Ming <ming.m.lin@intel.com> --- arch/x86/include/asm/msr-index.h | 2 + arch/x86/include/asm/perf_event_p4.h | 10 ++ arch/x86/kernel/cpu/perf_event_p4.c | ...

Currently, we use opcode(Event and Event-Selector) + emask to look up template in p4_templates. But cache events (L1-dcache-load-misses, LLC-load-misses, etc) use the same event(P4_REPLAY_EVENT) to do the counting, ie, they have the same opcode and emask. So we can not use current lookup mechanism to find the template for cache events. This patch introduces a "key", which is the index into p4_templates. The low 12 bits of CCCR are reserved, so we can hide the "key" in the low 12 bits of ...

Remove alignment padding to shrink struct request from 336 to 320 bytes so needing one fewer cacheline and therefore removing 48 bytes from struct request_queue. Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> --- patch against 2.6.34-rc1 compiled & tested on x86_64 regards Richard diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index ebd22db..6b66438 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -158,7 +158,6 @@ enum rq_flag_bits { ...

Nah, didn't fix them up, left it for some followup patch to avoid risking introducing problems, applied as is, did some testing and pushed - Arnaldo --

From: Zhang, Yanmin <yanmin_zhang@linux.intel.com> 'perf record' starts counters before subcommand is execed, so the statistics is not precise because it includes data of some preparation steps. I fix it with the patch. In addition, Change the condition to fork/exec subcommand. If there is a subcommand parameter, perf always fork/exec it. The usage example is: #perf record -f -a sleep 10 So this command could collect statistics for 10 seconds precisely. User still could stop it by CTRL+C. ...

I think you should use "depends on X" instead of "select X". --

That's a known bug unfortunatelly (Documentation/kbuild/kconfig-language.txt): Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on ...

No functional change. These are just wrappers of raw_cpu_notifier_call_chain. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Rusty Russell <rusty@rustcorp.com.au> --- kernel/cpu.c | 55 ++++++++++++++++++++++++++++++++----------------------- 1 files changed, 32 insertions(+), 23 deletions(-) diff --git a/kernel/cpu.c b/kernel/cpu.c index f8cced2..bc9c301 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -133,6 +133,26 @@ int __ref register_cpu_notifier(struct notifier_block ...

This changes notifier_from_errno(0) to be NOTIFY_OK instead of NOTIFY_STOP_MASK | NOTIFY_OK. Currently, the notifiers which return encapsulated errno value have to do something like this: err = do_something(); // returns -errno if (err) return notifier_from_errno(err); else return NOTIFY_OK; This change makes the above code simple: err = do_something(); // returns -errno return return notifier_from_errno(err); Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> --- ...

By the previous modification, the cpu notifier can return encapsulate errno value. This converts the cpu notifiers for kernel/*.c Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> --- kernel/padata.c | 4 ++-- kernel/profile.c | 4 ++-- kernel/relay.c | 2 +- kernel/sched.c | 2 +- kernel/smp.c | 2 +- kernel/softirq.c | 2 +- kernel/softlockup.c | 2 +- ...

By the previous modification, the cpu notifier can return encapsulate errno value. This converts the cpu notifiers for iucv. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Ursula Braun <ursula.braun@de.ibm.com> Cc: linux390@de.ibm.com Cc: linux-s390@vger.kernel.org --- net/iucv/iucv.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c index fd8b283..f28ad2c 100644 --- a/net/iucv/iucv.c +++ b/net/iucv/iucv.c @@ ...

I used this module to test the series of modification to the cpu notifiers code. Example1: inject CPU offline error (-1 == -EPERM) # modprobe cpu-notifier-error-inject cpu_down_prepare_error=-1 # echo 0 > /sys/devices/system/cpu/cpu1/online0 bash: echo: write error: Operation not permitted Example2: inject CPU online error (-2 == -ENOENT) # modprobe cpu-notifier-error-inject cpu_up_prepare_error=-2 # echo 1 > /sys/devices/system/cpu/cpu1/online0 bash: echo: write error: No such ...

--

£1,000,000Pounds has been awarded to you in the U.K PROMO.send to this office the following: Names........... Tel.............. Age............ Address.......... Occupation......... Country............. Send To: bnl.claimdept@live.co.uk --

Copied from orinoco, initialize a iw_handler array entry Signed-off-by: Joe Perches <joe@perches.com> --- include/linux/wireless.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/linux/wireless.h b/include/linux/wireless.h index 5b4c6c7..ad9f8d5 100644 --- a/include/linux/wireless.h +++ b/include/linux/wireless.h @@ -346,6 +346,8 @@ #define SIOCIWFIRST 0x8B00 #define SIOCIWLAST SIOCIWLASTPRIV /* 0x8BFF */ #define IW_IOCTL_IDX(cmd) ((cmd) - ...

I've no objection to moving the casts to the uses of the macro where necessary. --

Agreed. Also please change a comment referring to SIOCSIWCOMMIT in include/net/iw_handler.h It would be great if you don't copy LKML next time. It's a purely wireless issues. I don't like having a dilemma between cross-posting and trimming the recipient list. -- Regards, Pavel Roskin --

Hi all, Changes since 20100317: Dropped tree: tmio-mmc (long unresolved conflicts and unable to fetch) My fixes tree contains: a patch for a pktcdvd build error from Arnd Bergmann The ceph tree lost all its conflicts. The net tree gained 2 build failures for which I reverted 3 commits. The tip tree still has a build failure so I used the version from next-20100311. The driver-core tree lost its build ...

This implements a powerpc version of perf_arch_fetch_caller_regs. It's implemented in assembly because that way we can be sure there isn't a stack frame for perf_arch_fetch_caller_regs. If it was in C, gcc might or might not create a stack frame for it, which would affect the number of levels we have to skip. With this, we see results from perf record -e lock:lock_acquire like this: # Samples: 24878 # # Overhead Command Shared Object Symbol # ........ .............. ...

Ingo has reported me that context-switches software events (not the trace event version) have crappy callchains. So, while looking into it: - PERF_COUNT_SW_CPU_MIGRATIONS provides no regs. Heh, and it event doesn't work because of this perf_swevent_add give up if regs are NULL. Has PERF_COUNT_SW_CPU_MIGRATIONS ever worked? - PERF_COUNT_SW_CONTEXT_SWITCHES uses task_pt_regs(). This seems a very wrong thing. We don't want the regs when a user task was interrupted or before a ...

Yep, it does the trick. In case you test, I have two other misalignments, one is in perf_trace_buf_prepare but it is my bad and it is nothing related to percpu. I'm going to fix it. Another is in the ring buffer and Steve has a pending fix. Thanks. --

Hi, While using the lock events through perf in a sparc box, I can see the following message repeated many times: Kernel unaligned access at TPC[49357c] perf_trace_lock_acquire+0xb4/0x180 It actually hangs the box as the messages are sent to a serial console. When used with perf, the trace events use a per cpu buffer allocated in kernel/trace/trace_event_perf.c, and the allocation appears to return a misaligned percpu pointer. It is aligned to 4 while it seems it requires to be aligned ...

Yes, it's expanded by some crazy macro in include/trace/ftrace.h.. In linus' tree, it's called ftrace_profile_lock_acquire(), and it's renamed to perf_trace_lock_acquire() in -tip tree by commit 97d5a22005f38057b4bc0d95f81cd26510268794. #undef DECLARE_EVENT_CLASS #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \ static notrace void \ ftrace_profile_templ_##call(struct ftrace_event_call *event_call, \ ...

Yeah indeed. The problem happens in Linus's tree and -tip tree as well, it's just that I debugged it in -tip and there has been a naming change inside, I forgot about that. So in mainline the problem happens in ftrace_profile_templ_lock_acquire (macro generated above). Thanks. --

The timekeeping code handles this (although the shift value I picked may need some adjustment - what is the expected counter freq range on alpha?). The ACPI PM counter which is very common on x86 is only 24 bits and rolls over in ~5 seconds. It works fine. However, I'm not maintaining the arch, and this patch isn't limiting the timekeeping core, so the call is really yours. I sent this out on a whim since it looked easy to do. However, while this change is totally optional, I suspect my ...

With 8 seconds or less between roll-overs, do you actually consider this a continuous counter? I don't. I suggest this be left alone. r~ --

Nice! Thanks for testing! Another benefit that I forgot to mention, is that NTP adjustments will be made directly against the counter, instead of being made against the tick. This avoids possible small errors at tick time if the intertick interval doesn't match the actual tick Yea, selecting a good shift is obnoxious. You want to pick the largest value of shift, so that it can be finely adjusted by ntp, but that creates large mult values, which can cause overflows for large cycle intervals. ...

Ok, that sounds reasonable for now. I'll queue it up for .35. thanks, greg k-h --

Here's the dump from the lm64. 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 34 3e 00 03 08 46 00 46 00 03 08 46 00 46 00 00 4>.??F.F.??F.F.. 10: 60 10 00 00 00 00 e5 00 00 7b 1f 1f 00 00 00 00 `?....?..{??.... 20: 00 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .d.............. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40: 00 00 00 00 00 00 af 0f ff ff 00 00 05 08 00 05 ......??....??.? 50: 00 04 32 05 46 06 5a 07 5f 0b 64 ...

The LM64 appears to be an LM63 with added GPIO lines. Add support for the hwmon functionality - GPIO can be added at some later stage if someone has a need for them. Signed-off-by: Matthew Garrett <mjg@redhat.com> --- Capitalisation fixes and remove an unused variable. Documentation/hwmon/lm63 | 7 +++++++ drivers/hwmon/Kconfig | 9 +++++---- drivers/hwmon/lm63.c | 16 ++++++++++++---- 3 files changed, 24 insertions(+), 8 deletions(-) diff --git ...

Ack on this series. Acked-by: Veaceslav Falico <vfalico@redhat.com> -- Veaceslav --

On Wed, 17 Mar 2010 11:22:01 -0400 (EDT) No reason. About merging adjacent buffers, there are few IOMMU implementations that do. The recent IOMMU implementations such as VT-d and AMD IOMMU don't. If drivers don't support scatter-gather operation, they had better use dma_map_page() instead of forging scatter-gather lists and playing with dma_map_sg(). --

Mind checking latest -tip, which has these commits: d6d901c: perf events: Change perf parameter --pid to process-wide collection instead of thread-wid 46be604: perf record: Enable counters only when kernel is execing subcommand 6be2850: perf stat: Enable counters when collecting process-wide or system-wide data as they fix/improve various --pid related behavioral aspects of perf. Does it work fine for you now? Ingo --

Commit-ID: 7335f75e9ca166044e38a96abad422d8e6e364b5 Gitweb: http://git.kernel.org/tip/7335f75e9ca166044e38a96abad422d8e6e364b5 Author: Cyrill Gorcunov <gorcunov@openvz.org> AuthorDate: Wed, 17 Mar 2010 13:37:01 +0300 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Thu, 18 Mar 2010 17:03:22 +0100 x86, perf: Use apic_write unconditionally Since apic_write() maps to a plain noop in the !CONFIG_X86_LOCAL_APIC case we're safe to remove this conditional compilation and clean up the ...

I can't because amd_get_nb_id() returns garbage for the CPU when you call from CPU_STARTING. So looks like initialization of cpu_llc_id needs to be moved way earlier. I don't want to have to duplicate that code. --

So if the guest enables PAT at PTE level you completly disable reserved bit checking? You should only disable checking for [1][1] if !PSE. --

Agreed. And lets people use what is common for them: expressions that follow C rules in the context. And those who will be more familiar with perf probe will know they can use the simplified "." based scheme. --

Hmm, indeed. this code implies that ntevs > 0, it seems that we'd better check it first (e.g. 'if(ntevs <= 0) return;') too. -- Masami Hiramatsu e-mail: mhiramat@redhat.com --

Re-post due to missing macro parameter. interdiff: diff -u b/include/linux/syscalls.h b/include/linux/syscalls.h --- b/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -241,7 +241,7 @@ SYSCALL_METADATA(syscall, compat_sys_##sname, x); \ asmlinkage long syscall(__SC_DECL##x(__VA_ARGS__)) #else -#define COMPAT_SYSCALL_DEFINEx(x, sname, ...) \ +#define COMPAT_SYSCALL_DEFINEx(x, syscall, sname, ...) \ asmlinkage long syscall(__SC_DECL##x(__VA_ARGS__)) ...

Well, given the other issues with mpol_parse_str(), I suspect the entire tmpfs mpol option is not used all that often in the mainline kernel. I recall that this feature was introduced by SGI for some of their customers who may depend on it. There have been cases where I could have used it were it supported for the SYSV shm and MAP_ANON_MAP_SHARED internal tmpfs mount. Further, note that the addition of "mpol=local" occurred between when the major "enterprise distributions" selected a new ...

I wouldnt jump to assumptions there. perf shares some facilities with the kernel on the source code level - they can be built both in the kernel and in user-space. But my main thought wasnt even to actually share the implementation - but to actually synchronize when a piece of device emulation moves into the kernel. It is arguably bad for performance in most cases when Qemu handles a given device - so all the common devices should be kernel accelerated. The version and testing matrix ...

Ingo, Sorry, the patch has bugs. I need do a better job and will work out 2 separate patches against the 2 issues. Yanmin --

As you pointed out, NMI is not "Fixed interrupt". If we want to send NMI, it would need a specific delivery mode rather than vector number. And if you look at code, if we specific NMI_VECTOR, the delivery mode would be set to NMI. So what's wrong here? -- regards Yang, Sheng --

OK, I think I understand your points now. You meant that these vectors can't be filled in vector field directly, right? But NMI is a exception due to DM_NMI. Is that your point? I think we agree on this. -- regards Yang, Sheng --

Cool! Mind sending them as a series of patches instead of attachment? That makes it easier to review them. Also, the Signed-off-by lines seem to be missing plus we need a per patch changelog as well. Thanks, Ingo --

Ingo, What made KVM so successful was that the core kernel of the hypervisor was designed the right way, as a kernel module where it belonged. It was obvious to anyone who had been exposed to the main competition at the time, Xen, that this was the right approach. What has ended up killing Xen in the end is the not-invented-here approach of copying everything over, reformatting it, and rewriting half of it, which made it impossible to maintain and support as a single codebase. At my ...

If qemu was in tools/kvm/ then we wouldnt have such issues. A single patch (or series of patches) could modify tools/kvm/, arch/x86/kvm/, virt/ and tools/perf/. Numerous times did we have patches to kernel/perf_event.c that fixed some detail, also accompanied by a tools/perf/ patch fixing another detail. Having a single 'culture of contribution' is a powerful way to develop. It turns out kernel developers can be pretty good user-space developers as well and user-space developers can ...

It's not a 1:1 connection. There are more users of the KVM interface. To name a few I'm aware of: - Mac-on-Linux (PPC) - Dolphin (PPC) - Xenner (x86) - Kuli (s390) Having a clear userspace interface is the only viable solution there. And if you're interested, look at my MOL enabling patch. It's less than 500 lines of code. The kernel/userspace interface really isn't the difficult part. Getting device emulation working properly, easily and fast is. Alex--

There must be a misunderstanding here: tools/perf/ still has a clear userspace interface and ABI. There's external projects making use of it: sysprof and libpfm (and probably more i dont know about it). Those projects are also contributing back. Still it's _very_ useful to have a single reference implementation under tools/perf/ where we concentrate the best of the code. That is where we make sure that each new kernel feature is appropriately implemented in user-space as well, that ...

That would make sense for a truly minimal userspace for kvm: we once had a tool called kvmctl which was used to run tests (since folded into qemu). It didn't contain a GUI and was unable to run a general purpose guest. It was a few hundred lines of code, and indeed patches to kvmctl had a much closer correspondence to patches with kvm (though still low, Suppose we copy qemu tomorrow into tools/. All the problems will be copied with it. Someone still has to write patches to fix ...

You can't be serious. I find that the difficulty in contributing a patch has mostly to do with writing the patch, and less with figuring Indeed, working simultaneously on two different projects is difficult. I usually work for a while on one, and then 'cd', physically and psychically, to the other. Then switch back. Sort of like the We have a large number of such stupid, fanatic, desperate developers in By "serious developer" I mean - someone who is interested in ...

It's very simple: because the contribution latencies and overhead compound, almost inevitably. If you ever tried to implement a combo GCC+glibc+kernel feature you'll know ... Even with the best-run projects in existence it takes forever and is very I'm afraid practice is different from the rosy ideal you paint there. Even with assumed 'perfect projects' there's always random differences between projects, causing doubled (tripled) overhead and compounded up overhead: - random ...

My own experience and everyone i've talked about such topics (developers and distro people) about feature contribution tells the exact opposite: it's much harder to contribute features to multiple packages than to a single project. kernel+library+app features take forever to propagate, and there's constant fear of version friction, productization deadlines are uncertain and ABI messups are frequent as well due to disjoint testing. Also, each component has essential veto power: so if the ...

If it's functional to the extent of at least allowing say a serial console via the console (like the UML binary allows) i'd expect the minimal user-space to quickly grow out of this minimal state. The rest will be history. Maybe this is a better, simpler (and much cleaner and less controversial) approach than moving a 'full' copy of qemu there. There's certainly no risk: if qemu stays dominant then nothing is lost [tools/kvm/ can be removed after some time], and if this clean base ...

Alright, you just volunteered. Just give it a go and try to implement the "oh so simple" KVM frontend while maintaining compatibility with at least a few older Linux guests. My guess is that you'll realize it's a dead end before committing anything to the kernel source tree. But really, just try it out. Good Luck Alex --

Sorry, er, what? What distributions eagerly upgrade kernels in stable periods, were it not primarily motivated by security fixes? What users eagerly replace their kernels? - FChE --

Us guys reading and participating on the list. ;) --

Yeah, please, and I hadn't merged them, so the resend was the best thing to do. - Arnaldo --

Sorry but you cannot compare merging two chunks of kernel code that originated from the same base, with the efforts of mixing a large Both perf and oprofile are still relatively small projects in comparison You believe that I am wrong in my assessment of unified projects, and I obviously think you are mistaken and underestimating the cost and effects of trying to merge the two. Well I think we are just going to agree to disagree on this one. I am not against merging projects where it ...

I think you didnt understand my (tersely explained) point - which is probably my fault. What i said is: - distros update the kernel first. Often in stable releases as well if there's a new kernel released. (They must because it provides new hardware enablement and other critical changes they generally cannot skip.) - Qemu on the other hand is not upgraded with (nearly) that level of urgency. Completely new versions will generally have to wait for the next distro ...

I just replied to Frank Ch. Eigler with a specific example that shows how this If you check the update frequency of RHEL 5 kernels you'll see that it's Happy choice or not, this is what i said is the distro practice these days. (i Rawhide is generally for latest released versions, to ready them for the next distro release - with special exception for the kernel, which has a special position due being a hardware-enabler and because it has an extremely predictable release schedule ...

So, you propose to allow running tools/kvm/ only on the kernel it was shipped with? Of course it isn't a good thing, but it is unavoidable. Qemu compiles code just-in-time to avoid interpretation overhead, while kvm emulates one instruction at a time. No caching is possible, especially with ept/npt, since the guest is free to manipulate memory with no notification to the host. Qemu also supports the full instruction set while kvm only implements what is necessary. Qemu is a ...

QEMU is about 600k LOC. We have a mechanism to compile out portions of the code but a lot things are tied together in an intimate way. In the long run, we're working on adding stronger interfaces such that we can split components out into libraries that are consumable by other applications. Simplying forking the device model won't work. Well more than half of our contributors are not coming from KVM developers/users. If you just fork the device models, you start to lose a ton of ...

Thanks. In fact with have an QxKxGxT compatibility matrix since we need to keep compatibility with guests and with tools. Since the easiest interface to keep compatible is the qemu/kernel interface, allowing the kernel and qemu to change independently allows reducing the compatibility matrix while still providing some improvements. Regardless of that I'd keep binary compatibility anyway. Not everyone is on the update treadmill with everything updating every three months Some ...

We have to maintain a dirty bitmap because we don't have a paravirtual graphics driver. IOW, someone needs to write an Xorg driver. Ideally, we could just implement a Linux framebuffer device, right? Well, we took that approach in Xen and that sucks even worse because the Xorg framebuffer driver doesn't implement any of the optimizations that the Linux framebuffer supports and the Xorg driver does not provide use the kernel's interfaces for providing update regions. Of course, we ...

I don't think I've ever used full-screen mode with my VMs and I use virtualization on a daily basis. I don't see any actual KVM developer complaining about this so I'm not We lose a huge amount of users and contributors if we put QEMU in the Linux kernel. As I said earlier, a huge number of our contributions We've tried to create a "clean" version of QEMU specifically for KVM. Moving it into tools/kvm would be the second step. We've all failed on If the problem is ...

I took a quick look at the qemu.git log and more than half of all recent contributions came from Linux distributors. So without KVM Qemu would be a much, much smaller project. It would be similar The stats show that the huge increase in Qemu contributions over the past few years was mainly due to KVM. Do you claim it wasnt? What other projects make Sorry, i didnt comment on it because the answer is obvious: the file system tools and pretty much any Linux-exclusive tool (such as ...

That's the same i do, and that's what i'm hearing from other desktop users as well. The moment you work seriously in a guest OS you often want to switch to it full-screen, to maximize screen real-estate and to reduce host GUI element distractions. If it's just casual use of a single app then windowed mode suffices (but in that case performance doesnt matter much to begin with). I find the 'KVM mostly cares about the server, not about the desktop' attitude /me should do that too - ...

It's not kvm, just it's developers (and their employers, where applicable). If you post desktop oriented patches I'm sure they'll be welcome. -- error compiling committee.c: too many arguments to function --

It is, because testing is more focused and more people are testing the combination that developers tested as well. (and not some random version combination picked by the distributor or the user) Ingo --

Good that you mention it, i think it's an excellent example. The suckage of kernel async IO is for similar reasons: there's an ugly package separation problem between the kernel and between glibc - and between the apps that would make use of it. ( With the separated libaio it was made worse: there were 3 libraries to work with, and even less applications that could make use of it ... ) So IMO klibc is an arguably good idea - eventually hpa will get around posting it for upstream ...

I don't know what you're looking at, but in the past month, there's been 56 unique contributors, with 411 changesets. I count 16 people employed I'm not saying that KVM isn't significant. I'm employed to work on QEMU because of KVM. I'm just saying that KVM users aren't 99% of the community and that we can't neglect the rest of the community. Regards, Anthony Liguori --

I'm not going to argue about the Qemu merging here. But your above assessment is incomplete. It is not because developers don't want to clone two different trees that tools/perf is a success. Or may be it's a factor but I suspect it to be very minimal. I can script git commands if needed. It is actually because both kernel and user side are I think it has already really good results. --

Your concern is valid, and this issue has been raised in the past as one of the main counter-arguments against tools/perf/. (there was a big flamewar about it on lkml when it was introduced) Our roughly 1 year experience with perf is that, somewhat pradoxially, this scheme not only works as well as classic ABI schemes but actually brings a _better_ ABI than the classic "let the kernel define an ABI" single-sided solution. I know the difference first hand, i've written various ...

Our experience is the opposite, and we tried both variants and report about our experience with both models honestly. You only have experience about one variant - the one you advocate. Sorry, but this is pain not true. The 2.4->2.6 kernel cycle debacle has taught us that waiting long to 'iron out' the details has the following effects: - developer pain - user pain - distro pain - disconnect - loss of developers, testers and users - grave bugs discovered months (years ...) ...

I'm sorry to say that's pretty bad. Users don't want to update their So in addition to all the normal kernel regressions, you want to force No, I am suggesting qemu-kvm.git is not as stable as released versions (and won't get fixed backported). Keep in mind that unlike many userspace applications, qemu exposes an ABI to guests which we must keep compatible. -- error compiling committee.c: too many arguments to function --

I'd like to second that - i'm actually quite happy to update the distro kernel. Also, i have rarely any problems even with bleeding edge kernels in rawhide - they are working pretty smoothly. A large xorg update showing up in yum update gives me the cringe though ;-) Ingo --

Just to play devil's advocate, let's not mix up the development model with the distribution model. There is nothing to stop packagers and distributors from providing separate kernel "proper" packages and perf tools packages. It might even make good sense assuming backwards compatibility for distros that have conservative policies about new kernel versions to provide newer perf tools packages with older kernels. John --

Of course. Some distros are also very conservative about updating the kernel at all. I'm mostly talking about the distros that are at the frontier of kernel development: those with fresh packages, those which provide eager bleeding-edge testers and developers. Ingo --

That's true to a certain degree, but combined with the perf experience it's all rather clear. Similar arguments were made against the x86 unification and against perf. Similar arguments were made against KVM and in favor of Xen years ago - back when few of you knew about it ;-) These are all repeating patterns in my experience. You could fairly contrast that with a _failed_ unification perhaps - but i'm not aware of any such failed unification. (please educate me if you are) The ...

This has nothing todo with them being in separate source repos. We could update QEMU to new major feature releaes with the same frequency in a Fedora release, but we delibrately choose not to rebase the QEMU userspace because experiance has shown the downside from new bugs / regressions outweighs the benefit of any new features. The QEMU updates in stable Fedora trees, now just follow the minor bugfix release stream provided by QEMU & those arrive in Fedora with little noticable ...

--

Ok, that looks like the most readable variant, agreed? Ingo --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 no, these options have not been / are not enabled. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuimhkACgkQ+6sI4XSM4u1jtACfS9YfQfKZ/Pu/n62lT50xSise RdAAmgMfVmKXPFRT2hz7bSWAMIor9zTo =gMEL -----END PGP SIGNATURE----- --

Do what declare __sysno as long long? The current prototype is in unistd.h: #ifdef __USE_MISC /* Invoke `system call' number SYSNO, passing it the remaining arguments. This is completely system-dependent, and not often useful. In Unix, `syscall' sets `errno' for all errors and most calls return -1 for errors; in many systems you cannot pass arguments or get return values for all system calls (`pipe', `fork', and `getppid' typically among them). In Mach, all system ...

int is incompatible with long, so you already get undefined behaviour anyway. Andreas. -- Andreas Schwab, schwab@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." --

On Thu, 18 Mar 2010 08:54:11 +0900 BTW, I should explain how acculate this accounting is in this patch itself. Now, lock_page_cgroup/unlock_page_cgroup happens when - charge/uncharge/migrate/move accounting Then, the lock contention (trylock failure) seems to occur in conflict with - charge, uncharge, migarate. move accounting About dirty accounting, charge/uncharge/migarate are operation in synchronous manner with radix-tree (holding treelock etc). Then no account leak. move ...

On Thu, 18 Mar 2010 11:16:53 +0900 HmmHmm, thank you. then, only racy cases are truncate and force_empty. Thanks, -Kame --

On Thu, 18 Mar 2010 09:49:44 +0530 I never do silently. All e-mails are open. Thanks, -Kame --

Agreed, we need to find a simpler way of doing this without affecting the accuracy of accounting - may be two accounting routines for two code paths. I have not thought through this yet. -- Three Cheers, Balbir --

I have a proposed change to "[PATCH -mmotm 4/5] memcg: dirty pages accounting and limiting infrastructure" v6. The change is small and I am presenting it as a git patch (below) to be applied after 4/5 v6 has been applied. The change is fairly simple. An alternative would be to reject my patch (below) and enhance get_vm_dirty_param() to loop for consistenty in all cases. ---patch snip here, rest of email is git patch of 4/5 v6 --- Removed unneeded looping from get_vm_dirty_param(). The only ...

On 03/18/10 00:39, Frederic Weisbecker wrote: > On Wed, Mar 17, 2010 at 04:30:53PM +0900, Hitoshi Mitake wrote: >> On 03/17/10 10:32, Frederic Weisbecker wrote: >>> On Sun, Mar 14, 2010 at 07:13:55PM +0100, Peter Zijlstra wrote: >>>> On Sun, 2010-03-14 at 19:38 +0900, Hitoshi Mitake wrote: >>>>> Current lockdep is too complicated because, >>>>> * dependency validation >>>>> * statistics >>>>> * event tracing >>>>> are all implemented by it. >>>>> This cause problem of ...

No that's really not a problem. trylocks are pointless in latency profiling because by definition they don't content. OTOH, they grab the lock and other locks might wait and raise latencies. So they are part of the profile. But we don't care about having the usual acquire/aquired/release sequence as we have the flags that tell us if this is a trylock. So we just need to consider that acquire:try_lock - release is a right lock scenario, but that acquire - release is only a ...

Dear Rafael Wysocki, I am sorry for the late reply. When you said that this problem had been fixed in mainline, I thought that you meant the 2.6.34-rcX series, because I had already tested 2.6.33 before sending my original e-mail and confirmed that it had this problem as well. So, with the hope of seeing this problem fixed, I tried git commit a3d3203e4bb40f253b1541e310dc0f9305be7c84 (which happens to be the most recent version in the git repository as of a few hours ago) but I am sorry ...

On Sat, 13 Mar 2010 13:31:05 +0100 Is this ok? cheers, Flo --

But if the depends line is removed, it could be set without NUMA, memory hot-remove or compaction enabled. That wouldn't be very useful. I'm missing something obvious. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Actually, you're right and I was wrong. I was double decrementing the counts. Good spot. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Yes. --

Thank you! then, this logic depend on SLAB_DESTROY_BY_RCU, not refcount. So, I think we don't need your [1/11] patch. Am I missing something? --

Is it possible somehow to provide a kind of wrapper/backup function: trace_power_frequency_cpu(POWER_PSTATE, frequency, cpu); or another trace interface with eventually some more overhead? Then it should be easy to support all drivers. Otherwise you'll for example miss the pcc driver which supports latest/upcoming Intel CPUs and which does IO based switching which needs not to run on the cpu that gets switched. Thomas --

Hello, I swapped the motherboard with the ASUS and all problems have disappeared. Someone else e-mailed me with a similar issue (freeze/hang/etc) with a similar motherboard (but UDP3 instead of 5 I believe) and they could not find a solution either, they were trying to install Fedora. Justin. --

Hi Linus, I've updated my merge branch to add a build fix (mpc52xx) and an OF regression (fix comparison...). Please pull. Thanks, g. The following changes since commit 57d54889cd00db2752994b389ba714138652e60c: Linus Torvalds (1): Linux 2.6.34-rc1 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 merge David Miller (1): uartlite: Fix build on sparc. Grant Likely (3): powerpc/52xx: update defconfigs of: Fix comparison of ...

Peter and Thomas have a lockdep patch that resolves this, I thought it was going in through one of their trees, but in talking with them yesterday, I was wrong. I will be adding the patch to my tree, right before the "convert to mutex" patch, so this will not show up in the future. thanks, greg k-h --

I looked at this a bit closer using an iozone test very similar to Christian's. Despite buying a number of disks, I still can't reproduce his problem but I instrumented congestion_wait counts and times similar to what he did. 2.6.29-instrument:congestion_waittime 990 2.6.30-instrument:congestion_waittime 2823 2.6.31-instrument:congestion_waittime 193169 2.6.32-instrument:congestion_waittime 228890 2.6.33-instrument:congestion_waittime 785529 2.6.34-rc1-instrument:congestion_waittime ...

On Mon, 8 Mar 2010 14:14:49 +0100 This all seemed to die. Does Neil's mysterypatch fix all these issues? Neil, was that patch tagged for -stable backporting? Thanks. --

You do realize that the .23 and .24 kernels are no longer supported, right? thanks, greg k-h --

Hi Ira, For some strange reason this patch did not show up in my socketcan mbox, sorry. At least I cannot find it. Oliver, or somebody else, did you receive it? Nevertheless, for kernel inclusion the patch should go through the netdev mailing list as described in: http://svn.berlios.de/svnroot/repos/socketcan/trunk/README.submitting-patches It's also confusing that one 2/3 shows up on the Socketcan-core ML. At least 0/3 should also be presented there. Could you please ...

On Sun, Mar 7, 2010 at 4:42 PM, Dmitry Torokhov Sorry for the late reply, but this is a recurring theme. Remote controls (IR and radio) have the same problem and this was the core of my objection to their drivers being merged. Input devices need to communicate their human oriented events to user space using the input subsystem period. If you don't do this things like the xserver/apps have to implement custom drivers for every new user event interface that is dreamed up and that destroys ...

Thanks for adding it! --

I checked it again: I don't even have the virtualbox modules installed for this kernel, I cannot modprobe them. lsmod is here: before modprobe kvm_amd Module Size Used by snd_pcm_oss 33062 0 snd_mixer_oss 13798 1 snd_pcm_oss snd_seq_oss 23963 0 snd_seq_midi_event 5684 1 snd_seq_oss snd_seq 44953 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 5481 2 snd_seq_oss,snd_seq nvidia 9613596 40 ...

Please do. If that doesn't help ping me again. I'll write up a quirk patch then. Alex--