[PATCH] x86_64: make GART PTEs uncacheable
This patches fixes the silent data corruption problems being seen using the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia CK804 systems). This fix, to mark the memory regin the GART PTEs reside on as uncacheable, also brings the code in line with the AGP specification. Signed-off-by: Joachim Deguara [EMAIL PROTECTED] --- diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c index 2bac8c6..0bae862 100644 --- a/arch/x86_64/kernel/pci-gart.c +++ b/arch/x86_64/kernel/pci-gart.c @@ -519,7 +519,11 @@ static __init int init_k8_gatt(struct ag gatt_size = (aper_size PAGE_SHIFT) * sizeof(u32); gatt = (void *)__get_free_pages(GFP_KERNEL, get_order(gatt_size)); if (!gatt) - panic(Cannot allocate GATT table); + panic(Cannot allocate GATT table); + if (change_page_attr_addr((unsigned long)gatt, gatt_size PAGE_SHIFT, PAGE_KERNEL_NOCACHE)) + panic(Could not set GART PTEs to uncacheable pages); + global_flush_tlb(); + memset(gatt, 0, gatt_size); agp_gatt_table = gatt; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/28] i386: map enough initial memory to create lowmem mappings
Jeremy Fitzhardinge [EMAIL PROTECTED] writes: Chuck Ebbert wrote: H. Peter Anvin wrote: Andi Kleen wrote: Then we would have seen reports surely? Yes, I would have thought so. It surprised me that such an obvious bug could be there, apparently for a long time. But it's real, and potentially affects everyone. It probably doesn't affect highly modular distros much, since the kernel itself will be relatively small. I never saw a description of the symptoms of encountering this bug. Does it just hang, or what? You get an early-fault message on-screen, assuming that's enabled; otherwise it will just appear to hang. It happens in pagetable_init, when it allocates a new pagetable above the head.S mapping (8M in my case). It will only hit if the kernel size approaches a 4M boundary, since it won't leave enough space mapped to construct the lowmem mappings. It only affects native booting, since under Xen all those mappings have already been constructed. It happened to me with a paravirt kernel that happened to Xen compiled into it, but that was irrelevent (though misleading; the 40k difference in kernel size was enough to make it not happen in a non-Xen kernel). I happened to be looking at this stretch of code and I have realized that this is quite simply the wrong fix. The problem is that it depends intimately on the details of alloc_bootmem_pages_low. Essentially the problem is that when we are setting up the identity mappings in paging_init we assume the identity mappings already exist. If there are holes in the memory map or someone changes the way pages are returned from alloc_bootmem_pages_low() this code will break again. The only way to ensure this will not happen is to do what we do on x86_64 and map the new page table page into our address space before we write to it. Assuming the page we allocate is already mapped is simply not robust. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] i2c: adds support for i2c bus on 8xx
Hi Vitaly,
On Sun, 22 Apr 2007 15:29:37 +0400, Vitaly Bordug wrote:
On Sat, 21 Apr 2007 09:57:07 +0200 Jean Delvare wrote:
I wonder what's the point of having a separate i2c algorithm driver.
We don't expect any other driver than i2c-rpx to ever use it, do we?
In that case, all the code should be added to i2c-rpx directly, this
will makes things more simple and more efficient.
That is how it was back in 2.4 - if you see combine is a good move,
I'm OK with it. But what shouldn't be rpc then - basically rpx(lite) is
8xx-based target, so let's call it all mpc8xx then.
Sure, I'm fine with a name change. If it makes more sense to name that
driver i2c-mpc8xx, that's OK with me.
+ tmo = jiffies + 1 * HZ;
+ while (!(in_8(i2c-i2c_i2cer) 0x11 || time_after(jiffies,
tmo))) ;/* Busy wait, with a timeout */
This could result in a one-second busy loop, not very friendly for
other drivers. It should sleep while waiting. Line too long, please
fold.
Can you please elaborate a little here (or just point to the
similar code)? I assume we should not block here, handling timeout
in a waitqueue...
Blocking is not a problem. The problem is that you are keeping the CPU
for yourself while waiting, for up to one full second. That's not
acceptable. You should at least call schedule() or cond_resced() (I
don't know the difference, I admit) and/or cpu_relax() as is done in
i2c-mpc, i2c-ibm_iic and scx200_acb, or even sleep, as is done in
i2c-omap. Search for time_after in these 4 drivers for examples. I
believe that sleeping is more friendly.
You do not appear to handle repeated start. I can tell because the
code handles all messages the exact same way, be they the first,
second or last message of a group. This means that you don't really
implement the I2C protocol, but an approximation of it. It might be
sufficient for some I2C chips, but others will break. Look in the
specifications of your device for how this could be fixed.
I doubt 8xx has a full-fledged i2c protocol stuff onboard, and basic
code that were residing in 2.4 repo suite my needs quite well (afaict
many others just don't care :)).
I just think it is silly to drop the code already implemented and working
even if it requires some efforts to bring it up to shape.
Well as far as I can see, only the repeated start is missing, so it's
not that far from a complete implementation. If the hardware can do it,
you simply have to add it to the driver. If the hardware really doesn't
do it (which would surprise me, but you never know), of course you
cannot implement it in the driver and we'll have to live with (well,
without) it. But that's definitely an issue to keep in mind if I2C chip
drivers start failing when used together with this bus driver.
+static struct i2c_adapter rpx_ops = {
Could be const?
prolly yes.
+ .owner = THIS_MODULE,
+ .name = m8xx,
Find a better name (e.g. i2c-rpx).
What about mpc8xx?
i2c-mpc8xx then, OK.
+/* Structure for a device driver */
+static struct device_driver i2c_rpx_driver = {
+ .name = fsl-i2c-cpm,
+ .bus = platform_bus_type,
+ .probe = i2c_rpx_probe,
+ .remove = i2c_rpx_remove,
+};
Why don't you declare it as a struct platform_driver, register it with
platform_driver_register() and unregister it with
platform_driver_unregister()?
Well. This stuff belongs to CPM1, of the mpc8xx family, but the
target boards are different, and they may/should provide board
specific inits and filling of platform data. With
platform_driver_register we may end up with ifdef stuff here
(which is evil).
I don't follow you here, sorry. Platform devices are declared by
board-specific code which can include all the needed initialization.
And device-specific data can be carried to the platform driver for
further use. The platform device/driver infrastructure is meant to
handle that kind of situation, so there really is no excuse that I can
see not to use it. i2c-omap and i2c-mpc use it. As a matter of fact you
_are_ declaring a platform driver (.bus = platform_bus_type), just not
using the standard way.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Use TLB batching for MADV_FREE. Adds another 10-15% extra performance to the MySQL sysbench results on my quad core system. Signed-off-by: Rik van Riel [EMAIL PROTECTED] --- Rik van Riel wrote: I've added a 5th column, with just your mmap_sem patch and without my madv_free patch. It is run with the glibc patch, which should make it fall back to MADV_DONTNEED after the first MADV_FREE call fails. With the attached patch to make MADV_FREE use tlb batching, not only do we gain an additional 10-15% performance but Nick's mmap_sem patch also shows the performance increase that we expected to see. It looks like the tlb flushes (and IPIs) from zap_pte_range() could have been the problem. They're gone now. The second column from the right has Nick's patch and my own two patches. Performance with 16 threads is almost triple what it used to be... vanilla glibc glibc glibcglibc glibc glibc madv_free madv_free madv_free madv_free mmap_sem mmap_sem mmap_sem tlb batch tlb_batch threads 1 610 609 596 545 534 547 537 21032113611961200118012931194 41070112820142024202722482040 81000108816652087208923141869 16779107313101999201222141557 Now that I think about it - this is all with the rawhide kernel configuration, which has an ungodly number of debug config options enabled. I should try this with a more normal kernel, on various different systems. This is for another day. :) First some ebizzy runs... -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. --- linux-2.6.20.x86_64/mm/memory.c.orig 2007-04-23 02:48:36.0 -0400 +++ linux-2.6.20.x86_64/mm/memory.c 2007-04-23 02:54:42.0 -0400 @@ -677,11 +677,15 @@ static unsigned long zap_pte_range(struc remove_exclusive_swap_page(page); unlock_page(page); } - ptep_clear_flush_dirty(vma, addr, pte); - ptep_clear_flush_young(vma, addr, pte); SetPageLazyFree(page); if (PageActive(page)) deactivate_tail_page(page); + ptent = *pte; + set_pte_at(mm, addr, pte, + pte_mkclean(pte_mkold(ptent))); + /* tlb_remove_page frees it again */ + get_page(page); + tlb_remove_page(tlb, page); continue; } }
Re: [patch] CFS scheduler, -v5
* Nick Piggin [EMAIL PROTECTED] wrote: yeah - but they'll all be quad core, so the SMP timeslice multiplicator should do the trick. Most of the CFS testers use single-CPU systems. But desktop users could have have quad thread and even 8 thread CPUs soon, [...] SMT is indeed an issue, so i think what should be used to scale timeslices isnt num_online_cpus(), but the sum of all CPU's -cpu_power value (scaled down by SCHED_LOAD_SCALE). That way if the thread is not a 'full CPU', then the scaling will be proportionally smaller. Can you see any hole in that? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
crash with CFS v4 and qemu/kvm (was: [patch] CFS scheduler, v4)
On Friday 20 April 2007, Ingo Molnar wrote: i'm pleased to announce release -v4 of the CFS patchset. Hi Ingo, hi Avi, hi all, I'm trying to use kvm-20 with cfs v4 and get a crash: [EMAIL PROTECTED]:~$ /usr/local/kvm/bin/qemu -snapshot /mnt/data/virtual/qemu/winxp.img kvm_run: failed entry, reason 7 kvm_run returned -8 It works (though it is a bit slow) if I start qemu with strace, so for me it looks like a race condition? I did not test any earlier versions of cfs and kvm in combination - I can't say if it happens there as well. -- Regards, Chris signature.asc Description: This is a digitally signed message part.
Re: [PATCH] x86_64: make GART PTEs uncacheable
On Monday 23 April 2007 11:14:10 Joachim Deguara wrote: This patches fixes the silent data corruption problems being seen using the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia CK804 systems). Performance numbers? How much slower does this make this? Is it still faster than swiotlb? Also this will always split up the direct memory mapping of the kernel, so you'll lose more TLB entries even for other data. This fix, to mark the memory regin the GART PTEs reside on as uncacheable, also brings the code in line with the AGP specification. Where in the AGP specification? I can't find any such requirement in AGPv3 -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] workqueue: cancel_rearming_delayed_work/workqueue usage warning
On Fri, Apr 20, 2007 at 09:23:48PM +0400, Oleg Nesterov wrote: On 04/20, Jarek Poplawski wrote: Here is my proposal to make things clearer: (this time on 2.6.21-rc7) CC: David Chinner [EMAIL PROTECTED] CC: Oleg Nesterov [EMAIL PROTECTED] Signed-off-by: Jarek Poplawski [EMAIL PROTECTED] --- diff -Nurp 2.6.21-rc7-/kernel/workqueue.c 2.6.21-rc7/kernel/workqueue.c --- 2.6.21-rc7-/kernel/workqueue.c 2007-04-18 10:14:16.0 +0200 +++ 2.6.21-rc7/kernel/workqueue.c 2007-04-20 13:56:51.0 +0200 @@ -662,6 +662,8 @@ EXPORT_SYMBOL(flush_scheduled_work); * cancel_rearming_delayed_workqueue - reliably kill off a delayed work whose handler rearms the delayed work. * @wq: the controlling workqueue structure * @dwork: the delayed work struct + * + * WARNING: use only with handlers, which rearm unconditionally with delay 0 */ Nit: it is ok if the work re-arms itself with delay == 0 sometimes. What we need is that the handler use delay 0 eventually. Probably it would be shorter to write it yourself, because I'm not sure of your intentions: so, you think we can call this function with such a work? I'd suggest to re-diff against -mm tree. I don't think this patch can find its way to the soon to be released 2.6.21. The current thread seems to confirm my initial fear, this function is not explained enough, so it should help to remove errors as soon as possible from the current code. And I hope this functions will work other way soon... Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODULE_MAINTAINER
On 04/04/2007 06:38 PM, Rene Herman wrote: Rusty? On 04/04/2007 06:00 PM, Alan Cox wrote: Given that people seem to agree that authorship information has no place in the binary, that might actually be best. Authorship information is very useful in the binary, especially when you have to get lawyers involved in explaining things to people. Okay. So, MODULE_AUTHOR be gone? Not if I have anything to do with it. Putting maintainer in is not a bad idea but that assumes it gets maintained, the beauty of _AUTHOR is that it's generally right and stays that way or approximately so. Case in point; someone is working with me in private on a new mitsumi legacy CD-ROM driver. He's authoring the actual driver and upto now I've just been doing some peripheral module infrastructure work. Given that I have the hardware to test the thing, I'll be the maintainer though. Adding myself as a MODULE_AUTHOR would be largely incorrect and adding myself as the _only_ MODULE_AUTHOR would be so factually incorrect I wouldn't, even if only from a credits point of view. Yet I do want to make sure people contact me, and not the MODULE_AUTHOR (which will happen no matter the MAINTAINERS file). Other cases-in-point; I've lately been rummaging through sound/isa a bit. Nothing much copyrightable again but especially in those situations where (some of the) original authors are no longer active, I do again want people to contact me about them if needed. And all the which one of the three people listed here is maintaining this is yet another. MODULE_AUTHOR may be approximately right but especially with old drivers it also has little relation with who's maintaining the thing. If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER please? It doesn't need to be added to drivers directly, it can just grow (and being inside the code, I suppose it'll likely stay up to date better than the MAINTAINERS file). Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Bitbanging i2c bus driver using the GPIO API
Lennart, On Sun, 22 Apr 2007 11:41:51 -0400, Lennart Sorensen wrote: On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote: The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not much since then. I am not familiar with the hardware so I can't comment on which chips are supposed to work and which aren't. Well 2.6.18's scx200_acb works on the geode LX module I have, but no on the geode sc1200 module (where scx200_i2c does work). scx200_acb doesn't detect any device that it can drive (nothing in dmesg at all when loaded) on the sc1200. On the SCx200, the scx200_acb driver doesn't actually detect the device. It uses arbitrary I/O addresses and hopes for the best. By default, two buses are created, at 0x820 and 0x840. This might simply not be the right addresses for your board. See Documentation/i2c/busses/scx200_acb. You should enable CONFIG_I2C_DEBUG_BUS and see what the driver says when being loaded. I seem to remember there has been a patch floating around to auto-detect the right ports back in June 2006, but it seems to have been lost somehow. Jordan, do you remember? I believe the main changes that happened to scx200_acb was adding support for the newer CS chipsets, such as the one used with the geode LX (which does work now). Not only. There was also a log of bug fixing. -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make GART PTEs uncacheable
On Monday 23 April 2007 11:32, Andi Kleen wrote: On Monday 23 April 2007 11:14:10 Joachim Deguara wrote: This patches fixes the silent data corruption problems being seen using the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia CK804 systems). Performance numbers? How much slower does this make this? Is it still faster than swiotlb? I can work on that as a side note, but while the GART IOMMU is still in the kernel then we need this fix. Also this will always split up the direct memory mapping of the kernel, so you'll lose more TLB entries even for other data. This fix, to mark the memory regin the GART PTEs reside on as uncacheable, also brings the code in line with the AGP specification. Where in the AGP specification? I can't find any such requirement in AGPv3 Mark pointed this out and he can answer best. I believe he was referring to section 5.3.4 point 8: Core-logic accesses to the GART are not guaranteed to be coherent with host processor caches. In order to avoid having to flush the cache after every GART update, portable system software should place the GART in a range of the physical memory space that is considered un-cacheable by host processors. (A good example is mapping the GART as UC in an IntelÒ PentiumÒ II processor). However, the specification does not preclude the placement of the GART in cachable memory space in cases where the coherency is guaranteed through some hardware or software mechanism. updated patch follows with corrected long lone. -Joachim --- This patches fixes the silent data corruption problems being seen using the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia CK804 systems). This fix to mark the memory regin the GART PTEs reside on as uncacheable also brings the code in line with the AGP specification. Signed-off-by: Joachim Deguara [EMAIL PROTECTED] --- diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c index 2bac8c6..8fb4957 100644 --- a/arch/x86_64/kernel/pci-gart.c +++ b/arch/x86_64/kernel/pci-gart.c @@ -519,7 +519,12 @@ static __init int init_k8_gatt(struct ag gatt_size = (aper_size PAGE_SHIFT) * sizeof(u32); gatt = (void *)__get_free_pages(GFP_KERNEL, get_order(gatt_size)); if (!gatt) - panic(Cannot allocate GATT table); + panic(Cannot allocate GATT table); + if (change_page_attr_addr((unsigned long)gatt, gatt_size PAGE_SHIFT, + PAGE_KERNEL_NOCACHE)) + panic(Could not set GART PTEs to uncacheable pages); + global_flush_tlb(); + memset(gatt, 0, gatt_size); agp_gatt_table = gatt; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make GART PTEs uncacheable
On Monday 23 April 2007 11:45:11 Joachim Deguara wrote: I can work on that as a side note, but while the GART IOMMU is still in the kernel then we need this fix. If it's too slow we can just use swiotlb instead. Probably while enlarging it. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v5 (build problem - make headers_check fails)
* Zach Carter [EMAIL PROTECTED] wrote:
FYI, make headers_check seems to fail on this:
[EMAIL PROTECTED] linux-2.6]$ make headers_check
make[2]: *** No rule to make target
`/src/linux-2.6/usr/include/linux/.check.sched.h', needed by
`__headerscheck'. Stop.
make[1]: *** [linux] Error 2
make: *** [headers_check] Error 2
[EMAIL PROTECTED] linux-2.6]$
This also fails if I have CONFIG_HEADERS_CHECK=y in my .config
ah, indeed - the patch below should fix this. It will be in -v6.
Ingo
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -2,7 +2,6 @@
#define _LINUX_SCHED_H
#include linux/auxvec.h /* For AT_VECTOR_SIZE */
-#include linux/rbtree.h /* For run_node */
/*
* cloning flags:
*/
@@ -37,6 +36,8 @@
#ifdef __KERNEL__
+#include linux/rbtree.h /* For run_node */
+
struct sched_param {
int sched_priority;
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Nick Piggin wrote: Rik van Riel wrote: I've added a 5th column, with just your mmap_sem patch and without my madv_free patch. It is run with the glibc patch, which should make it fall back to MADV_DONTNEED after the first MADV_FREE call fails. Thanks! (I edited slightly so it doesn't wrap) vanilla new glibc madv_freemmap_semboth threads 1 610 609 596 534 545 210321136119611801200 410701128201420272024 810001088166520892087 167791073131020121999 Not doing the mprotect calls is the big one I guess, especially the fact that we don't need to take the mmap_sem for writing. Yes. With both our patches, single and two thread performance with MySQL sysbench is somewhat better than with just your patch, 4 and 8 thread performance are basically the same and just your patch gives a slight benefit with 16 threads. I guess I should benchmark up to 64 or 128 threads tomorrow, to see if this is just luck or if the cache benefit of doing the page faults and reusing hot pages is faster than not having page faults at all. I should run some benchmarks on other systems, too. Some of these results could be an artifact of my quad core CPU. The results could be very different on other systems... I'm getting the 16 core box out of retirement as we speak :) OK, 10 runs at 1 client, 2.6.21-rc6, MySQL version 5.33, and new Jakub's glibc gives a 99.9% confidence of: vanilla: 467.2 +/- 7.9 (tps) mmap_sem: 470.5 +/- 9.3 (tps) However, it seems those means jump around a bit from boot to boot, so there could be some some memory placement luck for cache and/or NUMA goodness involved. So I think it is safe to say that the mmap_sem patch doesn't hurt single threaded performance (from looking at the numbers and the patch). And that's the most important thing for that patch. I'll post some scalability results tomorrow. From my first round of tests, after new glibc and the mmap_sem patch, it doesn't seem like rwsem improvements, private futexes, or avoiding zero_page make any significant differences. I haven't tested your MADV_FREE patch yet. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix chapter reference in CodingStyle
Greetings, commit 226a6b84aaaf1fac7a5d41cf4e7387fd9ba895d5 renumbered Chapter 11 in Documentation/CodingStyle to Chapter 12, but it didn't update the reference to that chapter further down in the file. This patch corrects the chapter reference. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/CodingStyle |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 9069189..899777f 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -625,7 +625,7 @@ language. There appears to be a common misperception that gcc has a magic make me faster speedup option called inline. While the use of inlines can be -appropriate (for example as a means of replacing macros, see Chapter 11), it +appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Nick Piggin wrote: I haven't tested your MADV_FREE patch yet. Good. It turned out that one behaved a bit strange without tlb batching anyway. I'm now running ebizzy across the whole set of kernels I tested before, and will post the results in a bit. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: crash with CFS v4 and qemu/kvm (was: [patch] CFS scheduler, v4)
* Christian Hesse [EMAIL PROTECTED] wrote: On Friday 20 April 2007, Ingo Molnar wrote: i'm pleased to announce release -v4 of the CFS patchset. Hi Ingo, hi Avi, hi all, I'm trying to use kvm-20 with cfs v4 and get a crash: [EMAIL PROTECTED]:~$ /usr/local/kvm/bin/qemu -snapshot /mnt/data/virtual/qemu/winxp.img kvm_run: failed entry, reason 7 kvm_run returned -8 It works (though it is a bit slow) if I start qemu with strace, so for me it looks like a race condition? hm. Can you work it around with: echo 0 /proc/sys/kernel/sched_granularity_ns ? If yes then this is a wakeup race: some piece of code relies on the upstream scheduler preempting the waker task immediately in 99% of the cases. and you might want to test -v5 too which i released earlier today. It has no bugfix in this area though, so it will likely still trigger this race - but it will also hopefully be even more pleasant to use than -v4 ;-) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.21-rc7: known regressions
At Fri, 20 Apr 2007 20:26:10 +0200, I wrote: At Fri, 20 Apr 2007 11:18:07 -0700, Andrew Morton wrote: On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: Good to hear! I forgot the patch description and sign-off, so here it is again: [PATCH] ALSA: intel8x0 - Fix Oops in crash kernel When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init(). Neat, thanks. Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it? It should be safe (as I already merged ALSA tree for 2.6.22), but I'd like to test the following before merging 2.6.21: - suspend/resume works - no severe problem even if request_irq() fails I'll check this in this weekend, so let's hold on. Both seem OK as far as I tested. So, feel free to push it to 2.6.21 if it's still allowed. Otherwise I'll queue it up to stable tree later. Thanks, Takashi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Rik van Riel wrote: Use TLB batching for MADV_FREE. Adds another 10-15% extra performance to the MySQL sysbench results on my quad core system. Signed-off-by: Rik van Riel [EMAIL PROTECTED] --- Rik van Riel wrote: I've added a 5th column, with just your mmap_sem patch and without my madv_free patch. It is run with the glibc patch, which should make it fall back to MADV_DONTNEED after the first MADV_FREE call fails. With the attached patch to make MADV_FREE use tlb batching, not only do we gain an additional 10-15% performance but Nick's mmap_sem patch also shows the performance increase that we expected to see. It looks like the tlb flushes (and IPIs) from zap_pte_range() could have been the problem. They're gone now. I guess it is a good idea to batch these things. But can you do that on all architectures? What happens if your tlb flush happens after another thread already accesses it again, or after it subsequently gets removed from the address space via another CPU? The second column from the right has Nick's patch and my own two patches. Performance with 16 threads is almost triple what it used to be... vanilla glibc glibc glibcglibc glibc glibc madv_free madv_free madv_free madv_free mmap_sem mmap_sem mmap_sem tlb batch tlb_batch threads 1 610 609 596 545 534 547 537 21032113611961200118012931194 41070112820142024202722482040 81000108816652087208923141869 16779107313101999201222141557 Now that I think about it - this is all with the rawhide kernel configuration, which has an ungodly number of debug config options enabled. I should try this with a more normal kernel, on various different systems. This is for another day. :) First some ebizzy runs... --- linux-2.6.20.x86_64/mm/memory.c.orig2007-04-23 02:48:36.0 -0400 +++ linux-2.6.20.x86_64/mm/memory.c 2007-04-23 02:54:42.0 -0400 @@ -677,11 +677,15 @@ static unsigned long zap_pte_range(struc remove_exclusive_swap_page(page); unlock_page(page); } - ptep_clear_flush_dirty(vma, addr, pte); - ptep_clear_flush_young(vma, addr, pte); SetPageLazyFree(page); if (PageActive(page)) deactivate_tail_page(page); + ptent = *pte; + set_pte_at(mm, addr, pte, + pte_mkclean(pte_mkold(ptent))); + /* tlb_remove_page frees it again */ + get_page(page); + tlb_remove_page(tlb, page); continue; } } -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] introduce HIGH_ORDER delineating easily reclaimable orders
Andrew Morton wrote: On Sat, 21 Apr 2007 01:28:43 -0700 Andrew Morton [EMAIL PROTECTED] wrote: It would have been better to have patched page_alloc.c independently, then to have used HIGH_ORDER in lumpy: increase pressure at the end of the inactive list. Actually that doesn't matter, because I plan on lumping all the lumpy patches together into one lump. I was going to duck patches #2 and #3, such was my outrage. But given that it's all lined up to be a single patch, followup cleanup patches will fit in OK. Please. Yes. Its funny how you can get so close to a change that you can no longer see the obvious warts on it. I am actually travelling today, so it'll be tommorrow now. But I'll roll the cleanups and get them to you. I can also offer you a clean drop in lumpy stack with the HIGH_ORDER change pulled out to the top once you are happy. -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] Fix PF_NOFREEZE and freezeable race
On Fri, Apr 20, 2007 at 10:02:08PM +0400, Oleg Nesterov wrote:
On 04/19, Rafael J. Wysocki wrote:
On Thursday, 19 April 2007 14:02, Gautham R Shenoy wrote:
This patch fixes the race pointed out by Oleg Nesterov.
* Freezer marks a thread as freezeable.
* The thread now marks itself PF_NOFREEZE causing it to
freeze on calling try_to_freeze(). Thus the task is frozen, even though
it doesn't want to.
* Subsequent thaw_processes() will also fail to thaw the task since it is
marked PF_NOFREEZE.
Avoid this problem by checking the current task's PF_NOFREEZE status in
the
refrigerator before marking current as frozen.
Signed-off-by: Gautham R Shenoy [EMAIL PROTECTED]
Looks good, although I'm not sure if we don't need to call
recalc_sigpending()
for tasks that turn out to be PF_NOFREEZE.
I agree, we should clear TIF_SIGPENDING. It is not so critical for user-space
tasks, but for the kernel thread it may remain pending forever, causing subtle
failures.
Gautham, isn't it possible to make a more simpler patch ? Just add PF_NOFREEZE
check to frozen_process,
static inline void frozen_process(struct task_struct *p)
{
if (!unlikely(current-flags PF_NOFREEZE)) {
p-flags |= PF_FROZEN;
wmb();
}
clear_tsk_thread_flag(p, TIF_FREEZE);
}
No?
Actually yes. The idea anyway was to check one last time before declaring
ourselves as frozen. So I thought the best place was inside refrigerator since
we are already holding the task_lock there.
I wasn't too sure about calling recalc_sigpending(), but now that you
mention it, I agree, this would be a nicer way to do it.
Btw, since frozen_process is currently being called only from
refrigerator, I am wondering if we still need the struct task_struct *p
parameter there. It's very unlikely that some other task would mark a
particular task as frozen. No?
Anyways, Andrew, Could you please replace the earlier sent patch titled
fix_pf_nofreeze_and_freezeable_race.patch with the following one?
Thanks and Regards
gautham.
--
This patch fixes the race pointed out by Oleg Nesterov.
* Freezer marks a thread as freezeable.
* The thread now marks itself PF_NOFREEZE causing it to
freeze on calling try_to_freeze(). Thus the task is frozen, even though
it doesn't want to.
* Subsequent thaw_processes() will also fail to thaw the task since it is
marked PF_NOFREEZE.
Avoid this problem by checking the task's PF_NOFREEZE status in
frozen_processes() before marking the task as frozen.
Signed-off-by: Gautham R Shenoy [EMAIL PROTECTED]
---
include/linux/freezer.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc6/include/linux/freezer.h
===
--- linux-2.6.21-rc6.orig/include/linux/freezer.h
+++ linux-2.6.21-rc6/include/linux/freezer.h
@@ -57,8 +57,10 @@ static inline int thaw_process(struct ta
*/
static inline void frozen_process(struct task_struct *p)
{
- p-flags |= PF_FROZEN;
- wmb();
+ if (!unlikely(p-flags PF_NOFREEZE)) {
+ p-flags |= PF_FROZEN;
+ wmb();
+ }
clear_tsk_thread_flag(p, TIF_FREEZE);
}
--
Gautham R Shenoy
Linux Technology Center
IBM India.
Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Nick Piggin wrote: It looks like the tlb flushes (and IPIs) from zap_pte_range() could have been the problem. They're gone now. I guess it is a good idea to batch these things. But can you do that on all architectures? What happens if your tlb flush happens after another thread already accesses it again, or after it subsequently gets removed from the address space via another CPU? I have thought about this a lot tonight, and have come to the conclusion that they are ok. The reason is simple: 1) we do the TLB flush before we return from the madvise(MADV_FREE) syscall. 2) anything that accessess the pages between the start and end of the MADV_FREE procedure does not know in which order we go through the pages, so it could hit a page either before or after we get to processing it 3) because of this, we can treat any such accesses as happening simultaneously with the MADV_FREE and as illegal, aka undefined behaviour territory and we do not need to worry about them 4) because we flush the tlb before releasing the page table lock, other CPUs cannot remove this page from the address space - they will block on the page table lock before looking at this pte -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Rik van Riel wrote: Nick Piggin wrote: It looks like the tlb flushes (and IPIs) from zap_pte_range() could have been the problem. They're gone now. I guess it is a good idea to batch these things. But can you do that on all architectures? What happens if your tlb flush happens after another thread already accesses it again, or after it subsequently gets removed from the address space via another CPU? I have thought about this a lot tonight, and have come to the conclusion that they are ok. The reason is simple: 1) we do the TLB flush before we return from the madvise(MADV_FREE) syscall. 2) anything that accessess the pages between the start and end of the MADV_FREE procedure does not know in which order we go through the pages, so it could hit a page either before or after we get to processing it 3) because of this, we can treat any such accesses as happening simultaneously with the MADV_FREE and as illegal, aka undefined behaviour territory and we do not need to worry about them Yes, but I'm wondering if it is legal in all architectures. 4) because we flush the tlb before releasing the page table lock, other CPUs cannot remove this page from the address space - they will block on the page table lock before looking at this pte We don't when the ptl is split. What the tlb flush used to be able to assume is that the page has been removed from the pagetables when they are put in the tlb flush batch. I'm not saying there is any bugs, but just suggesting there might be. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH(experimental) 2/2] Fix freezer-kthread_stop race
On Sat, Apr 21, 2007 at 01:12:09AM +0400, Oleg Nesterov wrote:
On 04/19, Gautham R Shenoy wrote:
@@ -63,12 +74,16 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
+ task_lock(current);
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
if (!frozen(current))
break;
+ task_unlock(current);
schedule();
+ task_lock(current);
}
+ task_unlock(current);
pr_debug(%s left refrigerator\n, current-comm);
current-state = save;
Just curious, why this change?
This can race with hold_freezer_for_task() calling thaw_process. Earlier
thaw_process(p) was called only after the process 'p' was frozen.
Now with hold_freezer_for_task(), we can as well call thaw_process(p)
when 'p' is in the freezing stage. Hence the task_lock.
I know it's ugly, but couldn't think of any other alternative at that time.
+int hold_freezer_for_task(struct task_struct *p)
+{
+ int ret = 0;
+ spin_lock(freezer_status.lock);
+ if (freezer_status.count = 0)
+ {
+ set_tsk_thread_flag(p, TIF_FREEZER_HELD);
+ thaw_process(p);
+ freezer_status.count++;
+ ret = 1;
+ }
+ spin_unlock(freezer_status.lock);
+
+ return ret;
+}
I think this can work if it is used only in kthread_stop(). But what if
another task wants to do hold_freezer_for_task(p) ? freezer_status.count
is recursive, but TIF_FREEZER_HELD is not. IOW, I believe this is not
generic enough.
Yes. If more than one tasks want another task to be temporarily thawed, this
won't work. I hadn't anticipated such a case.
Also, you are planning to add different freezing states (FE_HOTPLUG_CPU,
FE_SUSPEND, etc). In that case each of them needs a separate .count, because
it should be negative when try_to_freeze_tasks() returns. Now consider
the case when we are doing freeze_processes(FE_A | FE_B) ...
So can't we in that case find out the weight of the freeze_event variable and
subtract that weight from the count (if the count is =0 ) ?
Oleg.
Thanks for the review.
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 3/3] freezer: Fix problem with kthread_stop
Hi!
Fix the problem with kthread_stop() that causes the freezer to fail if a
freezable thread is attempting to stop a frozen one and that may cause the
freezer to fail if the thread being stopped is freezable and
try_to_freeze_tasks() is running concurrently with kthread_stop().
Parse error.
Index: linux-2.6.21-rc6-mm1/kernel/kthread.c
===
--- linux-2.6.21-rc6-mm1.orig/kernel/kthread.c2007-04-09
15:23:48.0 +0200
+++ linux-2.6.21-rc6-mm1/kernel/kthread.c 2007-04-22 19:05:29.0
+0200
@@ -232,6 +233,14 @@ int kthread_stop(struct task_struct *k)
/* Now set kthread_should_stop() to true, and wake it up. */
kthread_stop_info.k = k;
+ if (!freezer_should_exempt(current)) {
+ /* We are freezable, so we must make sure that the thread being
+ * stopped is not frozen and will not be frozen until it dies
+ */
+ freezer_exempt(k);
+ if (frozen(k))
+ clear_frozen_flag(k);
+ }
wake_up_process(k);
put_task_struct(k);
Do we need to take some locks to access other process' flags? Or do
frozen_exempt() etc take enough locks, already?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 1/3] Separate freezer from PM code
Hi! Now that the freezer is used by kprobes, it is no longer a PM-specific piece of code. Move the freezer code out of kernel/power and introduce the CONFIG_FREEZER option that will be chosen automatically if PM or KPROBES is set. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] ACK. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
On Mon, Apr 23, 2007 at 08:21:37PM +1000, Nick Piggin wrote: I guess it is a good idea to batch these things. But can you do that on all architectures? What happens if your tlb flush happens after another thread already accesses it again, or after it subsequently gets removed from the address space via another CPU? Accessing the page by another thread before madvise (MADV_FREE) returns is undefined behavior, it can act as if that access happened right before the madvise (MADV_FREE) call or right after it. That's ok for glibc and supposedly any other malloc implementation, madvise (MADV_FREE) is called while holding containing's arena lock and for whatever malloc implementaton, madvise (MADV_FREE) would be part of free operations and you definitely need some synchronization between one thread freeing some memory and other thread deciding to reuse that memory and return it from malloc/realloc/calloc/etc. My only concern is whether using non-atomic update of the pte is ok or not. ptep_test_and_clear_young/ptep_test_and_clear_dirty Rik's patch was doing before are done using atomic instructions, at least on x86_64. The operation we want for MADV_FREE is, clear young/dirty bits if they have been set on entry to the MADV_FREE madvise call, undefined values for these 2 bits if some other task modifies the young/dirty bits concurrently with this MADV_FREE zap_page_range, but I'd say other bits need to be unmodified. Now, is there some kernel code which while either not holding corresponding mmap_sem at all or holding it just down_read modifies other bits in the pte? If yes, we need to do this clearing atomically, basically do a cmpxchg loop until we succeed to clear the 2 bits and then flush the tlb if any of them was set before (ptep_test_and_clear_dirty_and_young?), if not, set_pte_at is ok and faster than a lock prefixed insn. Jakub - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lazy freeing of memory through MADV_FREE
Use TLB batching for MADV_FREE. Adds another 10-15% extra performance to the MySQL sysbench results on my quad core system. Signed-off-by: Rik van Riel [EMAIL PROTECTED] --- Nick Piggin wrote: 3) because of this, we can treat any such accesses as happening simultaneously with the MADV_FREE and as illegal, aka undefined behaviour territory and we do not need to worry about them Yes, but I'm wondering if it is legal in all architectures. It's similar to trying to access memory during an munmap. You may be able to for a short time, but it'll come back to haunt you. 4) because we flush the tlb before releasing the page table lock, other CPUs cannot remove this page from the address space - they will block on the page table lock before looking at this pte We don't when the ptl is split. Even then we do. Each invocation of zap_pte_range() only touches one page table page, and it flushes the TLB before releasing the page table lock. What the tlb flush used to be able to assume is that the page has been removed from the pagetables when they are put in the tlb flush batch. All the tlb flush code seems to assume is that the tlb entries should be invalidated. I'm not saying there is any bugs, but just suggesting there might be. Jakub found a potential bug, in that I did not use an atomic operation to clear the page table entries. I've attached a new patch which simply uses ptep_test_and_clear_dirty/young to get rid of the dirty and accessed bits. It uses the same atomic accesses we use elsewhere in the VM and the code is a line shorter than before. Andrew, please use this one. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. --- linux-2.6.20.x86_64/mm/memory.c.orig 2007-04-23 02:48:36.0 -0400 +++ linux-2.6.20.x86_64/mm/memory.c 2007-04-23 02:54:42.0 -0400 @@ -677,11 +677,14 @@ static unsigned long zap_pte_range(struc remove_exclusive_swap_page(page); unlock_page(page); } - ptep_clear_flush_dirty(vma, addr, pte); - ptep_clear_flush_young(vma, addr, pte); + ptep_test_and_clear_dirty(vma, addr, pte); + ptep_test_and_clear_young(vma, addr, pte); SetPageLazyFree(page); if (PageActive(page)) deactivate_tail_page(page); + /* tlb_remove_page frees it again */ + get_page(page); + tlb_remove_page(tlb, page); continue; } }
[PATCH] pata_ali: More work
Still don't know why some people see problems with ATAPI devices
specifically but here are some more small fixes done while searching for
the root problem (some of these fixes are overconservative but that can
be fixed *after* the thing works fully)
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/ata/pata_ali.c
linux-2.6.21-rc6-mm1/drivers/ata/pata_ali.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/ata/pata_ali.c 2007-04-12
14:15:03.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/ata/pata_ali.c 2007-04-23 11:34:40.423648592
+0100
@@ -346,6 +346,16 @@
return 0;
}
+static int ali_check_atapi_dma_20(struct ata_queued_cmd *qc)
+{
+ if (qc-dma_dir == DMA_TO_DEVICE)
+ return -1;
+ /* Don't do DMA except for whole blocks */
+ if (qc-nbytes 511)
+ return -1;
+ return 0;
+}
+
static struct scsi_host_template ali_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -389,7 +399,6 @@
.qc_prep= ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
- .check_atapi_dma= ali_check_atapi_dma,
.data_xfer = ata_data_xfer,
@@ -432,7 +441,7 @@
.qc_prep= ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
- .check_atapi_dma= ali_check_atapi_dma,
+ .check_atapi_dma= ali_check_atapi_dma_20,
.data_xfer = ata_data_xfer,
@@ -629,22 +638,22 @@
.udma_mask = 0x1f,
.port_ops = ali_c2_port_ops
};
- /* Revision 0xC3 is UDMA100 */
+ /* Revision 0xC3 is UDMA66 for now */
static struct ata_port_info info_c3 = {
.sht = ali_sht,
.flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
ATA_FLAG_PIO_LBA48,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
- .udma_mask = 0x3f,
+ .udma_mask = 0x1f,
.port_ops = ali_c2_port_ops
};
- /* Revision 0xC4 is UDMA133 */
+ /* Revision 0xC4 is UDMA100 */
static struct ata_port_info info_c4 = {
.sht = ali_sht,
.flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
ATA_FLAG_PIO_LBA48,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
- .udma_mask = 0x7f,
+ .udma_mask = 0x3f,
.port_ops = ali_c2_port_ops
};
/* Revision 0xC5 is UDMA133 with LBA48 DMA */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 2/3] freezer: Introduce freezer_flags
Hi! From: Rafael J. Wysocki [EMAIL PROTECTED] Move all of the freezer-related flags to a separate field in task_struct and introduce functions to operate them using set_bit() etc. Looks sane to me. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] Containers (V8): Cpusets hooked into containers
[EMAIL PROTECTED] wrote: This patch removes the process grouping code from the cpusets code, instead hooking it into the generic container system. This temporarily adds cpuset-specific code in kernel/container.c, which is removed by the next patch in the series. Signed-off-by: Paul Menage [EMAIL PROTECTED] [snip] Index: container-2.6.20-new/init/Kconfig === --- container-2.6.20-new.orig/init/Kconfig +++ container-2.6.20-new/init/Kconfig @@ -239,17 +239,12 @@ config IKCONFIG_PROC through /proc/config.gz. config CONTAINERS - bool Container support - help - This option will let you create and manage process containers, - which can be used to aggregate multiple processes, e.g. for - the purposes of resource tracking. - - Say N if unsure + bool Hi Paul, This looks like some patch generation error. Description for containers should not be removed after applying this patch. --Vaidy config CPUSETS bool Cpuset support depends on SMP + select CONTAINERS help This option will let you create and manage CPUSETs which allow dynamically partitioning a system into sets of CPUs and @@ -278,6 +273,11 @@ config SYSFS_DEPRECATED If you are using a distro that was released in 2006 or later, it should be safe to say N here. +config PROC_PID_CPUSET + bool Include legacy /proc/pid/cpuset file + depends on CPUSETS + default y + config RELAY bool Kernel-user space relay support (formerly relayfs) help [snip] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: PageLRU can be non-atomic bit operation
Hi
PageLRU flag operation is protected by zone-lru_lock, so
SetPageLRU/ClearPageLRU
can be replaced to __SetPageLRU/__ClearPageLRU non-atomic bit operation.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.21-rc7.org/include/linux/page-flags.h
linux-2.6.21-rc7/include/linux/page-flags.h
--- linux-2.6.21-rc7.org/include/linux/page-flags.h 2007-04-17
16:36:05.0 +0900
+++ linux-2.6.21-rc7/include/linux/page-flags.h 2007-04-23
18:28:19.0 +0900
@@ -148,8 +148,7 @@ static inline void SetPageUptodate(struc
#define TestClearPageDirty(page) test_and_clear_bit(PG_dirty, (page)-flags)
#define PageLRU(page) test_bit(PG_lru, (page)-flags)
-#define SetPageLRU(page) set_bit(PG_lru, (page)-flags)
-#define ClearPageLRU(page) clear_bit(PG_lru, (page)-flags)
+#define __SetPageLRU(page) __set_bit(PG_lru, (page)-flags)
#define __ClearPageLRU(page) __clear_bit(PG_lru, (page)-flags)
#define PageActive(page) test_bit(PG_active, (page)-flags)
diff -Nrup linux-2.6.21-rc7.org/mm/migrate.c linux-2.6.21-rc7/mm/migrate.c
--- linux-2.6.21-rc7.org/mm/migrate.c 2007-04-17 16:36:05.0 +0900
+++ linux-2.6.21-rc7/mm/migrate.c 2007-04-23 18:30:43.0 +0900
@@ -52,7 +52,7 @@ int isolate_lru_page(struct page *page,
if (PageLRU(page)) {
ret = 0;
get_page(page);
- ClearPageLRU(page);
+ __ClearPageLRU(page);
if (PageActive(page))
del_page_from_active_list(zone, page);
else
diff -Nrup linux-2.6.21-rc7.org/mm/swap.c linux-2.6.21-rc7/mm/swap.c
--- linux-2.6.21-rc7.org/mm/swap.c 2007-02-05 03:44:54.0 +0900
+++ linux-2.6.21-rc7/mm/swap.c 2007-04-23 18:29:51.0 +0900
@@ -364,7 +364,7 @@ void __pagevec_lru_add(struct pagevec *p
spin_lock_irq(zone-lru_lock);
}
VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
+ __SetPageLRU(page);
add_page_to_inactive_list(zone, page);
}
if (zone)
@@ -391,7 +391,7 @@ void __pagevec_lru_add_active(struct pag
spin_lock_irq(zone-lru_lock);
}
VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
+ __SetPageLRU(page);
VM_BUG_ON(PageActive(page));
SetPageActive(page);
add_page_to_active_list(zone, page);
diff -Nrup linux-2.6.21-rc7.org/mm/vmscan.c linux-2.6.21-rc7/mm/vmscan.c
--- linux-2.6.21-rc7.org/mm/vmscan.c2007-04-17 16:36:05.0 +0900
+++ linux-2.6.21-rc7/mm/vmscan.c2007-04-23 18:30:30.0 +0900
@@ -642,7 +642,7 @@ static unsigned long isolate_lru_pages(u
* sure the page is not being freed elsewhere -- the
* page release code relies on it.
*/
- ClearPageLRU(page);
+ __ClearPageLRU(page);
target = dst;
nr_taken++;
} /* else it is being freed elsewhere */
@@ -704,7 +704,7 @@ static unsigned long shrink_inactive_lis
while (!list_empty(page_list)) {
page = lru_to_page(page_list);
VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
+ __SetPageLRU(page);
list_del(page-lru);
if (PageActive(page))
add_page_to_active_list(zone, page);
@@ -851,7 +851,7 @@ force_reclaim_mapped:
page = lru_to_page(l_inactive);
prefetchw_prev_lru_page(page, l_inactive, flags);
VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
+ __SetPageLRU(page);
VM_BUG_ON(!PageActive(page));
ClearPageActive(page);
@@ -881,7 +881,7 @@ force_reclaim_mapped:
page = lru_to_page(l_active);
prefetchw_prev_lru_page(page, l_active, flags);
VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
+ __SetPageLRU(page);
VM_BUG_ON(!PageActive(page));
list_move(page-lru, zone-active_list);
pgmoved++;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] Containers (V8): Generic Process Containers
Hi Paul,
In [patch 3/7] Containers (V8): Add generic multi-subsystem API to
containers, you have forcefully enabled interrupt in
container_init_subsys() with spin_unlock_irq() which breaks on PPC64.
+static void container_init_subsys(struct container_subsys *ss) {
+ int retval;
+ struct list_head *l;
+ printk(KERN_ERR Initializing container subsys %s\n,
ss-name);
+
+ /* Create the top container state for this subsystem */
+ ss-root = rootnode;
+ retval = ss-create(ss, dummytop);
+ BUG_ON(retval);
+ init_container_css(ss, dummytop);
+
+ /* Update all container groups to contain a subsys
+ * pointer to this state - since the subsystem is
+ * newly registered, all tasks and hence all container
+ * groups are in the subsystem's top container. */
+ spin_lock_irq(container_group_lock);
+ l = init_container_group.list;
+ do {
+ struct container_group *cg =
+ list_entry(l, struct container_group, list);
+ cg-subsys[ss-subsys_id] =
dummytop-subsys[ss-subsys_id];
+ l = l-next;
+ } while (l != init_container_group.list);
+ spin_unlock_irq(container_group_lock);
Interrupt gets enabled here and on PPC64, the kernel takes a pending
decrementer and crashes because it is too early to handle them.
Use of irqsave and restore routines would fix the problem.
I have included the fix along with minor Kconfig correction.
Also your 3/7 patch did not showup on LKML.
--Vaidy
+
+ need_forkexit_callback |= ss-fork || ss-exit;
Index: linux-2.6.20/kernel/container.c
===
--- linux-2.6.20.orig/kernel/container.c
+++ linux-2.6.20/kernel/container.c
@@ -1638,6 +1638,7 @@ int container_is_descendant(const struct
static void container_init_subsys(struct container_subsys *ss) {
int retval;
+ unsigned long flags;
struct list_head *l;
printk(KERN_ERR Initializing container subsys %s\n, ss-name);
@@ -1651,7 +1652,7 @@ static void container_init_subsys(struct
* pointer to this state - since the subsystem is
* newly registered, all tasks and hence all container
* groups are in the subsystem's top container. */
- spin_lock_irq(container_group_lock);
+ spin_lock_irqsave(container_group_lock, flags);
l = init_container_group.list;
do {
struct container_group *cg =
@@ -1659,7 +1660,7 @@ static void container_init_subsys(struct
cg-subsys[ss-subsys_id] = dummytop-subsys[ss-subsys_id];
l = l-next;
} while (l != init_container_group.list);
- spin_unlock_irq(container_group_lock);
+ spin_unlock_irqrestore(container_group_lock, flags);
need_forkexit_callback |= ss-fork || ss-exit;
Index: linux-2.6.20/init/Kconfig
===
--- linux-2.6.20.orig/init/Kconfig
+++ linux-2.6.20/init/Kconfig
@@ -239,8 +239,13 @@ config IKCONFIG_PROC
through /proc/config.gz.
config CONTAINERS
- bool
-
+ bool Container support
+ help
+ This option will let you create and manage process containers,
+ which can be used to aggregate multiple processes, e.g. for
+ the purposes of resource tracking.
+
+ Say N if unsure
config CPUSETS
bool Cpuset support
Re: ChunkFS - measuring cross-chunk references
On Mon, 2007-04-23 at 12:49 +0530, Karuna sagar K wrote: Hi, The tool estimates the cross-chunk references from an extt2/3 file system. It considers a block group as one chunk and calcuates how many block groups does a file span across. So, the block group size gives the estimate of chunk size. The file systems were aged for about 3-4 months on a developers laptop. With a blocksize of 4KB, a block group would be 128 MB. In the original Chunkfs paper, Valh had mentioned 1GB chunks and I believe it will be possible to use 2GB, 4GB or 8GB chunks in the future. As the chunk size increases the number of cross-chunk references will reduce and hence it might be a good idea to present these statistics considering different chunk sizes starting from 512MB upto 2GB. Thanks, Kalpak. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] Kconfig: silicon backplane dependency.
On Sun, 2007-04-22 at 11:46 +0200, Michael Buesch wrote: No, this doesn't look right. There are other devices that come with SiliconBackplane but are not PCI or PCMCIA style devices. Yes, Michael already told me about that. The current solution is to use !S390, could we use HAS_IOMEM instead ? I'd think either should be fine. I will use HAS_IOMEM then. The oddity with the select statement still exists though. I have to add the depends on HAS_IOMEM to SSB and B44. If I just add it to SSB then the config option for B44 exists for s390 and you can enable it. The select statement will then enable SSB as well (.config contains CONFIG_SSB=y for allyesconfig). This is in contradiction to the depends statement since HAS_IOMEM=n on s390. The current Kconfig code does not check all select statements if they can be enabled before allowing the config option that does the select. So the rule for using select statements is that the depends line of the config option that selects another config option needs to be at least as restrictive as the depends line of the selected option. Hence I'll add the HAS_IOMEM depends to B44 as well. Okay ? -- blue skies, IBM Deutschland Entwicklung GmbH MartinVorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Martin Schwidefsky Sitz der Gesellschaft: Böblingen Linux on zSeries Registergericht: Amtsgericht Stuttgart, Development HRB 243294 Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: PageLRU can be non-atomic bit operation
On Mon, 23 Apr 2007, Hisashi Hifumi wrote: PageLRU flag operation is protected by zone-lru_lock, so SetPageLRU/ClearPageLRU can be replaced to __SetPageLRU/__ClearPageLRU non-atomic bit operation. No. The PG_lru flag bit is just one bit amongst many others: what of concurrent operations changing other bits in that same unsigned long e.g. trying to lock the page by setting PG_locked? There are some places where such micro-optimizations can be made (typically while first allocating the page); but in general, no. Hugh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] Kconfig: silicon backplane dependency.
On Monday 23 April 2007, Martin Schwidefsky wrote: The current Kconfig code does not check all select statements if they can be enabled before allowing the config option that does the select. So the rule for using select statements is that the depends line of the config option that selects another config option needs to be at least as restrictive as the depends line of the selected option. Hence I'll add the HAS_IOMEM depends to B44 as well. Okay ? Isn't B44 already behind a WIRELESS or IEEE80211 or similar option that can't be selected on s390? Arnd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODULE_MAINTAINER
On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote: On 04/04/2007 06:38 PM, Rene Herman wrote: Rusty? Valid points have been made on both sides. I suggest: #define MODULE_MAINTAINER(_maintainer) \ MODULE_AUTHOR((Maintained by) _maintainer) Cheers, Rusty. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Testing framework
On 4/23/07, Kalpak Shah [EMAIL PROTECTED] wrote: On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote: . The file system is looked upon as a set of blocks (more precisely metadata blocks). We randomly choose from this set of blocks to corrupt. Hence we would be able to overcome the deficiency of the previous approach. However this approach makes it difficult to have a replayable corruption. Further thought about this approach has to be given. Fill a test filesystem with data and save it. Corrupt it by copying a chunk of data from random locations A to B. Save positions A and B so that you can reproduce the corruption. Hey, thats a nice idea :). But, this woundnt reproduce the same corruption right? Because, say, on first run of the tool there is metadata stored at locations A and B and then on the second run there may be user data present. I mean the allocation may be different. Or corrupt random bits (ideally in metadata blocks) and maintain the list of the bit numbers for reproducing the corruption. . The corrupted file system is repaired and recovered with 'fsck' or any other tools; this phase considers the repair and recovery action on the file system as a black box. The time taken to repair by the tool is measured I see that you are running fsck just once on the test filesystem. It might be a good idea to run it twice and if second fsck does not find the filesystem to be completely clean that means it is a bug in fsck. You are right. Will modify that. snip .. State of the either file system is stored, which may be huge, time consuming and not necessary. So, we could have better ways of storing the state. Also, people may want to test with different mount options, so something like mount -t $fstype -o loop,$MOUNT_OPTIONS $imgname $mountpt may be useful. Similarly it may also be useful to have MKFS_OPTIONS while formatting the filesystem. Right. I didnt think of that. Will look into it. Thanks, Kalpak. Comments are welcome!! Thanks, Karuna Thanks, Karuna - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: Spontaneous exit support
On Sun, Apr 22, 2007 at 09:12:55PM -0600, Eric W. Biederman wrote:
This patch implements the kthread helper functions kthread_start
and kthread_end which make it simple to support a kernel thread
that may decided to exit on it's own before we request it to.
It is still assumed that eventually we will get around to requesting
that the kernel thread stop.
I don't think having to parallel APIs is a good idea, people will
get utterly confused which one to use. Better always grab a reference
in kthread_create and drop it in kthread_stop. For normal thread
no change in behaviour and only slightly more code in the slowpath.
Of course it will need an audit for half-assed kthread conversion
first to avoid task_struct reference count leaks.
In addition to that kthrad_end implementation look wrong. When
the kthread has exited prematurely no one will call complete
on kthread_stop_info.done before it's been setup. Interestingly
the comment there indicates someone thought about threads exiting
early, but it became defunkt during all the rewrites of the
kthread code.
+/**
+ * kthread_start - create and wake a thread.
+ * @threadfn: the function to run until kthread_should_stop().
+ * @data: data ptr for @threadfn.
+ * @namefmt: printf-style name for the thread.
+ *
+ * Description: Convenient wrapper for kthread_create() followed by
+ * get_task_struct() and wake_up_process. kthread_start should be paired
+ * with kthread_end() so we don't leak task structs.
+ *
+ * Returns the kthread or ERR_PTR(-ENOMEM).
+ */
+#define kthread_start(threadfn, data, namefmt, ...) \
+({ \
+ struct task_struct *__k\
+ = kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); \
+ if (!IS_ERR(__k)) {\
+ get_task_struct(__k); \
+ wake_up_process(__k); \
+ } \
+ __k; \
+})
+int kthread_end(struct task_struct *k);
static inline int __kthread_should_stop(struct task_struct *tsk)
{
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 9b3c19f..d6d63c6 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -179,6 +179,24 @@ int kthread_stop(struct task_struct *tsk)
}
EXPORT_SYMBOL(kthread_stop);
+/**
+ * kthread_end - signal a kthread and wait for it to exit.
+ * @task: The kthread to end.
+ *
+ * Description: Convenient wrapper for kthread_stop() followed by
+ * put_task_struct(). Returns the kthread exit code.
+ *
+ * kthread_start()/kthread_end() can handle kthread that spontaneously exit
+ * before the kthread is requested to terminate.
+ */
+int kthread_end(struct task_struct *task)
+{
+ int ret;
+ ret = kthread_stop(task);
+ put_task_struct(task);
+ return ret;
+}
+EXPORT_SYMBOL(kthread_end);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] Kconfig: silicon backplane dependency.
On Mon, 2007-04-23 at 13:22 +0200, Arnd Bergmann wrote: The current Kconfig code does not check all select statements if they can be enabled before allowing the config option that does the select. So the rule for using select statements is that the depends line of the config option that selects another config option needs to be at least as restrictive as the depends line of the selected option. Hence I'll add the HAS_IOMEM depends to B44 as well. Okay ? Isn't B44 already behind a WIRELESS or IEEE80211 or similar option that can't be selected on s390? No, the option can be found in drivers/net/Kconfig under menu Ethernet (10 or 100Mbit). -- blue skies, IBM Deutschland Entwicklung GmbH MartinVorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Martin Schwidefsky Sitz der Gesellschaft: Böblingen Linux on zSeries Registergericht: Amtsgericht Stuttgart, Development HRB 243294 Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Here is something I don't understand... It seems there is a maintainer, namesys people, which is what I was supposing, and probably it is the most qualified one for reiser4, but it also seems you imply that they are not interested right now in kernel inclusion, since they are not asking in this moment for it. Do I misunderstand? To me it seems they are implicitally interested in kernel inclusion since they are maintaining the code, and they alredy asked for this. regards Luigi On Mon, 23 Apr 2007, Andrew Morton wrote: The namesys engineers continue to maintain reiser4 and I continue to receive patches for it. Right now I'd say that the main blockages for reiser4 are a) the developers aren't presently asking for inclusion (afaik) and b) lack of reviewing effort from other kernel developers. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] ChunkFS: fs fission for faster fsck
This is an initial implementation of ChunkFS technique, briefly discussed at: http://lwn.net/Articles/190222 and http://cis.ksu.edu/~gud/docs/chunkfs-hotdep-val-arjan-gud-zach.pdf This implementation is done within ext2 driver. Every chunk is an independent ext2 file system. The knowledge about chunks is kept within ext2 and 'continuation inodes', which are used to allow files and directories span across multiple chunks, are managed within ext2. At mount time, super blocks for all the chunks are created and linked with the global super_blocks list maintained by VFS. This allows independent behavior or individual chunks and also helps writebacks to happen seamlessly. Apart from this, chunkfs code in ext2 effectively only provides knowledge of: - what inode's which block number to look for, for a given file's logical block number - in which chunk to allocate next inode / block - number of inodes to scan when a directory is being read To maintain the ext2's inode number uniqueness property, 8 msb bits of inode number are used to indicate the chunk number in which it resides. As said, this is a preliminary implementation and lots of changes are expected before this code is even sanely usable. Some known issues and obvious optimizations are listed in the TODO file in the chunkfs patch. http://cis.ksu.edu/~gud/patches/chunkfs-v0.0.8.patch - one big patch - applies to 2.6.18 Attached - ext2-chunkfs-diff.patch.gz - since the code is a spin-off of ext2, this patch explains better what has changed from the ext2. git://cislinux.cis.ksu.edu/chunkfs-tools - mkfs, and fsck for chunkfs. http://cis.ksu.edu/~gud/patches/config-chunkfs-2.6.18-uml - config file used; tested mostly on UML with loopback file systems. NOTE: No xattrs and xips yet, CONFIG_EXT2_FS_XATTR and CONFIG_EXT2_FS_XIP should be no for clean compile. Please comment, suggest, criticize. Patches most welcome. Best, AG -- May the source be with you. http://www.cis.ksu.edu/~gud ext2-chunkfs-diff.patch.gz Description: Binary data
Re: [PATCH] lazy freeing of memory through MADV_FREE
Rik van Riel wrote: First some ebizzy runs... This is interesting. Ginormous speedups in ebizzy[1] on my quad core test system. The following numbers are the average of 10 runs, since ebizzy shows some variability. You can see a big influence from the tlb batching and from Nick's madv_sem patch. The reduction in system time from 100 seconds to 3 seconds is way more than I had expected, but I'm not complaining. The 4 fold reduction in wall clock time is a nice bonus. According to Val, ebizzy shows the weaknesses of Linux with a real workload, so this could be a useful result. kernel user system wall clock%CPU vanilla 186s101s 123s 230% madv_free (madv)175s 96s 120s 230% mmap_sem (sem) 100s 40s40s 370% madv+sem200s140s 100s 393% madv+sem+tlb118s 3s30s 395% madv+tlb150s 10s50s 310% [1] http://www.ussg.iu.edu/hypermail/linux/kernel/0604.2/1699.html -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]Fix parsing kernelcore boot option for ia64
On Fri, 13 Apr 2007 14:26:22 +0900 Yasunori Goto [EMAIL PROTECTED] wrote:
Hello.
cmdline_parse_kernelcore() should return the next pointer of boot option
like memparse() doing. If not, it is cause of eternal loop on ia64 box.
This patch is for 2.6.21-rc6-mm1.
Signed-off-by: Yasunori Goto [EMAIL PROTECTED]
arch/ia64/kernel/efi.c |2 +-
include/linux/mm.h |2 +-
mm/page_alloc.c|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
Index: current_test/arch/ia64/kernel/efi.c
===
--- current_test.orig/arch/ia64/kernel/efi.c2007-04-12
17:33:28.0 +0900
+++ current_test/arch/ia64/kernel/efi.c 2007-04-13 12:13:21.0
+0900
@@ -424,7 +424,7 @@ efi_init (void)
} else if (memcmp(cp, max_addr=, 9) == 0) {
max_addr = GRANULEROUNDDOWN(memparse(cp + 9, cp));
} else if (memcmp(cp, kernelcore=,11) == 0) {
- cmdline_parse_kernelcore(cp+11);
+ cmdline_parse_kernelcore(cp+11, cp);
} else if (memcmp(cp, min_addr=, 9) == 0) {
min_addr = GRANULEROUNDDOWN(memparse(cp + 9, cp));
} else {
Index: current_test/mm/page_alloc.c
===
--- current_test.orig/mm/page_alloc.c 2007-04-12 18:25:37.0
+0900
+++ current_test/mm/page_alloc.c2007-04-13 12:12:58.0 +0900
@@ -3736,13 +3736,13 @@ void __init free_area_init_nodes(unsigne
* kernelcore=size sets the amount of memory for use for allocations that
* cannot be reclaimed or migrated.
*/
-int __init cmdline_parse_kernelcore(char *p)
+int __init cmdline_parse_kernelcore(char *p, char **retp)
{
unsigned long long coremem;
if (!p)
return -EINVAL;
- coremem = memparse(p, p);
+ coremem = memparse(p, retp);
required_kernelcore = coremem PAGE_SHIFT;
/* Paranoid check that UL is enough for required_kernelcore */
Index: current_test/include/linux/mm.h
===
--- current_test.orig/include/linux/mm.h2007-04-11 14:15:33.0
+0900
+++ current_test/include/linux/mm.h 2007-04-13 12:12:20.0 +0900
@@ -1051,7 +1051,7 @@ extern unsigned long find_max_pfn_with_a
extern void free_bootmem_with_active_regions(int nid,
unsigned long max_low_pfn);
extern void sparse_memory_present_with_active_regions(int nid);
-extern int cmdline_parse_kernelcore(char *p);
+extern int cmdline_parse_kernelcore(char *p, char **retp);
#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
extern int early_pfn_to_nid(unsigned long pfn);
#endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
This will cause all other architectures to crash when kernelcore= is used.
I wasn't even aware of this kernelcore thing. It's pretty nasty-looking.
yet another reminder that this code hasn't been properly reviewed in the
past year or three.
Just now, I'm making memory-unplug patches with current MOVABLE_ZONE
code. So, I might be the first user of it on ia64.
Anyway, I'll try to fix it.
--
Yasunori Goto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] Kconfig: silicon backplane dependency.
On Monday 23 April 2007, Martin Schwidefsky wrote: Isn't B44 already behind a WIRELESS or IEEE80211 or similar option that can't be selected on s390? No, the option can be found in drivers/net/Kconfig under menu Ethernet (10 or 100Mbit). Ah, I was confusing it with b43. Depends on HAS_IOMEM sounds good then. I'd prefer to make it 'depends on SSB' instead of 'select SSB', but I don't want to get into that argument ;-) Arnd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODULE_MAINTAINER
On Mon, 23 Apr 2007, Rusty Russell wrote: On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote: On 04/04/2007 06:38 PM, Rene Herman wrote: Rusty? Valid points have been made on both sides. I suggest: #define MODULE_MAINTAINER(_maintainer) \ MODULE_AUTHOR((Maintained by) _maintainer) why bring MODULE_AUTHOR into it? just define it in terms of MODULE_INFO: #define MODULE_MAINTAINER(_m) MODULE_INFO(_m, (Maintained by) \ maintainer) technically, the maintainer is not the same as the author so why confuse the issue with an extra unnecessary macro expansion? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sleep during spinlock in TPM driver
On Mon, 23 Apr 2007, Jiri Kosina wrote:
On Sun, 22 Apr 2007, Parag Warudkar wrote:
@@ -1097,8 +1097,13 @@
/* Driver specific per-device data */
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
- if (chip == NULL)
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ + if (chip == NULL || devname == NULL) {
Hi,
this line looks bogus to me.
Hi - Yep, thanks for catching. Really not sure how that extra + got in
there - I diffed the exact same file this morning and it isn't there - new
diff attached.
--- linux-2.6-us/drivers/char/tpm/tpm.c 2007-04-21 14:55:03.134975360 -0400
+++ linux-2.6-wk/drivers/char/tpm/tpm.c 2007-04-22 14:58:51.95763 -0400
@@ -942,12 +942,12 @@
{
struct tpm_chip *chip = file-private_data;
+ flush_scheduled_work();
spin_lock(driver_lock);
file-private_data = NULL;
- chip-num_opens--;
del_singleshot_timer_sync(chip-user_read_timer);
- flush_scheduled_work();
atomic_set(chip-data_pending, 0);
+ chip-num_opens--;
put_device(chip-dev);
kfree(chip-data_buffer);
spin_unlock(driver_lock);
@@ -1097,8 +1097,13 @@
/* Driver specific per-device data */
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
- if (chip == NULL)
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+
+ if (chip == NULL || devname == NULL) {
+ kfree(chip);
+ kfree(devname);
return NULL;
+ }
init_MUTEX(chip-buffer_mutex);
init_MUTEX(chip-tpm_mutex);
@@ -1124,7 +1129,6 @@
set_bit(chip-dev_num, dev_mask);
- devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
scnprintf(devname, DEVNAME_SIZE, %s%d, tpm, chip-dev_num);
chip-vendor.miscdev.name = devname;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RESEND] ehea: fix for dlpar and sysfs entries
This patch includes:
- dlpar fix:
certain resources may only be allocated when first
logical port is available, and must be removed when
last logical port has been removed
- sysfs entries:
create symbolic link from each logical port to ehea driver
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
This patch applies on top of the netdev upstream branch for 2.6.22
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 1405d0b..173994d 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include asm/abs_addr.h
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0055
+#define DRV_VERSIONEHEA_0056
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index a36a023..f9f3133 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -78,6 +78,28 @@ MODULE_PARM_DESC(sq_entries, Number of
__MODULE_STRING(EHEA_DEF_ENTRIES_SQ) ));
MODULE_PARM_DESC(use_mcs, 0:NAPI, 1:Multiple receive queues, Default = 1 );
+static int port_name_cnt = 0;
+
+static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
+const struct of_device_id *id);
+
+static int __devexit ehea_remove(struct ibmebus_dev *dev);
+
+static struct of_device_id ehea_device_table[] = {
+ {
+ .name = lhea,
+ .compatible = IBM,lhea,
+ },
+ {},
+};
+
+static struct ibmebus_driver ehea_driver = {
+ .name = ehea,
+ .id_table = ehea_device_table,
+ .probe = ehea_probe_adapter,
+ .remove = ehea_remove,
+};
+
void ehea_dump(void *adr, int len, char *msg) {
int x;
unsigned char *deb = adr;
@@ -2108,6 +2130,28 @@ static int ehea_clean_all_portres(struct
return ret;
}
+static void ehea_remove_adapter_mr (struct ehea_adapter *adapter)
+{
+ int i;
+
+ for (i=0; i EHEA_MAX_PORTS; i++)
+ if (adapter-port[i])
+ return;
+
+ ehea_rem_mr(adapter-mr);
+}
+
+static int ehea_add_adapter_mr (struct ehea_adapter *adapter)
+{
+ int i;
+
+ for (i=0; i EHEA_MAX_PORTS; i++)
+ if (adapter-port[i])
+ return 0;
+
+ return ehea_reg_kernel_mr(adapter, adapter-mr);
+}
+
static int ehea_up(struct net_device *dev)
{
int ret, i;
@@ -2361,6 +2405,34 @@ static void __devinit logical_port_relea
of_node_put(port-ofdev.node);
}
+static int ehea_driver_sysfs_add(struct device *dev,
+ struct device_driver *driver)
+{
+ int ret;
+
+ ret = sysfs_create_link(driver-kobj, dev-kobj,
+ kobject_name(dev-kobj));
+ if (ret == 0) {
+ ret = sysfs_create_link(dev-kobj, driver-kobj,
+ driver);
+ if (ret)
+ sysfs_remove_link(driver-kobj,
+ kobject_name(dev-kobj));
+ }
+ return ret;
+}
+
+static void ehea_driver_sysfs_remove(struct device *dev,
+ struct device_driver *driver)
+{
+ struct device_driver *drv = driver;
+
+ if (drv) {
+ sysfs_remove_link(drv-kobj, kobject_name(dev-kobj));
+ sysfs_remove_link(dev-kobj, driver);
+ }
+}
+
static struct device *ehea_register_port(struct ehea_port *port,
struct device_node *dn)
{
@@ -2368,8 +2440,9 @@ static struct device *ehea_register_port
port-ofdev.node = of_node_get(dn);
port-ofdev.dev.parent = port-adapter-ebus_dev-ofdev.dev;
+ port-ofdev.dev.bus = ibmebus_bus_type;
- sprintf(port-ofdev.dev.bus_id, port%d, port-logical_port_id);
+ sprintf(port-ofdev.dev.bus_id, port%d, port_name_cnt++);
port-ofdev.dev.release = logical_port_release;
ret = of_device_register(port-ofdev);
@@ -2384,8 +2457,16 @@ static struct device *ehea_register_port
goto out_unreg_of_dev;
}
+ ret = ehea_driver_sysfs_add(port-ofdev.dev, ehea_driver.driver);
+ if (ret) {
+ ehea_error(failed to register sysfs driver link);
+ goto out_rem_dev_file;
+ }
+
return port-ofdev.dev;
+out_rem_dev_file:
+ device_remove_file(port-ofdev.dev, dev_attr_log_port_id);
out_unreg_of_dev:
of_device_unregister(port-ofdev);
out:
@@ -2394,6 +2475,7 @@ out:
static void ehea_unregister_port(struct ehea_port *port)
{
+ ehea_driver_sysfs_remove(port-ofdev.dev, ehea_driver.driver);
device_remove_file(port-ofdev.dev, dev_attr_log_port_id);
of_device_unregister(port-ofdev);
}
@@ -2520,7 +2602,6 @@ static int ehea_setup_ports(struct ehea_
struct
Re: Sleep during spinlock in TPM driver
G.. My email client was at it again. Sorry it messed up with the
additonal + again.
Do not use Alpine - This is the first email client (alphas and betas
included) which is buggy enough to change what you write!
Not taking chances this time - patch attached.
Parag
--- linux-2.6-us/drivers/char/tpm/tpm.c 2007-04-21 14:55:03.134975360 -0400
+++ linux-2.6-wk/drivers/char/tpm/tpm.c 2007-04-22 14:58:51.95763 -0400
@@ -942,12 +942,12 @@
{
struct tpm_chip *chip = file-private_data;
+ flush_scheduled_work();
spin_lock(driver_lock);
file-private_data = NULL;
- chip-num_opens--;
del_singleshot_timer_sync(chip-user_read_timer);
- flush_scheduled_work();
atomic_set(chip-data_pending, 0);
+ chip-num_opens--;
put_device(chip-dev);
kfree(chip-data_buffer);
spin_unlock(driver_lock);
@@ -1097,8 +1097,13 @@
/* Driver specific per-device data */
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
- if (chip == NULL)
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+
+ if (chip == NULL || devname == NULL) {
+ kfree(chip);
+ kfree(devname);
return NULL;
+ }
init_MUTEX(chip-buffer_mutex);
init_MUTEX(chip-tpm_mutex);
@@ -1124,7 +1129,6 @@
set_bit(chip-dev_num, dev_mask);
- devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
scnprintf(devname, DEVNAME_SIZE, %s%d, tpm, chip-dev_num);
chip-vendor.miscdev.name = devname;
Re: gtod/clocksource/clockevents documentation
Remy Bohmer : Hello All, I need to implement a gtod/clocksource/clockevents implementation for the Atmel ARM AT91SAM9261 CPU, and I am looking for some kernel (interface) documentation about these mechanisms. [..] I hacked something which now makes the RT kernel to boot, but the time-of-day warps several minutes per second, back and forward in time... ;-) I recall there is a patch by Michel Benoit that solves some issues on gettimeoffset()/gettimeofday(). It is in the ARM patch queue here : http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4149/1 and will be included in the upcoming kernel. Hope that it addresses this problem and that it will help you. Regards, -- Nicolas Ferre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v5
2007/4/23, Ingo Molnar [EMAIL PROTECTED]: Index: linux/kernel/sched.c === --- linux.orig/kernel/sched.c +++ linux/kernel/sched.c +#include sched_stats.h +#include sched_rt.c +#include sched_fair.c +#include sched_debug.c Index: linux/kernel/sched_stats.h === --- /dev/null +++ linux/kernel/sched_stats.h These look unnatural if it were to be included in mainline. WBR. -- Guillaume - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: PageLRU can be non-atomic bit operation
No. The PG_lru flag bit is just one bit amongst many others: what of concurrent operations changing other bits in that same unsigned long e.g. trying to lock the page by setting PG_locked? There are some places where such micro-optimizations can be made (typically while first allocating the page); but in general, no. In i386 and x86_64, btsl is used to change page flag. In this case, if btsl without lock prefix set PG_locked and PG_lru flag concurrently, does only one operation succeed ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
POST STARTUP ERRORS ( BIOS )
PC: IBM NetVista - Type: 6269-R2G - S/N 55224PG Operating system: Linux 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux Dear sir/madam, This is what I got after upgrading from sarge to etch (Debian): POST STARTUP ERRORS ( BIOS ) The following error(s) were detected when the system was started: 177 System security - Asset control has been violated Select one of the following: Continue Exit Setup A search on internet revealed that I am not the only one with this BIOS error, but I couldn't find any solution until now. Do you have any idea how to solve this problem? Sincerely, -- J-P Van Bylen [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODULE_MAINTAINER
On 04/23/2007 01:52 PM, Robert P. J. Day wrote: On Mon, 23 Apr 2007, Rusty Russell wrote: Valid points have been made on both sides. I suggest: #define MODULE_MAINTAINER(_maintainer) \ MODULE_AUTHOR((Maintained by) _maintainer) why bring MODULE_AUTHOR into it? just define it in terms of MODULE_INFO: #define MODULE_MAINTAINER(_m) MODULE_INFO(_m, (Maintained by) \ maintainer) technically, the maintainer is not the same as the author so why confuse the issue with an extra unnecessary macro expansion? Swap arguments to MODULE_INFO, but yes, other than the extra (Maintained by) that's what was originally submitted: http://lkml.org/lkml/2007/4/4/170 If you're going to be using a maintainer tag anyway as both that and yours above does, the (Maintained by) becomes superfluous, so we're back at the original. I must say I'm not particularly sure either why reusing MODULE_AUTHOR would be better if MODULE_AUTHOR also remains (as Alan Cox pointed out might be desirable for legal reasons if nothing else). As fas as I'm aware, the other trivial patch I posted to init-module-tools: http://lkml.org/lkml/2007/4/4/171 is all that's needed to make it useful. But, I also really only care about being able to add MODULE_MAINTAINER() to some drivers that have outlived their authors and from that viewpoint there is no difference, so if Rusty feels this is better, so be it. Andrew, mind if I submit this to you? === Provide MODULE_MAINTAINER() as a convenient place to stick a name and email address both for drivers having multiple (current and non-current) authors and for when someone who wants to maintain a driver isn't so much an author. Signed-off-by: Rene Herman [EMAIL PROTECTED] === Rene. diff --git a/include/linux/module.h b/include/linux/module.h index 10f771a..3c54774 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -128,6 +128,10 @@ extern struct module __this_module; /* Author, ideally of form NAME EMAIL[, NAME EMAIL]*[ and NAME EMAIL] */ #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author) +/* Maintainer, ideally of form NAME EMAIL */ +#define MODULE_MAINTAINER(_maintainer) \ + MODULE_AUTHOR((Maintained by) _maintainer) + /* What your module does. */ #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
Re: [patch] CFS scheduler, -v5
* Guillaume Chazarain [EMAIL PROTECTED] wrote: 2007/4/23, Ingo Molnar [EMAIL PROTECTED]: Index: linux/kernel/sched.c === --- linux.orig/kernel/sched.c +++ linux/kernel/sched.c +#include sched_stats.h +#include sched_rt.c +#include sched_fair.c +#include sched_debug.c Index: linux/kernel/sched_stats.h === --- /dev/null +++ linux/kernel/sched_stats.h These look unnatural if it were to be included in mainline. agreed - these will likely be separate modules - i just wanted to have an easy way of sharing infrastructure between sched.c and these. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 3/3] freezer: Fix problem with kthread_stop
On Sun, Apr 22, 2007 at 09:40:59PM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Fix the problem with kthread_stop() that causes the freezer to fail if a
freezable thread is attempting to stop a frozen one and that may cause the
freezer to fail if the thread being stopped is freezable and
try_to_freeze_tasks() is running concurrently with kthread_stop().
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/kthread.c |9 +
1 file changed, 9 insertions(+)
Index: linux-2.6.21-rc6-mm1/kernel/kthread.c
===
--- linux-2.6.21-rc6-mm1.orig/kernel/kthread.c2007-04-09
15:23:48.0 +0200
+++ linux-2.6.21-rc6-mm1/kernel/kthread.c 2007-04-22 19:05:29.0
+0200
@@ -13,6 +13,7 @@
#include linux/file.h
#include linux/module.h
#include linux/mutex.h
+#include linux/freezer.h
#include asm/semaphore.h
/*
@@ -232,6 +233,14 @@ int kthread_stop(struct task_struct *k)
/* Now set kthread_should_stop() to true, and wake it up. */
kthread_stop_info.k = k;
+ if (!freezer_should_exempt(current)) {
+ /* We are freezable, so we must make sure that the thread being
+ * stopped is not frozen and will not be frozen until it dies
+ */
+ freezer_exempt(k);
+ if (frozen(k))
+ clear_frozen_flag(k);
+ }
I'm trying hard to convince myself that this will work. May be I am
missing something here, but I find a potential race window (very small though)
when k is entering the refrigerator.
Here's how.
kthread_stop(k) k-refrigerator()
-
task_lock(k);
1) check_if_exempted();
/* not exempted. So
* we will freeze
* ourself.
*/
2) freezer_exempt(k);
3) if(frozen(k))
/* No, we're not yet frozen. So we
* don't clear_frozen_flag(k) here
*/
4) frozen_process(k);
task_unlock(k);
5) for(;;) {
set_current_state(UNINTERRUPTIBLE);
if(!frozen_process(k))
/* k is frozen. We
* don't break :(
*/
schedule();
}
wake_up_process(k);
put_task_struct(k);
Thus the freezer can still fail, no?
IMO, we need the to take the task_lock for k here. Something like
+ if (!freezer_should_exempt(current)) {
task_lock(k);
+ /* We are freezable, so we must make sure that the thread being
+ * stopped is not frozen and will not be frozen until it dies
+ */
+ freezer_exempt(k);
+ if (frozen(k))
+ clear_frozen_flag(k);
task_unlock(k);
+ }
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sleep during spinlock in TPM driver
Parag Warudkar napsal(a):
On Mon, 23 Apr 2007, Jiri Kosina wrote:
On Sun, 22 Apr 2007, Parag Warudkar wrote:
@@ -1097,8 +1097,13 @@
/* Driver specific per-device data */
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
- if (chip == NULL)
+ devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ + if (chip == NULL || devname == NULL) {
Hi,
this line looks bogus to me.
Hi - Yep, thanks for catching. Really not sure how that extra + got in
there - I diffed the exact same file this morning and it isn't there -
new diff attached.
[...]
@@ -1097,8 +1097,13 @@
/* Driver specific per-device data */
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
-if (chip == NULL)
+devname = kmalloc(DEVNAME_SIZE, GFP_KERNEL);
+ +if (chip == NULL || devname == NULL) {
I see this here too, but there is no extra '+' here:
http://lkml.org/lkml/2007/4/22/172 and here
http://lkml.org/lkml/2007/4/23/125
not even in the source of this message, weird... (using thunderbird 2.0rc1)
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.6.20 11/14; CRIS architecture update - IDE driver
Hello. Mikael Starvik wrote: The attached patch updates the CRIS IDE driver. Signed-off-by: Mikael Starvik [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Please attach the patch as text/plain and clean it from the whitespace noise. :-/ /Mikael MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODULE_MAINTAINER
On Mon, 23 Apr 2007, Robert P. J. Day wrote: On Mon, 23 Apr 2007, Rusty Russell wrote: On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote: On 04/04/2007 06:38 PM, Rene Herman wrote: Rusty? Valid points have been made on both sides. I suggest: #define MODULE_MAINTAINER(_maintainer) \ MODULE_AUTHOR((Maintained by) _maintainer) why bring MODULE_AUTHOR into it? just define it in terms of MODULE_INFO: #define MODULE_MAINTAINER(_m) MODULE_INFO(_m, (Maintained by) \ maintainer) whoops, the above is obviously syntactically incorrect, but you get the idea regarding MODULE_INFO, right? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]Fix parsing kernelcore boot option for ia64
On Mon, 23 Apr 2007, Yasunori Goto wrote:
On Fri, 13 Apr 2007 14:26:22 +0900 Yasunori Goto [EMAIL PROTECTED] wrote:
Hello.
cmdline_parse_kernelcore() should return the next pointer of boot option
like memparse() doing. If not, it is cause of eternal loop on ia64 box.
This patch is for 2.6.21-rc6-mm1.
Signed-off-by: Yasunori Goto [EMAIL PROTECTED]
arch/ia64/kernel/efi.c |2 +-
include/linux/mm.h |2 +-
mm/page_alloc.c|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
Index: current_test/arch/ia64/kernel/efi.c
===
--- current_test.orig/arch/ia64/kernel/efi.c2007-04-12 17:33:28.0
+0900
+++ current_test/arch/ia64/kernel/efi.c 2007-04-13 12:13:21.0 +0900
@@ -424,7 +424,7 @@ efi_init (void)
} else if (memcmp(cp, max_addr=, 9) == 0) {
max_addr = GRANULEROUNDDOWN(memparse(cp + 9, cp));
} else if (memcmp(cp, kernelcore=,11) == 0) {
- cmdline_parse_kernelcore(cp+11);
+ cmdline_parse_kernelcore(cp+11, cp);
} else if (memcmp(cp, min_addr=, 9) == 0) {
min_addr = GRANULEROUNDDOWN(memparse(cp + 9, cp));
} else {
Index: current_test/mm/page_alloc.c
===
--- current_test.orig/mm/page_alloc.c 2007-04-12 18:25:37.0 +0900
+++ current_test/mm/page_alloc.c2007-04-13 12:12:58.0 +0900
@@ -3736,13 +3736,13 @@ void __init free_area_init_nodes(unsigne
* kernelcore=size sets the amount of memory for use for allocations that
* cannot be reclaimed or migrated.
*/
-int __init cmdline_parse_kernelcore(char *p)
+int __init cmdline_parse_kernelcore(char *p, char **retp)
{
unsigned long long coremem;
if (!p)
return -EINVAL;
- coremem = memparse(p, p);
+ coremem = memparse(p, retp);
required_kernelcore = coremem PAGE_SHIFT;
/* Paranoid check that UL is enough for required_kernelcore */
Index: current_test/include/linux/mm.h
===
--- current_test.orig/include/linux/mm.h2007-04-11 14:15:33.0
+0900
+++ current_test/include/linux/mm.h 2007-04-13 12:12:20.0 +0900
@@ -1051,7 +1051,7 @@ extern unsigned long find_max_pfn_with_a
extern void free_bootmem_with_active_regions(int nid,
unsigned long max_low_pfn);
extern void sparse_memory_present_with_active_regions(int nid);
-extern int cmdline_parse_kernelcore(char *p);
+extern int cmdline_parse_kernelcore(char *p, char **retp);
#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
extern int early_pfn_to_nid(unsigned long pfn);
#endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
This will cause all other architectures to crash when kernelcore= is used.
I wasn't even aware of this kernelcore thing. It's pretty nasty-looking.
yet another reminder that this code hasn't been properly reviewed in the
past year or three.
Just now, I'm making memory-unplug patches with current MOVABLE_ZONE
code. So, I might be the first user of it on ia64.
Anyway, I'll try to fix it.
I'm looking at this as well. There may be more than one problem in there
so I'm being more thorough with testing on other arches.
Andrew, the option is part of the zone-based solution to fragmentation
avoidance which hasn't been mentioned in a while. That's probably why it
fell off your radar. It's nasty looking because sizing the portion of
memory usable by any allocation so that it is evenly spread throughout all
nodes is not trivial. I think that having mem= parsing broken on NUMA at
various times in the past (and probably still broken) highlights that.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7
--- Sergey Yanovich [EMAIL PROTECTED] wrote: For a typical, non-linux-geek user there are just two states of the device - available and not available. Ububtu is famous for its end-user support. They ship your driver since linux-2.6.17. But they pack it in one module. And that is _much_ easier, then a hotplug script. No, we ship a udev script. OK, me bad for using the present tense. But you had a single module in Oct 2006, didn't you? And maybe, you would like to post the script. Here's a simple udev rule that will do what you want: SUBSYSTEM==tifm, ACTION==add, TIFM_CARD_TYPE==SD, RUN+=/sbin/modprobe tifm_sd (just stick it somewhere in the udev rules). You shall take into consideration that mmc currently lacks uevent support, so mmc_block must be loaded manually (this is a long pending todo thingy; supposedly it waits for the first sdio driver). There's no direct dependency of tifm_sd on mmc_block (only on mmc_core). May be I'll add a modalias entry later so the explicit rule will not be needed. As a side note: I have some very good reasons for the current driver architecture. You may want to look them up in the mail archive (I outlined them during the initial driver submission). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 2/3] freezer: Introduce freezer_flags
On Sun, Apr 22, 2007 at 09:39:26PM +0200, Rafael J. Wysocki wrote:
@@ -63,9 +100,9 @@ static inline int thaw_process(struct ta
*/
static inline void frozen_process(struct task_struct *p)
{
- p-flags |= PF_FROZEN;
+ set_frozen_flag(p);
wmb();
- clear_tsk_thread_flag(p, TIF_FREEZE);
+ do_not_freeze(p);
We may want to rename do_not_freeze to something else. It kind of
looks weird calling do_not_freeze(p) after setting the frozen flag!
Probably, just a matter of taste :-)
}
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: PageLRU can be non-atomic bit operation
On Mon, 23 Apr 2007, Hisashi Hifumi wrote: No. The PG_lru flag bit is just one bit amongst many others: what of concurrent operations changing other bits in that same unsigned long e.g. trying to lock the page by setting PG_locked? There are some places where such micro-optimizations can be made (typically while first allocating the page); but in general, no. In i386 and x86_64, btsl is used to change page flag. In this case, if btsl without lock prefix set PG_locked and PG_lru flag concurrently, does only one operation succeed ? That's right: on an SMP machine, without the lock prefix, the operation is no longer atomic: what's stored back may be missing the result of one or the other of the racing operations. Hugh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC pci_32: Stop using old hotplug unsafe APIs
pci_find_slot isn't hot-plug safe. Move this code to the pci hotplug safe
equivalent and hold a refcount
properly while doinmg make_one_node_map.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/arch/powerpc/kernel/pci_32.c
linux-2.6.21-rc6-mm1/arch/powerpc/kernel/pci_32.c
--- linux.vanilla-2.6.21-rc6-mm1/arch/powerpc/kernel/pci_32.c 2007-04-12
14:14:43.0 +0100
+++ linux-2.6.21-rc6-mm1/arch/powerpc/kernel/pci_32.c 2007-04-23
12:20:22.007864440 +0100
@@ -656,10 +656,13 @@
reg = get_property(node, reg, NULL);
if (!reg)
continue;
- dev = pci_find_slot(pci_bus, ((reg[0] 8) 0xff));
- if (!dev || !dev-subordinate)
+ dev = pci_get_bus_and_slot(pci_bus, ((reg[0] 8) 0xff));
+ if (!dev || !dev-subordinate) {
+ pci_dev_put(dev);
continue;
+ }
make_one_node_map(node, dev-subordinate-number);
+ pci_dev_put(dev);
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Nvidia AGP: Use refcount aware PCI interfaces
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/char/agp/nvidia-agp.c
linux-2.6.21-rc6-mm1/drivers/char/agp/nvidia-agp.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/char/agp/nvidia-agp.c 2007-04-12
14:15:03.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/char/agp/nvidia-agp.c 2007-04-23
11:53:12.560578080 +0100
@@ -320,11 +320,11 @@
u8 cap_ptr;
nvidia_private.dev_1 =
- pci_find_slot((unsigned int)pdev-bus-number, PCI_DEVFN(0, 1));
+ pci_get_bus_and_slot((unsigned int)pdev-bus-number,
PCI_DEVFN(0, 1));
nvidia_private.dev_2 =
- pci_find_slot((unsigned int)pdev-bus-number, PCI_DEVFN(0, 2));
+ pci_get_bus_and_slot((unsigned int)pdev-bus-number,
PCI_DEVFN(0, 2));
nvidia_private.dev_3 =
- pci_find_slot((unsigned int)pdev-bus-number, PCI_DEVFN(30,
0));
+ pci_get_bus_and_slot((unsigned int)pdev-bus-number,
PCI_DEVFN(30, 0));
if (!nvidia_private.dev_1 || !nvidia_private.dev_2 ||
!nvidia_private.dev_3) {
printk(KERN_INFO PFX Detected an NVIDIA nForce/nForce2
@@ -443,6 +443,9 @@
static void __exit agp_nvidia_cleanup(void)
{
pci_unregister_driver(agp_nvidia_pci_driver);
+ pci_dev_put(nvidia_private.dev_1);
+ pci_dev_put(nvidia_private.dev_2);
+ pci_dev_put(nvidia_private.dev_3);
}
module_init(agp_nvidia_init);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sworks-agp: Switch to PCI ref counting APIs
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/char/agp/sworks-agp.c
linux-2.6.21-rc6-mm1/drivers/char/agp/sworks-agp.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/char/agp/sworks-agp.c 2007-04-12
14:15:03.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/char/agp/sworks-agp.c 2007-04-23
11:58:02.342524528 +0100
@@ -455,15 +455,6 @@
u32 temp, temp2;
u8 cap_ptr = 0;
- /* Everything is on func 1 here so we are hardcoding function one */
- bridge_dev = pci_find_slot((unsigned int)pdev-bus-number,
- PCI_DEVFN(0, 1));
- if (!bridge_dev) {
- printk(KERN_INFO PFX Detected a Serverworks chipset
- but could not find the secondary device.\n);
- return -ENODEV;
- }
-
cap_ptr = pci_find_capability(pdev, PCI_CAP_ID_AGP);
switch (pdev-device) {
@@ -483,6 +474,15 @@
return -ENODEV;
}
+ /* Everything is on func 1 here so we are hardcoding function one */
+ bridge_dev = pci_get_bus_and_slot((unsigned int)pdev-bus-number,
+ PCI_DEVFN(0, 1));
+ if (!bridge_dev) {
+ printk(KERN_INFO PFX Detected a Serverworks chipset
+ but could not find the secondary device.\n);
+ return -ENODEV;
+ }
+
serverworks_private.svrwrks_dev = bridge_dev;
serverworks_private.gart_addr_ofs = 0x10;
@@ -515,7 +515,7 @@
bridge-driver = sworks_driver;
bridge-dev_private_data = serverworks_private,
- bridge-dev = pdev;
+ bridge-dev = pci_dev_get(pdev);
pci_set_drvdata(pdev, bridge);
return agp_add_bridge(bridge);
@@ -525,8 +525,11 @@
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
+ pci_dev_put(bridge-dev);
agp_remove_bridge(bridge);
agp_put_bridge(bridge);
+ pci_dev_put(serverworks_private.svrwrks_dev)
+ serverworks_private.svrwrks_dev = NULL;
}
static struct pci_device_id agp_serverworks_pci_table[] = {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] edd: Switch to refcounting PCI APIs
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/firmware/edd.c
linux-2.6.21-rc6-mm1/drivers/firmware/edd.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/firmware/edd.c 2007-04-12
14:14:43.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/firmware/edd.c 2007-04-23 11:50:57.185158272
+0100
@@ -669,7 +669,7 @@
struct edd_info *info = edd_dev_get_info(edev);
if (edd_dev_is_type(edev, PCI)) {
- return pci_find_slot(info-params.interface_path.pci.bus,
+ return pci_get_slot(info-params.interface_path.pci.bus,
PCI_DEVFN(info-params.interface_path.pci.slot,
info-params.interface_path.pci.
function));
@@ -682,9 +682,12 @@
{
struct pci_dev *pci_dev = edd_get_pci_dev(edev);
+ int ret;
if (!pci_dev)
return 1;
- return sysfs_create_link(edev-kobj,pci_dev-dev.kobj,pci_dev);
+ ret = sysfs_create_link(edev-kobj,pci_dev-dev.kobj,pci_dev);
+ pci_dev_put(pci_dev);
+ return ret;
}
static inline void
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sl82c105: Switch to ref counting API
Not sure how this one got missed in the great purge some time ago but it
did.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c
linux-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c 2007-04-12
14:15:04.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c 2007-04-23
11:58:55.016516864 +0100
@@ -349,7 +349,7 @@
/*
* The bridge should be part of the same device, but function 0.
*/
- bridge = pci_find_slot(dev-bus-number,
+ bridge = pci_get_bus_and_slot(dev-bus-number,
PCI_DEVFN(PCI_SLOT(dev-devfn), 0));
if (!bridge)
return -1;
@@ -359,13 +359,15 @@
*/
if (bridge-vendor != PCI_VENDOR_ID_WINBOND ||
bridge-device != PCI_DEVICE_ID_WINBOND_83C553 ||
- bridge-class 8 != PCI_CLASS_BRIDGE_ISA)
+ bridge-class 8 != PCI_CLASS_BRIDGE_ISA) {
+ pci_dev_put(bridge);
return -1;
-
+ }
/*
* We need to find function 0's revision, not function 1
*/
pci_read_config_byte(bridge, PCI_REVISION_ID, rev);
+ pci_dev_put(bridge);
return rev;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
On Mon, Apr 23, 2007 at 01:04:45AM -0700, Andrew Morton wrote: The namesys engineers continue to maintain reiser4 and I continue to receive patches for it. Right now I'd say that the main blockages for reiser4 are a) the developers aren't presently asking for inclusion (afaik) and b) lack of reviewing effort from other kernel developers. If someone else started asking for it to be included and responded to requests for the various code changes required to increase its quality to the required level, wouldn't that be enough? Basically, if someone forked it. Or does it specifically have to be namesys engineers? Oh, two things really interest me about Reiser4. First, I despise having to care about how many tiny files I leave lying around when writing a program. Berkeley DB and its ilk are evil, evil programs that obscure data and make things harder. Secondly, the moves Reiser4 has made towards having actual transactions at the filesystem level also intrigue me. I want to use the filesystem as a DB. IMHO, there is no reason that filesystems shouldn't be a DB sans query language. If there were a more DB-like way to deal with filesystems, I think that it would be that much easier to make something that was a decent replacement for NFS and actually worked. Sadly, unless someone pays me to maintain it, I can't do the fork myself, and I likely wouldn't anyway as being a kernel hacker of something as important as a filesystem is a full-time job and I have other things that interest me a lot more. Just curious, -- Eric Hopper (http://www.omnifarious.org/~hopper/) pgpsYgvXETc70.pgp Description: PGP signature
[PATCH] via-pmu: Switch to ref counting PCI API
Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.21-rc6-mm1/drivers/macintosh/via-pmu.c linux-2.6.21-rc6-mm1/drivers/macintosh/via-pmu.c --- linux.vanilla-2.6.21-rc6-mm1/drivers/macintosh/via-pmu.c2007-04-12 14:15:04.0 +0100 +++ linux-2.6.21-rc6-mm1/drivers/macintosh/via-pmu.c2007-04-23 11:44:53.907384888 +0100 @@ -2130,7 +2130,7 @@ int ret; struct pci_dev *grackle; - grackle = pci_find_slot(0, 0); + grackle = pci_get_bus_and_slot(0, 0); if (!grackle) return -ENODEV; @@ -2177,6 +2177,8 @@ pci_read_config_word(grackle, 0x70, pmcr1); pmcr1 = ~(GRACKLE_PM|GRACKLE_DOZE|GRACKLE_SLEEP|GRACKLE_NAP); pci_write_config_word(grackle, 0x70, pmcr1); + + pci_dev_put(grackle); /* Make sure the PMU is idle */ pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,0); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RESEND] ehea: fix for dlpar and sysfs entries
On Monday 23 April 2007, Jan-Bernd Themann wrote: - dlpar fix: certain resources may only be allocated when first logical port is available, and must be removed when last logical port has been removed - sysfs entries: create symbolic link from each logical port to ehea driver I can't see anything wrong with the patch contents, but if you know that there are two changes, you really should make it two separate patches. Arnd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pci syscall.c: Switch to refcounting API
Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.21-rc6-mm1/drivers/pci/syscall.c linux-2.6.21-rc6-mm1/drivers/pci/syscall.c --- linux.vanilla-2.6.21-rc6-mm1/drivers/pci/syscall.c 2007-04-12 14:14:44.0 +0100 +++ linux-2.6.21-rc6-mm1/drivers/pci/syscall.c 2007-04-23 11:43:53.667542736 +0100 @@ -30,7 +30,7 @@ goto error; err = -ENODEV; - dev = pci_find_slot(bus, dfn); + dev = pci_get_bus_and_slot(bus, dfn); if (!dev) goto error; @@ -67,6 +67,7 @@ err = put_user(dword, (unsigned int __user *)buf); break; }; + pci_dev_put(dev); return err; error: @@ -84,6 +85,7 @@ put_user(-1, (unsigned int __user *)buf); break; }; + pci_dev_put(dev); return err; } @@ -101,7 +103,7 @@ if (!capable(CAP_SYS_ADMIN)) return -EPERM; - dev = pci_find_slot(bus, dfn); + dev = pci_get_bus_and_slot(bus, dfn); if (!dev) return -ENODEV; @@ -139,6 +141,6 @@ break; }; unlock_kernel(); - + pci_dev_put(dev); return err; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] openprom: Switch to ref counting PCI API
Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.21-rc6-mm1/drivers/sbus/char/openprom.c linux-2.6.21-rc6-mm1/drivers/sbus/char/openprom.c --- linux.vanilla-2.6.21-rc6-mm1/drivers/sbus/char/openprom.c 2007-04-12 14:14:44.0 +0100 +++ linux-2.6.21-rc6-mm1/drivers/sbus/char/openprom.c 2007-04-23 12:13:55.087685248 +0100 @@ -249,7 +249,7 @@ #ifdef CONFIG_PCI struct pci_dev *pdev; struct pcidev_cookie *pcp; - pdev = pci_find_slot (((int *) op-oprom_array)[0], + pdev = pci_get_bus_and_slot (((int *) op-oprom_array)[0], ((int *) op-oprom_array)[1]); pcp = pdev-sysdata; @@ -260,6 +260,7 @@ op-oprom_size = sizeof(int); err = copyout(argp, op, bufsize + sizeof(int)); } + pci_dev_put(pdev); #endif } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CRYPTO] is it really optimized ?
Hi
[Sorry for the late answer]
On 4/19/07, Francis Moreau [EMAIL PROTECTED] wrote:
On 4/17/07, Roland Dreier [EMAIL PROTECTED] wrote:
It seems trivial to keep the last key you were given and do a quick
memcmp in your setkey method to see if it's different from the last
key you pushed to hardware, and set a flag if it is. Then only do
your set_key() if you have a new key to pass to hardware.
I'm assuming the expense is in the aes_write() calls, and you could
avoid them if you know you're not writing something new.
that's a wrong assumption. aes_write()/aes_read() are both used to
access to the controller and are slow (no cache involved).
Sorry, I wasn't clear. I meant that the hardware access is what is
slow, and that anything you do on the CPU is relatively cheap compared
to that.
So my suggestion is just to keep a cache (in CPU memory) of what you
have already loaded into the HW, and before reloading the HW just
check the cache and don't do the actual HW access if you're not going
to change the HW contents. So you avoid any extra aes_write and
aes_read calls in the cache hit case.
This would have the advantage of making anything that does lots of
bulk encryption fast without special casing ecryptfs.
I'm not sure how memcmp(key, cache, KEY_SIZE) would impact AES
performance. I need to give it a test but can't today. I'll do
tomorrow and give you back the result.
OK, I gave it a test and it appears that the cache hit case is
slightly worse than unconditionnal key loading. So it means that
testing that hte key is cached is as long as loading the key into the
controller. Here is what I did in set_key() function:
static void set_key(const char *key)
{
static u32 my_key[4] __cacheline_aligned;
u32 key0 = *(const u32 *)(key + 12);
u32 key1 = *(const u32 *)(key + 8);
u32 key2 = *(const u32 *)(key + 4);
u32 key3 = *(const u32 *)(key);
int timeout = 100;
u32 miss = 0;
miss |= key0 ^ my_key[0];
miss |= key1 ^ my_key[1];
miss |= key2 ^ my_key[2];
miss |= key3 ^ my_key[3];
if (miss == 0)
return;
my_key[0] = key0;
my_key[1] = key1;
my_key[2] = key2;
my_key[3] = key3;
aes_write(be32_to_cpu(key0), AES_KEY0);
aes_write(be32_to_cpu(key1), AES_KEY1);
aes_write(be32_to_cpu(key2), AES_KEY2);
aes_write(be32_to_cpu(key3), AES_KEY3);
/* generate dkey: should take 11 cycles */
aes_write(aes_read(AES_CR) | CR_DKEYGEN, AES_CR);
while (aes_read(AES_CR) CR_DKEYGEN) {
if (--timeout == 0)
break;
}
}
So I was wrong, hardware access is not so expensive as I thought. But
it also means that all instructions executed in the drivers'
encrypt()/decrypt() methods have a real cost and skipping key loadings
is a win.
Using the driver exclusively doesn't seem to be the right solution,
but I don't see another way to do that...
--
Francis
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Nvidia/Riva FB: Switch to pci_get refcounting APIs not pci_find_slot
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/video/nvidia/nv_hw.c
linux-2.6.21-rc6-mm1/drivers/video/nvidia/nv_hw.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/video/nvidia/nv_hw.c 2007-04-12
13:40:47.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/video/nvidia/nv_hw.c 2007-04-23
12:16:11.636926608 +0100
@@ -686,7 +686,7 @@
if ((par-Chipset 0x0FF0) == 0x01A0) {
unsigned int uMClkPostDiv;
- dev = pci_find_slot(0, 3);
+ dev = pci_get_bus_and_slot(0, 3);
pci_read_config_dword(dev, 0x6C, uMClkPostDiv);
uMClkPostDiv = (uMClkPostDiv 8) 0xf;
@@ -694,11 +694,11 @@
uMClkPostDiv = 4;
MClk = 40 / uMClkPostDiv;
} else {
- dev = pci_find_slot(0, 5);
+ dev = pci_get_bus_and_slot(0, 5);
pci_read_config_dword(dev, 0x4c, MClk);
MClk /= 1000;
}
-
+
pll = NV_RD32(par-PRAMDAC0, 0x0500);
M = (pll 0) 0xFF;
N = (pll 8) 0xFF;
@@ -707,19 +707,21 @@
sim_data.pix_bpp = (char)pixelDepth;
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- pci_find_slot(0, 1);
+ /* pci_find_slot(0, 1); */
pci_read_config_dword(dev, 0x7C, sim_data.memory_type);
+ pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type 12) 1;
sim_data.memory_width = 64;
- dev = pci_find_slot(0, 3);
+ dev = pci_get_bus_and_slot(0, 3);
pci_read_config_dword(dev, 0, memctrl);
+ pci_dev_put(dev);
memctrl = 16;
if ((memctrl == 0x1A9) || (memctrl == 0x1AB) || (memctrl == 0x1ED)) {
int dimm[3];
- pci_find_slot(0, 2);
+ /* pci_find_slot(0, 2); */
pci_read_config_dword(dev, 0x40, dimm[0]);
dimm[0] = (dimm[0] 8) 0x4f;
pci_read_config_dword(dev, 0x44, dimm[1]);
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/video/nvidia/nv_setup.c
linux-2.6.21-rc6-mm1/drivers/video/nvidia/nv_setup.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/video/nvidia/nv_setup.c
2007-04-12 13:40:47.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/video/nvidia/nv_setup.c2007-04-23
12:16:47.848421624 +0100
@@ -261,7 +261,7 @@
}
#endif
- dev = pci_find_slot(0, 1);
+ dev = pci_get_bus_and_slot(0, 1);
if ((par-Chipset 0x) == 0x01a0) {
int amt = 0;
@@ -276,6 +276,7 @@
par-RamAmountKBytes =
(NV_RD32(par-PFB, 0x020C) 0xFFF0) 10;
}
+ pci_dev_put(dev);
par-CrystalFreqKHz = (NV_RD32(par-PEXTDEV, 0x) (1 6)) ?
14318 : 13500;
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/video/riva/nv_driver.c
linux-2.6.21-rc6-mm1/drivers/video/riva/nv_driver.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/video/riva/nv_driver.c 2007-04-12
13:40:47.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/video/riva/nv_driver.c 2007-04-23
12:17:38.764681176 +0100
@@ -231,12 +231,14 @@
case NV_ARCH_30:
if(chipset == NV_CHIP_IGEFORCE2) {
- dev = pci_find_slot(0, 1);
+ dev = pci_get_bus_and_slot(0, 1);
pci_read_config_dword(dev, 0x7C, amt);
+ pci_dev_put(dev);
memlen = (((amt 6) 31) + 1) * 1024;
} else if (chipset == NV_CHIP_0x01F0) {
- dev = pci_find_slot(0, 1);
+ dev = pci_get_bus_and_slot(0, 1);
pci_read_config_dword(dev, 0x84, amt);
+ pci_dev_put(dev);
memlen = (((amt 4) 127) + 1) * 1024;
} else {
switch ((NV_RD32(chip-PFB, 0x020C) 20)
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/video/riva/riva_hw.c
linux-2.6.21-rc6-mm1/drivers/video/riva/riva_hw.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/video/riva/riva_hw.c 2007-04-12
14:15:05.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/video/riva/riva_hw.c 2007-04-23
12:19:03.149852680 +0100
@@ -1118,8 +1118,9 @@
unsigned int uMClkPostDiv;
struct pci_dev *dev;
-dev = pci_find_slot(0, 3);
+dev = pci_get_bus_and_slot(0, 3);
pci_read_config_dword(dev, 0x6C, uMClkPostDiv);
+pci_dev_put(dev);
uMClkPostDiv = (uMClkPostDiv 8) 0xf;
if(!uMClkPostDiv) uMClkPostDiv = 4;
@@ -1132,8 +1133,9 @@
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
-dev = pci_find_slot(0, 1);
+dev = pci_get_bus_and_slot(0, 1);
pci_read_config_dword(dev, 0x7C,
Re: BUG: Null pointer dereference (2.6.21-rc7)
On Mon, 23 Apr 2007, Andrew Morton wrote: It certainly is. Are you able to identify an earlier kernel in which this didn't happen? 2.6.20? An earlier 2.6.21-rcX? I'll try .18 and .20 and see where that gets me - this is my first time trying to set up packet writing. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] plan-b: Switch to refcounting PCI API
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/media/video/planb.c
linux-2.6.21-rc6-mm1/drivers/media/video/planb.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/media/video/planb.c2007-04-12
13:40:33.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/media/video/planb.c2007-04-23
12:00:54.286385088 +0100
@@ -2207,7 +2207,7 @@
membase 0x%x (base reg. 0x%x)\n,
bus, PCI_SLOT(dev_fn), PCI_FUNC(dev_fn), old_base, confreg);
- pdev = pci_find_slot (bus, dev_fn);
+ pdev = pci_get_bus_and_slot(bus, dev_fn);
if (!pdev) {
printk(KERN_ERR planb: cannot find slot\n);
goto err_out;
@@ -2237,6 +2237,7 @@
pb-planb_base = planb_regs;
pb-planb_base_phys = (struct planb_registers *)new_base;
pb-irq = irq;
+ pb-dev = pdev;
return planb_num;
@@ -2244,6 +2245,7 @@
pci_disable_device(pdev);
err_out:
/* FIXME handle error */ /* comment moved from pci_find_slot, above */
+ pci_dev_put(pdev);
return 0;
}
@@ -2270,6 +2272,8 @@
printk(KERN_INFO PlanB: unregistering with v4l\n);
video_unregister_device(pb-video_dev);
+
+ pci_dev_put(pb-dev);
/* note that iounmap() does nothing on the PPC right now */
iounmap ((void *)pb-planb_base);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sl82c105: Switch to ref counting API
Hello. Alan Cox wrote: Not sure how this one got missed in the great purge some time ago but it did. Signed-off-by: Alan Cox [EMAIL PROTECTED] diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c linux-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c --- linux.vanilla-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c 2007-04-12 14:15:04.0 +0100 +++ linux-2.6.21-rc6-mm1/drivers/ide/pci/sl82c105.c 2007-04-23 11:58:55.016516864 +0100 @@ -349,7 +349,7 @@ /* * The bridge should be part of the same device, but function 0. */ - bridge = pci_find_slot(dev-bus-number, + bridge = pci_get_bus_and_slot(dev-bus-number, PCI_DEVFN(PCI_SLOT(dev-devfn), 0)); Isn't it better to use pci_get_slot()? WBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Testing framework
On Mon, 2007-04-23 at 02:16 +0530, Karuna sagar K wrote: For some time I had been working on this file system test framework. Now I have a implementation for the same and below is the explanation. Any comments are welcome. snip You may want to check out the paper EXPLODE: A Lightweight, General System for Finding Serious Storage System Errors from OSDI 2006 (if you haven't already). The idea sounds very similar to me, although I haven't read all the details of your proposal. Avishay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vioc_irq: Switch to pci refcount safe API
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.21-rc6-mm1/drivers/net/vioc/vioc_irq.c
linux-2.6.21-rc6-mm1/drivers/net/vioc/vioc_irq.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/net/vioc/vioc_irq.c2007-04-12
14:15:05.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/net/vioc/vioc_irq.c2007-04-23
12:01:53.354405384 +0100
@@ -233,8 +233,10 @@
devfn = PCI_DEVFN(slot, func);
/* Find pci_dev structure of the requested function */
- dev = pci_find_slot(dev_in-bus-number, devfn);
+ dev = pci_get_bus_and_slot(dev_in-bus-number, devfn);
if (dev) {
+ int irq = dev-irq
+ pci_dev_put(dev);
return irq;
} else {
return VIOC_IRQ_NONE;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] Kconfig: cleanup s390 v2.
Greetings, I've added the results of the review to the Kconfig cleanup patches for s390. Patch #2 has been split, one half has all the HAS_IOMEM depends lines the other the remaining !S390 depends lines. Andrew: I plan to add patches 1-5 to the for-andrew branch of the git390 repository if that is fine with you. The only thing that will be missing in the tree is the patch that disables wireless for s390. The code does compile but without hardware it is mute to have the config options. I'll wait until the git-wireless.patch is upstream. Patches 7-9 depend on patches found in -mm. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] Kconfig: refine depends statements.
From: Martin Schwidefsky [EMAIL PROTECTED] Refine some depends statements to limit their visibility to the environments that are actually supported. Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/auxdisplay/Kconfig |1 + drivers/char/Kconfig |2 ++ drivers/ieee1394/Kconfig |1 + drivers/kvm/Kconfig|1 + drivers/message/fusion/Kconfig |1 + drivers/message/i2o/Kconfig|1 + 6 files changed, 7 insertions(+) diff -urpN linux-2.6/drivers/auxdisplay/Kconfig linux-2.6-patched/drivers/auxdisplay/Kconfig --- linux-2.6/drivers/auxdisplay/Kconfig2007-04-23 15:50:41.0 +0200 +++ linux-2.6-patched/drivers/auxdisplay/Kconfig2007-04-23 15:52:59.0 +0200 @@ -6,6 +6,7 @@ # menu Auxiliary Display support + depends on PARPORT config KS0108 tristate KS0108 LCD Controller diff -urpN linux-2.6/drivers/char/Kconfig linux-2.6-patched/drivers/char/Kconfig --- linux-2.6/drivers/char/Kconfig 2007-04-23 15:51:30.0 +0200 +++ linux-2.6-patched/drivers/char/Kconfig 2007-04-23 15:52:59.0 +0200 @@ -81,6 +81,7 @@ config VT_HW_CONSOLE_BINDING config SERIAL_NONSTANDARD bool Non-standard serial port support + depends on HAS_IOMEM ---help--- Say Y here if you have any non-standard serial boards -- boards which aren't supported using the standard dumb serial driver. @@ -867,6 +868,7 @@ config COBALT_LCD config DTLK tristate Double Talk PC internal speech card support + depends on ISA help This driver is for the DoubleTalk PC, a speech synthesizer manufactured by RC Systems (http://www.rcsys.com/). It is also diff -urpN linux-2.6/drivers/ieee1394/Kconfig linux-2.6-patched/drivers/ieee1394/Kconfig --- linux-2.6/drivers/ieee1394/Kconfig 2007-04-23 15:51:33.0 +0200 +++ linux-2.6-patched/drivers/ieee1394/Kconfig 2007-04-23 15:52:59.0 +0200 @@ -1,6 +1,7 @@ # -*- shell-script -*- menu IEEE 1394 (FireWire) support + depends on PCI || BROKEN source drivers/firewire/Kconfig diff -urpN linux-2.6/drivers/kvm/Kconfig linux-2.6-patched/drivers/kvm/Kconfig --- linux-2.6/drivers/kvm/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/kvm/Kconfig 2007-04-23 15:52:59.0 +0200 @@ -2,6 +2,7 @@ # KVM configuration # menu Virtualization + depends on X86 config KVM tristate Kernel-based Virtual Machine (KVM) support diff -urpN linux-2.6/drivers/message/fusion/Kconfig linux-2.6-patched/drivers/message/fusion/Kconfig --- linux-2.6/drivers/message/fusion/Kconfig2007-04-23 15:50:43.0 +0200 +++ linux-2.6-patched/drivers/message/fusion/Kconfig2007-04-23 15:52:59.0 +0200 @@ -1,5 +1,6 @@ menu Fusion MPT device support + depends on PCI config FUSION bool diff -urpN linux-2.6/drivers/message/i2o/Kconfig linux-2.6-patched/drivers/message/i2o/Kconfig --- linux-2.6/drivers/message/i2o/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/message/i2o/Kconfig 2007-04-23 15:52:59.0 +0200 @@ -1,5 +1,6 @@ menu I2O device support + depends on PCI config I2O tristate I2O support - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] Kconfig: menus with depends on HAS_IOMEM.
From: Martin Schwidefsky [EMAIL PROTECTED] Add depends on HAS_IOMEM to a number of menus to make them disappear for s390 which does not have I/O memory. Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/ata/Kconfig|1 + drivers/char/ipmi/Kconfig |2 ++ drivers/char/tpm/Kconfig |1 + drivers/edac/Kconfig |1 + drivers/hwmon/Kconfig |1 + drivers/i2c/Kconfig|1 + drivers/ide/Kconfig|1 + drivers/infiniband/Kconfig |1 + drivers/leds/Kconfig |1 + drivers/media/Kconfig |1 + drivers/mfd/Kconfig|1 + drivers/mmc/Kconfig|1 + drivers/mtd/Kconfig|1 + drivers/parport/Kconfig|1 + drivers/pnp/Kconfig|1 + drivers/serial/Kconfig |1 + drivers/spi/Kconfig|1 + drivers/telephony/Kconfig |1 + drivers/usb/Kconfig|1 + drivers/video/Kconfig |1 + drivers/w1/Kconfig |1 + sound/Kconfig |1 + 22 files changed, 23 insertions(+) diff -urpN linux-2.6/drivers/ata/Kconfig linux-2.6-patched/drivers/ata/Kconfig --- linux-2.6/drivers/ata/Kconfig 2007-04-23 15:51:29.0 +0200 +++ linux-2.6-patched/drivers/ata/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -3,6 +3,7 @@ # menu Serial ATA (prod) and Parallel ATA (experimental) drivers + depends on HAS_IOMEM config ATA tristate ATA device support diff -urpN linux-2.6/drivers/char/ipmi/Kconfig linux-2.6-patched/drivers/char/ipmi/Kconfig --- linux-2.6/drivers/char/ipmi/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/char/ipmi/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -3,6 +3,8 @@ # menu IPMI + depends on HAS_IOMEM + config IPMI_HANDLER tristate 'IPMI top-level message handler' help diff -urpN linux-2.6/drivers/char/tpm/Kconfig linux-2.6-patched/drivers/char/tpm/Kconfig --- linux-2.6/drivers/char/tpm/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/char/tpm/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -3,6 +3,7 @@ # menu TPM devices + depends on HAS_IOMEM config TCG_TPM tristate TPM Hardware Support diff -urpN linux-2.6/drivers/edac/Kconfig linux-2.6-patched/drivers/edac/Kconfig --- linux-2.6/drivers/edac/Kconfig 2007-04-23 15:51:31.0 +0200 +++ linux-2.6-patched/drivers/edac/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -7,6 +7,7 @@ # menu 'EDAC - error detection and reporting (RAS) (EXPERIMENTAL)' + depends on HAS_IOMEM config EDAC tristate EDAC core system error reporting (EXPERIMENTAL) diff -urpN linux-2.6/drivers/hwmon/Kconfig linux-2.6-patched/drivers/hwmon/Kconfig --- linux-2.6/drivers/hwmon/Kconfig 2007-04-23 15:51:31.0 +0200 +++ linux-2.6-patched/drivers/hwmon/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -3,6 +3,7 @@ # menu Hardware Monitoring support + depends on HAS_IOMEM config HWMON tristate Hardware Monitoring support diff -urpN linux-2.6/drivers/i2c/Kconfig linux-2.6-patched/drivers/i2c/Kconfig --- linux-2.6/drivers/i2c/Kconfig 2007-04-23 15:51:31.0 +0200 +++ linux-2.6-patched/drivers/i2c/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -3,6 +3,7 @@ # menu I2C support + depends on HAS_IOMEM config I2C tristate I2C support diff -urpN linux-2.6/drivers/ide/Kconfig linux-2.6-patched/drivers/ide/Kconfig --- linux-2.6/drivers/ide/Kconfig 2007-04-23 15:51:32.0 +0200 +++ linux-2.6-patched/drivers/ide/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -7,6 +7,7 @@ if BLOCK menu ATA/ATAPI/MFM/RLL support + depends on HAS_IOMEM config IDE tristate ATA/ATAPI/MFM/RLL support diff -urpN linux-2.6/drivers/infiniband/Kconfig linux-2.6-patched/drivers/infiniband/Kconfig --- linux-2.6/drivers/infiniband/Kconfig2007-04-23 15:50:42.0 +0200 +++ linux-2.6-patched/drivers/infiniband/Kconfig2007-04-23 15:53:05.0 +0200 @@ -1,4 +1,5 @@ menu InfiniBand support + depends on HAS_IOMEM config INFINIBAND depends on PCI || BROKEN diff -urpN linux-2.6/drivers/leds/Kconfig linux-2.6-patched/drivers/leds/Kconfig --- linux-2.6/drivers/leds/Kconfig 2007-04-23 15:51:37.0 +0200 +++ linux-2.6-patched/drivers/leds/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -1,5 +1,6 @@ menu LED devices + depends on HAS_IOMEM config NEW_LEDS bool LED Support diff -urpN linux-2.6/drivers/media/Kconfig linux-2.6-patched/drivers/media/Kconfig --- linux-2.6/drivers/media/Kconfig 2007-04-23 15:50:43.0 +0200 +++ linux-2.6-patched/drivers/media/Kconfig 2007-04-23 15:53:05.0 +0200 @@ -3,6 +3,7 @@ # menu Multimedia devices + depends on HAS_IOMEM config VIDEO_DEV tristate Video For Linux diff -urpN linux-2.6/drivers/mfd/Kconfig
Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7
SUBSYSTEM==tifm, ACTION==add, TIFM_CARD_TYPE==SD, RUN+=/sbin/modprobe tifm_sd Thanks. As a side note: I have some very good reasons for the current driver architecture. You may want to look them up in the mail archive (I outlined them during the initial driver submission). I am not in any way argue that your driver architecture is wrong or that you should change anything. My point was simple. [tifm_sd] can only work with [tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which would have port offsets different that [tifm_7xx1], you would also need a completely new modules for slots (sd, ms, etc). -- Sergey Yanovich - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] Kconfig: unwanted menus for s390.
From: Martin Schwidefsky [EMAIL PROTECTED] Disable some more menus in the configuration files that are of no interest to a s390 machine. Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/dma/Kconfig |1 + drivers/input/Kconfig |1 + drivers/isdn/Kconfig|1 + drivers/net/phy/Kconfig |1 + drivers/rtc/Kconfig |1 + net/ax25/Kconfig|2 +- net/bluetooth/Kconfig |2 +- net/irda/Kconfig|2 +- 8 files changed, 8 insertions(+), 3 deletions(-) diff -urpN linux-2.6/drivers/dma/Kconfig linux-2.6-patched/drivers/dma/Kconfig --- linux-2.6/drivers/dma/Kconfig 2007-04-23 15:51:31.0 +0200 +++ linux-2.6-patched/drivers/dma/Kconfig 2007-04-23 15:53:07.0 +0200 @@ -3,6 +3,7 @@ # menu DMA Engine support + depends on !S390 config DMA_ENGINE bool Support for DMA engines diff -urpN linux-2.6/drivers/input/Kconfig linux-2.6-patched/drivers/input/Kconfig --- linux-2.6/drivers/input/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/input/Kconfig 2007-04-23 15:53:07.0 +0200 @@ -3,6 +3,7 @@ # menu Input device support + depends on !S390 config INPUT tristate Generic input layer (needed for keyboard, mouse, ...) if EMBEDDED diff -urpN linux-2.6/drivers/isdn/Kconfig linux-2.6-patched/drivers/isdn/Kconfig --- linux-2.6/drivers/isdn/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/isdn/Kconfig 2007-04-23 15:53:07.0 +0200 @@ -3,6 +3,7 @@ # menu ISDN subsystem + depends on !S390 config ISDN tristate ISDN support diff -urpN linux-2.6/drivers/net/phy/Kconfig linux-2.6-patched/drivers/net/phy/Kconfig --- linux-2.6/drivers/net/phy/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/drivers/net/phy/Kconfig 2007-04-23 15:53:07.0 +0200 @@ -3,6 +3,7 @@ # menu PHY device support + depends on !S390 config PHYLIB tristate PHY Device support and infrastructure diff -urpN linux-2.6/drivers/rtc/Kconfig linux-2.6-patched/drivers/rtc/Kconfig --- linux-2.6/drivers/rtc/Kconfig 2007-04-23 15:51:51.0 +0200 +++ linux-2.6-patched/drivers/rtc/Kconfig 2007-04-23 15:53:07.0 +0200 @@ -3,6 +3,7 @@ # menu Real Time Clock + depends on !S390 config RTC_LIB tristate diff -urpN linux-2.6/net/ax25/Kconfig linux-2.6-patched/net/ax25/Kconfig --- linux-2.6/net/ax25/Kconfig 2007-04-23 15:50:54.0 +0200 +++ linux-2.6-patched/net/ax25/Kconfig 2007-04-23 15:53:07.0 +0200 @@ -3,7 +3,7 @@ # menuconfig HAMRADIO - depends on NET + depends on NET !S390 bool Amateur Radio support help If you want to connect your Linux box to an amateur radio, answer Y diff -urpN linux-2.6/net/bluetooth/Kconfig linux-2.6-patched/net/bluetooth/Kconfig --- linux-2.6/net/bluetooth/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/net/bluetooth/Kconfig 2007-04-23 15:53:08.0 +0200 @@ -3,7 +3,7 @@ # menuconfig BT - depends on NET + depends on NET !S390 tristate Bluetooth subsystem support help Bluetooth is low-cost, low-power, short-range wireless technology. diff -urpN linux-2.6/net/irda/Kconfig linux-2.6-patched/net/irda/Kconfig --- linux-2.6/net/irda/Kconfig 2007-02-04 19:44:54.0 +0100 +++ linux-2.6-patched/net/irda/Kconfig 2007-04-23 15:53:08.0 +0200 @@ -3,7 +3,7 @@ # menuconfig IRDA - depends on NET + depends on NET !S390 tristate IrDA (infrared) subsystem support select CRC_CCITT ---help--- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] Kconfig: common config options for s390.
From: Martin Schwidefsky [EMAIL PROTECTED] Disable some configuration options in the common Kconfig files that are of no interest to a s390 machine. Enable hangcheck timer. Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/char/Kconfig |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff -urpN linux-2.6/drivers/char/Kconfig linux-2.6-patched/drivers/char/Kconfig --- linux-2.6/drivers/char/Kconfig 2007-04-23 15:53:01.0 +0200 +++ linux-2.6-patched/drivers/char/Kconfig 2007-04-23 15:53:09.0 +0200 @@ -6,6 +6,7 @@ menu Character devices config VT bool Virtual terminal if EMBEDDED + depends on !S390 select INPUT default y if !VIOCONS ---help--- @@ -775,7 +776,7 @@ config NVRAM config RTC tristate Enhanced Real Time Clock Support - depends on !PPC !PARISC !IA64 !M68K (!SPARC || PCI) !FRV !ARM !SUPERH + depends on !PPC !PARISC !IA64 !M68K (!SPARC || PCI) !FRV !ARM !SUPERH !S390 ---help--- If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod (man mknod), you @@ -823,7 +824,7 @@ config SGI_IP27_RTC config GEN_RTC tristate Generic /dev/rtc emulation - depends on RTC!=y !IA64 !ARM !M32R !SPARC !FRV + depends on RTC!=y !IA64 !ARM !M32R !SPARC !FRV !S390 ---help--- If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod (man mknod), you @@ -1054,7 +1055,7 @@ config HPET_MMAP config HANGCHECK_TIMER tristate Hangcheck timer - depends on X86 || IA64 || PPC64 + depends on X86 || IA64 || PPC64 || S390 help The hangcheck-timer module detects when the system has gone out to lunch past a certain margin. It can reboot the system - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] Kconfig: use common Kconfig files for s390.
From: Martin Schwidefsky [EMAIL PROTECTED] Disband drivers/s390/Kconfig, use the common Kconfig files. The s390 specific config options from drivers/s390/Kconfig are moved to the respective common Kconfig files. Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- arch/s390/Kconfig | 49 +++-- drivers/block/Kconfig |4 drivers/char/Kconfig |2 drivers/crypto/Kconfig | 22 drivers/s390/Kconfig | 239 - drivers/s390/block/Kconfig | 11 -- drivers/s390/char/Kconfig | 166 +++ drivers/s390/net/Kconfig |8 - include/asm-s390/param.h |2 9 files changed, 217 insertions(+), 286 deletions(-) diff -urpN linux-2.6/arch/s390/Kconfig linux-2.6-patched/arch/s390/Kconfig --- linux-2.6/arch/s390/Kconfig 2007-04-23 15:51:21.0 +0200 +++ linux-2.6-patched/arch/s390/Kconfig 2007-04-23 15:53:10.0 +0200 @@ -4,27 +4,23 @@ # config MMU - bool - default y + def_bool y config ZONE_DMA def_bool y depends on 64BIT config LOCKDEP_SUPPORT - bool - default y + def_bool y config STACKTRACE_SUPPORT - bool - default y + def_bool y config RWSEM_GENERIC_SPINLOCK bool config RWSEM_XCHGADD_ALGORITHM - bool - default y + def_bool y config ARCH_HAS_ILOG2_U32 bool @@ -35,8 +31,7 @@ config ARCH_HAS_ILOG2_U64 default n config GENERIC_HWEIGHT - bool - default y + def_bool y config GENERIC_TIME def_bool y @@ -55,8 +50,7 @@ config NO_DMA mainmenu Linux Kernel Configuration config S390 - bool - default y + def_bool y source init/Kconfig @@ -280,6 +274,10 @@ config WARN_STACK_SIZE config ARCH_POPULATES_NODE_MAP def_bool y +comment Kernel preemption + +source kernel/Kconfig.preempt + source mm/Kconfig config HOLES_IN_ZONE @@ -320,17 +318,6 @@ config QDIO_DEBUG comment Misc -config PREEMPT - bool Preemptible Kernel - help - This option reduces the latency of the kernel when reacting to - real-time or interactive events by allowing a low priority process to - be preempted even if it is in kernel mode executing a system call. - This allows applications to run more reliably even when the system is - under load. - - Say N if you are unsure. - config IPL bool Builtin IPL record support help @@ -488,6 +475,8 @@ config APPLDATA_NET_SUM This can also be compiled as a module, which will be called appldata_net_sum.o. +source kernel/Kconfig.hz + config NO_IDLE_HZ bool No HZ timer ticks in idle help @@ -535,18 +524,12 @@ endmenu source net/Kconfig config PCMCIA - bool - default n - -source drivers/base/Kconfig + def_bool n -source drivers/connector/Kconfig - -source drivers/scsi/Kconfig - -source drivers/s390/Kconfig +config CCW + def_bool y -source drivers/net/Kconfig +source drivers/Kconfig source fs/Kconfig diff -urpN linux-2.6/drivers/block/Kconfig linux-2.6-patched/drivers/block/Kconfig --- linux-2.6/drivers/block/Kconfig 2007-04-23 15:50:41.0 +0200 +++ linux-2.6-patched/drivers/block/Kconfig 2007-04-23 15:53:10.0 +0200 @@ -444,8 +444,6 @@ config CDROM_PKTCDVD_WCACHE this option is dangerous unless the CD-RW media is known good, as we don't do deferred write error handling yet. -source drivers/s390/block/Kconfig - config ATA_OVER_ETH tristate ATA over Ethernet support depends on NET @@ -453,6 +451,8 @@ config ATA_OVER_ETH This driver provides Support for ATA over Ethernet block devices like the Coraid EtherDrive (R) Storage Blade. +source drivers/s390/block/Kconfig + endmenu endif diff -urpN linux-2.6/drivers/char/Kconfig linux-2.6-patched/drivers/char/Kconfig --- linux-2.6/drivers/char/Kconfig 2007-04-23 15:53:10.0 +0200 +++ linux-2.6-patched/drivers/char/Kconfig 2007-04-23 15:53:10.0 +0200 @@ -1090,5 +1090,7 @@ config DEVPORT depends on ISA || PCI default y +source drivers/s390/char/Kconfig + endmenu diff -urpN linux-2.6/drivers/crypto/Kconfig linux-2.6-patched/drivers/crypto/Kconfig --- linux-2.6/drivers/crypto/Kconfig2007-04-23 15:50:42.0 +0200 +++ linux-2.6-patched/drivers/crypto/Kconfig2007-04-23 15:53:10.0 +0200 @@ -66,4 +66,26 @@ config CRYPTO_DEV_GEODE To compile this driver as a module, choose M here: the module will be called geode-aes. +config ZCRYPT + tristate Support for PCI-attached cryptographic adapters + depends on S390 + select ZCRYPT_MONOLITHIC if ZCRYPT=y + default m + help + Select this option if you want to use a PCI-attached cryptographic + adapter like: + + PCI Cryptographic
[PATCH 6/9] Kconfig: no wireless on s390.
From: Martin Schwidefsky [EMAIL PROTECTED] Hide the config menues for wireless on s390. Goes on top of git-wireless.patch. Cc: John W. Linville [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/net/wireless/Kconfig |1 + net/Kconfig |1 + 2 files changed, 2 insertions(+) diff -urpN linux-2.6/drivers/net/wireless/Kconfig linux-2.6-patched/drivers/net/wireless/Kconfig --- linux-2.6/drivers/net/wireless/Kconfig 2007-04-23 15:51:50.0 +0200 +++ linux-2.6-patched/drivers/net/wireless/Kconfig 2007-04-23 15:53:12.0 +0200 @@ -3,6 +3,7 @@ # menu Wireless LAN + depends on !S390 config WLAN_PRE80211 bool Wireless LAN (pre-802.11) diff -urpN linux-2.6/net/Kconfig linux-2.6-patched/net/Kconfig --- linux-2.6/net/Kconfig 2007-04-23 15:52:26.0 +0200 +++ linux-2.6-patched/net/Kconfig 2007-04-23 15:53:12.0 +0200 @@ -217,6 +217,7 @@ config FIB_RULES bool menu Wireless + depends on !S390 source net/wireless/Kconfig source net/mac80211/Kconfig - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] Kconfig: silicon backplane dependency.
From: Martin Schwidefsky [EMAIL PROTECTED] Add HAS_IOMEM dependency to the Sonics Silicon Backplane menu. This hides the menu for s390. Goes on top of git-wireless.patch. Cc: Michael Buesch [EMAIL PROTECTED] Cc: John W. Linville [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/ssb/Kconfig |1 + 1 files changed, 1 insertion(+) diff -urpN linux-2.6/drivers/ssb/Kconfig linux-2.6-patched/drivers/ssb/Kconfig --- linux-2.6/drivers/ssb/Kconfig 2007-04-23 15:51:57.0 +0200 +++ linux-2.6-patched/drivers/ssb/Kconfig 2007-04-23 15:53:15.0 +0200 @@ -1,4 +1,5 @@ menu Sonics Silicon Backplane + depends on HAS_IOMEM config SSB tristate Sonics Silicon Backplane support - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] Kconfig: no userspace I/O on s390.
[PATCH 7/9] Kconfig: no userspace I/O on s390. From: Martin Schwidefsky [EMAIL PROTECTED] Hide the config menu for userspace I/O on s390. Goes on top of gregkh-driver-uio.patch. Cc: Greg Kroah-Hartman [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/uio/Kconfig |2 ++ 1 files changed, 2 insertions(+) diff -urpN linux-2.6/drivers/uio/Kconfig linux-2.6-patched/drivers/uio/Kconfig --- linux-2.6/drivers/uio/Kconfig 2007-04-23 15:51:59.0 +0200 +++ linux-2.6-patched/drivers/uio/Kconfig 2007-04-23 15:53:14.0 +0200 @@ -1,4 +1,6 @@ menu Userspace I/O + depends on !S390 + config UIO tristate Userspace I/O drivers default n - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] Kconfig: broadcom 4400 dependency.
[PATCH 9/9] Kconfig: broadcom 4400 dependency. From: Martin Schwidefsky [EMAIL PROTECTED] Add HAS_IOMEM dependency to the B44 Broadcom 4400 ethernet support config option. This hides the option for s390. Goes on top of git-wireless.patch. Cc: Michael Buesch [EMAIL PROTECTED] Cc: John W. Linville [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertion(+) diff -urpN linux-2.6/drivers/net/Kconfig linux-2.6-patched/drivers/net/Kconfig --- linux-2.6/drivers/net/Kconfig 2007-04-23 15:51:44.0 +0200 +++ linux-2.6-patched/drivers/net/Kconfig 2007-04-23 15:53:16.0 +0200 @@ -1432,6 +1432,7 @@ config APRICOT config B44 tristate Broadcom 4400 ethernet support + depends on HAS_IOMEM select SSB select MII help - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 2/3] freezer: Introduce freezer_flags
Hi Satyam, On Mon, Apr 23, 2007 at 09:39:30AM +0530, Satyam Sharma wrote: Hi Rafael, +/* + * Per task flags used by the freezer + * + * They should not be referred to directly outside of this file. + */ +#define TFF_NOFREEZE 0 /* task should not be frozen */ +#define TFF_FREEZE 8 /* task should go to the refrigerator ASAP */ +#define TFF_SKIP 9 /* do not count this task as freezable */ +#define TFF_FROZEN 10 /* task is frozen */ Aren't NOFREEZE and SKIP doing the same thing? One of them appears superfluous. I'm looking at 21-rc6-mm1 and vfork(2) seems to be its only user. Seeing how vfork(2) used it, can't the call to freezer_do_not_count() be replaced with a call to freezer_exempt()? Similarly, the freezer_count() after the wait_for_completion might just as well be a clear of the NOFREEZE bit followed by a try_to_freeze(). Could you please explain the rationale behind the SKIP flag? The difference between the NOFREEZE and the SKIP flag is a subtle one. When a task (say p) sets it's NOFREEZE flag, it tells the freezer not to consider it for freezing. Which means freezeable(p) will return 0. So the freezer will not even mark it for freezing. However, when a task sets it SKIP flag, it tells the freezer - I might block at a safe place. So when you are counting the processes which have been marked as freezeable, but have not frozen yet, please don't count me in. IOW, please skip me. Thus such a task can still be marked for freezing. The typical usage is freezer_do_not_count(current); /* currents goes to an uninterruptible sleep, like wait_for_completion. */ freezer_count(current); Once the task wakes up from it's uninterruptible sleep, it will call freezer_count which in turn calls try_to_freeze. If the task was marked for freezing, it will be frozen now. You may want to check the thread http://lkml.org/lkml/2007/2/18/47 on how it came into existance. Cheers, Satyam Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Nvidia AGP: Use refcount aware PCI interfaces
On Mon, Apr 23, 2007 at 02:50:27PM +0100, Alan Cox wrote: Signed-off-by: Alan Cox [EMAIL PROTECTED] This is lacking a changelog. What's the purpose of changing this? Is pci_find_slot() obsolete and going away? (If so, it should be marked as such). These devices aren't hotpluggable, so I'm not sure why they need to be reference counted. Inquisitive minds would like to know more. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Nvidia/Riva FB: Switch to pci_get refcounting APIs not pci_find_slot
On Mon, 2007-04-23 at 15:01 +0100, Alan Cox wrote:
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Thanks, and this actually helped expose 2 bugs.
pll = NV_RD32(par-PRAMDAC0, 0x0500);
M = (pll 0) 0xFF;
N = (pll 8) 0xFF;
@@ -707,19 +707,21 @@
sim_data.pix_bpp = (char)pixelDepth;
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- pci_find_slot(0, 1);
+ /* pci_find_slot(0, 1); */
This should have been dev = pci_find_slot/pci_get_bus_and_slot().
pci_read_config_dword(dev, 0x7C, sim_data.memory_type);
+ pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type 12) 1;
sim_data.memory_width = 64;
- dev = pci_find_slot(0, 3);
+ dev = pci_get_bus_and_slot(0, 3);
pci_read_config_dword(dev, 0, memctrl);
+ pci_dev_put(dev);
memctrl = 16;
if ((memctrl == 0x1A9) || (memctrl == 0x1AB) || (memctrl == 0x1ED)) {
int dimm[3];
- pci_find_slot(0, 2);
+ /* pci_find_slot(0, 2); */
Ditto.
Will resubmit.
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] 64bit-futex - provide new commands instead of new syscall
Hi,
Jakub Jelinek a écrit :
I don't think you should blindly add all operations to sys_futex64 without
thinking what they really do.
E.g. FUTEX_{{,UN,TRY}LOCK,CMP_REQUEUE}_PI doesn't really make any sense for
64-bit
futexes, the format of PI futexes is hardcoded in the kernel and is always
32-bit, see FUTEX_TID_MASK, FUTEX_WAITERS, FUTEX_OWNER_DIED definitions.
exit_robust_list/handle_futex_death will handle 32-bit PI futexes anyway.
Similarly, sys_futex64 shouldn't support the obsolete operations that
are there solely for compatibility (e.g. FUTEX_REQUEUE or FUTEX_FD).
When you just -ENOSYS on the PI ops, there is no need to implement
futex_atomic_cmpxchg_inatomic64.
FUTEX_WAKE_OP is questionable for 64-bit, IMHO it is better to just
-ENOSYS on it and only if anyone ever finds actual uses for it, add it.
For 64-bit futexes the only needed operations are actually
FUTEX_WAIT and perhaps FUTEX_CMP_REQUEUE, so I wonder if it isn't
better to just add FUTEX_WAIT64 and FUTEX_CMP_REQUEUE64 ops to sys_futex
instead of adding a new syscall.
But the FUTEX_{{,UN,TRY}LOCK,CMP_REQUEUE}_PI removal for 64-bit futexes
is IMHO the most important part of my complain.
Following this mail sent few weeks ago, here is a patch which should meet your
requirements.
I've quickly done it on top of the latest -mm (2.6.21-rc6-mm2) and a little bit
tested.
To be honest, as I'm not really aware of your exact needs and as I don't know
the exact usage which will be done with 64bit futexes, I can't really maintain
it. So I'll let you take/modify/adapt this patch following your needs.
Thanks,
Signed-off-by: Pierre Peiffer [EMAIL PROTECTED]
--
Pierre
---
include/asm-ia64/futex.h|8 -
include/asm-powerpc/futex.h |6 -
include/asm-s390/futex.h|8 -
include/asm-sparc64/futex.h |8 -
include/asm-um/futex.h |9 -
include/asm-x86_64/futex.h | 86 ---
include/asm-x86_64/unistd.h |2
include/linux/futex.h |8 +
include/linux/syscalls.h|3
kernel/futex.c | 199 +---
kernel/futex_compat.c |2
kernel/sys_ni.c |1
12 files changed, 93 insertions(+), 247 deletions(-)
Index: linux-2.6.21-rc6-mm2/include/asm-ia64/futex.h
===
--- linux-2.6.21-rc6-mm2.orig/include/asm-ia64/futex.h 2007-04-20 14:01:25.0 +0200
+++ linux-2.6.21-rc6-mm2/include/asm-ia64/futex.h 2007-04-20 13:50:00.0 +0200
@@ -124,13 +124,7 @@ futex_atomic_cmpxchg_inatomic(int __user
static inline u64
futex_atomic_cmpxchg_inatomic64(u64 __user *uaddr, u64 oldval, u64 newval)
{
- return 0;
-}
-
-static inline int
-futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
-{
- return 0;
+ return -ENOSYS;
}
#endif /* _ASM_FUTEX_H */
Index: linux-2.6.21-rc6-mm2/include/asm-powerpc/futex.h
===
--- linux-2.6.21-rc6-mm2.orig/include/asm-powerpc/futex.h 2007-04-20 14:01:25.0 +0200
+++ linux-2.6.21-rc6-mm2/include/asm-powerpc/futex.h 2007-04-20 13:51:49.0 +0200
@@ -119,11 +119,5 @@ futex_atomic_cmpxchg_inatomic64(u64 __us
return 0;
}
-static inline int
-futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
-{
- return 0;
-}
-
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_FUTEX_H */
Index: linux-2.6.21-rc6-mm2/include/asm-s390/futex.h
===
--- linux-2.6.21-rc6-mm2.orig/include/asm-s390/futex.h 2007-04-20 14:01:24.0 +0200
+++ linux-2.6.21-rc6-mm2/include/asm-s390/futex.h 2007-04-20 13:47:30.0 +0200
@@ -51,13 +51,7 @@ static inline int futex_atomic_cmpxchg_i
static inline u64
futex_atomic_cmpxchg_inatomic64(u64 __user *uaddr, u64 oldval, u64 newval)
{
- return 0;
-}
-
-static inline int
-futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
-{
- return 0;
+ return -ENOSYS;
}
#endif /* __KERNEL__ */
Index: linux-2.6.21-rc6-mm2/include/asm-sparc64/futex.h
===
--- linux-2.6.21-rc6-mm2.orig/include/asm-sparc64/futex.h 2007-04-20 14:01:25.0 +0200
+++ linux-2.6.21-rc6-mm2/include/asm-sparc64/futex.h 2007-04-20 13:48:48.0 +0200
@@ -108,13 +108,7 @@ futex_atomic_cmpxchg_inatomic(int __user
static inline u64
futex_atomic_cmpxchg_inatomic64(u64 __user *uaddr, u64 oldval, u64 newval)
{
- return 0;
-}
-
-static inline int
-futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
-{
- return 0;
+ return -ENOSYS;
}
#endif /* !(_SPARC64_FUTEX_H) */
Index: linux-2.6.21-rc6-mm2/include/asm-um/futex.h
===
--- linux-2.6.21-rc6-mm2.orig/include/asm-um/futex.h 2007-04-20 14:01:25.0 +0200
+++ linux-2.6.21-rc6-mm2/include/asm-um/futex.h 2007-04-20 13:51:42.0 +0200
@@ -6,14 +6,7 @@
static inline u64
Re: [PATCH 7/8] Kconfig: silicon backplane dependency.
On Monday 23 April 2007 13:48, Arnd Bergmann wrote: On Monday 23 April 2007, Martin Schwidefsky wrote: Isn't B44 already behind a WIRELESS or IEEE80211 or similar option that can't be selected on s390? No, the option can be found in drivers/net/Kconfig under menu Ethernet (10 or 100Mbit). Ah, I was confusing it with b43. Depends on HAS_IOMEM sounds good then. I'd prefer to make it 'depends on SSB' instead of 'select SSB', but I don't want to get into that argument ;-) No, don't. Add depends on to SSB and B44. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] Kconfig: silicon backplane dependency.
On Monday 23 April 2007 16:14, Martin Schwidefsky wrote: From: Martin Schwidefsky [EMAIL PROTECTED] Add HAS_IOMEM dependency to the Sonics Silicon Backplane menu. This hides the menu for s390. Goes on top of git-wireless.patch. Cc: Michael Buesch [EMAIL PROTECTED] Cc: John W. Linville [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] Acked-by: Michael Buesch [EMAIL PROTECTED] --- drivers/ssb/Kconfig |1 + 1 files changed, 1 insertion(+) diff -urpN linux-2.6/drivers/ssb/Kconfig linux-2.6-patched/drivers/ssb/Kconfig --- linux-2.6/drivers/ssb/Kconfig 2007-04-23 15:51:57.0 +0200 +++ linux-2.6-patched/drivers/ssb/Kconfig 2007-04-23 15:53:15.0 +0200 @@ -1,4 +1,5 @@ menu Sonics Silicon Backplane + depends on HAS_IOMEM config SSB tristate Sonics Silicon Backplane support -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] Kconfig: broadcom 4400 dependency.
On Monday 23 April 2007 16:14, Martin Schwidefsky wrote: [PATCH 9/9] Kconfig: broadcom 4400 dependency. From: Martin Schwidefsky [EMAIL PROTECTED] Add HAS_IOMEM dependency to the B44 Broadcom 4400 ethernet support config option. This hides the option for s390. Goes on top of git-wireless.patch. Cc: Michael Buesch [EMAIL PROTECTED] Cc: John W. Linville [EMAIL PROTECTED] Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED] Acked-by: Michael Buesch [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertion(+) diff -urpN linux-2.6/drivers/net/Kconfig linux-2.6-patched/drivers/net/Kconfig --- linux-2.6/drivers/net/Kconfig 2007-04-23 15:51:44.0 +0200 +++ linux-2.6-patched/drivers/net/Kconfig 2007-04-23 15:53:16.0 +0200 @@ -1432,6 +1432,7 @@ config APRICOT config B44 tristate Broadcom 4400 ethernet support + depends on HAS_IOMEM select SSB select MII help -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitbanging i2c bus driver using the GPIO API
On 23/04/07 11:42 +0200, Jean Delvare wrote: I seem to remember there has been a patch floating around to auto-detect the right ports back in June 2006, but it seems to have been lost somehow. Jordan, do you remember? I don't remember that, and Google isn't helping, either. Regardless, randomly hitting ISA ports seems scary to me. I know its a pain to use the module params all the time, but thats really probably the cleanest way to to it without carrying around a special patch for your system. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. www.amd.com/embeddedprocessors - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
