subscribe linux-kernel --

Fixed a warning caused by a badly placed ifdef. Signed-off-by: Steven Noonan <steven@uplinklabs.net> --- include/asm-x86/dma-mapping.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index a072ae6..8bb3108 100644 --- a/include/asm-x86/dma-mapping.h +++ b/include/asm-x86/dma-mapping.h @@ -255,9 +255,9 @@ static inline unsigned long dma_alloc_coherent_mask(struct device *dev, static inline gfp_t ...

From: Alain Knaff <alain@knaff.lu> This is an updated version of my bzip2/lzma patch It is based on an idea by Christian Ludwig, includes support for compressing the kernel with bzip2 or lzma rather than gzip. Both compressors give smaller sizes than gzip. Lzma's decompresses faster than bzip2. It also supports ramdisks and initramfs' compressed using these two compressors. The functionality has been successfully used for a couple of years by the udpcast project This version applies ...

From: Alain Knaff <alain@knaff.lu> This is an updated version of my bzip2/lzma patch It is based on an idea by Christian Ludwig, includes support for compressing the kernel with bzip2 or lzma rather than gzip. Both compressors give smaller sizes than gzip. Lzma's decompresses faster than bzip2. It also supports ramdisks and initramfs' compressed using these two compressors. The functionality has been successfully used for a couple of years by the udpcast project This version applies ...

Hello Linus, some time ago I sent two patch scripts to LKML that changed the MAINTAINERS file. One fixed the alphabetic ordering and another merged the P and M fields to ease copy'n'paste. See http://thread.gmane.org/gmane.linux.kernel/702194 for the details. I still like both changes, but I think it's not sensible to send you the resulting patches because MAINTAINERS changes frequently. If you like these two changes, too, I would be happy if you run the attached script in your ...

1) nf_conntrack_sip has a local variable marked static unintentionally, for a function callable in parallel by multiple threads this is very bad. Fix from Alexey Dobriyan. 2) GRE conntrack module's keymap list has bad locking leading to OOPS. Fix by Alexey Dobriyan. 3) GRE conntrack module kfree()'s list head member of structure instead of structure itself, yikes... Fixed by Alexey Dobriyan. 4) Potential remote exploit issue, IRC conntrack module blindly parses strings ...

Overview This patch reworks the handling of POSIX CPU timers, including the ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together with the help of Roland McGrath, the owner and original writer of this code. The problem we ran into, and the reason for this rework, has to do with using a profiling timer in a process with a large number of threads. It appears that the performance of the old implementation of run_posix_cpu_timers() was at least O(n*3) (where "n" is the number ...

That looks OK, but rather than copying it, why not move the definition into pgtable.h? Isn't it identical for all pagetable modes? --

Main thing is Alan's commit, rightly taking me to task, and cleaning up the mess in the Marvell dual-mode controller (legacy or AHCI) case. Plus some new ids and fixes from Tejun (see commits for more info). Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git upstream-linus to receive the following updates: drivers/ata/Kconfig | 6 +++- drivers/ata/ahci.c | 21 +++++++++++++++++- drivers/ata/libata-sff.c ...

Sam: Is there a reason cc-option and friends use -S instead of -c? -hpa --

Linus, Please pull the latest x86-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus Thanks, -hpa ------------------> H. Peter Anvin (1): x86: prevent binutils from being "smart" and generating NOPLs for us Jeremy Fitzhardinge (1): xen: fix 2.6.27-rc5 xen balloon driver warnings Linus Torvalds (1): x86: disable static NOPLs on 32 bits arch/x86/Kconfig.cpu | 13 ++++++++----- ...

Oh bloody hell... cc-option = $(call try-run,\ $(CC) $(KBUILD_CFLAGS) $(1) -S -xc /dev/null -o "$$TMP",$(1),$(2)) Note the -S. Useless for anything related to the assembler. /me wimpers... -hpa --

What you can do it increase the /proc/sys/kernel/sched_shares_ratelimit value and thereby decrease the accuracy of the SMP fairness of the group scheduler. --

Hmm. The only other thing seems to be X86_INTEL_USERCOPY. Which doesn't seem to be something we want to force either. And I have to say, that whole X86_GENERIC -> L1_CACHE_BYTES=128 -> cache_line_size() -> SLAB/SLUB/SLOB alignment worries me too. Looking at that, I really don't feel like I want to force 128-byte alignment on everybody, just because the P4 was a pig in cacheline size. So NOPL really stands out as being different from the other things that X86_GENERIC ...

On Tue, 09 Sep 2008 01:17:19 +0200 so your cpu does not fall into this bucket...... no big deal. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

SLAB/SLUB should actually auto detect the cache line at runtime. Similar feeling here. -Andi -- ak@linux.intel.com --

agreed - especially the verify_area() impact makes it a non-starter. but 486 and higher is certainly quite reasonable, and is still being tested. ... and _in practice_ 99% of all systems that run Linux today understand CMOV. ... _and_ in practice 99% of all new Linux systems shipped today are Core2 or better. ... and so on it goes with this argument. Everyone has a different target audience and there's no firm limit. Maybe what makes more sense is to have some sort of time ...

Support all from the last 10 years (ok excluding legacy models that just shipped forever like 486). I think that's quite reasonable to do and worked for a long time. -Andi -- ak@linux.intel.com --

VIA C3 (Samuel 2/Ezra, 600 - 1000 MHz?, common on VIA EPIA-*: home theatres etc) can't CMOV. -- Krzysztof Halasa --

As far as I can tell, -Wa,-mtune=generic *should* work. It doesn't look to me as if cc1 will generate the long NOPs. That one we can do Well, the argument in favour would be that if you want a kernel that can cross between different microarchitectures, then you want the "don't suck horribly on any of them". We can, of course, divide them down further, but is it useful? The "ideal" way to do any of this would probably to have checkboxes for all the CPUs you want to support and ...

We (the -stable team) are announcing the release of the 2.6.26.5 kernel. It fixes the build error introduced in 2.6.26.4 due to me applying a stale patch to the tree. Thanks to David Miller for providing the correct patch and Randy Dunlap for pointing out my error. I'll also be replying to this message with a copy of the patch between 2.6.26.4 and 2.6.26.5 The updated 2.6.26.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.26.y.git and ...

From: Randy Dunlap <randy.dunlap@oracle.com> For kernel bugzilla #11425: http://bugzilla.kernel.org/show_bug.cgi?id=11425 Release memory on init failure. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Reported-by: Daniel Marjamäki <danielm77@spray.se> cc: tpmdd-devel@lists.sourceforge.net --- drivers/char/tpm/tpm.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) --- linux-next-20080905.orig/drivers/char/tpm/tpm.c +++ ...

applied to tip/sched/cpu-hotplug - thanks Manfred, nice cleanup. (FYI, i fixed up the 3 problems that checkpatch reported) David, can you see any problems with the Sparc32 bits? Ingo --

Easiest and cleanest way for the dmi_system_id arrays is probably the attached patch. There are two downsides though: 1. It makes the inital kernel image bigger than needed (even if the memory itself is freed later) 2. We have to make sure, that the string lengths fit into the given array limits (else you get the compiler warning "initializer-string for array of chars is too long") I haven't tested how much memory this really saves. please CC me on replies! ---------- Patch: ...

Ok, I committed v0.31.1. Thanks for noticing! Josef 'Jeff' Sipek. -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw --

From: James Bottomley <James.Bottomley@HansenPartnership.com> It's in my sparc next tree: That's not what I do, I use the real RAW chip drivers provided by the RTC layer. That's the way to do this. I think the powerpc folks did the wrong thing and should just register generic platform_device objects in their platform code, and let the RTC layer drive the individual devices in response. All the powerpc folks are doing is providing a dummy shim into the RTC layer using their machine ...

But realistically that's all we need. Our RTC is controlled by two calls into firmware: a get and a set; nothing else. We don't have the docs to get at the clock without the firmware calls. James --

Preventing them from doing stupid stuff is exactly why we have Kconfig prevent both legacy *AND* framework RTC code from being selected. :) Of course stupidity is infinite, and we didn't know about I'd worry if "the mean time" takes too long. But lacking a Well, previously there was no override ... I think you mean that parisc just completely ignored RTC_CLASS, treating it like junk DNA. - Dave --

Folk have been migrating already. IMO there's no rush ... but similarly, retrograde motion should be discouraged. (Same issue The same benefit always found in sharing infrastructure. Lots of little differences/bugs go away. Infrastructure improvements and bugfixes get leveraged. Dead and crufticious code can vanish. So you affirmed that there was no override, AND that it was previously treated as junk DNA (ignored). So just what were you disagreeing with me about?? I have a hard ...

From: David Brownell <david-b@pacbell.net> I absolutely and positively agree with David here. I just last week converted all of both sparc ports to the generic RTC layer and what a huge burdon has been moved off of my shoulders. The RTC layer is very nice and it even allows writing drivers for very simplistic RTC devices (even ones that cannot be written) with ease. I had two such cases to handle on sparc64. --

Yes, but think of distro config people rather like users ... if you can prevent them from doing something stupid, it's a good idea. In this case, there's currently no way anyone should ever select RTC_CLASS on OK, I can look at that, but in the mean time could we make the option that causes the damage unselectable? This is technically a regression because before your patch GEN_RTC would override RTC_CLASS, now it's the other way around. James --

True for PARISC ... but not for PowerPC. Lots of PowerPC system boards use off-the-shelf RTCs with more capabilities than the machine description vector acknowledges. - Dave --

Do not use KERN_DEBUG several times on the same line being printed. Introduced by mine previous patch, sorry. Reported-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/io_apic.c =================================================================== --- linux-2.6.git.orig/arch/x86/kernel/io_apic.c 2008-09-08 19:32:34.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/io_apic.c 2008-09-08 19:34:10.000000000 ...

If there is coming more funtionality, ok, but currently it's irritating to Yeah, the dprintk()s are ok, but I was after the printk()s that follow. Guess I picked a bad example... There are some in the code that are Yeah, but in nearly all cases you don't need to change anything in that line, when you use sizeof(*ptr), because it always gets you the correct size you want. There are cases we could argue about, because you might want to do a limited memset() or memcpy() with a ...

Hi. I am pleased to announce new Distributed Storage (DST) project release. DST is a block layer network device, which among others has following features: * Kernel-side client and server. No need for any special tools for data processing (like special userspace applications) except for configuration. * Bullet-proof memory allocations via memory pools for all temporary objects (transaction and so on). * Zero-copy sending (except header) if supported by device using sendpage(). ...

On Thinkpads with ACPI video support, yes. -- Matthew Garrett | mjg59@srcf.ucam.org --

Please drop h8300-kallsyms-exclude-local-symbols.patch from mm for now. I'm all in favour of its intent, cutting local .Lfoo symbols out of the the symbol table. But at present it's cutting out all .symbols - which is very unfriendly to powerpc, whose every function is a .symbol! The undotted symbol being the descriptor that points to the function. My 2.6.27-rc5 powerpc System.map doesn't actually contain any .Lsymbols, but I expect someone else's does: I doubt excluding .Lsymbols is ...

Crap, I messed up, David sent me the fixed patch and I forgot it. I'll go do a new release in a few hours... thanks, greg k-h --

That file is still used by ./net/ipv6/ip6mr.c:#include <linux/pim.h> so there are build errors... net/ipv6/ip6mr.c:48:23: error: linux/pim.h: No such file or directory net/ipv6/ip6mr.c:354: error: dereferencing pointer to incomplete type net/ipv6/ip6mr.c:358: error: dereferencing pointer to incomplete type net/ipv6/ip6mr.c:358: error: 'PIM_VERSION' undeclared (first use in this function) net/ipv6/ip6mr.c:358: error: (Each undeclared identifier is reported only once net/ipv6/ip6mr.c:358: ...

We (the -stable team) are announcing the release of the 2.6.26.4 kernel. It contains lots of bugfixes, all over the map. Any users of the 2.6.26 kernel series should upgrade to this version. For details on the fixes, see the changelog entries and the diffstat below. I'll also be replying to this message with a copy of the patch between 2.6.26.3 and 2.6.26.4 The updated 2.6.26.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.26.y.git and ...

All the logic and locking is in the core code so would show up on all sorts of boxes. You say you are using sata_sil - is this on an Nvidia Can you duplicate this with the drives just on the ata_piix ? Alan --

We (the -stable team) are announcing the release of the 2.6.25.17 kernel. It contains lots of bugfixes, all over the map. Any users of the 2.6.25 kernel series should upgrade to this version. For details on the fixes, see the changelog entries and the diffstat below. I'll also be replying to this message with a copy of the patch between 2.6.25.16 and 2.6.25.17 The updated 2.6.25.y git tree can be found at: ...

The drives are on the ata_piix. I have no clue why the 'install' added the sata_sil driver because I have never used on on this machine! I note thet /etc/modprobe.conf has an alias for it so at one time a Fedora install thought it found one! Cheers, Dick Johnson Penguin : Linux version 2.6.25.17 on an i686 machine (4786.48 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information transmitted in this ...

Hello everyone, I originally hit this with btrfs and assumed I was doing something wrong, but it looks like it is a generic problem. The stack trace at the bottom of this email came from the following setup: mdadm --create /dev/md0 --level=1 --raid-devices=4 --assume-clean /dev/sd[cdef] mkfs.ext4dev /dev/md0 50000000 mount /dev/md0 /mnt synctest -t 100 -F -f -u /mnt synctest is an old benchmark from akpm that I dug up to test the btrfs fsync code. google doesn't seem to know much about ...

Guilt v0.31 is available for download. Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git This is a mostly bugfixes-only release to get the fixes that accumulated over the past several months out of the door. As always, patches, and other feedback is welcome. Josef "Jeff" ...

I must admit, that I don't like these extra tarballs with docs. I always expect, that the manpages are nicely installed if I type 'make install' (or at least with a install-doc target). But I need to download this extra package, and extract it to the right place, there is no Makefile whatsoever. In case of git its really annoying, because the help mechanism is relying on the manpages (i.e. git help <cmd> or git <cmd> --help, but you know this). Thanks --

But the utsname gets freed after the mnt_ns, so the analysis seems wrong somehow. I trust addr2line or whatever verified that rpc_create+0x332/0x42f is exactly at the call to utsname()? --

On a system with nfs mounts, if a task unshares its mount namespace, a oops can occur when the system is rebooted if the task is the last to unreference the nfs mount. It will try to create a rpc request using utsname() which has been invalidated by free_nsproxy(). The patch fixes the issue by using the global init_utsname() but at the same time, it breaks the capability of identifying rpc clients per uts namespace. Any better suggestions ? BUG: unable to handle kernel NULL pointer ...

--

hi, this is basically the same as hfsplus-fix-buffer-overflow-with-a-corrupted-image.patch. We use the length parameter for a memcopy without checking it and thereby corruption memory. Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de> --- linux/fs/hfs/catalog.c.orig 2008-09-08 15:20:15.000000000 +0200 +++ linux/fs/hfs/catalog.c 2008-09-08 15:21:02.000000000 +0200 @@ -190,6 +190,10 @@ int hfs_cat_find_brec(struct super_block fd->search_key->cat.ParID = rec.thread.ParID; len = ...

This cannot be a global variable, what happens when we have two disjoint --

Preferably in the form of in-code comments and code structure, this That would be much appreciated. But I also prefer to get rid of that power savings tweak in cpu_coregroup_map(). But above all, readable code ;-) find_busiest_group() is the stuff of nightmares. --

From: Gautham R Shenoy <ego@in.ibm.com> *** RFC patch of work in progress and not for inclusion. *** Currently the sched_mc/smt_power_savings variable is a boolean, which either enables or disables topology based power savings. This extends the behaviour of the variable from boolean to multivalued, such that based on the value, we decide how aggressively do we want to perform topology based powersavings balance. Variable levels of power saving tunable would benefit end user to match ...

> 1. Detailed documentation Messy code cannot be really made good with documentation. It's not that your patches are that messy, it's more that it makes I think one issue is that there are general too many special cases that completely change the algorithm especially for power saving. Perhaps it would make sense to refactor the code a bit and then use different high level code paths for those? I assume that would make it all simpler and easier to understand. The other alternative would be ...

current power save balance code: 1. Detailed documentation 2. Cleanup the group_min and group_leader stuff in find_busiest_group() Did I get the requirements correct? --Vaidy --

Just in case two groups have identical load, prefer to move load to lower logical cpu number rather than the present logic of moving to higher logical number. find_busiest_group() tries to look for a group_leader that has spare capacity to take more tasks and freeup an appropriate least loaded group. Just in case there is a tie and the load is equal, then the group with higher logical number is favoured. This conflicts with user space irqbalance daemon that will move interrupts to lower ...

When the system utilisation is low and more cpus are idle, then the process waking up from sleep should prefer to wakeup an idle cpu from semi-idle cpu package (multi core package) rather than a completely idle cpu package which would waste power. Use the sched_mc balance logic in find_busiest_group() to nominate a preferred wakeup cpu. This info can be sored in appropriate sched_domain, but updating this info in all copies of sched_domain is not practical. For now lets try with a global ...

To be able to do SDIO the s3cmci driver has to support non-word-sized transfers. Change pio_words into pio_bytes and fix up all the places where it is used. This variant of the patch will not overrun the buffer when reading an odd number of bytes. When writing, this variant will still read past the end of the buffer, but since the driver can't support non-word- aligned transfers anyway, this should not be a problem, since a word-aligned transfer will never cross a page boundary. This has ...

Hmm, i'd be interested to find out how long these are taking... I might try and rig up something to test the time being taken via an SMDK. If the fifo read/writes are taking significant amounts of time, then the pio tasklet will at least improve the interrupt latencies invloved, as iirc we're currently running the main irq handler in IRQ_DISABLED mode to stop any problems with re-enternancy.... I'll check this and see what -- -- Ben Q: What's a light-year? A: One-third less ...

Ok, I just measured this on the 200 MHz S3C24A0, when running the SDIO bus at 10 MHz, the longest time I saw the driver spend in the pio_read function was ~10us. I guess that means that the hardware managed to empty the fifo enough to do yet another spin through the loop. So with a faster SDIO clock the time spent in pio_read ought to go up, and for a long transfer it could grow without bounds. I also tried to run the code with the schedule_tasklet still there, and then I saw ~13us as ...

This adds support for the SDIO irq to the s3cmci driver. The driver calls to enable_irq and disable_irq are not matched properly when doing SDIO, so I've worked around this by counting the number of enables and disables. This is not the proper way to do it, but makes things work for me the moment on a Samsung S3C24A0 processor. There are supposed to be issues with spurious interrupts on some S3C processors, so this needs more investigation and testing, but I thought this patch may be useful ...

Acked-by: Christoph Lameter <cl@linux-foundation.org> --

Oh, I see. Thanks Hugh. Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --

Signed-off-by: Alex Nixon <alex.nixon@citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Ingo Molnar <mingo@elte.hu> --- arch/x86/xen/smp.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index be5cbb2..bf51a46 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -332,6 +332,7 @@ static void xen_smp_cpus_done(unsigned int max_cpus) { } +#ifdef CONFIG_HOTPLUG_CPU int ...

Hello, My board is using MV64460 chip and lots of bogus devices were detected at PCI bus probe time.Those bogus devices has vendor/device id of 0x648511ab. I don't know why there has so much devices with vendor/device id of 0x648511ab. Anybody has ideas? pcibios_init:probe devices for hose 0xc0546800 I/O 0xd0000000-0xd0000fff MEM0 0x80000000-0x87ffffff MEM1 0xf2000000-0xf203ffff MEM2 0xb0000000-0xb0003fff pci_scan_child_bus: PCI: Scanning bus 0000:00 pci_scan_device: devfn=0, ...

Dave put a recent copy up at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/libpcap.git --

subscribe linux-kernel --

The timeout feature is added to "freeze ioctl" to solve a deadlock when the freezer accesses a frozen filesystem. And new ioctl to reset the timeout period is added to extend the timeout period. For example, the freezer resets the timeout period to 10 seconds every 5 seconds. In this approach, even if the freezer causes a deadlock by accessing the frozen filesystem, it will be solved by the timeout in 10 seconds and the freezer will be able to recognize that at the next reset of timeout ...

It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. Signed-off-by: Dave Chinner <dgc@sgi.com> Signed-off-by: Takashi Sato <t-sato@yk.jp.nec.com> --- linux-2.6/xfs_ioctl.c | 15 --------------- linux-2.6/xfs_ioctl32.c | 2 -- xfs_fs.h | 4 ++-- 3 files changed, 2 insertions(+), 19 deletions(-) diff -uprN -X linux-2.6.27-rc5.org/Documentation/dontdiff ...

The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. ...

Super, that's fine, thanks for sorting it out. (I'll forgive you the build error under my name!) Hugh --

The hardware virtualization technology evolves very fast. But currently it's hard to tell if your CPU support a certain kind of HW technology without digging into the source code. The patch add a new item under /proc/cpuinfo, named "virt flags". The "virt flags" got the similar purpose as "flags". It is used to indicate what HW virtulization features does this CPU supported, and it don't cover all features but only the important ones. Current implementation just cover Intel VMX ...

FWIW when I added the "power management:" flags back then for the 64bit kernel I didn't get any reports of user programs breaking. Also some other fields got added like cpu cores or initial apicid etc. and that also didn't lead to breakage. So adding new lines to cpuinfo should be ok. -Andi -- ak@linux.intel.com --

It probably makes sense to separate these out as a separate word, especially if they come from the hardware in any reasonable way. But yes, adding them to the feature array makes sense. -hpa --

--

This patchset is minor cleanups for swiotlb. It doesn't confilict with the swiotlb fixes for the x86 tree (that I've just sent): http://lkml.org/lkml/2008/9/8/30 This can be cleanly applied to tip/master and tip/x86/iommu. Ingo, can you apply this to your tree? --

No objections from me. -Tony --

This adds is_swiotlb_buffer() helper function to see whether a buffer belongs to the swiotlb buffer or not. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- lib/swiotlb.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index bf61c73..b5f5d11 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -283,6 +283,11 @@ address_needs_mapping(struct device *hwdev, dma_addr_t addr) return (addr & ~mask) != 0; } ...

The check to see if dev->dma_mask is NULL in pci-nommu is more appropriate for dma_alloc_coherent(). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/x86/kernel/pci-nommu.c | 3 --- include/asm-x86/dma-mapping.h | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index 73853d3..0f51883 100644 --- a/arch/x86/kernel/pci-nommu.c +++ b/arch/x86/kernel/pci-nommu.c @@ -80,9 +80,6 @@ ...

-- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy --

This patchset (against tip/master) fixes the problem that swiotlb exhausts ZONE_DMA: http://lkml.org/lkml/2008/8/31/16 The root problem is that swiotlb_alloc_coherent always use ZONE_DMA, which is fine for IA64 but not for x86_64. This patchset makes the callers set up the gfp flags so that swiotlb_alloc_coherent can stop playing with the gfp flags. I think that it would be better to remove the allocation code in swiotlb_alloc_coherent theoretically (what swiotlb should do is ...

Cool :-) This is much better than our last two tries to solve this problem. Doing no gfp handling at all in swiotlb_alloc_coherent is a nice and clean solution. Joerg -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC ...

i've applied Fujita's patches to tip/x86/iommu: 68e91d6: swiotlb: remove GFP_DMA hack in swiotlb_alloc_coherent 823e7e8: x86: dma_alloc_coherent sets gfp flags properly 8a53ad6: x86: fix nommu_alloc_coherent allocation with NULL device argument de9f521: x86: move pci-nommu's dma_mask check to common code 3a80b6a: ia64: dma_alloc_coherent always use GFP_DMA Tony, do you have any problem with us carrying the ia64 commit above (3a80b6a, also attached below) in tip/x86/iommu tree? It's ...

Non real IOMMU implemenations (which doesn't do virtual mappings, e.g. swiotlb, pci-nommu, etc) need to use proper gfp flags and dma_mask to allocate pages in their own dma_alloc_coherent() (allocated page need to be suitable for device's coherent_dma_mask). This patch makes dma_alloc_coherent do this job so that IOMMUs don't need to take care of it any more. Real IOMMU implemenataions can simply ignore the gfp flags. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- ...

tosa_battery should also depend on wm97xx_ts as it uses dac-accessing functions from that module. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> --- drivers/power/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 9ce5585..b001984 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -51,7 +51,7 @@ config BATTERY_OLPC config BATTERY_TOSA tristate "Sharp SL-6000 (tosa) ...

This simple patch should solve the above problem. Seeing the config, its seems to be a 32bit box. It convert tlbstate_lock spin_lock to raw_spin_lock. Preemption has already been disabled, hence this change shouldn't affect latency numbers. Signed-Off-By: Chirag <chirag@linux.vnet.ibm.com> diff --git a/arch/x86/kernel/tlb_32.c b/arch/x86/kernel/tlb_32.c index 9bb2363..228849c 100644 --- a/arch/x86/kernel/tlb_32.c +++ b/arch/x86/kernel/tlb_32.c @@ -23,7 +23,7 @@ ...

Thanks, I've applied it to the ext4 patch queue. - Ted --

Hi. The new address_space_ops is_partially_uptodate was added at 2.6.27-rc1. On ext3, this aops checks whether buffer_heads that are attached to a page are uptodate or not when a page is not uptodate. When all buffers which correspond to a portion we want to read are uptodate even if a page is not uptodate, we can avoid actual read ...

I am pleased to announce the release of Merkey's LinuxWare, an MS-DOS (or DR-DOS) loader that allows you to compile a Linux kernel as an MS-DOS Executable, boot and load Linux from MS-DOS (while DOS stays resident). This in essence is exactly the same as old Legacy Netware, and in fact, I wrote a linker that does what the old NetWare custom linker did when it compiled the NetWare kernel and linked it as a DOS Application. Linux works just like it does normally, except you can quit Linux and ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/Kconfig.cpu | 10 +- arch/x86/kernel/cpu/Makefile | 3 +- arch/x86/kernel/cpu/amd_64.c | 473 ------------------------------------------ 3 files changed, 2 insertions(+), 484 deletions(-) delete mode 100644 arch/x86/kernel/cpu/amd_64.c diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu index 331922c..dd8a937 100644 --- a/arch/x86/Kconfig.cpu +++ b/arch/x86/Kconfig.cpu @@ -462,17 +462,9 @@ config ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/apic.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/apic.c b/arch/x86/kernel/apic.c index 0556f37..f3f5085 100644 --- a/arch/x86/kernel/apic.c +++ b/arch/x86/kernel/apic.c @@ -1548,7 +1548,7 @@ void __init init_apic_mappings(void) apic_phys = mp_lapic_addr; set_fixmap_nocache(FIX_APIC_BASE, apic_phys); - apic_printk(APIC_VERBOSE, "mapped APIC to %16lx ...

applied to tip/x86/unify-cpu-detect, thanks. Ingo --

1. make 32bit have early_init_amd_mc and amd_detect_cmp 2. seperate init_amd_k5/k6/k7 ... v2: fix compiling for !CONFIG_SMP Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/amd.c | 396 ++++++++++++++++++++++++------------------ arch/x86/kernel/cpu/amd_64.c | 17 +- arch/x86/kernel/cpu/common.c | 2 +- include/asm-x86/processor.h | 2 +- 4 files changed, 236 insertions(+), 181 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/amd_64.c | 2 -- arch/x86/kernel/process.c | 1 - 2 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/amd_64.c b/arch/x86/kernel/cpu/amd_64.c index 7913e48..466a1ea 100644 --- a/arch/x86/kernel/cpu/amd_64.c +++ b/arch/x86/kernel/cpu/amd_64.c @@ -9,8 +9,6 @@ #include "cpu.h" -int force_mwait __cpuinitdata; - #ifdef CONFIG_NUMA static int __cpuinit nearby_node(int ...

nice! Applied these patches to tip/x86/unify-cpu-detect: ff73152: x86: make 64 bit to use amd.c 2a02505: x86: make amd_64 have 32 bit code 6c62aa4: x86: make amd.c have 64bit support code 8d71a2e: x86: merge header in amd_64.c 2b86473: x86: add srat_detect_node for amd64 c58606a: x86: remove duplicated force_mwait 11fdd25: x86: cpu make amd.c more like amd_64.c v2 thanks Yinghai, Ingo --

I meant repeated as in "after different boots", but I now also see repeats when I leave the system on for some time. It keeps increasing the min_delta_ns to ever higher values. CE: __tick_program_event of hpet is stuck 1468f1b3c9 1468f1c751 CE: increasing min_delta_ns 5000 to 10000 nsec [...] CE: __tick_program_event of hpet is stuck 33576032f74 33576035684 CE: increasing min_delta_ns 10000 to 20000 nsec [...] CE: __tick_program_event of hpet is stuck 63242b30d28 63242b35b48 CE: ...

Exactly the same problem here. This is a Lenovo Thinkpad R61 with current git head (7686ad56). Cheers, Stefan Hellermann --

I was concerned that would cause lots of cross-arch churn, but of course the only other relevant architecture is ia64. I'll prep a followup patch. J --

You mean there's code which just assumes that it can keep using a linear-mapped acpi even after __acpi_map_table() should have implicitly __acpi_map_table() is called by acpi_map_table(), which does have a acpi_unmap_table() counterpart. But it only calls iounmap() once we're past the stage of calling early_*(). I could easily make it call __acpi_unmap_table()->early_iounmap(). But if the concern is that the early boot callers of acpi_map_table() "know" that they never need to And the ...

Acked-by: Yinghai Lu <yhlu.kernel@gmail.com> --

Er, also written like: +#ifdef CONFIG_SMP Bonk. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Should really be just: +#if defined(CONFIG_SMP) Can you amend? Thanks a lot, Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Doesn't matter. If gcc passes "-mtune=i686" down to gas and thus the end result doesn't match gcc's own documentation (and whole point of -mtune), then it's still a gcc bug, even if it may not be a "cc1" bug. The fact that "cc1" and "gas" are two different phases is pretty much irrelevant. gcc calls them both. But sure, if there are separate bugzillas, post it in both. Linus --

It almost certainly never gets as far as detect_nopl(). -hpa --

yes. X86_P6_NOPS is a totally insignificant optimization and if it makes _any_ CPU not boot (be that virtual or real), then it's frankly not worth it. David, exactly how does the kernel fail to boot with latest -git? (v2.6.27-rc5-313-g64f996f or later) Does detect_nopl() run? It really should, and it should detect the non-working instructions. Ingo --

Under that logic we shouldn't even have CPU configurables, since you want it to "just work" whatever crap you're running on. That is EXACTLY what CONFIG_X86_GENERIC means, and the fact that any particular distribution is broken with respect to not enabling it is a bug in that distribution, and not grounds for breaking the upstream kernel. -hpa --

No, please don't. Instead, David, please enable CONFIG_X86_GENERIC. -hpa --

The help text is indeed out of date. I did a patch yesterday to, among other things, update it; I also want to verify that we are disabling all options that can cause gcc or binutils to generate nopl's; I plan to push it today. -hpa --

Sounds like a plan. I'll have a patch shortly. -hpa --

Btw, I do think that the whole NOPL issue is separate from all the other issues. There can be _other_ cases where it really is worth doing some "generic" optimizations or being more "specific", and my argument really is that NOPL is _not_ one of those cases. So I'm still not sure that X86_GENERIC is necessarily the answer. The answer may be: - never use NOPL statically unless we _know_ it works (eg x86-64) - never allow such a stupid decision by gcc as to use NOPL on ...

I always understood the CPU selection to be "this CPU and ones compatible with it will work, others won't" unless generic was enabled. the fact that only a few CPU's wouldn't work and the rest was optimization is true, but the details of what chips would and wouldn't work were never that clear. The difference between a kernel compiled for generic and once compiled for a specific CPU can be very significant. (I ran into 30% differences back in the 2.4 days between generic and Athlon) This ...

Ingo, With CONFIG_X86_GENERIC=y, the latest v2.6.27 in Linus's tree boots fine. But if you don't select that option (and some distributions don't) it won't boot at all. It just hangs (blank screen) with no error messages and nothing in dmesg. I assume it is hitting one of the ASM_NOP? instructions. David --

That is A TOTAL PIECE OF SH*T, and against gcc's own documentation. "-mtune=x" is very much defined to be a performance _tuning_ option, not an "architectural" option. Quite frankly, this is a gcc bug. Plain and simple. Look at the gcc man-pages. It very much says: -mtune=cpu_type Set only the instruction scheduling parameters for machine type cpu_type. The instruction set is not changed. (in various different formats - it says the same things ...

The issue at hand is that at least with the current toolchain, we need to pass -march=generic in order for these instructions to be generated. We have an option for this, CONFIG_X86_GENERIC, which distributions really *should* be using anyway. And yes, it should be the default. The patch I have makes it "default y" as well as change the help text. Would it make you happier if this option was forced enabled unless CONFIG_EMBEDDED was on? -hpa --

Okay, a few things here... 1. First, I wrote up a patch yesterday to update the CONFIG_X86_GENERIC description and to make it "default y". It is currently on x86/defconfig, but I think it should be promoted to mainline immediately. 2. X86_P6_NOPS is not the only source of static NOPLs. If gcc is set to optimize for specific architectures, then gcc/binutils will generate static NOPLs. The only way we can prevent that is by not using specific -march options, as far as I can ...

Ok, goodie. And we don't pass the -mtune=xyz option when we use gas I have no problem with it, with the fix to actually assemble things. But I also don't think it's a huge deal (ie not 2.6.27 stuff - we don't know if some odd version of as does something odd with -mtune=generic, or whether this can interact oddly with some version of gcc perhaps passing the _correct_ -mtune to the assembler?). Linus --

The option that works best for users is for the kernel to not use NOPLs on 32-bit cpu's. That is what Linus's patch accomplishes. I am not having any issues with gcc or gas generating NOPLs. The kernel should work out of the box for PentiumPro or later cpu's running in 32-bit mode. I think you are trying to over-engineer the issue. Just apply the patch and move on. David --

Previously they could set CPU x and it would still run on other CPUs even if that option was not set. If that's not the case anymore then they will have some unhappy users once they update their kernels. -Andi -- ak@linux.intel.com --

OK, turns out that is already happending, by virtue of: # add at the end to overwrite eventual tuning options from earlier # cpu entries cflags-$(CONFIG_X86_GENERIC) += $(call tune,generic,$(call tune,i686)) -mtune=generic on 32-bit CPUs disable NOPL generation, and any gcc/binutils combo too old to have -mtune=generic won't generate them at all. I think I verified this some time in the past, but I just had to refresh my memory. This was a major reason to put this functionality on ...

Likely broke a lot of distribution setups how? -hpa --

Originally it was an option because the 128 byte cache line it selects caused bloat in several important data structures. That was back then when cache line padded NR_CPUs arrays were still pretty common. I don't know if it's still a problem, but before making it default y it would be good to check the dynamic+static memory cost at least. -Andi --

[Ingo Molnar - Mon, Sep 08, 2008 at 04:33:35PM +0200] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > Convert DO_ACTION macro into more obvious io_apic_modify_irq | > function with callers | > --- | > | > I found it more readable then original was. Especialy we could grep | > the callers in normal way. It's just an attempt - free to drop this | > patch. I hope I don't messed with all these masks :) So the question | > is rather NOT about details but idea in general. | | yeah ...

El lun, 08-09-2008 a las 12:46 -0700, Randy Dunlap escribi=C3=B3: So is it useful to report them or i just do: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" Thanks for the answer, Cheers --=20 The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place.=20 ...

=20 Ok; thank you for your time

pulled into tip/timers/range-hrtimers, thanks Arjan! Ingo --

we dont really ignore it - we detect that it got corrupted by the bootloader. (it got overwritten by the kernel image - information has been destroyed irrevocably) how we react to that breakage we detect is up to debate: it's fine to try to continue (presumably a huge vmlinux means it has all the drivers already) - and if a system relies on an initrd it wont get fast in bootup anyway. that's why i suggested to print a warning, do a 5 seconds delay after that warning via ...

Well, the specific problem is that the BIOS appears to corrupt low memory. It might corrupt other memory anywhere, but that would be pretty pathologically evil. The assumption is that it gets away with it Well, it wouldn't help in this case. It's not random hardware bit-flipping. J --

OK, fine, sorry I didn't follow the thread back. --

Indication of the faulty part, so I know whether to contact AMD or Tyan. Without a clear idea of which it could quickly turn into an infinite redirect loop between the two. Regards, Tony V.

I was hoping for some help in narrowing it down, yes. Jeroen's reply was very helpful, and more among the line of what I was expecting. I have contacted all vendors involved now, and it looks like the system RAM is not fully compatible with the mainboard. With regard to the message, I would suggest an alternate wording like such: A hardware component in your system is failing. Please contact your hardware vendor(s). If unsure, contact your CPU vendor first. Regards, Tony V.

Or this: "A hardware component in your system is failing. [insert specific bit if MCE is certain enough about what part] If you can, try to narrow it down by placing it in another mainboard (assuming you have one available), or run [memcheck, another tool]. Then contact the hardware vendor(s) in question, if uncertain, try Jeroen. --

Ok so you wanted linux-kernel to diagnose your hardware for you? For DIMMs you can get that with --dmi if you run the latest mcelog and if it's a memory problem. Unfortunately the BIOS vendors in their wisdom often deliver incorrect DMI tables, so the information is not always very useful. -Andi -- ak@linux.intel.com --

Umm, right, my cut and paste error... Thanks, --

Sorry that patch seems incredibly messy. Global variables and a tricky ordering and while it's at least commented it's still a mess and maintenance unfriendly. Also I think set_affinity is the only case where a truly arbitary cpu mask can be passed in anyways. And it's passed in from elsewhere. The other cases generally just want to handle a subset of CPUs which are nearby. How about you define a new cpumask like type that consists of a start/stop CPU and a mask for that range only and ...

seconded. Mike, since none of this is v2.6.27 material, lets do it right with a v2.6.28 target. You know all the cpumask_t using code sites inside out already, so the know-how is all available already :-) Please make it finegrained series of patches so that we can resolve conflicts with other trees more easily. perhaps propose the new cpumask_t API early (in this thread?), so that people can comment on it before NAKs come flying against a full patchset ;-) Ingo --

Again, yes, as I got farther into that one, it became clear that having static cpumask_t temps over too large a range was ending up very messy. Thanks, Mike --

What I'll do is resubmit the changes that have nothing to do with cpumask_ptr's first as they are mostly just "cleaning up extraneous temp cpumask variables". Then I'll try the redefine of cpumask_t to see what kind of hornet's nest is opened up. What do you think of a pool of temp cpumask_t's? That way, they could be made available early (before kmalloc is available). An atomic op could be used for reservation which when the zero-based percpu variables finally get completed, become very ...

Your patch fixes the compilation error I reported, thanks. -- Martin Michlmayr http://www.cyrius.com/ --

Both 7zip and LZMA-Utils have serious file format problems. The author of LZMA-Utils is working on a new format, which is likely to be widely adopted once it materializes. -hpa --

I suspect this behavior may have already been changed, you may want to try a newer kernel and see.. --

Thanks! Masoud --

Phil, I got about the same improvement when CFS was being evaluated from patches, so I think you can trust your result, HT really does help in the 1.30..1.35 range depending on the application. It also seems to help when processes or threads are running data through a pipe, and my check Just to provide a confirmation of the magnitude of the benefit, no real new information, although you might have a real piped operation to track, noting the real time, CPU time, and ctx rate. I believe ...

Yes, the patches are in Andi's test tree currently. please run #git-clone git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6 acpi_test #git-branch -r #git-branch --track test origin/test #git-checkout test to get the source code if you want to give it a try. :) thanks, rui --

It shouldn't be, because the old code has that same warning I think. It also probably shouldn't be the caller, because nothing is using the new interfaces yet. I'm sure it must be something wrong with the vmap rewrite patch, but I'm simply not having any luck reproducing it yet. Is 32-bit a common theme? (I'm trying to test 64-bit with a greatly reduced vmalloc space, but I don't have access to a 32-bit compiler just now - travelling). I might have to send a test-and-report-back debug ...

OK, would it be possible to test the following patch on the failing machine(s), and send me the complete dmesg trace afterwards, please? The patch does a little bit of extra page table checking, and also prints a trace of operations on the vmap-space. Thanks, Nick

applied to tip/timers/hpet-percpu, thanks Venki! Ingo --

From: Mike Travis <travis@sgi.com> Yes, of course, the pointer should be const. --

Linus's idea of defining cpumask_t to be a simple long[1] or a pointer to a cpumask is a good one. Unfortunately, the amount (and breadth) of the code changes required is daunting, to say the least. In my source tree there are 892 references to cpumask_t. But I'll start looking into it asap. I don't know however if "NR_CPUS > BITS_PER_LONG" is the correct metric to decide when to use pointers. There must be a better "pain" indicator... ;-) Thanks, Mike --

Considering that, unless I'm mistaken, you want to run production systems with 4096 CPUs at some point, then I would say you should really consider increasing NR_CPUS _further_ than that in QA efforts, so that we might be a bit more confident of running production kernels with 4096. Is that being tried? Setting it to 8192 or even higher during QA seems like a good idea to me. --

That's a good idea. I do occasionally set it to 16k (and 64k) for experimental reasons (and to really highlight where cpumask_t space hogs reside), but I hadn't thought to do it in the QA environment. Thanks, Mike --

Hi, OK in addition to the bisection I've collected trace data for the good (commit 4d770ccf4257b23a7ca2a85de1b1c22657b581d8) and bad (commit e261f51f25b98c213e0b3d7f2109b117d714f69d) cases. Attached is a file called trace.tar.bz2 inside you'll find 4 files, for the two sessions: bad-wireshark bad-strace good-wireshark good-strace From a quick glance the difference seems to be the bad case does an UNSTABLE NFS WRITE call. I don't really know what that means or what its ...

On Mon, Sep 8, 2008 at 10:54 AM, Luca Tettamanti <kronos.it@gmail.com> wrote: can you post boot log with working kernel + "debug"? YH --

so some config works, others not? YH --

that could explain sth. big kernel use more, and lilo put ramdisk need to figure out, lilo put ramdisk so low... need to know e820 table layout... YH --

do you mean tip/master? http://people.redhat.com/mingo/tip.git/readme.txt YH --

Well, just for executing code (and reading RO data), then it shouldn't matter at all actually if the CPU starts executing from the new page or the old page, so long as there is a way to quiesce NMIs before freeing the old page. So the NMI can run, and read data, but it may have a problem with stores. At least, some kind of redesign of NMI handlers might be required so that they can make a note of the pending operation and try to do something sane in that case. Or, there could be a small ...

It's hard for NMIs at least. They cannot execute faults. In the end you would need to define a core kernel which cannot be remapped and the rest which can and you end up Well in general someone remapping all the memory beyond you. That's essentially a hypervisor in my book. -Andi --

Sorry, by "block", I really mean spin I guess. I mean that the CPU will be forced to stop executing due to the page fault during this sequence: for prot RO: alloc new page memcpy(new, old) ptep_clear_flush(ptep) <--- from here set_pte(ptep, newpte) <--- until here for prot RW, the window also would include the memcpy, however if that adds too much latency for execute/reads, then it can be mapped RO first, What would be? Blocking in interrupts? Or non-linear kernel ...

Right, but the "high level" software solution is to have nonlinear kernel mappings. Executing kernel code should not be so hard because it could be handled just like executing user code (ie. the CPU that is executing will subsequently fault and be blocked until the relocation is complete). DMAs aren't trivial at all, but I guess there could be say, a method to submit and revoke areas of memory for DMA, and the submit would block if the memory is currently being relocated underneath it ...

You use non-linear mappings for the kernel, so that kernel data is not tied to a specific physical address. AFAIK, that is the only way to really do it completely (like the fragmentation problem). Of course, I don't think that would be a good idea to do that in the forseeable future. --

Thanks a lot for these numbers Alan, it definitely looks like a clear win (and a pretty big one) for all of the above and the previous mail. It would be interesting to see sys and usr times seperately, as well as trying to compare profiles of two runs. On the testing that I did with a 4-way ppc box, lock contention and bouncing was way down with XFS and btrfs. I didn't test other file systems yet. I saw mean acquisition and hold time reductions in the 20-30% range and waittime reductions of ...

applied to tip/x86/mm-debug - thanks Jan! Ingo --

-tip testing found various kernel crashes on 32-bit testboxes and i've bisected it down to: | 3766e71257859cecb73d929c4974c729efeae51f is first bad commit | commit 3766e71257859cecb73d929c4974c729efeae51f | Author: Jan Beulich <jbeulich@novell.com> | Date: Mon Sep 8 11:50:21 2008 +0100 | | x86: x86_{phys,virt}_bits field also for i386 (v2) # bad: [6b822d60] manual merge of x86/xen # good: [bce7f793] Linux 2.6.26 # good: [6069fb2e] Re-delete zombie ...

Why do you need to clear down anonymous mapping ? I think if you don't convert this cleardown in free_hot_cold_page(), you don't need it. -- Thanks, MinChan Kim --

*Much* less likely, actually. Because there should be very little allocation required for reclaim (only dirty pages, and only when backed by filesystems that do silly things like not ensuring their own reserves before allowing the page to be dirtied). Also, your scheme still doesn't avoid allocation for reclaim so I don't see I don't see why it should be unfair to allow a process to allocate 1024 order-0 pages ahead of one order-10 page (actually, yes the order 10 page is I guess ...

Yeah that has slipped through from where originally this patch used to merge two different instances of this code. Good spot. Will sort that -apw --

Ok, so please add a comment to this so we know in the future why this is there. Joerg -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, ...

btw., the build became very noisy - see the messages below. Ingo ----------> init/initramfs.c:517: warning: 'clean_rootfs' defined but not used In file included from include/linux/dma-mapping.h:53, from include/linux/dmaengine.h:30, from include/linux/skbuff.h:30, from include/linux/netlink.h:156, from include/linux/genetlink.h:5, from include/net/genetlink.h:5, from ...

ok - i've picked up your narrowed patch into tip/x86/urgent. Ingo --

Hi Jeremy, I used the complete patch, I had some compile warnings. The oops is gone and I was able to access the /sys/devices/system/xen_memory/xen_memory0/info/current_kb entry. thanks, R. --

We could certainly propagate it to x86/urgent, if it fixes a real issue. It cherry-picks just fine. Ingo --

Well, the compile warning are bad news. Just use the first hunk. Ingo, could you send this up to Linus? It's a subset of a patch you've already got in your tree. Thanks, J Subject: xen-balloon: fix balloon sysfs name Set the class so it doesn't clash with the normal memory class. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> =================================================================== --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ ...

Hmm, I don't think that it does. There's a queue per drive in the old IDE driver, so there should be a 1:1 relation between queues and gendisk -- Jens Axboe --

I think the problem here is due to the usage of kobject_init_and_add(). When we hit the add the second time, the ->state_initalised in the kojb is still 1. The below should fix it. The ->state_initalised stuff is a disaster imho, it should be shot and killed. diff --git a/block/blk-core.c b/block/blk-core.c index 6cb3c6d..820132b 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -495,6 +495,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id) ...

On Mon, 8 Sep 2008 13:40:25 -0700 What is a good way to say "i am polling for a while"? --

On Mon, 8 Sep 2008 14:08:24 -0700 can you take a fixed time delay? or use cond_resched() -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Btw Yinghai, do you really have a machine with that many unconnected pins? --

thanks for explanation Yinghai, i was reffering to MP and didn't take a look on ACPI facility (that is why I've asked you). Thanks! --

got 0-16<7> 0-17<7> 0-18<7> 0-19<7> 0-20<7> 0-21<7> 0-22<7> 0-23<7> (apicid-pin) not connected 1-0<7> 1-1<7> 1-2<7> 1-3<7> 1-4<7> 1-5<7> 1-6<7> 1-7<7> 1-8<7> 1-9<7> 1-10<7> 1-11<7> 1-12<7> 1-13<7> 1-14<7> 1-15<7> 1-16<7> 1-17<7> 1-18<7> 1-19<7> 1-20<7> 1-21<7> 1-22<7> 1-23<7> (apicid-pin) not connected can you remove the extra <7>? YH --

Thank you for the review and comments. You are right in that searching the whole process address space is not a good idea. The idea is to make the scan range flexible, thus normally, assuming that the code has been well-tuned, only a very limited number of VMA's are scanned. In general, i think that the cluster size and the scan range should be tuned depending on the backing storage characteristics and the low-on-memory severity. Like any VM code, this one needs tuning. BTW, the code could ...

I do not think that the virt_to_page() can work well on userland virtual address space. And the linear searching for whole address space of a vma is not good --

Your disk went offline and then refused to come back when the link was reset. The initial trigger appears to have been the drive, the fact it didn't come back could either be the drive or a controller problem. We've seen a few cases where devices or controllers fail to recover from one end being stuck expecting data. Mark Lord did some patches to try and drain data in this case but I don't remember if they were merged yet. Alan --

.. That would be this patch, currently not merged, not maintained, and probably needs rework for some chipsets. But for the record: I think this original patch still applies cleanly on at least 2.6.23-rc7. Drain up to 512 words from host/bridge FIFO on stuck DRQ HSM violation, rather than just getting stuck there forever. Signed-off-by: Mark Lord <mlord@pobox.com> --- --- old/drivers/ata/libata-sff.c 2007-09-28 09:29:22.000000000 -0400 +++ ...

Jumping in the API thread : how will this API interact with the namespaces ? I think the exact question is how are we seeing the restart sequence ? shall we (1) restart from inside a set of pre established namespaces or (2) restore the state of the namespaces upon restart ? I think (1) is the best option in semantic, because it's closer to what the kernel does: create a directory (a container) and then fill it with files (tasks). That's how the cgroup framework works and I have ...

I'd suggest not storing virtual addresses in 'unsigned long'. It's passable when you're doing lots of arithmetic on the addresses, but that isn't happening here. That probably means cascading back and changing Have you looked at mprotect_fixup()? It deals with two things: 1. altering the commit charge against RSS if the mapping is actually writable. 2. Merging the VMA with an adjacent one if possible We don't want to do either of these two things. Even if we do merge the VMA, it ...

applied. I edited the text a bit, for formatting and clarity only (see attached)

Don't use __init but __devinit to define probe function. A pointer to sa11xx_uda1341_probe is passed to the core via platform_driver_register and so the function must not disappear after the module is loaded. Using __init and having HOTPLUG=y and SND_SA11XX_UDA1341=m the following probably oopses: echo -n sa11xx_uda1341.1 > /sys/bus/platform/driver/sa11xx_uda1341/unbind echo -n sa11xx_uda1341.1 > /sys/bus/platform/driver/sa11xx_uda1341/bind Signed-off-by: Uwe Kleine-König ...

On Mon, 8 Sep 2008 15:27:16 +0200 timers are slacking today, at least for select() and poll(), and are a great deal more so than the defaults in this patchkit. The great advantage of the prctl() approach (which is usable) over new system calls and glibc APIs is that it will get used, because the admin can use it just like he uses the "nice" command, on existing software. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power ...

...and new applications, yes. I believe applications should explicitely enable slacking timers. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

No, we'd need the dmidecode output of the two *specific* 3000-N100 machines involved in the issue, so that we can know the specific BIOS version they are running. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

It's almost certainly only 3000 series that's interesting; I think they test the Thinkpads with Linux and wouldn't ship with a quirky BIOS there. The 3000 series only officially supports Windows, and so there can be problems (evidently, mine does something odd with the legacy mux, and newer ones do something odd with the active mux). You might want to poke at the quirk in the patch in this thread and see if one or the other mode works better, or if they're the same on your machines. In ...

You're right, I changed the patch accordingly (I also fixed the read timeout path). From 03b2d04b2e597ec073f2ff61224df1d3dee3b9de Mon Sep 17 00:00:00 2001 From: Matthew Fleming <matthew.fleming@imgtec.com> Date: Mon, 8 Sep 2008 14:10:14 +0100 Subject: [PATCH] MMC: Use timeout values from CSR Currently, the MMC/SD over SPI code has a hard-coded timeout value of 250ms on writes and 100ms on reads. This is correct for SDHC cards and is specified in the spec, but it is not correct for MMC/SD ...

Sorry for the delay in sending out the new patch, I am traveling and thus a little less responsive. Here is the update patch v3...v2 1. Convert flags to unsigned long 2. Move page_cgroup->lock to a bit spin lock in flags v2...v1 1. Fix a small bug, don't call radix_tree_preload_end(), if preload fails This is a rewrite of a patch I had written long back to remove struct page (I shared the patches with Kamezawa, but never posted them anywhere else). I spent the weekend, cleaning them ...

On Mon, 8 Sep 2008 23:35:19 +0200 The basics: * Hello timer is always enabled * STP defaults to off unless you turn it on * Turn STP on/off with brctl. In the existing design, the hello timer always runs, even when STP is not turned on. If STP is not enabled, the packet is just never created. Fixing it would not be hard (or gain much), but would have to deal with complex lock ordering and timer problems, so it isn't worth fixing for current releases. --

I don't know what to say :) A little nitpick: 200 times greater context switch rate :), like Btw. is there a way to make the command to turn STP off work too? brctl stp br0 off Because AFAIK if I shut down STP the hello timer should shut down too, but it still continues to work. Thank you for your time and effort --

--- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

I've no experience of what happens if NX is set to a non-NX-supporting CPU, so can't advise on that at all. But I think you're looking at it the wrong way round - or else I am. Here's the declaration and comment on level2_ident_pgt in head_64.S: NEXT_PAGE(level2_ident_pgt) /* Since I easily can, map the first 1G. * Don't set NX because code runs from these pages. */ PMDS(0, __PAGE_KERNEL_LARGE_EXEC, PTRS_PER_PMD) (The "Since I easily can" comment is there because it used to ...

[Empty message]

[Added CC to Roland McGrath] I think it was just forgotten to be updated. Bit 4 was introduced by Roland McGrath, and it means elf header pages in file-backed private VMAs are dumped even if bit 2 is cleared. Thanks, Subject: [PATCH] coredump_filter: add description of bit 4 There is no description of bit 4 of coredump_filter in the documentation. This patch adds it. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> CC: Roland McGrath <roland@redhat.com> --- ...

On Thu, 04 Sep 2008 22:34:47 -0700 kmalloc becomes more unreliable above 32 kbytes and 100% unreliable above MAX_ORDER. --

Agreed, but that's something to be fixed in a different patch - the existing cgroups code (and cpusets originally) has had this kind of kmalloc call in it. I think it should be reasonably straightforward to replace it with an array of page allocations. Paul --

After some more careful testing with the real program (clamd) I can say that there is no regression. If I scan the exact same files as the box running 2.6.18 I get similar results, the difference is within 10% [1]. There is however a problem with mmap [mmap with N threads is as slow as mmap with 1 thread, i.e. it is sequential :(], pagefaults and disk I/O, I think I am hitting the problem described in this thread (2 years ...

Ulrich -- ping! ---------- Forwarded message ---------- From: Michael Kerrisk <mtk.manpages@googlemail.com> Date: Aug 29, 2008 10:45 PM Subject: Re: paccept() oddity To: Ulrich Drepper <drepper@redhat.com> Cc: Davide Libenzi <davidel@xmailserver.org>, Andrew Morton <akpm@linux-foundation.org>, lkml <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org> Ulrich -- Ping! On Wed, Aug 20, 2008 at 6:50 PM, Michael Kerrisk -- Michael Kerrisk Linux man-pages ...

Here is another follow-on patch. It gets applied after and probably should be consolidated (for final submission) with the following two: tty-fix-loss-of-echoed-characters.patch tty-minor-code-efficiency-and-style-cleanup.patch This one fixes handling of some tab erasure cases and also improves locking for the echo buffer. Thanks, Joe

Okay, seems like vojtech fixed my notebook with a bit of compressed air... a lot of dust came out, and machine works okay now. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

This patch broke kallsyms on powerpc. Please see http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062549.html --

At Sun, 7 Sep 2008 23:56:27 -0700, Hmm... h8300 local symbol head of '.L'. But powerpc don't have '.L' pattern. I think add condition "str[1] == 'L'". -- Yoshinori Sato <ysato@users.sourceforge.jp> --

Seems like the above 3 sequences are asking to be factored out into ide_dma_write_status(); with the latter two possibly factored out into MBR, Sergei --

Hi Linus: This push reverts a patch that caused a regression after 2.6.26. It broke the Camellia algorithm which may be used by IPsec or for encrypted disks. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git or master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Herbert Xu (1): Revert "crypto: camellia - Use kernel-provided bitops, unaligned access helpers" crypto/camellia.c | 84 ...

If you want this to be used by more callsites, it probably doesn't make sense to have it print out a message each time. In fact would it make more sense to have a framework (cpu feature flag?) to detect that we're in any virtualized environment and make this one of the detection routines, and perhaps cache the result. Especially if this detection would be used to manage anything near a hot-path in the page cache as you suggested. But maybe that's overkill. --