[PATCH] x86_64: make GART PTEs uncacheable

[Joachim Deguara]

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

[Eric W. Biederman]

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

[Jean Delvare]

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_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 = _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 = _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

[Rik van Riel]

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

[Ingo Molnar]

* 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)

[Christian Hesse]

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

[Andi Kleen]

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

[Jarek Poplawski]

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

[Rene Herman]

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

[Jean Delvare]

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

[Joachim Deguara]

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

[Andi Kleen]

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)

[Ingo Molnar]

* 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   /* For AT_VECTOR_SIZE */
-#include   /* For run_node */
 /*
  * cloning flags:
  */
@@ -37,6 +36,8 @@
 
 #ifdef __KERNEL__
 
+#include   /* 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]

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

[Jesper Juhl]

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

[Rik van Riel]

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)

[Ingo Molnar]

* 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

[Takashi Iwai]

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

[Nick Piggin]

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

[Andy Whitcroft]

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

[Gautham R Shenoy]

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

[Rik van Riel]

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

[Nick Piggin]

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

[Gautham R Shenoy]

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(>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(_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(_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

[Pavel Machek]

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

[Pavel Machek]

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

[Jakub Jelinek]

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

[Rik van Riel]

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

[Alan Cox]

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 = _c2_port_ops
};
-   /* Revision 0xC3 is UDMA100 */
+   /* Revision 0xC3 is UDMA66 for now */
static struct ata_port_info info_c3 = {
.sht = _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 = _c2_port_ops
};
-   /* Revision 0xC4 is UDMA133 */
+   /* Revision 0xC4 is UDMA100 */
static struct ata_port_info info_c4 = {
.sht = _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 = _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

[Pavel Machek]

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

[Vaidyanathan Srinivasan]

[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//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

[Hisashi Hifumi]

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(>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(>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(_list)) {
page = lru_to_page(_list);
VM_BUG_ON(PageLRU(page));
-   SetPageLRU(page);
+   __SetPageLRU(page);
list_del(>lru);
if (PageActive(page))
add_page_to_active_list(zone, page);
@@ -851,7 +851,7 @@ force_reclaim_mapped:
page = lru_to_page(_inactive);
prefetchw_prev_lru_page(page, _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(_active);
prefetchw_prev_lru_page(page, _active, flags);
VM_BUG_ON(PageLRU(page));
-   SetPageLRU(page);
+   __SetPageLRU(page);
VM_BUG_ON(!PageActive(page));
list_move(>lru, >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

[Vaidyanathan Srinivasan]

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 = 
> + 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(_group_lock);
> + l = _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 != _container_group.list);
> + spin_unlock_irq(_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(_group_lock);
+	spin_lock_irqsave(_group_lock, flags);
 	l = _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 != _container_group.list);
-	spin_unlock_irq(_group_lock);
+	spin_unlock_irqrestore(_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

[Kalpak Shah]

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.

[Martin Schwidefsky]

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

[Hugh Dickins]

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.

[Arnd Bergmann]

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

[Rusty Russell]

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

[Karuna sagar K]

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.







..

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

[Christoph Hellwig]

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.

[Martin Schwidefsky]

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

[l . genoni]

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

[Amit Gud]

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]

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

[Yasunori Goto]

> 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, ));
> > } else if (memcmp(cp, "kernelcore=",11) == 0) {
> > -   cmdline_parse_kernelcore(cp+11);
> > +   cmdline_parse_kernelcore(cp+11, );
> > } else if (memcmp(cp, "min_addr=", 9) == 0) {
> > min_addr = GRANULEROUNDDOWN(memparse(cp + 9, ));
> > } 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, );
> > +   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.

[Arnd Bergmann]

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

[Robert P. J. Day]

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

[Parag Warudkar]

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(_lock);
file->private_data = NULL;
-   chip->num_opens--;
del_singleshot_timer_sync(>user_read_timer);
-   flush_scheduled_work();
atomic_set(>data_pending, 0);
+   chip->num_opens--;
put_device(chip->dev);
kfree(chip->data_buffer);
spin_unlock(_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(>buffer_mutex);
init_MUTEX(>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

[Jan-Bernd Themann]

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 
 #include 
 
 #define DRV_NAME   "ehea"
-#define DRV_VERSION"EHEA_0055"
+#define DRV_VERSION"EHEA_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(>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, >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(>kobj, >kobj,
+   kobject_name(>kobj));
+   if (ret == 0) {
+   ret = sysfs_create_link(>kobj, >kobj,
+   "driver");
+   if (ret)
+   sysfs_remove_link(>kobj,
+ kobject_name(>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(>kobj, kobject_name(>kobj));
+   sysfs_remove_link(>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 = >adapter->ebus_dev->ofdev.dev;
+   port->ofdev.dev.bus = _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(>ofdev);
@@ -2384,8 +2457,16 @@ static struct device *ehea_register_port
goto out_unreg_of_dev;
}
 
+   ret = ehea_driver_sysfs_add(>ofdev.dev, _driver.driver);
+   if (ret) {
+   ehea_error("failed to register sysfs driver link");
+   goto out_rem_dev_file;
+   }
+
return >ofdev.dev;
 
+out_rem_dev_file:
+   device_remove_file(>ofdev.dev, _attr_log_port_id);
 out_unreg_of_dev:
of_device_unregister(>ofdev);
 out:
@@ -2394,6 +2475,7 @@ out:
 
 static void ehea_unregister_port(struct ehea_port *port)
 {
+   ehea_driver_sysfs_remove(>ofdev.dev, _driver.driver);
device_remove_file(>ofdev.dev, _attr_log_port_id);
of_device_unregister(>ofdev);
 }
@@ -2520,7 +2602,6 @@ static int ehea_setup_ports(struct ehea_
struct device_node *eth_dn = NULL;
 
u32 *dn_log_port_id;
-   int port_setup_ok = 0;
 

Re: Sleep during spinlock in TPM driver

[Parag Warudkar]

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(_lock);
 	file->private_data = NULL;
-	chip->num_opens--;
 	del_singleshot_timer_sync(>user_read_timer);
-	flush_scheduled_work();
 	atomic_set(>data_pending, 0);
+	chip->num_opens--;
 	put_device(chip->dev);
 	kfree(chip->data_buffer);
 	spin_unlock(_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(>buffer_mutex);
 	init_MUTEX(>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

[Nicolas Ferre]

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

[Guillaume Chazarain]

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

[Hisashi Hifumi]

>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 )

[J-P Van Bylen]

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

[Rene Herman]

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 [, NAME ]*[ and NAME ] */
 #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
   
+/* Maintainer, ideally of form NAME  */
+#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

[Ingo Molnar]

* 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

[Gautham R Shenoy]

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 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  /*
> @@ -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

[Jiri Slaby]

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

[Sergei Shtylyov]

Hello.

Mikael Starvik wrote:

The attached patch updates the CRIS IDE driver.



Signed-off-by: Mikael Starvik <[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

[Robert P. J. Day]

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

[Mel Gorman]

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, ));
} else if (memcmp(cp, "kernelcore=",11) == 0) {
-   cmdline_parse_kernelcore(cp+11);
+   cmdline_parse_kernelcore(cp+11, );
} else if (memcmp(cp, "min_addr=", 9) == 0) {
min_addr = GRANULEROUNDDOWN(memparse(cp + 9, ));
} 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, );
+   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

[Alex Dubov]

--- 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

[Gautham R Shenoy]

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

[Hugh Dickins]

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

[Alan Cox]

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

[Alan Cox]

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(_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

[Alan Cox]

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 = _driver;
bridge->dev_private_data = _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

[Alan Cox]

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(>kobj,_dev->dev.kobj,"pci_dev");
+   ret = sysfs_create_link(>kobj,_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

[Alan Cox]

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, );
+   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

[Eric Hopper]

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

[Alan Cox]

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 &= ~(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

[Arnd Bergmann]

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

[Alan Cox]

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

[Alan Cox]

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 ?

[Francis Moreau]

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

[Alan Cox]

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 >> 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 /= 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, _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, );
+   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, [0]);
dimm[0] = (dimm[0] >> 8) & 0x4f;
pci_read_config_dword(dev, 0x44, [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, );
+   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, );
+   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, );
+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, _data.memory_type);
+

Re: BUG: Null pointer dereference (2.6.21-rc7)

[William Heimbigner]

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

[Alan Cox]

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(>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

[Sergei Shtylyov]

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

[Avishay Traeger]

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.



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

[Alan Cox]

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.

[Martin Schwidefsky]

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.

[Martin Schwidefsky]

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 ().  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.

[Martin Schwidefsky]

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 

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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.

[Martin Schwidefsky]

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.

[Martin Schwidefsky]

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.

[Martin Schwidefsky]

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
+   

[PATCH 6/9] Kconfig: no wireless on s390.

[Martin Schwidefsky]

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.

[Martin Schwidefsky]

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.

[Martin Schwidefsky]

[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.

[Martin Schwidefsky]

[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

[Gautham R Shenoy]

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

[Dave Jones]

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

[Antonino A. Daplas]

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, _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, );
> + 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

[Pierre Peiffer]

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.

[Michael Buesch]

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.

[Michael Buesch]

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.

[Michael Buesch]

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

[Jordan Crouse]

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.



-
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/