Corrected printk calls with multiple output lines which did not correctly preface each line with KERN_<level> Fixed uses of some single lines with too many KERN_<level> Please pull from: git://repo.or.cz/linux-2.6/trivial-mods.git pr_newlines Signed-off-by: Joe Perches <joe@perches.com> arch/arm/kernel/ecard.c | 3 ++- arch/blackfin/kernel/dualcore_test.c | 3 ++- arch/blackfin/kernel/traps.c | 4 +++- arch/h8300/kernel/setup.c | ...

Sounds like the drive has gotten into a really hosed state after this point. The SError register is showing a CRC error, disparity error, and 10b to 8b decode error, which indicates that there are some major SATA communication problems happening. It could be a hardware problem (bad drive, bad SATA cable, insufficient power, etc.) or maybe this is another drive with broken NCQ.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home ...

Hi Andrew, I get the following BUG when booting 2.6.23-rc3-mm1 on i386. I wonder if you would have some ideas about what is causing this problem. I'll start bissecting it soon. I seems to be caused by an buggy skb_put call in kobject_uevent_env. Thanks, Mathieu Synthesizing the initial hotplug events...[ 13.738308] skb_over_panic: text:c0252ede len:97 put:11 head:c2237e00 data:c2237e00 tail:0xc2237e61 end:0xc2237e60 dev:<NULL> [ 13.772252] ------------[ cut here ]------------ [ ...

I think this patch got dropped a while ago when things were just reworked too much in this area. If this patch now works properly, I have no objection to taking it in my tree again. thanks, greg k-h -

Convert cpu_llc_id from a static array sized by NR_CPUS to a per_cpu variable. This saves sizeof(cpu_llc_id) * NR unused cpus. Access is mostly from startup and CPU HOTPLUG functions. Note there's an addtional change of the type of cpu_llc_id from int to u8 for ARCH i386 to correspond with the same type in ARCH x86_64. Signed-off-by: Mike Travis <travis@sgi.com> --- arch/i386/kernel/cpu/intel_cacheinfo.c | 4 ++-- arch/i386/kernel/smpboot.c | 6 +++--- ...

Convert cpu_sibling_map from a static array sized by NR_CPUS to a per_cpu variable. This saves sizeof(cpumask_t) * NR unused cpus. Access is mostly from startup and CPU HOTPLUG functions. Signed-off-by: Mike Travis <travis@sgi.com> --- arch/i386/kernel/cpu/cpufreq/p4-clockmod.c | 2 - arch/i386/kernel/cpu/cpufreq/speedstep-ich.c | 2 - arch/i386/kernel/io_apic.c | 4 +-- arch/i386/kernel/smpboot.c | 36 +++++++++++++-------------- ...

Fix four instances where cpu_to_node is referenced by array instead of via the cpu_to_node macro. This is preparation to moving it to the per_cpu data area. Signed-off-by: Mike Travis <travis@sgi.com> --- arch/x86_64/kernel/vsyscall.c | 2 +- arch/x86_64/mm/numa.c | 4 ++-- arch/x86_64/mm/srat.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) --- a/arch/x86_64/kernel/vsyscall.c +++ b/arch/x86_64/kernel/vsyscall.c @@ -283,7 +283,7 @@ unsigned long ...

When a cpu is disabled, move_task_off_dead_cpu() is called for tasks that have been running on that cpu. Currently, such a task is migrated: 1) to any cpu on the same node as the disabled cpu, which is both online and among that task's cpus_allowed 2) to any cpu which is both online and among that task's cpus_allowed It is typical of a multithreaded application running on a large NUMA system to have its tasks confined to a cpuset so as to cluster them near the memory that they share. ...

Hi Linus, Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git for-linus H. Peter Anvin (2): [x86 setup] Volatilize asm() statements [x86 setup] Make sure AH=00h when setting a video mode arch/i386/boot/boot.h | 24 ++++++++++++------------ arch/i386/boot/cpucheck.c | 3 ++- arch/i386/boot/edd.c | 6 +++--- arch/i386/boot/tty.c | 14 +++++++------- arch/i386/boot/video-vga.c | 17 +++++++++-------- 5 files ...

It seems that since it was added in kernel 2.2.0 (sic) securebits was never used. This patch therefore removes it. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- include/linux/sched.h | 1 - include/linux/securebits.h | 30 ------------------------------ kernel/capability.c | 1 - security/commoncap.c | 34 ++++++++++++++-------------------- security/dummy.c | 16 +++++++--------- 5 files changed, 21 insertions(+), 61 ...

The main feature is that export_report now automatically works for O= builds. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- This patch has been sent on: - 14 Aug 2007 --- a/Makefile +++ b/Makefile @@ -1153,6 +1153,7 @@ help: @echo 'Static analysers' @echo ' checkstack - Generate a list of stack hogs' @echo ' namespacecheck - Name space analysis on compiled kernel' + @echo ' export_report - List the usages of all exported symbols' @if [ -r ...

Adrian, I am fine with these changes. RP -

I don't care whether it compares strings or numbers as long as it works... I'm not the author of this script, and my patch fixes the one annoying bug I observed when using it. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -

Hi, 2.6.22 kernel with hyperthreading enabled only ext3 filesystems (2). [ 346.314640] ======================================================= [ 346.314758] [ INFO: possible circular locking dependency detected ] [ 346.314815] 2.6.22 #5 [ 346.314862] ------------------------------------------------------- [ 346.314920] tor/2421 is trying to acquire lock: [ 346.314973] (tty_mutex){--..}, at: [<c121aa83>] mutex_lock+0x8/0xa [ 346.315193] [ 346.315195] but task is already holding ...

Most USB keys nowadays have a small LED somewhere inside of them that lights up when they are plugged in. On a windows box, the key is lit up whenever it is mounted, and as soon as it is unmounted it turns off, giving a handy physical indicator that the key is safe to remove. On linux, the light is simply on whenever the key is plugged in. Should linux toggle the light depending on mount state? Is it as trivial as it seems or does this reflect some larger issue? -Casey Dahlin -

I've two things in mind to try: (1) there is 1 newer official BIOS release and 2 beta BIOSes out for this motherboard. The recent official BIOS (0901) does mention Linux: "Fixed Red Hat Enterprise Linux 4 installation failed" So maybe a BIOS update will fix things. (2) I will try booting with the "noapic" kernel option to see what So I guess these drives should be added to the ata_blacklist_entry in libata-core.c with ATA_HORKAGE_NONCQ? Stirk, Lamont & Associates ...

Thanks for the hint. 2.6.22.5 with CFS v20.3 does not skip anymore. It was skipping when turning the desktop cube in compiz, or (without compiz) when scrolling in the output of less in a full-screen pseudo-transparant gnome-terminal, or when rapidly scrolling with Firefox in http://phoenity.com/newtedge/ (test case from the previous thread). Now the kernel which I'm using normally, also had the high resolution timers patch for x86_64 applied. I tried applying it again to the current ...

menuconfig BLK_DEV bool "Block devices" depends on BLOCK default y ---help--- Say Y here to get to see options for various different block device drivers. This option alone does not add any kernel code. If you say N, all options in this submenu will be skipped and disabled only do this if you know what you are doing. Jan -- -

Well, where do you think your hard disk drivers come from? Definitely not from the BLK_DEV menu... Jan -- -

mm.h doesn't use directly anything from mutex.h and backing-dev.h, so remove them and add them back to files which need them. Cross-compile tested on many configs and archs. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- BTW, switching to SLUB makes this nice workload to go OOM, which SLAB never allowed itself, however, I'm not prepared right now to tell the story. It smells like semi-recent breakage, because, I can swear, I ran it with SLUB for stress-testing purposes. ...

Hi Andrew, With the "redefine register_hotcpu_notifier() stub as static inline function" patch gone, I can no longer reproduce the section mismatches mentioned in: x86_64-mce_amd-fix-section-mismatch-warnings.patch [ The section annotations of that patch still stand, just the changelog is no longer completely accurate. ] If we care enough about this, I'm resubmitting that patch with updated patch name and changelog here -- the content is same. Satyam [PATCH] x86_64 mce{_amd}: ...

It is available for KVM compilation, not for KVM use. In fact smp_ops is not available for KVM use, so as smp_call_function_mask() is smp_ops.smp_call_function_mask() we can say it is not available... My first reflex was to export smp_ops, but as it seems it is an internal and hidden variable, it appears I should export smp_call_function_mask() instead. Laurent -

On Thu, 23 Aug 2007 08:27:09 -0400 Jesper Juhl I submitted a patch via gmail/smtp after setting the following up and all looked well... gmail --> settings --> forwarding and pop --> enable pop. directions for setting up thunderbird: Thunderbird 1.5 http://mail.google.com/support/bin/answer.py?answer=38343 configuring Thunderbird for wordwrap: Edit -> Preferences -> Composition Wrap Plain Text Messages at: 99999 .... and that's it... I'm gathering up a list of free email ...

Ohh, that was inspirational. Let me free-associate some wild ideas. Suppose we keep a running average of the recent packet arrival rate, Lets say its 10 per millisecond ("typical" for a gigabit eth runnning flat-out). If we could poll the driver at a rate of 10-20 per millisecond (i.e. letting the OS do other useful work for 0.05 millisec), then we could potentially service the card without ever having to enable interrupts on the card, and without hurting latency. If the packet arrival ...

hrtimer worked fine on the powerpc cell arch last summer. Heh. Do the math. Even on 1gigabit cards, that's not enough: (1gigabit/sec) x (byte/8 bits) x (packet/1500bytes) x (sec/1000 jiffy) is 83 packets a jiffy (for big packets, even more for small packets, and more again for 10 gigabit cards). So polling once per jiffy is a latency disaster. --linas -

On Fri, 24 Aug 2007 22:03:42 +0200 Every single one of them is wrong. The encoding of iomap values is Agreed entirely -

Why, if you know it's surely a mem region (and thus you rely on it and do ioremap)? There are many places in the kernel, where this approach is used, e.g. at least get rid of the reading the hwbase address from pci conf space, use pci_resource_start instead. -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University -

Heh, it doesn't seem like -stable material to me, but if there aren't any screams while it sits in -mm, maybe it's 2.6.23 material. Jeff -- Work email - jdike at linux dot intel dot com -

[ This looks non-urgent to me ] Without linux/pagemap.h, asm-generic/tlb.h is missing declarations of page_cache_release and release_pages. Signed-off-by: Jeff Dike <jdike@linux.intel.com> -- include/asm-generic/tlb.h | 1 + 1 file changed, 1 insertion(+) Index: linux-2.6.22/include/asm-generic/tlb.h =================================================================== --- linux-2.6.22.orig/include/asm-generic/tlb.h 2007-07-08 19:32:17.000000000 -0400 +++ ...

define pci_dma_flags_set_dmaflush() for sn-ia64 - it "borrows" bits from the direction argument (renamed "flags") to the dma_map_* routines to pass an additional "dmaflush" attribute. Also define routines to retrieve the original direction and attribute from "flags". Signed-off-by: Arthur Kepner <akepner@sgi.com> -- arch/ia64/sn/pci/pci_dma.c | 33 ++++++++++++++++++++++++--------- include/asm-ia64/sn/io.h | 22 ++++++++++++++++++++++ 2 files changed, 46 insertions(+), 9 ...

On Altix, DMA may be reordered within the NUMA interconnect. This can be a problem with Infiniband, where DMA to Completion Queues can race with data DMA. This patchset allows a driver to associate a memory region with a "dmaflush" attribute, so that writes to the memory region flush in-flight DMA, preventing the CQ/data race. There are three patches in this set: [1/3]: add pci_dma_flags_set_dmaflush() to pci interface [2/3]: redefine pci_dma_flags_set_dmaflush() for ...

Ah! good catch. I totally missed that get_monotonic_cycles was being So if I'm understanding this right, not taking a lock isn't an optimization (as the seq read lock code is almost the same), but a requirement (as this might be called while xtime_lock is held), correct? Otherwise: Acked-by: John Stultz <johnstul@us.ibm.com> thanks -john -

-- Exactly. The latency tracer uses this so no locks can be grabbed OK, will do and send a updated patch. I wasn't in the best state writing this patch in the wee hours of the night ;-) -- Steve -

The get_monotonic_cycles needs to produce a monotonic counter as output. Currently it uses cycles_last as the base to add the delta too. cycles_last only is the counter that was last measured and is cyclic in nature (not monotonic). This patch adds a cycle_raw to produce an accumulative counter. Unfortunately there is already an cycle_accumulate variable, but that is used to avoid clock source overflow and can also be decremented (probably that name should be changed and we should use that for ...

Hi all, Here is a list of some known regressions in 2.6.23-rc3 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Adrian Bunk 9 Andi Kleen 5 Linus Torvalds 5 Andrew Morton 4 Al Viro 3 Alan Stern ...

Try with the latest kernel from GIT; maybe that cpufreq thing (since reverted) was a factor. -

Hi all, Here is a list of some known regressions in 2.6.23-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Adrian Bunk 9 Andi Kleen 5 Linus Torvalds 5 Andrew Morton 4 Al Viro 3 Alan Stern 3 Cornelia ...

First off, thanks so much for tracking these, it can't be an easy job, Last I heard was that Tino was going to try to do further testing, but as he hasn't responded in a few weeks, I'd mark this one down to, "unknown and unreproducable". Unless someone else knows more? thanks, greg k-h -

Parag, thanks. I reproduced this bug with your kernel config on 2.6.23-rc3 and verified it does not happen on latest git. I inspected memory after the crash and determined the problem was patching of instructions went awry. Chris in the meantime fixed a bug with patching instructions, and the change from 100% apocalyptic failure to 100% unequivocal success has convinced me that was the same bug. Zach -

Hi all, Here is a list of some known regressions in 2.6.23-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Adrian Bunk 9 Andi Kleen 5 Linus Torvalds 5 Andrew Morton 4 Al Viro 3 Alan Stern 3 Cornelia ...

Thomas Meyer, The commit just adds the pinconfigs which Mac OS X and win32 use for the Intel Macs (intel hda audio with the Sigmatel STAC9221 codec). For me "Master" works fine with the speakers/headphones plugged in. The volume of the internal speakers is bound to "Front" in the mixer (can also be controled by "PCM"), but does not react to the "Master". I've just thought this is by design - one can maintain two volume sets for the internal speakers and the external speakers. I am ...

There are several files that: #include "linux/file" not #include <linux/file> #include "asm/file" not #include <asm/file> Here's the little script that converted them: egrep -i -r -l --include=*.[ch] \ "^[[:space:]]*\#[[:space:]]*include[[:space:]]*\"(linux|asm)/(.*)\"" * \ | xargs sed -i -e 's/^[[:space:]]*#[[:space:]]*include[[:space:]]*"\(linux\|asm\)\/\(.*\)"/#include <\1\/\2>/g' Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Christoph Lameter <clameter@sgi.com> Acked-by: ...

They are the same, but they do not identify the files containing the dead var. It may be worth to just "grep back" in kernel sources for the dead symbol to readd this feature, but it may be slower that way. The difference is that since I find symbols together with file name, I cannot use uniq but I must use that awk script. Anyway, do we agree that a script for this should be probably merged in kernel sources? ___________________________________ L'email della prossima ...

No, I don't. I just basically hardcoded my nbd-client to do a 6 second timeout by default, but Wouter will probably want to do something a little less hackish for the official nbd-client. -- Paul -

Hi Paul, Thanks for implementing this! Do you happen to have an associated nbd-client patch for userspace? If not I'd be happy to coordinate with you and Wouter on a patch. regards, Mike -

This patch allows NBD I/O to be cancelled when a network outage occurs. Previously, I/O would just hang, and if enough I/O was hung in nbd, the system (at least user-level) would completely hang until a TCP timeout (default, 15 minutes) occurred. The patch introduces a new ioctl NBD_SET_TIMEOUT that allows a transmit timeout value (in seconds) to be specified. Any network send that exceeds the timeout will be cancelled and the nbd connection will be shut down. I've tested with various ...

On Fri, 24 Aug 2007 20:53:03 +0400 It's not completely clear who "maintainers" refers to when it comes to this fyi, with a little rework I queued these changes behind Akinobu Mita's cpu-hotplug ...

We could update CodingStyle, but it's still just a guideline, diff -p output is preferred for diffs (for review). Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

Sorry, I'll let the gurus speak then ;) regards, Benoit -

The box runs stable for days on end. Only when running gpg --gen-key I get this issue. Other gpg operations, run by a user, are without issue. There is 512MB of RAM and the hardware is `refreshed` regularly when an interesting VIA board comes out. Case stays closed otherwise. I am ESD certified. (or how to put that in the english language) memtest86 shows no problems. Kernel compiles etc run without issue. F7 upgraded installation. Updated regularly. gnupg rpm is Red Hat-stock. My own ...

That comes from the fact that the KVA in x86 has traditionally been mapped with huge pages where at all possible, for performance reasons. The purpose of the remap itself always has been performance based, we are remapping node-local memory into KVA to hold the memmap in part to exploit locality of process to its memory, and to in part to distribute the load on the NUMA memory infrastructure by "striping" the storage. As a result it makes sense to map these remapped areas with huge pages also. ...

Not in this case. memmap is allocated node local and mapped in the virtual memory area normally occupied by the end of low memory. The objective was to have memmap for the struct pages node-local. Hence, portions of I'll have to take your word for it because I haven't looked closely enough. I'll try and find time to look at it but the earliest I'll get around to it is post kernel-summit. In the meantime, SPARSEMEM works. -- Mel Gorman Part-time Phd Student Linux ...

The KVA acronym is being used in the x86 discontig code. The terms direct or linear mappings are not perfectly accurate either because the direct mappings are being altered in a way that pages that would normally be in Other than the fact that the memmap must be PMD aligned to use hugepage entries for the memmap. It could be mapped with small pages in corner cases I can't see this type of lifting being done any time soon. As SPARSEMEM works and there is hope with the vmemmap work that ...

Ok, but that still doesn't mean it has to be PMD aligned, as long as illegal virtual aliases are prevent in the overlap Ok, so we disable DISCONTIG i386 NUMA because there's nobody willing to maintain it? I'll take your word SPARSEMEM works, although I was told DISCONTIG NUMA works too and then my testing told a quite different story. -Andi -

You don't need to map it with small pages in the normal case, the only requirement is that c_p_a() is aware of it so it can It's a trivial change, probably less code than your original patch. -Andi -

Hello lists, I am currently working on a FUSE-based filesystem much like nfs/sshfs. I pass the syscall on to the storage server, where it is executed, and get back the result, or errno code. Let's jump into the real world example where the storage unit is x86_64 and the mount side is sparc/sparc64, and the syscall is getxattr. If a file does not have the requested attribute, the syscall will produce ENODATA. On x86_64, that is mapped to the value 61. Back on the sparc side, 61 is ...

On Fri, Aug 24, 2007 at 06:24:48PM +0200, Jan Engelhardt wrote: I'd think that passing the raw error code is a bad idea, and that you probably want to have your own set of codes that you use in the trasport and I wouldn't - Linux on different different architectures seems to have It would break userspace :-/ Josef 'Jeff' Sipek. -- *NOTE: This message is ROT-13 encrypted twice for extra protection* -

I just got: Building modules, stage 2. MODPOST 414 modules ERROR: "scsi_normalize_sense" [drivers/md/dm-rdac.ko] undefined! make[1]: *** [__modpost] Error 1 Presumably DM_MULTIPATH_RDAC needs to depend on SCSI (not enabled here) since it uses scsi_normalize_sense. -- Martin Michlmayr http://www.cyrius.com/ -

I do agree that the following patch would be needed. Since the rdac hardware handler is for a scsi device, including it without SCSI would not achieve anything (as his device won't be visible in the first place). Hence my question. -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sekharan@us.ibm.com | .......you may get ...

This patch export i386 smp_call_function_mask() with EXPORT_SYMBOL(). This function is needed by KVM to call a function on a set of CPUs. arch/i386/kernel/smp.c | 7 +++++++ include/asm-i386/smp.h | 9 +++------ 2 files changed, 10 insertions(+), 6 deletions(-) Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

Hi, Andrew, Here's version 7 of the memory controller (against 2.6.23-rc2-mm2). I was told "7" is a lucky number, so I am hopeful this version of the patchset will get merged ;) The salient features of the patches are a. Provides *zero overhead* for non memory controller users b. Enable control of both RSS (mapped) and Page Cache (unmapped) pages c. The infrastructure allows easy addition of other types of memory to control d. Provides a double LRU: global memory pressure causes reclaim ...

From: Pavel Emelianov <xemul@openvz.org> Changelog for v5 1. Remove inclusion of memcontrol.h from mm_types.h Changelog As per Paul's review comments 1. Drop css_get() for the root memory container 2. Use mem_container_from_task() as an optimization instead of using mem_container_from_cont() along with task_container. Basic setup routines, the mm_struct has a pointer to the container that it belongs to and the the page has a page_container associated with it. Signed-off-by: ...

Choose if we want cached pages to be accounted or not. By default both are accounted for. A new set of tunables are added. echo -n 1 > mem_control_type switches the accounting to account for only mapped pages echo -n 3 > mem_control_type switches the behaviour back Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> --- include/linux/memcontrol.h | 9 ++++ mm/filemap.c | 2 mm/memcontrol.c | 92 +++++++++++++++++++++++++++++++++++++++++++++ ...

Changelog for v6 1. Do a css_put() in the case of a race in allocating page containers (YAMAMOTO Takashi) Changelog for v5 1. Rename meta_page to page_container 2. Remove PG_metapage and use the lower bit of the page_container pointer for locking Changelog for v3 1. Fix a probable leak with meta_page's (pointed out by Paul Menage) 2. Introduce a wrapper around mem_container_uncharge for uncharging pages mem_container_uncharge_page() Changelog 1. Improved error ...

Changelong 1. use depends instead of select in init/Kconfig 2. Port to v11 3. Clean up the usage of names (container files) for v11 Setup the memory container and add basic hooks and controls to integrate and work with the container. Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> --- include/linux/container_subsys.h | 6 + include/linux/memcontrol.h | 21 ++++++ init/Kconfig | 7 ++ mm/Makefile | 1 mm/memcontrol.c ...

or added to Documentation/SubmitChecklist. How does this script compare to http://www.fsdev.net/wiki/index.php?title=Misspelled_CONFIG_variables and http://www.fsdev.net/wiki/index.php?title=Dead_CONFIG_variables --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

i've uploaded the -v20.3 CFS backport patches, which includes a handful of other (small) fixes as well, two of which could improve interactivity corner-cases. It can be picked up from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ Ingo -

Linus, please pull the latest scheduler git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git It includes 8 commits, 3 of which are important: the most important change is a bugfix to the new task startup penalty code. This could explain the task-startup unpredictability problem reported by Al Boldi. Then there's also a change/tweak that increases the default granularity: it's still well below human perception so should not be noticeable, but servers ...

Hi all, Support for NUMA has been there in Linux Kernel from years. Here comes the initial set (long delayed) of NUMA Test-cases from LTP and written by sivakumar.c@in.ibm.com. You can download a copy of LTP Suite containing NUMA-testcases from: http://prdownloads.sourceforge.net/ltp/ltp-nightly-snapshot_numa.tgz?download We request you to comment on the effectiveness/coverage of these testcases and help us contribute to the same. Your suggestions/corrections are extremely valuable and ...

Sounds exactly like the default netperf TCP_RR test and any number of other benchmarks. The "send a request, wait for reply, send next request, etc etc etc" is a rather common application behaviour afterall. rick jones -

From: David Stevens <dlstevens@us.ibm.com> This is one of many reasons why hardware interrupt mitigation is really needed for this. -

From: Jan-Bernd Themann <ossthema@de.ibm.com> Indeed, this is the "who should manage the list" problem. Probably the answer is that whoever transitions the NAPI_STATE_SCHED bit from cleared to set should do the list addition. This is why minimal levels of HW interrupt mitigation should be enabled in your chip. If it does not support this, you will indeed need to look into using high resolution timers or other schemes to alleviate this. I do not think it deserves a generic core networking ...

Hi, I don't see how this should work. Our latest machines are fast enough that they simply empty the queue during the first poll iteration (in most cases). Even if you wait until X packets have been received, it does not help for the next poll cycle. The average number of packets we process per poll queue is low. So a timer would be preferable that periodically polls the queue, without the need of generating a HW interrupt. This would allow us to wait until a reasonable amount of packets ...

Yes, that was one idea as well. But the problem with that is that net_rx_action will call the same poll function over and over again in a row if there are no further network devices. The problem about this approach is that you always poll just a very few packets each time. This does not work with LRO well, as there are no packets to aggregate... So it would make more sense to wait for a certain time before trying it again. Second problem: after the jiffies incremented by one in ...

Stephen Hemminger <shemminger@linux-foundation.org> wrote on 08/24/2007 have expired. For generic hardware that doesn't support it, couldn't you use an estimater and adjust the timer dynamicly in software based on sampled values? Switch to per-packet interrupts when the receive rate is low... Actually, that's how I thought NAPI worked before I found out otherwise (ie, before I looked :-)). The hardware-accelerated one is essentially siloing as done by ancient ...

From: James Chapman <jchapman@katalix.com> It interacts quite excellently. There was a long saga about this with tg3 and huge SGI numa systems with large costs for interrupt processing, and the fix was to do a minimal amount of interrupt mitigation and this basically cleared up all the problems. Someone should reference that thread _now_ before this discussion goes too far and we repeat a lot of information and people like myself have to stay up all night correcting the misinformation ...

Here's part of the thread: http://marc.info/?t=111595306000001&r=1&w=2 Also, Jamal's paper may be of interest - Google for ""when napi comes to town". -- Arthur -

Hi, when I tried to get the eHEA driver working with the new interface, the following issues came up. 1) The current implementation of netif_rx_schedule, netif_rx_complete    and the net_rx_action have the following problem: netif_rx_schedule    sets the NAPI_STATE_SCHED flag and adds the NAPI instance to the poll_list.    netif_rx_action checks NAPI_STATE_SCHED, if set it will add the device    to the poll_list again (as well). netif_rx_complete clears the NAPI_STATE_SCHED.    If an ...

I've just built a new machine using a ASUS M2A-VM boardboard (ATI SB600 chipset), AMD X2 3800+ processor, and 2 Western Digital 2.5" 80Gb drives running in RAID-1 using MD. I've had these problems with both 2.6.22.1 and now 2.6.22.5 kernels. I'm getting the following errors on occasion: Aug 24 13:19:22 playpbx kernel: APIC error on CPU0: 00(40) Aug 24 13:19:33 playpbx kernel: APIC error on CPU0: 40(40) Aug 24 13:20:01 playpbx last message repeated 5 times Aug 24 13:20:54 playpbx last message ...

Kconfig and Makefile for TOMOYO Linux. TOMOYO Linux is placed in security/tomoyo . Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- security/Kconfig | 1 + security/Makefile | 1 + security/tomoyo/Kconfig | 18 ++++++++++++++++++ security/tomoyo/Makefile | 3 +++ 4 files changed, 23 insertions(+) --- linux-2.6.orig/security/Kconfig 2007-08-23 21:25:12.000000000 +0900 +++ ...

Just a trivial minor nitpick - IMHO this breaks bisectability. It might be better to add the Kconfig/Makefile patch at the end of the whole series, so that bisect doesn't end up in the tree in which Makefile references non-exsting files/directories. -- Jiri Kosina -

Domain transition functions for TOMOYO Linux. Every process belongs to a domain in TOMOYO Linux. Domain transition occurs when execve(2) is called and the domain is expressed as 'process invocation history', such as '<kernel> /sbin/init /etc/init.d/rc'. Domain information is stored in task_struct->security. Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- security/tomoyo/domain.c | 1291 ...

argv[0] check functions for TOMOYO Linux. If the executed program name and argv[0] is different, TOMOYO Linux checks permission. Each permission can be automatically accumulated into the policy of each domain using 'learning mode'. Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- security/tomoyo/exec.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 230 insertions(+) --- ...

Data structures and prototype defitions for TOMOYO Linux. Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- security/tomoyo/include/realpath.h | 44 +++ security/tomoyo/include/tomoyo.h | 516 +++++++++++++++++++++++++++++++++++++ 2 files changed, 560 insertions(+) --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/security/tomoyo/include/realpath.h 2007-08-24 15:51:34.000000000 +0900 @@ -0,0 +1,44 ...

LSM expansion for TOMOYO Linux. LSM hooks for sending signal: * task_kill_unlocked is added in sys_kill * task_tkill_unlocked is added in sys_tkill * task_tgkill_unlocked is added in sys_tgkill LSM hooks for network accept and recv: * socket_post_accept is modified to return int. * post_recv_datagram is added in skb_recv_datagram. You can try TOMOYO Linux without this patch, but in that case, you can't use access control functionality for restricting signal transmission and ...

This patch makes access logs sent to auditing subsystem. TOMOYO Linux uses two channels for auditing. One is 'AUDIT_TMY_GRANTED', used for auditing accesses which are granted in the TOMOYO Linux policy. The other is 'AUDIT_TMY_REJECTED', used for auditing accesses which are not granted in the TOMOYO Linux policy. Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- include/linux/audit.h | 3 ++ ...

LSM wrapper functions for TOMOYO Linux access control. If bind mounts are used, TOMOYO requires all permissions for all possible pathnames (whereas AppArmor requires one of possible pathnames). If "struct vfsmount" is passed to LSM hooks as AppArmor proposes, this file will become more simpler and "namespace_sem" can remain "static". Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- security/tomoyo/tomoyo.c | 745 ...

This patch allows administrators use conditional permission. TOMOYO Linux supports conditional permission based on process's UID,GID etc. and/or requested pathname's UID/GID. Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- security/tomoyo/condition.c | 680 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 680 insertions(+) --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ ...

could you first check whether CFS v20.3: http://people.redhat.com/mingo/cfs-scheduler/ is it still showing the same symptoms with rhythmbox? If yes, what kind of load of yours is typically causing the Rhythmbox skipping? x11perf? Ingo -

I don't think it's much related then (though I don't know its real implications) Willy -

Right, that will not match. You could add: alias pnp:dCTL0001 snd-sb16 to: /etc/modprobe.d/pnp or some other file in that directory. We may switch to acpi based module autoloading in the future and add "acpi:*" aliases to the modules intsead of the broken pnp alias hack. Just to check if that would work, can you please provide the output of: grep . /sys/bus/acpi/devices/*/modalias Thanks, Kay -

Not out-of-the-box, I guess. There are likely no aliases in the kernel modules which match the hardware for these old drivers. You could put them in a modprobe config file maybe. What's in the module? What does: /sbin/modinfo <kernel module name> | grep alias print? And what does the hardware say? What does: grep . /sys/bus/pnp/devices/*/id print? Kay -

Finish the rename of CONFIG_USB_OHCI to CONFIG_USB_OHCI_HCD, which started in 2005 (before 2.6.12-rc2). The patch in this message has not been applied yet; moreover, it is not something to fix afterwards. I've verified that no more instances of 'CONFIG_USB_[UOE]HCI\>' exist in the source tree. http://www.linux-mips.org/archives/linux-mips/2005-06/msg00060.html I'm also sending a script to detect undefined Kconfig variables in next patch. Thanks to my colleague Giuseppe Patanè for the ...

Hi, I'm still plugging away at fsblock slowly. Haven't really got around to to finishing up any big new features, but there has been a lot of bug fixing and little API changes since last release. I still think fsblock has merit, and even if a more extent-based approach ends up working better for most things. I think a block based one will still have its place (either along-side or underneath), and I think fsblock is just much better than buffer_heads. fsblock proper and minix port patches ...

Yes. They both will call __sigqueue_free(). But please note that __sigqueue_free() checks SIGQUEUE_PREALLOC, which is cleared by sigqueue_free(). IOW, when sigqueue_free() unlocks ->siglock, we know that it can't be used by collect_signal() from another thread. So we can clear SIGQUEUE_PREALLOC and free sigqueue. We don't need this lock around sigqueue_free() to prevent the race. collect_signal() can "see" only those sigqueues which are on list. IOW, when sigqueue_free() takes ->siglock, ...

Then just don't build this module if you are creating such a kernel :) Same thing goes for the existing blackberry charge driver too... thanks, greg k-h -

Update usbmon documentation, mentioning the "zero" (wildcard) bus. Possibly, in my first hunk, the 'either ... or ...' should be rephrased a bit to be expressed better. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Cc: USB development list <linux-usb-devel@lists.sourceforge.net> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Alan Stern <stern@rowland.harvard.edu> --- Documentation/usb/usbmon.txt | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff ...

sure. if no one has any objections, i have no problem with that. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== -

Hi, The following two patches make it possible to restore the memory state from a hibernation image with the help of a kernel different from the image one. The first patch adds the generic, platform independent code needed for that. The second patch implements the idea on x86_64. Greetings, Rafael -

What happens in case where both parts want to be at the same place? (Like kernel being restored is 4KB smaller, so that routines now collide?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

From: Rafael J. Wysocki <rjw@sisk.pl> Make it possible to restore a hibernation image on x86_64 with the help of a kernel different from the one in the image. The idea is to split the core restoration code into two separate parts and to place each of them in a different page.  The first part belongs to the boot kernel and is executed as the last step of the image kernel's memory restoration procedure.  It restores all of the image kernel's memory that has not been restored yet except for the ...

From: Rafael J. Wysocki <rjw@sisk.pl> Add the bits needed for supporting arbitrary boot kernels to the common hibernation code. To support arbitrary boot kernels, make it possible to replace the 'struct new_utsname' and the kernel version in the hibernation image header by some architecture specific data that will be used to verify if the image is valid and to restore the image. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> --- kernel/power/power.h ...

Hi, I noticed that DTR toggling doesn't work with the nozomi driver (TIOCMBIS/TIOCMBIC ioctls have no effect). This is a nuisance because that makes it hard to get the modem back in command mode. Attached patch adds a tty_ops->tiocmset function that makes it work. Should we also rip out the TIOCMBIS/TIOCMBIC handling in ntty_ioctl()? It doesn't seem to be used anyway. Patch is against 2.6.23-rc3-mm1, but not tested with that. I tested it with 2.6.18.4 and the pharscape.org ...

That's great, but you've ignored the second part of my mail. I'll Notice the problem now? :-) -

We should probably keep it that way. I don't see why anybody should be using __setup_param directly anyway, so this becomes a nice build-time error to flag such errant usage :-) Seriously speaking, though, we should probably just get rid of that wrong line. It's just an init.h-internal macro to be used by early_param and __setup, and because those are themselves empty when MODULE, there's no issues in removing the (unused, broken) __setup_param either. -

From: Andre Haupt <andre@finow14.de> Signed-off-by: Andre Haupt <andre@finow14.de> --- Index: linus/Documentation/SubmittingPatches =================================================================== --- linus.orig/Documentation/SubmittingPatches 2007-08-24 11:12:33.000000000 +0200 +++ linus/Documentation/SubmittingPatches 2007-08-24 11:13:51.000000000 +0200 @@ -126,7 +126,7 @@ without even being read. At a minimum you should check your patches with the patch style -checker prior to ...

REQUEST_IRQ is never used, so delete it. In the process get rid of the macro FREE_IRQ which makes the code unnecessarily difficult to read. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- diff -urNp linux-2.6.23-rc3-orig/drivers/isdn/sc/debug.h linux-2.6.23-rc3/drivers/isdn/sc/debug.h --- linux-2.6.23-rc3-orig/drivers/isdn/sc/debug.h 2007-07-09 08:32:17.000000000 +0900 +++ linux-2.6.23-rc3/drivers/isdn/sc/debug.h 1970-01-01 09:00:00.000000000 +0900 @@ -1,19 +0,0 @@ -/* ...

Hi Ingo, RT driver patch to eliminate in_atomic stack dump. The problem code was identified by Michael S. Tsirkin, and he suggested the fix. I adapted to use RT's _nort primitives- should work correctly in all configs. Thanks, Sven Fixes in_atomic stack-dump, when Mellanox module is loaded into the RT Kernel. From: Michael S. Tsirkin <mst@dev.mellanox.co.il> "Basically, if you just make spin_lock_irqsave (and spin_lock_irq) not disable interrupts for non-raw spinlocks, ...

perhaps i'm missing it, but it seems that the macro __setup_param is entirely superfluous: $ grep -rw __setup_param * include/linux/init.h:#define __setup_param(str, unique_id, fn, early) \ include/linux/init.h: __setup_param(str, unique_id, NULL, 0) include/linux/init.h: __setup_param(str, fn, fn, 0) include/linux/init.h: __setup_param(str, fn, fn, 1) include/linux/init.h:#define __setup_param(str, unique_id, fn) /* nothing */ $ or am i must misreading something ...

Superfluous how? It does different things depending on whether MODULE is defined or not. It's a good indicator of how often people use __setup_param() from module context though, given the complete mismatch of parameters. It's probably worth fixing that up at least. -

ah, you mean we should pick up an upstream fix for -rt? We'll do that and we'll pick up much more: all the other ~100 CFS commits that happened meanwhile. (Btw., there's no need to sign off on patch forwarding or backport requests - the signoff made me first believe this is some new patch.) Ingo -

Wonderful, I just did the same {-.-} (but then dropped the patch because it did not help my application at all, And using % pipe->buffers then? Jan -- -

The check if (task_pgrp_nr(p) != pgid) is almost always true, because pgid is a "virtual" pid and it is most often much smaller than the "real" pgrp id of any task (because pids are generated sequentially most of the time). This leads to the task's pgrp is always reset, even if it is not needed. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- kernel/sys.c | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/kernel/sys.c b/kernel/sys.c index ...

thanks, applied. Ingo -

I mean the error message is badly worded. That's bad C and the macro needs deletion a lot more than it needs an extra set of parens. Been chasing a heisen bug too long. Need sleep. Sorry. -sb -

in some code that does like: #define foo { a, b, c, \ d, e, f, g } ... int boo[] = foo; ... checkpatch.pl throws a fit: ERROR: Macros with complex values should be enclosed in parenthesis #10: FILE: ... +#define foo {a, b, c, d} perhaps the check should also allow {...} ? or ignore lists like this ... -mike -

I sent a reply accidentally only to Mike and not the list. I think the error message is wrong. That is really ugly code. Linux Kernel code believes in C not preprocessor tricks, so why would you need this? Who uses code like this, by the way? -sb -

the way we came across it was in code that hasnt been pushed to mainline yet ... we run the code on our tree however, there are plenty of cases in the tree right now ... a quick grep picks out sound/pci/ice1712/aureon.h as the first offender $ diff -Nu /dev/null ./sound/pci/ice1712/aureon.h | perl ./scripts/checkpatch.pl - ERROR: Macros with complex values should be enclosed in parenthesis #31: FILE: sound/pci/ice1712/aureon.h:28: +#define AUREON_DEVICE_DESC "{Terratec,Aureon ...

Hi, I got the following BUG in nfs_inode_add_request() when I was using eCryptfs on NFS. (Don't ask me why I was doing that) ------------[ cut here ]------------ kernel BUG at fs/nfs/write.c:387! invalid opcode: 0000 [#1] PREEMPT SMP Modules linked in: cbc md5 aes ecb blkcipher cryptomgr crypto_algapi ecryptfs nfs iscsi_tcp libiscsi scsi_transport_iscsi nfsd exportfs lockd nfs_acl sunrpc nbd md_mod dm_snapshot dm_mirror dm_mod video output CPU: 5 EIP: 0060:[<f90113e2>] Not ...

I recently sent off a fix for lazy vmalloc faults which can happen under paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a bit on fixing this. I neglected to notice that since the new call to flush the MMU update queue is called from the page fault handler, it can be pre-empted. Both VMI and Xen use per-cpu variables to track lazy mode state, as all previous calls to set, disable, or flush lazy mode happened from a non-preemptable state. I have no idea how to ...

Agree 100%. It is the lazy mode flush that might happen when preempt is enabled, but lazy mode is disabled. In that case, the code relies on per-cpu variables, which is a bad thing to do in preemtible code. This can happen in the current code path. Thinking slightly deeper about it, it might be the case that there is no bug, because the local lazy mode variables are only _modified_ in the preemptible state, and guaranteed to be zero in the non-preemtible state; but it was not clear ...

I'll look at this again on my next weekend and make the changes. If it exists I'd rather it functioned without issues. My initrds are created by gentoo's genkernel script, which places dmraid on them. I'm not sure if it supports autodetect or not. -

Ok, I confused it with that one, sorry. But as this is in the same area, some one needs to sort it all out :( thanks, greg k-h -

I thought this patch was rejected in the past as it broke other machines. thanks, greg k-h -

On Fri, 24 Aug 2007 11:55:59 +0900 ho hum. Below is the patch from Jan (which I'll now need to drop) which we are, in a rather haphazard manner, trying to get into some sort of working shape. Please discuss. From: Jan Beulich <jbeulich@novell.com> Fix http://bugzilla.kernel.org/show_bug.cgi?id=8187 The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from ...

No idea about the error, but isn't vfat torture of a dvd-ram? Don't they come preformated with UDF since it does wear leveling while vfat would very very quickly trash the part of the disk storing the FAT. -- Len Sorensen -

Hi, I agree with Chris on this point, it seems like this sort of detection (and reporting) should be a job for a user-space daemon, rather than polluting kernel code (and logs) with warning messages of this sort... I don't think the type of warning this patch yields is appropriate for kernel logs, nor do I think the kernel should be the entity to decide that this warning should be given. It _feels_ wrong. -- Regards, Tom Spink University of Edinburgh -

Added to include/asm-i386/cpufeature.h, which is also used by the x86_64 Possibly, but I don't know pci well enough to know for sure, so I'll let Done. Thanks again, sln -- ====================================================================== Mr. Shannon Nelson LAN Access Division, Intel Corp. Shannon.Nelson@intel.com I don't speak for Intel (503) 712-7659 Parents can't afford to be squeamish. -

Thanks, sln -- ====================================================================== Mr. Shannon Nelson LAN Access Division, Intel Corp. Shannon.Nelson@intel.com I don't speak for Intel (503) 712-7659 Parents can't afford to be squeamish. -

What's with these (KERN_INFO " " "...more strings"); ?? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

Rename the ioatdma.c file in preparation for splitting into multiple files, which will allow for easier adding new functionality. Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Acked-by: David S. Miller <davem@davemloft.net> --- drivers/dma/Makefile | 1 drivers/dma/ioat_dma.c | 828 ++++++++++++++++++++++++++++++++++++++++++++++++ drivers/dma/ioatdma.c | 828 ------------------------------------------------ 3 files changed, 829 insertions(+), 828 deletions(-) diff ...

Yes, feature bits need to be integrated with the other CPU-specific --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

Yep, will do. Thanks for the comments, sln -- ====================================================================== Mr. Shannon Nelson LAN Access Division, Intel Corp. Shannon.Nelson@intel.com I don't speak for Intel (503) 712-7659 Parents can't afford to be squeamish. -

Direct Cache Access (DCA) is a method for warming the CPU cache before data is used, with the intent of lessening the impact of cache misses. This patch adds a manager and interface for matching up client requests for DCA services with devices that offer DCA services. In order to use DCA, a module must do bus writes with the appropriate tag bits set to trigger a cache read for a specific CPU. However, different CPUs and chipsets can require different sets of tag bits, and the methods for ...

Take care of a bunch of little code nits in ioatdma files Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Acked-by: David S. Miller <davem@davemloft.net> --- drivers/dma/ioat_dma.c | 200 +++++++++++++++++++++++++++--------------------- 1 files changed, 111 insertions(+), 89 deletions(-) diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c index 55227d4..9a4d154 100644 --- a/drivers/dma/ioat_dma.c +++ b/drivers/dma/ioat_dma.c @@ -1,10 +1,10 @@ /* - * Copyright(c) ...

Add support for MSI and MSI-X interrupt handling, including the ability to choose the desired interrupt method. Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Acked-by: David S. Miller <davem@davemloft.net> --- drivers/dma/ioat_dma.c | 353 ++++++++++++++++++++++++++++++++------- drivers/dma/ioatdma.h | 12 + drivers/dma/ioatdma_registers.h | 6 + 3 files changed, 305 insertions(+), 66 deletions(-) diff --git a/drivers/dma/ioat_dma.c ...

As the HOWTO says: "The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and ...

Floating point operations are not allowed in the kernel. Often, when you think you are simply creating a constant, the compiler generates runtime code so you have to watch out for that as well. You can use "long long" for high precision math if necessary. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information ...

No need to cast the void pointer returned by kmalloc() in drivers/media/video/zoran_driver.c::v4l_fbuffer_alloc(). Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- drivers/media/video/zoran_driver.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/zoran_driver.c b/drivers/media/video/zoran_driver.c index 72a037b..bc2e5b3 100644 --- a/drivers/media/video/zoran_driver.c +++ b/drivers/media/video/zoran_driver.c @@ -347,10 +347,7 @@ ...

-- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -

vmalloc() returns a void pointer that we don't need to cast. This patch should clean this up in sound/oss/. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- sound/oss/midibuf.c | 4 ++-- sound/oss/pss.c | 6 +++--- sound/oss/sequencer.c | 4 ++-- sound/oss/sscape.c | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/sound/oss/midibuf.c b/sound/oss/midibuf.c index a40be0c..66f8a7f 100644 --- a/sound/oss/midibuf.c +++ ...

Righto, I'll take care of this. Jeff -- Work email - jdike at linux dot intel dot com -

Same -- vda -

Thank you for pointing that out. I plan to resend those patches that don't get picked up in about a week or so. I'll address this issue then (or if it does get picked up -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -

Jesper, Thanks for the patch. I've applied it to my latest tree and will ask Mauro to pull from it. The latest source is a bit different and has in fact a third cast which I've also removed. Thanks, -

vmalloc() returns a void pointer, so there's no need to cast its return value in mm/page_alloc.c::zone_wait_table_init(). Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- mm/page_alloc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6427653..a8615c2 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2442,7 +2442,7 @@ int zone_wait_table_init(struct zone *zone, unsigned long zone_size_pages) * To use this new ...

kmalloc() and friends return void*, no need to cast it. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- drivers/net/wireless/libertas/debugfs.c | 2 +- drivers/net/wireless/libertas/ethtool.c | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/libertas/debugfs.c b/drivers/net/wireless/libertas/debugfs.c index 715cbda..6ade63e 100644 --- a/drivers/net/wireless/libertas/debugfs.c +++ b/drivers/net/wireless/libertas/debugfs.c @@ -1839,7 ...

vmalloc() returns void*. No need to cast in drivers/isdn/hardware/eicon/platform.h::diva_os_malloc() Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Acked-by: Armin Schindler <armin@melware.de> --- drivers/isdn/hardware/eicon/platform.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/isdn/hardware/eicon/platform.h b/drivers/isdn/hardware/eicon/platform.h index 15d4942..8756ef1 100644 --- a/drivers/isdn/hardware/eicon/platform.h +++ ...

Three lines later: for (i=0; i < osst_max_dev; ++i) os_scsi_tapes[i] = NULL; This wants to be os_scsi_tapes = kcalloc(osst_max_dev, sizeof(struct osst_tape *), GFP_ATOMIC); Eike

There's no need to cast the, void *, return value of kmalloc() when assigning to a pointer variable. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- fs/jfs/jfs_dtree.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index c14ba3c..3f15b36 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -592,9 +592,7 @@ int dtSearch(struct inode *ip, struct component_name * key, ino_t * data, struct component_name ...

Thanks, but Jack Stone submitted the same patch a few weeks ago. It's already in the jfs git tree and the -mm kernel. Shaggy -- David Kleikamp IBM Linux Technology Center -

Ok, thank you for that feedback. I'll respin the patch with that change when I resubmit all the ones that don't get picked up (probably next week). -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -

[kv]alloc() return void *. No need to cast the return value. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- drivers/scsi/osst.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c index 08060fb..3ad9d49 100644 --- a/drivers/scsi/osst.c +++ b/drivers/scsi/osst.c @@ -1404,7 +1404,7 @@ static int osst_read_back_buffer_and_rewrite(struct osst_tape * STp, struct osst int dbg = debugging; #endif ...

The general kernel memory allocation functions return void pointers and there is no need to cast their return values. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- drivers/net/bsd_comp.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/net/bsd_comp.c b/drivers/net/bsd_comp.c index 202d4a4..88edb98 100644 --- a/drivers/net/bsd_comp.c +++ b/drivers/net/bsd_comp.c @@ -406,8 +406,7 @@ static void *bsd_alloc (unsigned char *options, int opt_len, int ...

I would do it like this: static int iphone_probe(struct usb_interface *intf, const struct usb_device_id *id) { struct usb_device *udev = interface_to_usbdev(intf); int rc; if (udev->actconfig->desc.bConfigurationValue != 3) { dbg(&udev->dev, "Calling set_configuration\n"); rc = usb_driver_set_configuration(udev, 3); } else { dbg(&udev->dev, "Configuration set, sending magic comand\n"); rc = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0x40, (USB_DIR_OUT | ...

Am Freitag 24 August 2007 schrieb Greg KH: int usb_driver_set_configuration(struct usb_device *udev, int config) { struct set_config_request *req; req = kmalloc(sizeof(*req), GFP_KERNEL); if (!req) return -ENOMEM; req->udev = udev; req->config = config; INIT_WORK(&req->work, driver_set_config_work); usb_get_dev(udev); schedule_work(&req->work); return 0; } This schedules the change via a workqueue, so you'll be reprobed. If you fire of the first vendor command you are ...

Yeah, that would make more sense, if that is what is needed. Can someone with a iphone test this out? If you look at how the berry_charge driver does it, the set_config stuff happens after the magic command. As I don't have an iphone, nor have I ever seen any dumps of the command streams, I don't really know if the set_config message really is necessary or not. thanks, greg k-h -

I thought so too, untill you look at the 2.6.22.5 release, which already has that change in it for some reason. So that part of the patch drops out, it turns out you just reverted things back to the way things used to be here :) thanks, greg k-h -

Odd. This doesn't include the entire patch; the second hunk is missing. It should go on to say: @@ -1109,10 +1113,12 @@ static void acm_disconnect(struct usb_interface *intf) return; } if (acm->country_codes){ - device_remove_file(&intf->dev, &dev_attr_wCountryCodes); - device_remove_file(&intf->dev, ...

On Fri, 24 Aug 2007 08:46:31 -0400 This one works too. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 -

On Thu, 23 Aug 2007 14:05:35 -0700 Using plain 2.6.23-rc3-g1a8f4610 and "nmi_watchdog=1" I've managed to capture a Kernel Panic (about 40 seconds after switching to hpet as clocksource): http://img170.imageshack.us/img170/1552/2hpetoopshw9.jpg it's stuck in "update_wall_time()". -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 -

Ok, since no one screamed too badly about this one, and it does fix this issue, I'm sending it out for reals. I think Bob's patch which addresses duplicate clocksources should go in, but this one is a little more forceful in keeping the wrong hpet clocksource from possibly being selected. Andrew, would you mind picking this up? thanks -john The ia64 hpet clocksource was implemented in generic code, and is not yet ready to replace the i386 and x86_64 implementations. This ...

Yea. While I'm still not completely comfortable leaving this up to boot order alone (the ia64 hpet clocksource is clearly causing issues on -

On Fri, 24 Aug 2007 09:04:22 -0700 100% agree -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 -

collect_signal() is always called under ->siglock which is also taken by sigqueue_free(), so this is not possible. Basically, this patch is the same one-liner I sent you before http://marc.info/?l=linux-kernel&m=118772206603453&w=2 (Thanks for the additional testing and report, btw). P.S. It would be nice to know if this patch solves the problems reported by Jeremy, but his email is disabled. Oleg. -

I know, using current->sighand->siglock to prevent one sigqueue is free twice. I want to know whether it is possible that the two function is called in different thread. If that, the spin_lock is useless. yue.tao -

look at the contents and you'll see why :-) Ingo -

thanks, applied. Ingo -

If you have a spare audio-card lying around or maybe a tv-card/webcam or so, give then: http://www.vanheusden.com/aed/ (for audio) http://www.vanheusden.com/ved/ (for video4linux) a try. And no, audio-entropyd won't fill up the entropy pool in a second, it takes a while. And often video-entropyd bails out because of not enough noise in the video-signal. Folkert van Heusden -- MultiTail er et flexible tool for å kontrolere Logfiles og commandoer. Med filtrer, farger, sammenføringer, ...

Applied thanks -Andi -

Sorry. No we do not need this fix. The patch is fine as is. In slab_alloc() the slow path is entered if c->lockless is NULL. So it does not matter for slow path determination that node_match always returns 1 in the !NUMA case. c->node only needs to be checked for slow path determination in slab_free(). And there the node_match is not called. -

So let's update CodingStyle once and for all so that doesn't pop up again. See attached patch (inline version is whitespace damaged - can't help it from my current location). As continuously gets pointed out, the 80 col line length defined in CodingStyle is not a hard limit in real life. Let the document reflect reality. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- --- Documentation/CodingStyle~ 2007-08-24 13:04:20.000000000 +0200 +++ Documentation/CodingStyle 2007-08-24 ...

It happens so often that people send mangled patches that it might be useful to create a wiki page or something with the most common email clients and a sample configuration that prevents them from mangling patches. Maybe somebody I think this is also a matter of conding style. Documentation/CodingStyle says: "The limit on the length of lines is 80 columns and this is a hard limit." So actually there shouldn't be any line longer than that. Perhaps it would be nice to create a patches ...

I too had thought about this problem. I think email clients do wordwrap to improve readability. But, in some cases we just might have to override. ( I had an experience of sending a malformed patch just because my wordwrap setting for vim and my email client were different) What should be ideally expected out of a good email client? Is it sufficient if the email client provides a facility to disable wordwrap while inserting file alone and does wordwrap while typing text? or is it expected to ...

Thank you. That explains the linear write curve(perfect!) in Chris' graph. I wonder if XFS can benefit any more from the general writeback clustering. How large would be a typical XFS cluster? -fengguang -

Do you have a pointer to the scanbuttond source code? I'll try to take a look at this tomorrow. thanks, greg k-h -

Right. The problem is that the memory never seems to get freed no matter what I do. I've tried setting /proc/sys/vm/vfs_cache_pressure to 10000, but after a few days all my programs are running out of swap and OK I just rebuilt 2.6.22.3 with SLAB and I seem to be getting the same result..obviously I haven't waited several days, but sysfs_dir_cache/dentry/inode_cache grow continuously when scanbuttond is Yes, I don't know enough to understand why this would affect sysfs_dir_cache, but ...

I can't see and subsystem ID. Since it is not on the few range of boards where we know other ways for detecting the board internals, there's no known way for auto-detecting your board. The solution for you is to add: options bttv card=65 into /etc/modprobe.conf (or /etc/modules.conf, or /etc/modules - depending on your distro). This way, every time the driver is loaded, the card=65 option will automatically be used by the bttv driver. -- Cheers, Mauro -

boot log with the andrew patch applied Welcome to yaboot version 1.3.13 Enter "help" to get some basic usage information boot: autobench Please wait, loading kernel... Elf64 kernel loaded... Loading ramdisk... ramdisk loaded at 02400000, size: 1191 Kbytes OF stdout device is: /vdevice/vty@30000000 Hypertas detected, assuming LPAR ! command line: ro console=hvc0 autobench_args: root=/dev/sda6 ABAT:1187885681 memory layout at init: alloc_bottom : 000000000252a000 alloc_top : ...

This indicates to me that the zonelists are trashed. All memory is on zone 2 according to early_node_map[] and the CPU is most likely part of -- -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -

OK, will try to keep an open mind... ;-) Thanx, Paul -

From: Randy Dunlap <randy.dunlap@oracle.com> Drop the URL for DCO (URL is invalid). Also, point to SubmittingPatches for the current DCO. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- MAINTAINERS | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- linux-2.6.23-rc3-git6.orig/MAINTAINERS +++ linux-2.6.23-rc3-git6/MAINTAINERS @@ -44,9 +44,10 @@ trivial patch so apply some common sense or does something very odd once a month document it. PLEASE remember ...

I currently object to becoming an SPI member due to a number of personal reasons at this point in time. thanks, greg k-h -

Because git only goes back to 2.6.12. josh -

As I said; what's wrong with just using SPI membership? It's not like it is remotely hard for kernel hackers to gain membership in SPI. And somebody else takes care of the bureaucracy for you. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -

My impression as an SPI member is that in practice most SPI members come from the SPI projects [1], and due to Debian's size Debian developers are the majority of SPI members. If you elect at KS it'll favor kernel developers. If you let all SPI members elect it'll favor Debian developers. The Linux Foundation homepage says "The Technical Advisory Board (TAB) provides the Linux kernel community a direct voice into The Linux Foundation’s activities...". If this is the intention, an ...

> How about one vote per git commit merged to linus' tree? So you think people who send hundreds of small typo fixes are worth more than say someone who spends 3 months writing a new driver and gets it in with one commit ? Curious.... And very gameable of course. James proposal at least has the advantage of simplicity, of drawing from a rough set of relevant people (far from perfectly) and a certain amount of random changeover according to the KS of the year I would make only one change ...

I don't think it's the /perfect/ organisation by any means, but let's consider the requirements: - Membership open to significant contributors to 'Linux' [1] - Has a voting process - Reasonably agnostic Maybe an organisation like Linux International could handle this too, I ran the election last year (by counting hands) and there was no weighting by contribution ;-) More important though is the expressed desire for the TAB to be more than kernel people. [1] Is Linux even the right ...

Given the huge overlap between SPI membership and Debian membership, and then taking a look at the craziness that takes place on various Debian mailing lists, such as but not limited to debian-legal, I'm quite convinced that this would be a baaaaaad idea. - Ted -

There's another alternative: and that's that we could use the voting mechanism of the LF itself. When the LF was formed, it inherited the individual affiliate members from the FSG (These members actually elect two of the board seats to the LF). We could simply use that pool as the electorate for the TAB ... of course, coming from the FSG it will be more user space centric. To be brutally frank, I couldn't give a toss about choosing the perfect representational system for the TAB election. ...

Ahh. Yes. I remember some of that. Acked-by: Christoph Lameter <clameter@sgi.com> -

Right. Lets make sure to cc Lee on future discussions of the memoryless node patchset. Acked-by: Christoph Lameter <clameter@sgi.com> -

This boots the IA-64 successful and gets rid of that DMA corrupts memory message. As a bonus, it fixes up the memoryless nodes (the bug where Total pages == 0 and there is a BUG in page_alloc.c) by building zonelists properly. The machine still fails to boot with the more familiar net/core/skbuff.c:95 but that is a separate problem. Well spotted Yasunori-san. Andrew, this fixes a real problem and should be considered a fix ...

This patch resolves the kernel panic problem. - Kamalesh Babulal. -

drop_caches YAMAMOTO Takashi -

It's a bit gross that the compiler is using inc here rather than lea or add, but still... Er, something's spending 30% of its time in memchr? This is not the code to fix. J -

Indeed. I'm just pointing out the general optimization of walking one counter instead of two. Hmm, perhaps the culprit is validate_nla? -- Mathematics is the supreme nostalgia of our time. -

Yes, very funny. -- Mathematics is the supreme nostalgia of our time. -

Grumble. Ok. This is a two sided bug. The NET_IRDA define as not put in sysctl.h where it belongs so I missed it, when making the list of all existing binary sysctls. So really I need to put update the sysctl_check tables to have the NET_IRDA numbers, because at least at first skim everything looks ok on the binary side. Patches to follow shortly. Eric -

3/2.6.23-rc3-mm1/ After applying Matthew Wilcox' patch to include/linux/isa.h this compiles= and boots on my Intel/openSUSE 10.2 test machine but throws out the following messages I don't remember ever seeing with other kernels: - on console early during boot, also in SuSE's /var/log/boot.msg: your system time is not correct: Wed Jul 13 13:15:31 UTC 1910 setting system time to: Tue Jul 24 00:00:00 UTC 2007 - later, dto. on console and in /var/log/boot.msg: FATAL: Error inserting ...

It turns out that the net/irda code didn't register any of it's binary paths in the global sysctl.h header file so I missed them completely when making an authoritative list of binary sysctl paths in the kernel. So add them to the list of valid binary sysctl paths. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- kernel/sysctl_check.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/kernel/sysctl_check.c ...

Grumble. These numbers should have been in sysctl.h from the beginning if we ever expected anyone to use them. Oh well put them there now so we can find them and make maintenance easier. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- include/linux/sysctl.h | 20 ++++++++++++++++++++ net/irda/irsysctl.c | 34 ++++++++++++++-------------------- 2 files changed, 34 insertions(+), 20 deletions(-) diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h index ...

That means that even when you specify noreplace_smp, some replacing takes place anyway. One of the consequences, besides noreplace_smp not working as expected, is that lguest crashes when you feed it an SMP kernel Hmm yes, my bad. Regards, Frederik -

This one is no longer neccessary. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Ok, ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -

Think you for your help. I reserved the first patch: http://lkm.org/lkml/2007/8/12/193 and applied the previous patch, running the test program again. Up to now, the test program has been running for more than one day. It seems likely that the patches avoid the race condition. yue.tao -

I suspect that this is not sufficient. The application should be prepared to rewrite data if it can determine what data did not get written. Using fsync will tell the application when data was not written to the server correctly, but not which part of the data. Perhaps O_SYNC or fsync following each write, but either one of these options will also cause a large performance degradation. The right solution is the use of TCP and hard mounting. ps -

Good. That stuff shouldn't have been a class in the first place. ADB is a bus type, not a class. -

Hi Rusty, Please tell me if I'm wrong, but I think it would not be a problem: - seq_read() makes sure that a buffer large enough is available so that m_show() can fully extract and print the information relative to 1 module. - m_start() and m_stop() takes the module_mutex, therefore within one seq_read(), once m_start has returned, the struct module * that we have is valid and will be consistent during the whole seq_read operation. - If a module is removed, and then a different ...

The same could have been achieved more simply: if (id->hw_config == 0 && (short}id->major_rev_num >= 0x0020 so I'll probably recast... MBR, Sergei -

I agree. 8250_pnp is actually fine -- it won't claim SMCf010 devices. The problem is that we have the legacy addresses (including the SMCf010 SIR range) in SERIAL_PORT_DFNS, so 8250.c claims the SIR range in serial8250_isa_init_ports(). I'm still hoping to fix that bit of 8250, but it's going to take some work. I'll post the SMCf010 quirk removal as a fix for the 2.6.23-rc3 regression. Bjorn -

How does that help? gdb should stop as easily on a "else foo;" line as on else foo; right? Jeff -- Work email - jdike at linux dot intel dot com -

Applied. thanks, -Len -

Good call, have changed the configuration accordingly. Thanks for the feedback all :) Cheers, Hugh -

As per recent discussions... The list is moderated for SPAM prevention, messages from valid senders will be forwarded manually and their email added to the whitelist. I've changed the list config so that it no longer generates the "subscriber-only" notification. On this basis I recommended the patch be NAKd so that people aren't put off copying the list where appropriate. Thanks, Regards, Hugh -

your original claim and these additional claims are both incorrect. What Mike said is true: there is nothing "missing", RT class tasks do not need any extra setup over what they already receive from the generic function. A NULL pointer for sched_class->task_new means: "do default setup, no class-specific setup needed". If you disagree with what we say then please send a fix-patch or quote the specific code that is missing something in your opinion. Ingo -

Sort modules list - use ppos instead of m->private When reading the data by small chunks (i.e. byte by byte), the index (ppos) is incremented by seq_read() directly and no "next" callback is called when going to the next module. Therefore, use ppos instead of m->private to deal with the fact that this index is incremented directly to pass to the next module in seq_read() after the buffer has been emptied. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> --- fs/seq_file.c ...

I think better name may help. Nuke atomic_read() altogether. n = atomic_value(x); // doesnt hint as strongly at reading as "atomic_read" n = atomic_fetch(x); // yes, we _do_ touch RAM n = atomic_read_uncached(x); // or this How does that sound? -- vda -

Hi Denys, in atomic_{read,set} myself, but frankly, at least personally speaking (now that I know better), I'm not so much in favour of implicit barriers (compiler, memory or both) in atomic_{read,set}. This might sound like an about-turn if you read my own postings to Nick Piggin from a week back, but I do agree with most his opinions on the matter now -- separation of barriers from atomic ops is actually good, beneficial to certain code that knows what it's doing, explicit usage of ...

To me, "atomic_read" means a read which is synchronized with other changes to the variable (using the atomic_XXX functions) in such a way that I will always only see the "before" or "after" state of the variable - never an intermediate state while a modification is happening. It doesn't imply that I have to see the "after" state immediately after another thread modifies it. Perhaps the Linux atomic_XXX functions work like that, or used to work like that, but it's counter-intuitive to me ...

I would agree that fixing the compiler in this case would be a good thing, even quite regardless of any "atomic_read()" discussion. I just have a strong suspicion that "volatile" performance is so low down the list of any C compiler persons interest, that it's never going to happen. And quite frankly, I cannot blame the gcc guys for it. That's especially as "volatile" really isn't a very good feature of the C language, and is likely to get *less* interesting rather than more (as ...

Not just P4 ... there are other threaded cpus where it is useful to let the core know that this is a busy loop so it would be a good thing to let other threads have priority. Even on a non-threaded cpu the cpu_relax() could be useful in the future to hint to the cpu that it could drop into a lower power hogging state. But I agree with your main point that the loop without the cpu_relax() looks like it ought to work because atomic_read() ought to actually go out and read memory each time ...

It doesn't mean that (volatile int*) cast is bad, it means that current gcc is bad (or "not good enough"). IOW: instead of avoiding volatile cast, Linus, in all honesty gcc has many more cases of suboptimal code, case of "volatile" is just one of many. Off the top of my head: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417 unsigned v; void f(unsigned A) { v = ((unsigned long long)A) * 365384439 >> (27+32); } gcc-4.1.1 -S -Os -fomit-frame-pointer t.c f: movl ...

Please don't make that a macro, make it a function. Otherwise it looks ok, care to fix that up and resubmit? -- Jens Axboe -

It doesn't send a complaint, it sends a useful note that your message is pending moderation. The rest appears to be your personal issue Matt, perhaps caused by not setting up smart enough mail filters ? -

Does your list generate a complaint message back to the sender if a non-subscriber posts to it? If so, it qualifies as a subscribers-only list. -- Mathematics is the supreme nostalgia of our time. -

And as I said, "does your list generate a complaint message back to the sender?" It's the moderation message that's the problem. -- Mathematics is the supreme nostalgia of our time. -

It's another waste of space in my inbox due to poorly-implemented software. If their mailman installation uses a whitelist, so I get *one* message per list rather than a bounce for every message I send, then that's somewhat acceptable. If I get mailbombed just for participating in a thread on lkml, that's definitely not acceptable (and I will remove such lists from the Cc). It would be vastly better if mailman were smart enough to autoapprove threaded replies -- it's not as if the ...

Yeah, I was thinking about elevators :) It's meaningless to convert s_io to radix tree. Because inodes on s_io will normally be sent to block layer elevators at the same time. Also s_dirty holds 30 seconds of inodes, while s_io only 5 seconds. The more inodes, the more chances of good clustering. That's the general rule. s_dirty is the right place to do address-clustering. As for the dirty_expire_interval parameter on dirty age, we can apply a simple rule: do one full scan/sweep over ...

ok. I think i might finally have found the bug causing this. Could you try the fix below, does your webserver thread-startup test work any better? Ingo ---------------------------> Subject: sched: fix startup penalty calculation From: Ingo Molnar <mingo@elte.hu> fix task startup penalty miscalculation: sysctl_sched_granularity is unsigned int and wait_runtime is long so we first have to convert it to long before turning it negative ... Signed-off-by: Ingo Molnar ...

Hmmm, it's either the driver or device. Please uncomment the "#define DUMP_PACKETS" in line 58 of sound/usb/usbmidi.c and recompile the driver. All MIDI data should then be visible in the system log. Regards, Clemens -

Amen. -- vda -

IMHO, this should be fixed by last changes to free_irq & request_irq. (Seems to be possible only with CONFIG_DEBUG_SHIRQ?) Otherwise I can be CC-ed - my pleasure! Cheers, Jarek P. -

So, this time I f-ed the diff part: it's not exactly against 2.6.23-rc-git6. But, it's Andrew to blame: he should've known that some old & slow chips can't do science and poetry at the same time. Sorry (for him)! Anyway, beside an offset, should be OK... Regards, Jarek P. -