Re: [PATCH 02/10] Blackfin SPI driver: use new GPIO API and add error handling
On Thu, 2007-10-11 at 23:26 -0700, David Brownell wrote:
> On Thursday 11 October 2007, Bryan Wu wrote:
> > @@ -1182,12 +1198,9 @@ static int __init bfin5xx_spi_probe(struct
> > platform_device *pdev)
> > return -ENOMEM;
> > }
> >
> > - if (peripheral_request(P_SPI0_SCK, DRV_NAME) ||
> > -peripheral_request(P_SPI0_MISO, DRV_NAME) ||
> > -peripheral_request(P_SPI0_MOSI, DRV_NAME) ) {
> > -
> > + if (setup_pin_mux(1)) {
> > dev_err(&pdev->dev, ": Requesting Peripherals failed\n");
> > - goto out_error_queue_alloc;
> > + goto out_error;
> > }
> >
> > drv_data = spi_master_get_devdata(master);
> >
>
> Still doesn't apply ... what tree are you generating this series against??
I apply this patch on Linus git tree at 2.6.23 tag
git-request-pull output:
---
The following changes since commit bbf25010f1a6b761914430f5fca081ec8c7accd1:
Linus Torvalds (1):
Linux 2.6.23
Bryan Wu (4):
Blackfin SPI driver: Initial supporting BF54x in SPI driver
Blackfin SPI driver: add error handing
Blackfin SPI driver: Blackfin SPI driver does not respect the
per-transfer cs_change field
Blackfin SPI driver: update spi driver to support multi-ports
Michael Hennerich (1):
Blackfin SPI driver: use new GPIO API and add error handling
Mike Frysinger (1):
Blackfin SPI driver: prevent people from setting bits in ctl_reg
Sonic Zhang (4):
Blackfin SPI driver: Add SPI master controller platform device 1
Blackfin SPI driver: Move GPIO config to setup and cleanup
Blackfin SPI driver: Fix SPI driver to work with SPI flash ST25P16 on
bf548
Blackfin SPI driver: Clean up useless wait in bfin SPI driver
drivers/spi/spi_bfin5xx.c | 586 ++-
include/asm-blackfin/mach-bf533/portmux.h |2 +-
include/asm-blackfin/mach-bf548/defBF54x_base.h | 17 +
3 files changed, 373 insertions(+), 232 deletions(-)
---
Need I send out just one SPI patch.
Thanks
-Bryan Wu
-
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] Make m68k cross compile like every other architecture.
On Thu, 11 Oct 2007, Rob Landley wrote:
> On Thursday 11 October 2007 11:26:07 am Finn Thain wrote:
> My toolchains override the default prefix to just the target, resulting
> in "m68k-gcc". (It's shorter, and when you're creating a dozen toolchains
> having them all say -linux- in the middle of every command name gets a bit
> silly...)
>
> When it started complaining about "m68k-linux-gnu-gcc" (which is _not_ what
> my
> cross compiler is called) I spent half an hour tracking down where it was
> getting that name from and what exactly was going on. (Was my build script
> supplying the wrong name? Did something set an environment variable it
> shouldn't have? Did the gcc build suddenly reveal another strange buried
> corner case that made it revert to a default against explicit instructions
> _again_?)
>
> When I found the surprising behavior that cost me time and effort to
> diagnose,
> I submitted a patch so it wouldn't confuse future developers the first time
> _they_ try to build m68k. (Yes, I think there might be such. Call me
> crazy.) I've seen "didn't specify any cross compiler" failures before, on
> arm and x86-64 and mips and sparc and so on. I've seen it in the linux
> kernel, in busybox, in uClibc, and in various gnu packages
> with ./configureitis. This is the first time I've seen a package confidently
> decide for itself to use a compiler name that isn't in the $PATH, and
> especially the first time I've seen Linux do it. It cost me time to
> disagnose because it looks like it's getting a CROSS_COMPILE setting from its
> environment somehow, and the logical thing to do is look at that environment
> (and the build scripts driving it, and the temp files) to see where such a
> thing might be leaking in from. The fact it might be hallucinating its own
> value was not my first guess, because nothing else I've encountered does that
> in this context.
>
> > This wasn't an issue before we came to depend on cross compilers. Since we
> > tend to need them more as compilation becomes more expensive, IMHO we
> > should follow the practice of the embedded architectures.
>
> That topic's a can of worms, but I point out that you always needed a cross
> compiler to bootstrap a new platform. :)
>
> If you're going to support cross compiling at all, you might as well do it
> more or less consistently for all targets.
If your cross-compiler is called differently than the default on in
arch/*/Makefile, what's the problem with calling?
make ARCH=myarch CROSS_COMPILE=my-cross-compile-prefx-
This has been working for +10 years on all non-ia32 platforms I ever worked on.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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] add missing parenthesis in cfe_writeblk() macro
Add missing parenthesis in cfe_writeblk() macro. Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> include/asm-mips/fw/cfe/cfe_api.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.23-mm1-a/include/asm-mips/fw/cfe/cfe_api.h2007-10-12 08:25:46.0 +0200 +++ linux-2.6.23-mm1-b/include/asm-mips/fw/cfe/cfe_api.h2007-10-12 08:37:42.0 +0200 @@ -154,7 +154,7 @@ int64_t cfe_getticks(void); #define cfe_readblk(a, b, c, d)__cfe_readblk(a, b, c, d) #define cfe_setenv(a, b) __cfe_setenv(a, b) #define cfe_write(a, b, c) __cfe_write(a, b, c) -#define cfe_writeblk(a, b, c, d__cfe_writeblk(a, b, c, d) +#define cfe_writeblk(a, b, c, d) __cfe_writeblk(a, b, c, d) #endif /* CFE_API_IMPL_NAMESPACE */ int cfe_close(int handle); - 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: 2.6.23-mm1
KAMEZAWA Hiroyuki wrote: > On Thu, 11 Oct 2007 21:31:26 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ >> >> - I've been largely avoiding applying anything since rc8-mm2 in an attempt >> to stabilise things for the 2.6.23 merge. >> > On RHEL5/x86_64 environment, > > == > [EMAIL PROTECTED] ref-2.6.23-mm1]$ make menuconfig > Makefile:456: /home/kamezawa/ref-2.6.23-mm1/arch//Makefile: No such file or > directory > make: *** No rule to make target > `/home/kamezawa/ref-2.6.23-mm1/arch//Makefile'. Stop. > == > > $(ARCH) cannot be detected automatically... > > What information is useful for fixing this ? cross compile work but native compile doesn't anymore :( Here's a tmp fix. Thanks, C. Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]> --- Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: 2.6.23-mm1/Makefile === --- 2.6.23-mm1.orig/Makefile +++ 2.6.23-mm1/Makefile @@ -191,7 +191,7 @@ SUBARCH := $(shell uname -m | sed -e s/i # The empty ARCH and CROSS_COMPILE statements exist so it is easy to # patch in hardcoded values for ARCH and CROSS_COMPILE -ARCH ?= +ARCH ?= $(SUBARCH) CROSS_COMPILE ?= # Kbuild save the ARCH and CROSS_COMPILE setting in .kbuild > > Thanks, > -Kame > > - > 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/
Re: 2.6.23-mm1
On Thu, Oct 11, 2007 at 11:42:02PM -0700, Andrew Morton wrote: > On Fri, 12 Oct 2007 14:03:28 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > wrote: > > > On Thu, 11 Oct 2007 21:31:26 -0700 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > - I've been largely avoiding applying anything since rc8-mm2 in an attempt > > > to stabilise things for the 2.6.23 merge. > > > > > On RHEL5/x86_64 environment, > > > > == > > [EMAIL PROTECTED] ref-2.6.23-mm1]$ make menuconfig > > Makefile:456: /home/kamezawa/ref-2.6.23-mm1/arch//Makefile: No such file or > > directory > > make: *** No rule to make target > > `/home/kamezawa/ref-2.6.23-mm1/arch//Makefile'. Stop. > > == > > > > $(ARCH) cannot be detected automatically... > > So you need to set $ARCH by hand? I always do that so I didn't notice this. > > > What information is useful for fixing this ? > > Sam's email address ;) More serious breakage happened to UML - include/asm-um/arch went straight to hell; I'll look into fixing that tomorrow... - 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: Linux 2.6.23
On Friday 12 October 2007 15:46, Ingo Molnar wrote: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > ;) I think you snipped the important bit: > > > > "the peak is terrible but it has virtually no dropoff and performs > > better under load than the default 2.6.21 scheduler." (verbatim) > > hm, i understood that peak remark to be in reference to FreeBSD's > scheduler (which the FreeBSD guys are primarily interested in > obviously), not v2.6.21 - but i could be wrong. I think the Linux peak has always been roughly as good as their best FreeBSD ones (eg. http://people.freebsd.org/~jeff/sysbench.png). Obviously in that graph, Linux sucks because of the malloc/mmap_sem issue. It also shows what he is calling the terrible CFS peak, I guess. In my own tests, after that was fixed, Linux's peak got even a bit higher, so that's the benchmark for performance. > In any case, there is indeed a regression with sysbench and a low number > of threads, and it's being fixed. The peak got improved visibly in > sched-devel: > > http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg > > but there is still some peak regression left, i'm testing a patch for > that. OK good. Once that's fixed, we'll hopefully be competitive with FreeBSD again in this test :) - 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] sched: Rationalize sys_sched_rr_get_interval()
On 12-10-2007 00:23, Peter Williams wrote:
...
> The reason I was going that route was for modularity (which helps when
> adding plugsched patches). I'll submit a revised patch for consideration.
...
IMHO, it looks like modularity could suck here:
> +static unsigned int default_timeslice_fair(struct task_struct *p)
> +{
> + return NS_TO_JIFFIES(sysctl_sched_min_granularity);
> +}
If it's needed for outside and sched_fair will use something else
(to avoid double conversion) this could be misleading. Shouldn't
this be kind of private and return something usable for the class
mainly? Why anything else than sched_fair should care about this?
Regards,
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: 2.6.23-mm1
On Fri, 12 Oct 2007 14:03:28 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > On Thu, 11 Oct 2007 21:31:26 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > - I've been largely avoiding applying anything since rc8-mm2 in an attempt > > to stabilise things for the 2.6.23 merge. > > > On RHEL5/x86_64 environment, > > == > [EMAIL PROTECTED] ref-2.6.23-mm1]$ make menuconfig > Makefile:456: /home/kamezawa/ref-2.6.23-mm1/arch//Makefile: No such file or > directory > make: *** No rule to make target > `/home/kamezawa/ref-2.6.23-mm1/arch//Makefile'. Stop. > == > > $(ARCH) cannot be detected automatically... So you need to set $ARCH by hand? I always do that so I didn't notice this. > What information is useful for fixing this ? Sam's email address ;) - 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/
CPU speed after hibernation
Hi all, I have enable suspend-to-disk on myetch system K 2.6.21.1 I have enabled acpi cpu frequency scaling and using "convservative" governer. When I boot the system, the cpu frequency works switches fine based on the requirement. But when i go to hibernation and come back from hibernation, the cpu frequency gets stuck at the maximum. I have already written to debian-users list but did not get any reply (with the same subject line). Is this a known issue ? If i try to remove and re-insert the cpufreq_conservative module, the whole system hangs. thanks -- Bhasker C V To feel rich count all things you have in life that money can't buy. - 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/
help for ip_nat_setup_info() in 2.6.22
Dear all, ip_nat_setup_info() has been moved from 2.6.22, I grep it in 2.6.12 what is the equally func. in 2.6.22 ,and why changed it ? Thanks! BR - 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] Reserve N process to root
Kyle Moffett wrote: > On Oct 12, 2007, at 01:37:23, Al Boldi wrote: > > You have a point, and resource-controllers can probably control DoS > > a lot better, but the they also incur more overhead. Think of this > > "lockout prevention" patch as a near zero overhead safety valve. > > But why do you need to add "lockout prevention" if it already > exists? I said this before, but I'll say it again: it's about overhead! > With CFS' extremely efficient per-user-scheduling (hopefully > soon to be the default) there are only two forms of lockout by non- > root processes: (1) Running out of PIDs in the box's PID-space > (think tens or hundreds of thousands of processes), or (2) Swap- > storming the box to death. To put it bluntly trying to reserve free > PID slots is attacking the wrong end of the problem and your so > called "lockout prevention" could very easily ensure that 10 PIDs are > available even if the user has swapstormed the box with the PIDs he > does have. I think you are reading this wrong. It's not about reserving PIDs, it's about exceeding the max-threads limit. This limit is global and affects every user including root, which is good, as this allows the sysadmin to fence the system into a controllable state. So once the system reaches the fence, sysadmin-intervention allows root to exceed the fence. Again, this is much nicer with real resource-controllers, but again it's also more overhead. Thanks! -- Al - 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 02/10] Blackfin SPI driver: use new GPIO API and add error handling
On Thursday 11 October 2007, Bryan Wu wrote:
> @@ -1182,12 +1198,9 @@ static int __init bfin5xx_spi_probe(struct
> platform_device *pdev)
> return -ENOMEM;
> }
>
> - if (peripheral_request(P_SPI0_SCK, DRV_NAME) ||
> - peripheral_request(P_SPI0_MISO, DRV_NAME) ||
> - peripheral_request(P_SPI0_MOSI, DRV_NAME) ) {
> -
> + if (setup_pin_mux(1)) {
> dev_err(&pdev->dev, ": Requesting Peripherals failed\n");
> - goto out_error_queue_alloc;
> + goto out_error;
> }
>
> drv_data = spi_master_get_devdata(master);
>
Still doesn't apply ... what tree are you generating this series against??
-
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] more bio fallout
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 2473e2a..a2da76b 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -169,7 +169,6 @@ static void end_bio_io_page(struct bio *bio, int error)
else
printk(KERN_WARNING "gfs2: error %d reading superblock\n",
error);
unlock_page(page);
- return 0;
}
static void gfs2_sb_in(struct gfs2_sb_host *sb, const void *buf)
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index 3429fa7..bbc588d 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2162,7 +2162,7 @@ static void lbmStartIO(struct lbuf * bp)
/* check if journaling to disk has been disabled */
if (log->no_integrity) {
bio->bi_size = 0;
- lbmIODone(bio, 0, 0);
+ lbmIODone(bio, 0);
} else {
submit_bio(WRITE_SYNC, bio);
INCREMENT(lmStat.submitted);
@@ -2234,8 +2234,6 @@ static void lbmIODone(struct bio *bio, int error)
/* wakeup I/O initiator */
LCACHE_WAKEUP(&bp->l_ioevent);
-
- return 0;
}
/*
@@ -2260,7 +2258,6 @@ static void lbmIODone(struct bio *bio, int error)
if (bp->l_flag & lbmDIRECT) {
LCACHE_WAKEUP(&bp->l_ioevent);
LCACHE_UNLOCK(flags);
- return 0;
}
tail = log->wqueue;
@@ -2339,8 +2336,6 @@ static void lbmIODone(struct bio *bio, int error)
LCACHE_UNLOCK(flags); /* unlock+enable */
}
-
- return 0;
}
int jfsIOWait(void *arg)
diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
index 1332adc..941369c 100644
--- a/fs/jfs/jfs_metapage.c
+++ b/fs/jfs/jfs_metapage.c
@@ -291,8 +291,6 @@ static void metapage_read_end_io(struct bio *bio, int err)
dec_io(page, last_read_complete);
bio_put(bio);
-
- return 0;
}
static void remove_from_logsync(struct metapage *mp)
@@ -349,7 +347,6 @@ static void metapage_write_end_io(struct bio *bio, int err)
}
dec_io(page, last_write_complete);
bio_put(bio);
- return 0;
}
static int metapage_writepage(struct page *page, struct writeback_control *wbc)
diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index ad6626e..bdf6002 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -216,7 +216,7 @@ static void o2hb_wait_on_io(struct o2hb_region *reg,
wait_for_completion(&wc->wc_io_complete);
}
-static int o2hb_bio_end_io(struct bio *bio,
+static void o2hb_bio_end_io(struct bio *bio,
int error)
{
struct o2hb_bio_wait_ctxt *wc = bio->bi_private;
@@ -228,7 +228,6 @@ static int o2hb_bio_end_io(struct bio *bio,
o2hb_bio_wait_dec(wc, 1);
bio_put(bio);
- return 0;
}
/* Setup a Bio to cover I/O against num_slots slots starting at
diff --git a/fs/xfs/linux-2.6/xfs_aops.c b/fs/xfs/linux-2.6/xfs_aops.c
index 3f13519..6f4c29e 100644
--- a/fs/xfs/linux-2.6/xfs_aops.c
+++ b/fs/xfs/linux-2.6/xfs_aops.c
@@ -323,7 +323,7 @@ xfs_iomap_valid(
/*
* BIO completion handler for buffered IO.
*/
-STATIC int
+STATIC void
xfs_end_bio(
struct bio *bio,
int error)
@@ -339,7 +339,6 @@ xfs_end_bio(
bio_put(bio);
xfs_finish_ioend(ioend, 0);
- return 0;
}
STATIC void
diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c
index 6a75f4d..39f44ee 100644
--- a/fs/xfs/linux-2.6/xfs_buf.c
+++ b/fs/xfs/linux-2.6/xfs_buf.c
@@ -1103,7 +1103,7 @@ _xfs_buf_ioend(
}
}
-STATIC int
+STATIC void
xfs_buf_bio_end_io(
struct bio *bio,
int error)
@@ -1139,7 +1139,6 @@ xfs_buf_bio_end_io(
_xfs_buf_ioend(bp, 1);
bio_put(bio);
- return 0;
}
STATIC 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/
Re: [Patch 002/002] Create/delete kmem_cache_node for SLUB on memory online callback
> On Fri, 12 Oct 2007, Yasunori Goto wrote:
>
> > If pages on the new node available, slub can use it before making
> > new kmem_cache_nodes. So, this callback should be called
> > BEFORE pages on the node are available.
>
> If its called before pages on the node are available then it must
> fallback and cannot use the pages.
Hmm. My description may be wrong. I would like to just
mention that kmem_cache_node should be created before the node's page
can be allocated. If not, it will cause of panic.
> > +#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
> > +static int slab_mem_going_offline_callback(void *arg)
> > +{
> > + struct kmem_cache *s;
> > + struct memory_notify *marg = arg;
> > + int local_node, offline_node = marg->status_change_nid;
> > +
> > + if (offline_node < 0)
> > + /* node has memory yet. nothing to do. */
>
> Please clarify the comment. This seems to indicate that we should not
> do anything because the node still has memory?
Yes. kmem_cache_node is still necessary for remaining memory on the
node.
> Doesnt the node always have memory before offlining?
If node doesn't have memory and offline_pages() called for it,
it must be check and fail. This callback shouldn't be called.
If not, it is bug of memory hotplug, I think.
> > + return 0;
> > +
> > + down_read(&slub_lock);
> > + list_for_each_entry(s, &slab_caches, list) {
> > + local_node = page_to_nid(virt_to_page(s));
> > + if (local_node == offline_node)
> > + /* This slub is on the offline node. */
> > + return -EBUSY;
> > + }
> > + up_read(&slub_lock);
>
> So this checks if the any kmem_cache structure is on the offlined node? If
> so then we cannot offline the node?
Right. If slabs' migration is possible, here would be good place for
doing it. But, it is not possible (at least now).
> > + kmem_cache_shrink_node(s, offline_node);
>
> kmem_cache_shrink(s) would be okay here I would think. The function is
> reasonably fast. Offlining is a rare event.
Ok. I'll fix it.
> > +static void slab_mem_offline_callback(void *arg)
>
> We call this after we have established that no kmem_cache structures are
> on this and after we have shrunk the slabs. Is there any guarantee that
> no slab operations have occurrent since then?
If slabs still exist, it can't be migrated and offline_pages() has
to give up offline. This means MEM_OFFLINE event is not generated when
slabs are on the removing node.
In other word, when this event is generated, all of pages on
this section is isolated and there are no used pages(slabs).
>
> > +{
> > + struct kmem_cache_node *n;
> > + struct kmem_cache *s;
> > + struct memory_notify *marg = arg;
> > + int offline_node;
> > +
> > + offline_node = marg->status_change_nid;
> > +
> > + if (offline_node < 0)
> > + /* node has memory yet. nothing to do. */
> > + return;
>
> Does this mean that the node still has memory?
Yes.
> > + down_read(&slub_lock);
> > + list_for_each_entry(s, &slab_caches, list) {
> > + n = get_node(s, offline_node);
> > + if (n) {
> > + /*
> > +* if n->nr_slabs > 0, offline_pages() must be fail,
> > +* because the node is used by slub yet.
> > +*/
>
> It may be clearer to say:
>
> "If nr_slabs > 0 then slabs still exist on the node that is going down.
> We were unable to free them so we must fail."
Again. If nr_slabs > 0, offline_pages must be fail due to slabs
remaining on the node before. So, this callback isn't called.
> > +static int slab_mem_going_online_callback(void *arg)
> > +{
> > + struct kmem_cache_node *n;
> > + struct kmem_cache *s;
> > + struct memory_notify *marg = arg;
> > + int nid = marg->status_change_nid;
> > +
> > + /* If the node already has memory, then nothing is necessary. */
> > + if (nid < 0)
> > + return 0;
>
> The node must have memory Or we have already brought up the code?
kmem_cache_node is created at boot time if the node has memory.
(Or, it is created by this callback on first added memory on the node).
When nid = - 1, kmem_cache_node is created before this node due to
node has memory.
>
> > + /*
> > +* New memory will be onlined on the node which has no memory so far.
> > +* New kmem_cache_node is necssary for it.
>
> "We are bringing a node online. No memory is available yet. We must
> allocate a kmem_cache_node structure in order to bring the node online." ?
Your mention might be ok.
But. I would like to prefer to define status of node hotplug for
exactitude like followings
A)Node online -- pgdat is created and can be accessed for this node.
but there are no gurantee that cpu or memory is onlined.
This status is very close from memory-less node.
But this might be halfway status for node hotplug.
Re: linux-2.6.23 - acting funny
* poison <[EMAIL PROTECTED]> wrote: > Also the transfer rate didn't degrade too much for copying directly > from reiserfs to reiserfs and not using encfs: > > dd if=/mnt/.backup/2CpGkrxvz6wgA0b0xloz8PavzMLrMymOgi9 of=/mnt/.tdata/test > 1033+0 records in > 1033+0 records out > 1083179008 bytes (1.1 GB) copied, 16.9303 s, 64.0 MB/s > > Plus the transfer rate doesn't increase if I start a CPU hog while > copying between reiserfs. > > So it looks more to me like theres a bad interaction between the new > scheduler, fuse and encfs ... i have no quick ideas - the behavior you are seeing is quite unexpected. Could you try the current sched-devel code: http://redhat.com/~mingo/cfs-scheduler/devel/sched-devel-combo-v2.6.23.patch since this version of CFS does various things differently then the one in v2.6.23, lets see whether perturbing it makes any difference to your throughput. you could also try the scheduler backport to v2.6.22.10, at: http://redhat.com/~mingo/cfs-scheduler/ that would establish whether it's the changes in scheduling that cause this or something else. Plus please enable CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS and run this debug script while such a transfer is going on: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh and send me the resulting file. 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/
[PATCH] missed bio_endio() in axonram
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index ab037a3..46fd9c6 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -117,7 +117,7 @@ axon_ram_make_request(struct request_queue *queue, struct
bio *bio)
transfered = 0;
bio_for_each_segment(vec, bio, idx) {
if (unlikely(phys_mem + vec->bv_len > phys_end)) {
- bio_io_error(bio, bio->bi_size);
+ bio_io_error(bio);
rc = -ERANGE;
break;
}
@@ -131,7 +131,7 @@ axon_ram_make_request(struct request_queue *queue, struct
bio *bio)
phys_mem += vec->bv_len;
transfered += vec->bv_len;
}
- bio_endio(bio, transfered, 0);
+ bio_endio(bio, 0);
return rc;
}
-
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: sometimes very long response times on network interfaces since 2.6.22
On 10.10.2007 09:00, Eric Dumazet wrote (please find the answer below the original text): > Ingo Freund a écrit : >> Hello, >> >> since I switched to kernel 2.6.22 my dell 1750 server >> with the two onboard BCM5704 network interfaces doesn't >> work properly anymore. >> TCP requests sometimes need more than 30 seconds to be answered >> (or to get away) and the application stops with timeouts. >> We are talking about two servers connected via Gigabit switch. >> The timeouts happen up to ten times a day. >> In the meantime I tried an old 3com 3c905c NIC which showed >> the same behaviour. >> I still couldn't figure out in which special situation the >> communication stops. >> The only solution ist to boot the old 2.6.21.5 kernel. >> With this, all runs fine. >> Did I miss a config issue in the migration to 2.6.22? >> The machines run in a productive environment and there is >> not much room (time) to debug, but if needed, I could try >> if anyone would need more information for help. >> > > Hi > 1) A tcpdump would help for sure... > 2) Could you try 2.6.23 > - I'm trying 2.6.23 with the same config as 2.6.22.n since yesterday. The error after on day uptime didn't show up again. It seems that 2.6.22.n is buggy in some special conditions concerning high load network traffic. This is not depending on the used NIC. Thanks for reading this. -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/
[PATCH -mm -v5 2/3] i386/x86_64 boot: boot parameters export via sysfs
This patch export the boot parameters via sysfs. This can be used for
debugging and kexec.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
i386/kernel/Makefile|1
i386/kernel/ksysfs.c| 267
i386/kernel/setup.c |2
x86_64/kernel/Makefile |1
x86_64/kernel/setup64.c |2
5 files changed, 271 insertions(+), 2 deletions(-)
Index: linux-2.6.23-rc8/arch/x86_64/kernel/Makefile
===
--- linux-2.6.23-rc8.orig/arch/x86_64/kernel/Makefile 2007-10-12
11:20:29.0 +0800
+++ linux-2.6.23-rc8/arch/x86_64/kernel/Makefile2007-10-12
11:21:05.0 +0800
@@ -39,6 +39,7 @@
obj-$(CONFIG_K8_NB)+= k8.o
obj-$(CONFIG_AUDIT)+= audit.o
obj-$(CONFIG_STACK_UNWIND) += unwind.o
+obj-$(CONFIG_SYSFS)+= ../../i386/kernel/ksysfs.o
obj-$(CONFIG_MODULES) += module.o
obj-$(CONFIG_PCI) += early-quirks.o
Index: linux-2.6.23-rc8/arch/x86_64/kernel/setup64.c
===
--- linux-2.6.23-rc8.orig/arch/x86_64/kernel/setup64.c 2007-10-12
11:20:29.0 +0800
+++ linux-2.6.23-rc8/arch/x86_64/kernel/setup64.c 2007-10-12
11:21:05.0 +0800
@@ -24,7 +24,7 @@
#include
#include
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
cpumask_t cpu_initialized __cpuinitdata = CPU_MASK_NONE;
Index: linux-2.6.23-rc8/arch/i386/kernel/ksysfs.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.23-rc8/arch/i386/kernel/ksysfs.c 2007-10-12 11:21:05.0
+0800
@@ -0,0 +1,267 @@
+/*
+ * arch/i386/ksysfs.c - architecture specific sysfs attributes in /sys/kernel
+ *
+ * Copyright (C) 2007, Intel Corp.
+ * Huang Ying <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static unsigned long copy_from_phys(void *to, unsigned long from_phys,
+ unsigned long n)
+{
+ struct page *page;
+ void *from;
+ unsigned long remain = n, offset, trunck;
+
+ while (remain) {
+ page = pfn_to_page(from_phys >> PAGE_SHIFT);
+ from = kmap_atomic(page, KM_USER0);
+ offset = from_phys & ~PAGE_MASK;
+ if (remain > PAGE_SIZE - offset)
+ trunck = PAGE_SIZE - offset;
+ else
+ trunck = remain;
+ memcpy(to, from + offset, trunck);
+ kunmap_atomic(from, KM_USER0);
+ to += trunck;
+ from_phys += trunck;
+ remain -= trunck;
+ }
+ return n;
+}
+
+static ssize_t boot_params_version_show(struct kset *kset, char *page)
+{
+ return sprintf(page, "0x%x\n", boot_params.hdr.version);
+}
+
+static struct subsys_attribute boot_params_version_attr = {
+ .attr = {
+ .name = "version",
+ .mode = S_IRUGO,
+ },
+ .show = boot_params_version_show,
+};
+
+static struct attribute *boot_params_attrs[] = {
+ &boot_params_version_attr.attr,
+ NULL
+};
+
+static struct attribute_group boot_params_attr_group = {
+ .attrs = boot_params_attrs,
+};
+
+static ssize_t boot_params_data_read(struct kobject *kobj,
+struct bin_attribute *bin_attr,
+char *buf, loff_t off, size_t count)
+{
+ memcpy(buf, (void *)&boot_params + off, count);
+ return count;
+}
+
+static struct bin_attribute boot_params_data_attr = {
+ .attr = {
+ .name = "data",
+ .mode = S_IRUGO,
+ },
+ .read = boot_params_data_read,
+ .size = sizeof(boot_params),
+};
+
+struct setup_data_kobj
+{
+ struct kobject kobj;
+ unsigned long pa_setup_data;
+ struct bin_attribute *data_attr;
+};
+
+struct setup_data_attribute {
+ struct attribute attr;
+ ssize_t (*show) (struct setup_data_kobj *setup_data_kobj, char *buf);
+};
+
+static ssize_t setup_data_type_show(struct setup_data_kobj *setup_data_kobj,
+ char *page)
+{
+ struct setup_data data;
+ copy_from_phys(&data, setup_data_kobj->pa_setup_data, sizeof(data));
+ return sprintf(page, "0x%x\n", data.type);
+}
+
+static struct setup_data_attribute setup_data_type_attr = {
+ .attr = {
+ .name = "type",
+ .mode = S_IRUGO,
+ },
+ .show = setup_data_type_show,
+};
+
+static ssize_t setup_data_attr_show(struct kobject *kobj,
+ struct attribute *attr,
+ char *buf)
+{
+ struct setup_data_kobj *setup_data_kobj =
+ (struct
[PATCH -mm -v5 3/3] i386/x86_64 boot: document for 32 bit boot protocol
This patch defines a 32-bit boot protocol and adds corresponding
document. It is based on the proposal of Peter Anvin.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
boot.txt | 70 +++
zero-page.txt | 129 +-
2 files changed, 99 insertions(+), 100 deletions(-)
Index: linux-2.6.23-rc8/Documentation/i386/boot.txt
===
--- linux-2.6.23-rc8.orig/Documentation/i386/boot.txt 2007-10-12
11:20:30.0 +0800
+++ linux-2.6.23-rc8/Documentation/i386/boot.txt2007-10-12
11:21:00.0 +0800
@@ -2,7 +2,7 @@
H. Peter Anvin <[EMAIL PROTECTED]>
- Last update 2007-05-23
+ Last update 2007-09-18
On the i386 platform, the Linux kernel uses a rather complicated boot
convention. This has evolved partially due to historical aspects, as
@@ -42,6 +42,9 @@
Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
the boot command line
+Protocol 2.07: (kernel 2.6.23) Added a field of 64-bit physical
+ pointer to single linked list of struct setup_data.
+ Added 32-bit boot protocol.
MEMORY LAYOUT
@@ -168,6 +171,9 @@
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
0235/3 N/A pad2Unused
0238/4 2.06+ cmdline_sizeMaximum size of the kernel command line
+023c/4 N/A pad3Unused
+0240/8 2.07+ setup_data 64-bit physical pointer to linked list
+ of struct setup_data
(1) For backwards compatibility, if the setup_sects field contains 0, the
real value is 4.
@@ -480,6 +486,36 @@
cmdline_size characters. With protocol version 2.05 and earlier, the
maximum size was 255.
+Field name:setup_data
+Type: write (obligatory)
+Offset/size: 0x240/8
+Protocol: 2.07+
+
+ The 64-bit physical pointer to NULL terminated single linked list of
+ struct setup_data. This is used to define a more extensible boot
+ parameters passing mechanism. The definition of struct setup_data is
+ as follow:
+
+ struct setup_data {
+ u64 next;
+ u32 type;
+ u32 len;
+ u8 data[0];
+ } __attribute__((packed));
+
+ Where, the next is a 64-bit physical pointer to the next node of
+ linked list, the next field of the last node is 0; the type is used
+ to identify the contents of data; the len is the length of data
+ field; the data holds the real payload.
+
+ With this field, to add a new boot parameter written by bootloader,
+ it is not needed to add a new field to real mode header, just add a
+ new setup_data type is sufficient. But to add a new boot parameter
+ read by bootloader, it is still needed to add a new field.
+
+ TODO: Where is the safe place to place the linked list of struct
+ setup_data?
+
THE KERNEL COMMAND LINE
@@ -753,3 +789,35 @@
After completing your hook, you should jump to the address
that was in this field before your boot loader overwrote it
(relocated, if appropriate.)
+
+
+ SETUP DATA TYPES
+
+
+ 32-bit BOOT PROTOCOL
+
+For machine with some new BIOS other than legacy BIOS, such as EFI,
+LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
+based on legacy BIOS can not be used, so a 32-bit boot protocol need
+to be defined.
+
+In 32-bit boot protocol, the first step in loading a Linux kernel
+should still be to load the real-mode code and then examine the kernel
+header at offset 0x01f1. But, it is not necessary to load all
+real-mode code, just first 4K bytes traditionally known as "zero page"
+is needed.
+
+In addition to read/modify/write kernel header of the zero page as
+that of 16-bit boot protocol, the boot loader should also fill the
+additional fields of the zero page as that described in zero-page.txt.
+
+After loading and setuping the zero page, the boot loader can load the
+32/64-bit kernel in the same way as that of 16-bit boot protocol.
+
+In 32-bit boot protocol, the kernel is started by jumping to the
+32-bit kernel entry point, which is the start address of loaded
+32/64-bit kernel.
+
+At entry, the CPU must be in 32-bit protected mode with paging
+disabled; the CS and DS must be 4G flat segments; %esi holds the base
+address of the "zero page"; %esp, %ebp, %edi should be zero.
Index: linux-2.6.23-rc8/Documentation/i386/zero-page.txt
===
--- linux-2.6.23-rc8.orig/Documentation/i386/zero-page.txt 2007-10-12
11:20:30.0 +0800
+++ linux-2.6.23-rc8/Documentation/i386/zero-page.txt 2007-10-12
11:21:00.0 +0800
@@ -1,99 +1,30 @@
-!!!WARNING
-The zero page
[PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol
This patchset defines a 32-bit boot protocol for i386/x86_64 platform, adds an extensible boot parameter passing mechanism, export the boot parameters via sysfs. The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64 and i386. This patchset is based on the proposal of Peter Anvin. Known Issues: - Where is safe to place the linked list of setup_data? Because the length of the linked list of setup_data is variable, it can not be copied into BSS segment of kernel as that of "zero page". We must find a safe place for it, where it will not be overwritten by kernel during booting up. The i386 kernel will overwrite some pages after _end. The x86_64 kernel will overwrite some pages from 0x1000 on. - The fields in zero page are fairly complex (such as struct edd_info). Is it necessary to document every field inside the first level fields, until the primary data type? Or is it sufficient to provide the C struct name only? v5: - Use bt_ioremap/bt_iounmap in copy_setup_data. v4: - Reserve setup_data and boot parameters for accessing during runtime. - Export boot parameters via sysfs. v3: - Move hd0_info and hd1_info back to zero page for compatibility. v2: - Increase the boot protocol version number - Check version number before parsing setup data. - Revise zero page description according to the source code and move them to zero-page.txt. Best Regards, Huang Ying - 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] Reserve N process to root
On Oct 12, 2007, at 01:37:23, Al Boldi wrote: Kyle Moffett wrote: This isn't really necessary any more with the new CFS scheduler. If you want to prevent excess memory usage then you limit memory usage, not process count, so just set the system max process count to something absurdly high and leave the user counts down at the maximum a user might run. Then as long as the sum of the user processes is less than the max number of processes (which you just set absurdly high or unlimited), you may still log in. With the per-user scheduling enabled CFS allows you to run an optimistically-real-time game as one user and several thousand busy-loops as another user and get almost picture perfect 50% CPU distribution between the users. To me that seems a much better DoS- prevention system than limits which don't scale based on how many people are requesting resources. You have a point, and resource-controllers can probably control DoS a lot better, but the they also incur more overhead. Think of this "lockout prevention" patch as a near zero overhead safety valve. But why do you need to add "lockout prevention" if it already exists? With CFS' extremely efficient per-user-scheduling (hopefully soon to be the default) there are only two forms of lockout by non- root processes: (1) Running out of PIDs in the box's PID-space (think tens or hundreds of thousands of processes), or (2) Swap- storming the box to death. To put it bluntly trying to reserve free PID slots is attacking the wrong end of the problem and your so called "lockout prevention" could very easily ensure that 10 PIDs are available even if the user has swapstormed the box with the PIDs he does have. Cheers, Kyle Moffett - 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 -v5 1/3] i386/x86_64 boot: setup data
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
arch/i386/Kconfig|3 -
arch/i386/boot/header.S |8 +++
arch/i386/kernel/setup.c | 95 +++
arch/x86_64/kernel/setup.c | 37
include/asm-i386/bootparam.h | 15 ++
include/asm-i386/io.h|7 +++
6 files changed, 161 insertions(+), 4 deletions(-)
Index: linux-2.6.23-rc8/include/asm-i386/bootparam.h
===
--- linux-2.6.23-rc8.orig/include/asm-i386/bootparam.h 2007-10-09
11:26:06.0 +0800
+++ linux-2.6.23-rc8/include/asm-i386/bootparam.h 2007-10-12
11:20:28.0 +0800
@@ -9,6 +9,17 @@
#include
#include
+/* setup data types */
+#define SETUP_NONE 0
+
+/* extensible setup data list node */
+struct setup_data {
+ u64 next;
+ u32 type;
+ u32 len;
+ u8 data[0];
+} __attribute__((packed));
+
struct setup_header {
u8 setup_sects;
u16 root_flags;
@@ -41,6 +52,10 @@
u32 initrd_addr_max;
u32 kernel_alignment;
u8 relocatable_kernel;
+ u8 _pad2[3];
+ u32 cmdline_size;
+ u32 _pad3;
+ u64 setup_data;
} __attribute__((packed));
struct sys_desc_table {
Index: linux-2.6.23-rc8/arch/i386/boot/header.S
===
--- linux-2.6.23-rc8.orig/arch/i386/boot/header.S 2007-10-09
11:26:06.0 +0800
+++ linux-2.6.23-rc8/arch/i386/boot/header.S2007-10-09 11:26:08.0
+0800
@@ -119,7 +119,7 @@
# Part 2 of the header, from the old setup.S
.ascii "HdrS" # header signature
- .word 0x0206 # header version number (>= 0x0105)
+ .word 0x0207 # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
realmode_swtch:.word 0, 0# default_switch, SETUPSEG
@@ -214,6 +214,12 @@
#added with boot protocol
#version 2.06
+pad4: .long 0
+
+setup_data:.quad 0 # 64-bit physical pointer to
+ # single linked list of
+ # struct setup_data
+
# End of setup header #
.section ".inittext", "ax"
Index: linux-2.6.23-rc8/arch/x86_64/kernel/setup.c
===
--- linux-2.6.23-rc8.orig/arch/x86_64/kernel/setup.c2007-10-09
11:26:06.0 +0800
+++ linux-2.6.23-rc8/arch/x86_64/kernel/setup.c 2007-10-12 11:20:28.0
+0800
@@ -250,6 +250,40 @@
ebda_size = 64*1024;
}
+static void __init parse_setup_data(void)
+{
+ struct setup_data *data;
+ unsigned long pa_data;
+
+ if (boot_params.hdr.version < 0x0207)
+ return;
+ pa_data = boot_params.hdr.setup_data;
+ while (pa_data) {
+ data = early_ioremap(pa_data, PAGE_SIZE);
+ switch (data->type) {
+ default:
+ break;
+ }
+ pa_data = data->next;
+ early_iounmap(data, PAGE_SIZE);
+ }
+}
+
+static void __init reserve_setup_data(void)
+{
+ struct setup_data *data;
+ unsigned long pa_data;
+
+ if (boot_params.hdr.version < 0x0207)
+ return;
+ pa_data = boot_params.hdr.setup_data;
+ while (pa_data) {
+ data = __va(pa_data);
+ reserve_bootmem_generic(pa_data, sizeof(*data)+data->len);
+ pa_data = data->next;
+ }
+}
+
void __init setup_arch(char **cmdline_p)
{
printk(KERN_INFO "Command line: %s\n", boot_command_line);
@@ -285,6 +319,8 @@
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
+ parse_setup_data();
+
parse_early_param();
finish_e820_parsing();
@@ -373,6 +409,7 @@
*/
acpi_reserve_bootmem();
#endif
+ reserve_setup_data();
/*
* Find and reserve possible boot-time SMP configuration:
*/
Index: linux-2.6.23-rc8/arch/i386/kernel/setup.c
===
--- linux-2.6.23-rc8.orig/arch/i386/kernel/setup.c 2007-10-09
11:26:06.0 +0800
+++ linux-2.6.23-rc8/arch/i386/kernel/setup.c 2007-10-12 11:20:29.0
+0800
@@ -424,6 +424,94 @@
{
Re: Linux 2.6.23
* Nick Piggin <[EMAIL PROTECTED]> wrote: > ;) I think you snipped the important bit: > > "the peak is terrible but it has virtually no dropoff and performs > better under load than the default 2.6.21 scheduler." (verbatim) hm, i understood that peak remark to be in reference to FreeBSD's scheduler (which the FreeBSD guys are primarily interested in obviously), not v2.6.21 - but i could be wrong. In any case, there is indeed a regression with sysbench and a low number of threads, and it's being fixed. The peak got improved visibly in sched-devel: http://people.redhat.com/mingo/misc/sysbench-sched-devel.jpg but there is still some peak regression left, i'm testing a patch for 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/
Re: [GIT PULL] MMC updates
On Thu, 11 Oct 2007 22:30:41 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > There seems to be some breakage here: > > drivers/mmc/core/host.c: In function ‘mmc_remove_host’: > drivers/mmc/core/host.c:146: error: implicit declaration of > function ‘led_trigger_unregister’ drivers/mmc/core/host.c:146: error: > ‘struct mmc_host’ has no member named ‘led’ > > this was after doing a few "make randconfig" runs, a habit I'm trying > to encourage (and do myself occasionally too). > How embarrassing. I'll have a look at it and reping you when I've solved it. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - 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] Reserve N process to root
Kyle Moffett wrote: > Please don't trim CC lists > > On Oct 11, 2007, at 17:02:37, Al Boldi wrote: > > David Newall wrote: > >> [EMAIL PROTECTED] wrote: > >>> What David meant was that "root will always have a slot" doesn't > >>> *actually* help unless you *also* have a way to actually *spawn* > >>> such a process. In order to do the ps, kill, and so on that you > >>> need to recover, you need to already have either a root shell > >>> available, or a way to *get* a root shell that doesn't rely on a > >>> non-root process (so /bin/su doesn't help here). > >> > >> That's right, although it's worse than that. You need to have a > >> process with CAP_SYS_ADMIN. If root processes normally have that > >> capability then the reserved slots may well disappear before you > >> notice a problem. If root processes normally don't have it, then > >> you need to guarantee that one is already running. > > > > I once posted a patch to handle this DoS, but, as usual, it wasn't > > accepted. Go figure... > > This isn't really necessary any more with the new CFS scheduler. If > you want to prevent excess memory usage then you limit memory usage, > not process count, so just set the system max process count to > something absurdly high and leave the user counts down at the maximum > a user might run. Then as long as the sum of the user processes is > less than the max number of processes (which you just set absurdly > high or unlimited), you may still log in. With the per-user > scheduling enabled CFS allows you to run an optimistically-real-time > game as one user and several thousand busy-loops as another user and > get almost picture perfect 50% CPU distribution between the users. > To me that seems a much better DoS-prevention system than limits > which don't scale based on how many people are requesting resources. You have a point, and resource-controllers can probably control DoS a lot better, but the they also incur more overhead. Think of this "lockout prevention" patch as a near zero overhead safety valve. Thanks! -- Al - 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: [RFD] iptables: mangle table obsoletes filter table
Patrick McHardy wrote:
> Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] is bouncing me.
> Al Boldi wrote:
> > With the existence of the mangle table, how useful is the filter table?
> >
> > Other than requiring the REJECT target to be ported to the mangle table,
> > is the filter table faster than the mangle table?
>
> There are some minor differences in ordering (mangle comes before
> DNAT, filter afterwards), but for most rulesets thats completely
> irrelevant. The only difference that really matters is that mangle
> performs rerouting in LOCAL_OUT for packets that had their routing
> key changed, so its really a superset of the filter table. If you
> want to use REJECT in the mangle table, you just need to remove the
> restriction to filter, it works fine. I would prefer to also remove
> the restriction of MARK, CONNMARK etc. to mangle, they're used for
> more than just routing today so that restriction also doesn't make
> much sense. Patches for this are welcome.
Something like this (untested):
--- ipt_REJECT.bak.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +0300
@@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
static inline void send_unreach(struct sk_buff *skb_in, int code)
{
+ if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
}
@@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
.family = AF_INET,
.target = reject,
.targetsize = sizeof(struct ipt_reject_info),
- .table = "filter",
- .hooks = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
- (1 << NF_IP_LOCAL_OUT),
.checkentry = check,
.me = THIS_MODULE,
};
> > If not, then shouldn't the filter table be obsoleted to avoid confusion?
>
> That would probably confuse people. Just don't use it if you don't
> need to.
The problem is that people think they are safe with the filter table, when in
fact they need the prerouting chain to seal things. Right now this is only
possible in the mangle table.
Thanks!
--
Al
-
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: [GIT PULL] MMC updates
On Wed, 10 Oct 2007, Pierre Ossman wrote: > > Linus, please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus > > Lot's of changes in here. There seems to be some breakage here: drivers/mmc/core/host.c: In function ‘mmc_remove_host’: drivers/mmc/core/host.c:146: error: implicit declaration of function ‘led_trigger_unregister’ drivers/mmc/core/host.c:146: error: ‘struct mmc_host’ has no member named ‘led’ this was after doing a few "make randconfig" runs, a habit I'm trying to encourage (and do myself occasionally too). Linus - 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: hdparm standby timeout not working for WD raptors?
On 10/11/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > What do you get when you try this: > hdparm -S1 -C /dev/sda;sleep 6; hdparm -C /dev/sda > ?? Thanks for taking an interest. I ran the commands and got the result shown below. Anything else you want me to try? # hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda /dev/sda: setting standby to 1 (5 seconds) drive state is: active/idle /dev/sda: drive state is: active/idle Should I give sdparm a shot? - 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: 2.6.23-mm1
On Thu, 11 Oct 2007 21:31:26 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > - I've been largely avoiding applying anything since rc8-mm2 in an attempt > to stabilise things for the 2.6.23 merge. > On RHEL5/x86_64 environment, == [EMAIL PROTECTED] ref-2.6.23-mm1]$ make menuconfig Makefile:456: /home/kamezawa/ref-2.6.23-mm1/arch//Makefile: No such file or directory make: *** No rule to make target `/home/kamezawa/ref-2.6.23-mm1/arch//Makefile'. Stop. == $(ARCH) cannot be detected automatically... What information is useful for fixing this ? Thanks, -Kame - 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/
2.6.23.git build error
Greetings, Freshly pulled 2.6.23.git failed to build: make[1]: *** No rule to make target `arch/x86/kernel/asm-offsets.c', needed by `arch/x86/kernel/asm-offsets.s'. Stop. make: *** [prepare0] Error 2 make: *** Waiting for unfinished jobs -Mike - 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 001/002] extract kmem_cache_shrink
> On Fri, 12 Oct 2007, Yasunori Goto wrote: > > > Make kmem_cache_shrink_node() for callback routine of memory hotplug > > notifier. This is just extract a part of kmem_cache_shrink(). > > Could we just call kmem_cache_shrink? It will do the shrink on every node > but memory hotplug is rare? Yes it is. Memory hotplug is rare. Ok. I'll do it. Thanks. -- 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: [RFD] iptables: mangle table obsoletes filter table
Please send mails discussing netfilter to netfilter-devel. Al Boldi wrote: > With the existence of the mangle table, how useful is the filter table? > > Other than requiring the REJECT target to be ported to the mangle table, is > the filter table faster than the mangle table? There are some minor differences in ordering (mangle comes before DNAT, filter afterwards), but for most rulesets thats completely irrelevant. The only difference that really matters is that mangle performs rerouting in LOCAL_OUT for packets that had their routing key changed, so its really a superset of the filter table. If you want to use REJECT in the mangle table, you just need to remove the restriction to filter, it works fine. I would prefer to also remove the restriction of MARK, CONNMARK etc. to mangle, they're used for more than just routing today so that restriction also doesn't make much sense. Patches for this are welcome. > If not, then shouldn't the filter table be obsoleted to avoid confusion? That would probably confuse people. Just don't use it if you don't need to. - 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 001/002] Make description of memory hotplug notifier in document
> Looks good. Some suggestions on improving the wording. Thanks! I'll fix them. Bye. > > On Fri, 12 Oct 2007, Yasunori Goto wrote: > > > +MEMORY_GOING_ONLINE > > + This is notified before memory online. If some structures must be > > prepared > > + for new memory, it should be done at this event's callback. > > + The new onlining memory can't be used yet. > > Generated before new memory becomes available in order to be able to > prepare subsystems to handle memory. The page allocator is still unable > to allocate from the new memory. > > > +MEMORY_CANCEL_ONLINE > > + If memory online fails, this event is notified for rollback of setting at > > + MEMORY_GOING_ONLINE. > > + (Currently, this event is notified only the case which a callback routine > > + of MEMORY_GOING_ONLINE fails). > > Generated if MEMORY_GOING_ONLINE fails. > > > +MEMORY_ONLINE > > + This event is called when memory online is completed. The page allocator > > uses > > + new memory area before this notification. In other words, callback > > routine > > + use new memory area via page allocator. > > + The failures of callbacks of this notification will be ignored. > > Generated when memory has succesfully brought online. The callback may > allocate from the new memory. > > > +MEMORY_GOING_OFFLINE > > + This is notified on halfway of memory offline. The offlining pages are > > + isolated. In other words, the page allocater doesn't allocate new pages > > from > > + offlining memory area at this time. If callback routine freed some pages, > > + they are not used by the page allocator. > > + This is good place for shrinking cache. (If possible, it is desirable to > > + migrate to other area.) > > Generated to begin the process of offlining memory. Allocations are no > longer possible from the memory but some of the memory to be offlined > is still in use. The callback can be used to free memory known to a > subsystem from the indicated node. > > > +MEMORY_CANCEL_OFFLINE > > + If memory offline fails, this event is notified for rollback against > > + MEMORY_GOING_OFFLINE. The page allocator will use target memory area > > after > > + this callback again. > > Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from > the node that we attempted to offline. > > > + +MEMORY_OFFLINE > > Generated after offlining memory is complete. -- 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/
2.6.23-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ - I've been largely avoiding applying anything since rc8-mm2 in an attempt to stabilise things for the 2.6.23 merge. But that didn't stop all the subsystem maintainers from going nuts, with the usual accuracy. We're up to a 37MB diff now, but it seems to be working a bit better. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.23-rc8-mm2: git-acpi.patch git-alsa.patch git-arm.patch git-audit-master.patch git-avr32.patch git-cifs.patch git-cpufreq.patch git-powerpc.patch git-drm.patch git-dvb.patch git-hwmon.patch git-gfs2-nmw.patch git-hid.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-jfs.patch git-jg-misc.patch git-kbuild.patch git-kvm.patch git-leds.patch git-libata-all.patch git-m32r.patch git-md-accel.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-net.patch git-backlight.patch git-battery.patch git-nfs.patch git-nfsd.patch git-ocfs2.patch git-r8169.patch git-selinux.patch git-s390.patch git-sched.patch git-sh.patch git-sh64.patch git-scsi-misc.patch git-block.patch git-unionfs.patch git-v9fs.patch git-watchdog.patch git-wireless.patch git-ipwireless_cs.patch git-newsetup.patch git-xfs.patch git-kgdb.patch git trees -x86_64-mm-vdso-text-offset.patch -fix-proc-acpi-alarm-to-work-with-bcd-alarm-encodings-award.patch -input-xpad-fix-dependancy-on-leds-class.patch -powerpc-include-pagemaph-in-asm-powerpc-tlbh.patch -exit-acpi-processor-module-gracefully-if-acpi-is-disabled.patch -hibernation-make-sure-that-acpi-is-enabled-in-acpi_hibernation_finish.patch -acpi-clean-up-acpi_enter_sleep_state_prep.patch -acpi-sbs-fix-sbs-add-alarm-patch.patch -acpi-suppress-uninitialized-var-warning.patch -generic-ac97-mixer-modem-oss-use-list_for_each_entry.patch -documentation-arm-00-index-add-missing-entries.patch -fs-cifs-connectc-kmalloc-memset-conversion-to-kzalloc.patch -cpufreq-move-policys-governor-initialisation-out-of-low-level-drivers-into-cpufreq-core.patch -cpufreq-allow-ondemand-and-conservative-cpufreq-governors-to-be-used-as-default.patch -allow-ondemand-and-conservative-cpufreq-governors-to-be-used-as-default-kconfig-fix.patch -cpufreq-mark-hotplug-notifier-callback-as-__cpuinit.patch -cpufreq-implement-config_cpu_freq-stub-for.patch -cpufreq_stats-misc-cpuinit-section-annotations.patch -powerpc-vdso-install-unstripped-copies-on-disk.patch -powerpc-vdso-install-unstripped-copies-on-disk-update.patch -sky-cpu-and-nexus-code-style-improvement.patch -sky-cpu-and-nexus-include-ioh.patch -sky-cpu-and-nexus-check-for-platform_get_resource-ret.patch -sky-cpu-and-nexus-check-for-create_proc_entry-ret-code.patch -sky-cpu-use-c99-style-for-struct-init.patch -sky-cpu-and-nexus-get-rid-of-useless-null-init.patch -sky-cpu-and-nexus-use-seq_file-single_open-on-proc-interface.patch -powerpc-proper-defconfig-for-crosscompiles.patch -powerpc-proper-defconfig-for-crosscompiles-fix.patch -powerpc-ptrace-check_full_regs.patch -gregkh-driver-sysfs-kill-sysfs_flag_removed.patch -revert-gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch -fix-gregkh-driver-kobject-remove-the-static-array-for-the-name.patch -fix-3-gregkh-driver-kobject-remove-the-static-array-for-the-name.patch -fix-2--gregkh-driver-drivers-clean-up-direct-setting-of-the-name-of-a-kset.patch -fix-gregkh-driver-drivers-clean-up-direct-setting-of-the-name-of-a-kset.patch -make-kobject-dynamic-allocation-check-use-kallsyms_lookup.patch -kobject-temporarily-save-k_name-on-cleanup-for-
Re: [v4l-dvb-maintainer] [PATCH 3/3] V4L: cinergyT2, remove bad usage of ERESTARTSYS
On Wed, 10 Oct 2007 00:18:28 -0400 Michael Krufky wrote: > Mauro Carvalho Chehab wrote: > > Hi Jiri, > > > > Em Seg, 2007-10-08 às 13:41 +0100, Jiri Slaby escreveu: > > > >> cinergyT2, remove bad usage of ERESTARTSYS > >> > >> test of cinergyt2->disconnect_pending doesn't ensure pending signal and so > >> ERESTARTSYS would reach userspace, which is not permitted. Change it to > >> EAGAIN > >> > >> > > > > checkpatch.pl is complaining about your changeset: > > > > do not use assignment in if condition > > #82: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:492: > > + if ((err = mutex_lock_interruptible(&cinergyt2->wq_sem))) > > > > do not use assignment in if condition > > #86: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:495: > > + if ((err = mutex_lock_interruptible(&cinergyt2->sem))) > > > > do not use assignment in if condition > > #133: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:1036: > > + if ((err = mutex_lock_interruptible(&cinergyt2->wq_sem))) > > > > do not use assignment in if condition > > #137: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:1039: > > + if ((err = mutex_lock_interruptible(&cinergyt2->sem))) > > Is this illegal as per kernel codingstyle? I could understand if we may > want to avoid this sort of thing for the sake of code readability, but > this seems 100% proper to me, especially considering that we're simply > trying to catch an error return code. Anyway, it's not strictly from CodingStyle. The closest that CodingStyle has to say about it IMO is this: "Don't put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions." Also, Andrew Morton and Christoph Hellwig push for splitting up the if-assignment lines, so it's a trend over the past few (probably) years. It's not real new. > One of the things that I really enjoy about the c programming language > is the fact that you can string many operations together into a single > statement through the use of logic. I hate the thought of a patch being > nacked because of the above. :-/ so you like the challenge of reading obfuscated code? At any rate, it's rare that a patch is nacked only due to coding style, unless it's blatant and occurs many times (like throughout the entire source file). > If this is indeed kernel codingstyle, then IMHO, we should let it slide > for catching error return codes. Nope. --- ~Randy - 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/
[git patch] libata critical fix
There is a lingering corruption in sata_mv that took me several days to
narrow down... the failure to mask off the lower 16 bits of the S/G
length was leading to corruption, because this stomped on other
important bits in that S/G entry.
This should fix it (stable aka 2.6.23.1 needs this too):
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-fixes
to receive the following updates:
drivers/ata/sata_mv.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
commit 6c08772e49622e90d39903e7ff0be1a0f463ac86
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri Oct 12 00:16:23 2007 -0400
[libata] sata_mv: more S/G fixes
* corruption fix: we only want the lower 16 bits of length (0 == 64kb)
* ditto: the upper layer sets max-phys-segments to LIBATA_MAX_PRD,
so we must reset it to own hw-specific length.
* delete unused mv_fill_sg() return value
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index cb7dec9..d9832e2 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -69,10 +69,11 @@
#include
#include
#include
+#include
#include
#define DRV_NAME "sata_mv"
-#define DRV_VERSION"1.0"
+#define DRV_VERSION"1.01"
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
@@ -420,6 +421,7 @@ static void mv_error_handler(struct ata_port *ap);
static void mv_post_int_cmd(struct ata_queued_cmd *qc);
static void mv_eh_freeze(struct ata_port *ap);
static void mv_eh_thaw(struct ata_port *ap);
+static int mv_slave_config(struct scsi_device *sdev);
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
static void mv5_phy_errata(struct mv_host_priv *hpriv, void __iomem *mmio,
@@ -457,7 +459,7 @@ static struct scsi_host_template mv5_sht = {
.use_clustering = 1,
.proc_name = DRV_NAME,
.dma_boundary = MV_DMA_BOUNDARY,
- .slave_configure= ata_scsi_slave_config,
+ .slave_configure= mv_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
@@ -475,7 +477,7 @@ static struct scsi_host_template mv6_sht = {
.use_clustering = 1,
.proc_name = DRV_NAME,
.dma_boundary = MV_DMA_BOUNDARY,
- .slave_configure= ata_scsi_slave_config,
+ .slave_configure= mv_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
@@ -763,6 +765,17 @@ static void mv_irq_clear(struct ata_port *ap)
{
}
+static int mv_slave_config(struct scsi_device *sdev)
+{
+ int rc = ata_scsi_slave_config(sdev);
+ if (rc)
+ return rc;
+
+ blk_queue_max_phys_segments(sdev->request_queue, MV_MAX_SG_CT / 2);
+
+ return 0; /* scsi layer doesn't check return value, sigh */
+}
+
static void mv_set_edma_ptrs(void __iomem *port_mmio,
struct mv_host_priv *hpriv,
struct mv_port_priv *pp)
@@ -1130,10 +1143,9 @@ static void mv_port_stop(struct ata_port *ap)
* LOCKING:
* Inherited from caller.
*/
-static unsigned int mv_fill_sg(struct ata_queued_cmd *qc)
+static void mv_fill_sg(struct ata_queued_cmd *qc)
{
struct mv_port_priv *pp = qc->ap->private_data;
- unsigned int n_sg = 0;
struct scatterlist *sg;
struct mv_sg *mv_sg;
@@ -1151,7 +1163,7 @@ static unsigned int mv_fill_sg(struct ata_queued_cmd *qc)
mv_sg->addr = cpu_to_le32(addr & 0x);
mv_sg->addr_hi = cpu_to_le32((addr >> 16) >> 16);
- mv_sg->flags_size = cpu_to_le32(len);
+ mv_sg->flags_size = cpu_to_le32(len & 0x);
sg_len -= len;
addr += len;
@@ -1160,12 +1172,9 @@ static unsigned int mv_fill_sg(struct ata_queued_cmd *qc)
mv_sg->flags_size |=
cpu_to_le32(EPRD_FLAG_END_OF_TBL);
mv_sg++;
- n_sg++;
}
}
-
- return n_sg;
}
static inline void mv_crqb_pack_cmd(__le16 *cmdw, u8 data, u8 addr, unsigned
last)
-
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: Help with rtc to hpet conversion of OSGPS driver
Rick Niles wrote: I'm the Linux maintainer for the OSGPS (open source GPS) project. Our last release version was based off Fedora 5 and since we have had some hardware issues with our on board interrupt line I was using the RTC interrupt to service the tracking loops. I've been trying to make the driver work with Fedora 7 and the 2.6.22 kernel, but the rtc_register() and other RTC functions seems to have been removed. I see they've been replaced by the corresponding HPET functions, which is great. However, hpet_register() always returns -16 (EBUSY). This could be because I lack the correct hardware (I'm running 32-bit Linux on a Athlon64 with an NVIDIA chipset) or some other reason. I'm looking for any help here. The RTC version of the code can be viewed at: http://osgps.cvs.sourceforge.net/osgps/osgps/linuxmod.c?revision=1.12&view=markup Can device drivers still use the real-time clock at all? Does the tickless kernel effect this at all? Thanks for any help you can lend, Rick Niles. Am I missing why you can't just use a normal kernel timer for this? You shouldn't have to mess with the RTC or HPET directly.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: ioremap_nocache and mem= parameter with k 2.6.18
[EMAIL PROTECTED] wrote: Hi, I'm using a driver for a framegrabber device that needs to alloc a huge buffer of ram for dma transfers So it works: 1) Having 2GB of ram installed, boot the kernel with mem=1024M parameter 2) remap the unmapped memory above first GB using ioremap_nocache function, using PAGE_ALIGN(). This works fine with kernel 2.6.9 but it doesn't with newer ones 2.6.18, 2.6.20, 2.6.22. With newer kernel ioremap returns 0. It seems like memory above 1G has been marked reserved, IMHO. What changes in the mm? I'm not the driver's developer, but I'd like to understand and possibly find a workaround... It doesn't make sense to use ioremap_nocache on RAM. It's only meant for mapping MMIO memory regions on a device. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: [Patch 001/002] Make description of memory hotplug notifier in document
Looks good. Some suggestions on improving the wording. On Fri, 12 Oct 2007, Yasunori Goto wrote: > +MEMORY_GOING_ONLINE > + This is notified before memory online. If some structures must be prepared > + for new memory, it should be done at this event's callback. > + The new onlining memory can't be used yet. Generated before new memory becomes available in order to be able to prepare subsystems to handle memory. The page allocator is still unable to allocate from the new memory. > +MEMORY_CANCEL_ONLINE > + If memory online fails, this event is notified for rollback of setting at > + MEMORY_GOING_ONLINE. > + (Currently, this event is notified only the case which a callback routine > + of MEMORY_GOING_ONLINE fails). Generated if MEMORY_GOING_ONLINE fails. > +MEMORY_ONLINE > + This event is called when memory online is completed. The page allocator > uses > + new memory area before this notification. In other words, callback routine > + use new memory area via page allocator. > + The failures of callbacks of this notification will be ignored. Generated when memory has succesfully brought online. The callback may allocate from the new memory. > +MEMORY_GOING_OFFLINE > + This is notified on halfway of memory offline. The offlining pages are > + isolated. In other words, the page allocater doesn't allocate new pages > from > + offlining memory area at this time. If callback routine freed some pages, > + they are not used by the page allocator. > + This is good place for shrinking cache. (If possible, it is desirable to > + migrate to other area.) Generated to begin the process of offlining memory. Allocations are no longer possible from the memory but some of the memory to be offlined is still in use. The callback can be used to free memory known to a subsystem from the indicated node. > +MEMORY_CANCEL_OFFLINE > + If memory offline fails, this event is notified for rollback against > + MEMORY_GOING_OFFLINE. The page allocator will use target memory area after > + this callback again. Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from the node that we attempted to offline. > + +MEMORY_OFFLINE Generated after offlining memory is complete. - 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: [GIT PULL] kbuild updates
On Thu, Oct 11, 2007 at 07:08:53PM -0700, Linus Torvalds wrote: > > > On Wed, 10 Oct 2007, Sam Ravnborg wrote: > > > > This set of commits are the kbuild stuff that does not > > conflict with the pending x86 merge. > > Hmm. It does for me, actually. I did not try it out obviously - I just removed everything touching x86_64/i386. This is the SRCARCH changes in top-level Makefile. > > I fixed up the trivial conflict in the main Makefile, but that seems to > leave $(ARCH) entirely undefined in my case, so the end result doesn't > work. That seems to have nothing to do with my conflict fixup, but is > something else. > > It also gets a trivial conflict with the 'mmc' pull I just did, but that > didn't seem problematic (mmc added a new case to scripts/mod/file2alias.c, > and you added a free, both at the end of the same function) - but the x86 > merge conflict means that I decided that I'll let you sort it out. It's > probably really trivial, but I'll merge the other stuff I have pending > instead. As Andrew has an issue with my geneius "save ARCH & CROSS_COMPILE" patch this is perfect. I will sort out the conflicts and Andrew's use-case and submit a new pull request. Sam - 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 002/002] Create/delete kmem_cache_node for SLUB on memory online callback
On Fri, 12 Oct 2007, Yasunori Goto wrote:
> If pages on the new node available, slub can use it before making
> new kmem_cache_nodes. So, this callback should be called
> BEFORE pages on the node are available.
If its called before pages on the node are available then it must
fallback and cannot use the pages.
> +#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
> +static int slab_mem_going_offline_callback(void *arg)
> +{
> + struct kmem_cache *s;
> + struct memory_notify *marg = arg;
> + int local_node, offline_node = marg->status_change_nid;
> +
> + if (offline_node < 0)
> + /* node has memory yet. nothing to do. */
Please clarify the comment. This seems to indicate that we should not
do anything because the node still has memory?
Doesnt the node always have memory before offlining?
> + return 0;
> +
> + down_read(&slub_lock);
> + list_for_each_entry(s, &slab_caches, list) {
> + local_node = page_to_nid(virt_to_page(s));
> + if (local_node == offline_node)
> + /* This slub is on the offline node. */
> + return -EBUSY;
> + }
> + up_read(&slub_lock);
So this checks if the any kmem_cache structure is on the offlined node? If
so then we cannot offline the node?
> + kmem_cache_shrink_node(s, offline_node);
kmem_cache_shrink(s) would be okay here I would think. The function is
reasonably fast. Offlining is a rare event.
> +static void slab_mem_offline_callback(void *arg)
We call this after we have established that no kmem_cache structures are
on this and after we have shrunk the slabs. Is there any guarantee that
no slab operations have occurrent since then?
> +{
> + struct kmem_cache_node *n;
> + struct kmem_cache *s;
> + struct memory_notify *marg = arg;
> + int offline_node;
> +
> + offline_node = marg->status_change_nid;
> +
> + if (offline_node < 0)
> + /* node has memory yet. nothing to do. */
> + return;
Does this mean that the node still has memory?
> + down_read(&slub_lock);
> + list_for_each_entry(s, &slab_caches, list) {
> + n = get_node(s, offline_node);
> + if (n) {
> + /*
> + * if n->nr_slabs > 0, offline_pages() must be fail,
> + * because the node is used by slub yet.
> + */
It may be clearer to say:
"If nr_slabs > 0 then slabs still exist on the node that is going down.
We were unable to free them so we must fail."
> +static int slab_mem_going_online_callback(void *arg)
> +{
> + struct kmem_cache_node *n;
> + struct kmem_cache *s;
> + struct memory_notify *marg = arg;
> + int nid = marg->status_change_nid;
> +
> + /* If the node already has memory, then nothing is necessary. */
> + if (nid < 0)
> + return 0;
The node must have memory Or we have already brought up the code?
> + /*
> + * New memory will be onlined on the node which has no memory so far.
> + * New kmem_cache_node is necssary for it.
"We are bringing a node online. No memory is available yet. We must
allocate a kmem_cache_node structure in order to bring the node online." ?
> + */
> + down_read(&slub_lock);
> + list_for_each_entry(s, &slab_caches, list) {
> + /*
> + * XXX: The new node's memory can't be allocated yet,
> + * kmem_cache_node will be allocated other node.
> + */
"kmem_cache_alloc node will fallback to other nodes since memory is
not yet available from the node that is brought up.¨ ?
> + n = kmem_cache_alloc(kmalloc_caches, GFP_KERNEL);
> + if (!n)
> + return -ENOMEM;
> + init_kmem_cache_node(n);
> + s->node[nid] = n;
> + }
> + up_read(&slub_lock);
> +
> + return 0;
> +}
Re: [Patch 001/002] extract kmem_cache_shrink
On Fri, 12 Oct 2007, Yasunori Goto wrote: > Make kmem_cache_shrink_node() for callback routine of memory hotplug > notifier. This is just extract a part of kmem_cache_shrink(). Could we just call kmem_cache_shrink? It will do the shrink on every node but memory hotplug is rare? - 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: [GIT PULL] please pull infiniband.git for-linus
On Thu, 11 Oct 2007, Greg KH wrote: > On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote: > > > > So I merged it all, and I don't expect any problems, but I'm hoping > > somebody is thinking about that mod_devicetable.h/file2alias.c mess. > > > > I'm not entirely sure who to blame on that thing. I'm adding Greg to the > > Cc, on the assumption that blaming him is usually the right thing to do ;) > > Hey, it wasn't me this time, I haven't even built my trees for you to > pull from and break everything yet :) No, I meant more in the "who the hell is responsible for designing those *files*" rather than who is responsible for the particular merge mess that happened to involve them this time around. > But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very > good idea, I'll see what I can come up with tomorrow. I don't think it's a huge issue, but I wanted to bring it up because these days we're normally so good with these kinds of things that it actually stood out a bit. I used to do these kinds of nasty merges all the time with init/main.c and the configuration files, until we split them up. So I'm certainly perfectly able and used to doing them, it's just that I also think that we have generally learnt to do so much better. In other words: no hurry or pressure, I just wanted to bring it up, since during the merge I got flashbacks to various "bad old times" that I had hoped we had mostly left behind. Those files were originally designed/set up by Rusty. I could have blamed him, or perhaps Sam as a kbuild guy, but the reason I cc'd you is that I think this kind of smells like a "device model"ish thing... Hmm? Linus - 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] JFS: fix bio-related build breakage
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index 57c3b8a..ccfd029 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2162,7 +2162,7 @@ static void lbmStartIO(struct lbuf * bp)
/* check if journaling to disk has been disabled */
if (log->no_integrity) {
bio->bi_size = 0;
- lbmIODone(bio, 0, 0);
+ lbmIODone(bio, 0);
} else {
submit_bio(WRITE_SYNC, bio);
INCREMENT(lmStat.submitted);
@@ -2234,8 +2234,6 @@ static void lbmIODone(struct bio *bio, int error)
/* wakeup I/O initiator */
LCACHE_WAKEUP(&bp->l_ioevent);
-
- return 0;
}
/*
@@ -2260,7 +2258,6 @@ static void lbmIODone(struct bio *bio, int error)
if (bp->l_flag & lbmDIRECT) {
LCACHE_WAKEUP(&bp->l_ioevent);
LCACHE_UNLOCK(flags);
- return 0;
}
tail = log->wqueue;
@@ -2339,8 +2336,6 @@ static void lbmIODone(struct bio *bio, int error)
LCACHE_UNLOCK(flags); /* unlock+enable */
}
-
- return 0;
}
int jfsIOWait(void *arg)
-
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: [v4l-dvb-maintainer] [PATCH 3/3] V4L: cinergyT2, remove bad usage of ERESTARTSYS
Mauro Carvalho Chehab wrote: > Hi Jiri, > > Em Seg, 2007-10-08 às 13:41 +0100, Jiri Slaby escreveu: > >> cinergyT2, remove bad usage of ERESTARTSYS >> >> test of cinergyt2->disconnect_pending doesn't ensure pending signal and so >> ERESTARTSYS would reach userspace, which is not permitted. Change it to >> EAGAIN >> >> > > checkpatch.pl is complaining about your changeset: > > do not use assignment in if condition > #82: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:492: > + if ((err = mutex_lock_interruptible(&cinergyt2->wq_sem))) > > do not use assignment in if condition > #86: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:495: > + if ((err = mutex_lock_interruptible(&cinergyt2->sem))) > > do not use assignment in if condition > #133: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:1036: > + if ((err = mutex_lock_interruptible(&cinergyt2->wq_sem))) > > do not use assignment in if condition > #137: FILE: drivers/media/dvb/cinergyT2/cinergyT2.c:1039: > + if ((err = mutex_lock_interruptible(&cinergyt2->sem))) Is this illegal as per kernel codingstyle? I could understand if we may want to avoid this sort of thing for the sake of code readability, but this seems 100% proper to me, especially considering that we're simply trying to catch an error return code. One of the things that I really enjoy about the c programming language is the fact that you can string many operations together into a single statement through the use of logic. I hate the thought of a patch being nacked because of the above. :-/ If this is indeed kernel codingstyle, then IMHO, we should let it slide for catching error return codes. Regards, Mike Krufky - 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: [GIT PULL] please pull infiniband.git for-linus
On Thu, Oct 11, 2007 at 07:58:04PM -0700, Linus Torvalds wrote: > > So I merged it all, and I don't expect any problems, but I'm hoping > somebody is thinking about that mod_devicetable.h/file2alias.c mess. > > I'm not entirely sure who to blame on that thing. I'm adding Greg to the > Cc, on the assumption that blaming him is usually the right thing to do ;) Hey, it wasn't me this time, I haven't even built my trees for you to pull from and break everything yet :) But yeah, splitting up the mod_devicetable.h/file2alias.c mess is a very good idea, I'll see what I can come up with tomorrow. thanks, greg k-h - 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: [GIT PULL] please pull infiniband.git for-linus
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu, 11 Oct 2007 19:58:04 -0700 (PDT) > > > On Thu, 11 Oct 2007, David Miller wrote: > > > > Even if you're confident there won't be merge issues, could you just > > wait for the net-2.6 stuff to go in first? > > I pulled the net stuff first, and merged the IB stuff afterwards. No > conflicts in IB, but there *were* conflicts with the networking pull for > other reasons. > > That horrid, horrid mess that is called include/linux/mod_devicetable.h > and scripts/mod/file2alias.c must go at some point. The thing is > unmaintainable. Different maintainers add their own structures to both, > and functions to both, and it's just messy. That's not how maintainable > and modularized code should be written. > > Now it broke on sdio vs ssb, but there was actually a conflict earlier > with the Kbuild merge (which I aborted for other reasons), so this file > really is starting to be a problem. > > The merge was fairly straightforward and stupid - it's not like the code > added is *complicated*, but all those small functions and structrues are > set up to be a maze of very similar lines, so the merge is actually much > worse than it should be - because there is inherent similarity, some lines > are automatically auto-merged, making the result just harder to visualize. > > So I merged it all, and I don't expect any problems, but I'm hoping > somebody is thinking about that mod_devicetable.h/file2alias.c mess. It all looks good from here. - 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/2 -mm] kexec based hibernation -v5
On Thu, 2007-10-11 at 12:17 +0200, Rafael J. Wysocki wrote: > On Thursday, 11 October 2007 04:13, Huang, Ying wrote: > > Kexec base hibernation has some potential advantages over uswsusp and > > TuxOnIce (suspend2). Some most obvious advantages are: > > Well, I have some doubts as far as the obviousness is concerned. OK, I will remove the "obvious". > > 1. The hibernation image size can exceed half of memory size easily. > > This is also possible with TuxOnIce. I will add detail description about this. It is possible with TuxOnIce, and hard with u/swsusp. > > > 2. The hibernation image can be written to and read from almost > >anywhere, such as USB disk, NFS. > > This is possible with uswsusp, at least in theory, probably with TuxOnIce too. I will remove this. > > 3. It is possible to eliminate freezer from kexec based hibernation > >implementation. > > This isn't true as long as we have not changed the handling of devices > (which is in the works, but will take time). I know it has not been implemented yet. I just say that it is possible for khibernation and it is almost impossible for u/swsusp and TuxOnIce. > > 4. Based on kexec/kdump implementation, the kernel code needed is > >less. > > Well, maybe. > Best Regards, Huang Ying - 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 02/10] Blackfin SPI driver: use new GPIO API and add error handling
From: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 29 +++--
include/asm-blackfin/mach-bf533/portmux.h |2 +-
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 2992ada..8041b89 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -1165,6 +1165,22 @@ static inline int destroy_queue(struct driver_data
*drv_data)
return 0;
}
+static int setup_pin_mux(int action)
+{
+
+ u16 pin_req[] = {P_SPI0_SCK, P_SPI0_MISO, P_SPI0_MOSI, 0};
+
+ if (action) {
+ if (peripheral_request_list(pin_req, DRV_NAME)) {
+ return -EFAULT;
+ }
+ } else {
+ peripheral_free_list(pin_req);
+ }
+
+ return 0;
+}
+
static int __init bfin5xx_spi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1182,12 +1198,9 @@ static int __init bfin5xx_spi_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- if (peripheral_request(P_SPI0_SCK, DRV_NAME) ||
-peripheral_request(P_SPI0_MISO, DRV_NAME) ||
-peripheral_request(P_SPI0_MOSI, DRV_NAME) ) {
-
+ if (setup_pin_mux(1)) {
dev_err(&pdev->dev, ": Requesting Peripherals failed\n");
- goto out_error_queue_alloc;
+ goto out_error;
}
drv_data = spi_master_get_devdata(master);
@@ -1223,9 +1236,11 @@ static int __init bfin5xx_spi_probe(struct
platform_device *pdev)
dev_dbg(&pdev->dev, "controller probe successfully\n");
return status;
- out_error_queue_alloc:
+out_error_queue_alloc:
destroy_queue(drv_data);
+out_error:
spi_master_put(master);
+
return status;
}
@@ -1255,6 +1270,8 @@ static int __devexit bfin5xx_spi_remove(struct
platform_device *pdev)
/* Disconnect from the SPI framework */
spi_unregister_master(drv_data->master);
+ setup_pin_mux(0);
+
/* Prevent double remove */
platform_set_drvdata(pdev, NULL);
diff --git a/include/asm-blackfin/mach-bf533/portmux.h
b/include/asm-blackfin/mach-bf533/portmux.h
index b88d7a0..137f488 100644
--- a/include/asm-blackfin/mach-bf533/portmux.h
+++ b/include/asm-blackfin/mach-bf533/portmux.h
@@ -42,7 +42,7 @@
#define P_SPORT0_DRPRI (P_DONTCARE)
#define P_SPI0_MOSI(P_DONTCARE)
-#define P_SPI0_MIS0(P_DONTCARE)
+#define P_SPI0_MISO(P_DONTCARE)
#define P_SPI0_SCK (P_DONTCARE)
#define P_SPI0_SSEL7 (P_DEFINED | P_IDENT(GPIO_PF7))
#define P_SPI0_SSEL6 (P_DEFINED | P_IDENT(GPIO_PF6))
--
1.5.3.4
-
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 07/10] Blackfin SPI driver: Add SPI master controller platform device 1
From: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 52 ++--
1 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 891d263..ecfb7c5 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -209,17 +209,26 @@ static void cs_deactive(struct chip_data *chip)
write_FLAG(flag);
}
-#define MAX_SPI0_SSEL 7
+#define MAX_SPI_SSEL 7
/* stop controller and re-config current chip*/
static int restore_state(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
int ret = 0;
- u16 ssel[MAX_SPI0_SSEL] = {P_SPI0_SSEL1, P_SPI0_SSEL2, P_SPI0_SSEL3,
- P_SPI0_SSEL4, P_SPI0_SSEL5,
- P_SPI0_SSEL6, P_SPI0_SSEL7,};
-
+ u16 ssel[3][MAX_SPI_SSEL] = {
+ {P_SPI0_SSEL1, P_SPI0_SSEL2, P_SPI0_SSEL3,
+ P_SPI0_SSEL4, P_SPI0_SSEL5,
+ P_SPI0_SSEL6, P_SPI0_SSEL7},
+
+ {P_SPI1_SSEL1, P_SPI1_SSEL2, P_SPI1_SSEL3,
+ P_SPI1_SSEL4, P_SPI1_SSEL5,
+ P_SPI1_SSEL6, P_SPI1_SSEL7},
+
+ {P_SPI2_SSEL1, P_SPI2_SSEL2, P_SPI2_SSEL3,
+ P_SPI2_SSEL4, P_SPI2_SSEL5,
+ P_SPI2_SSEL6, P_SPI2_SSEL7},
+ };
/* Clear status and disable clock */
write_STAT(BIT_STAT_CLR);
bfin_spi_disable(drv_data);
@@ -234,9 +243,9 @@ static int restore_state(struct driver_data *drv_data)
int i = chip->chip_select_num;
dev_dbg(&drv_data->pdev->dev, "chip select number is %d\n", i);
-
- if ((i > 0) && (i <= MAX_SPI0_SSEL))
- ret = peripheral_request(ssel[i-1], DRV_NAME);
+ if ((i > 0) && (i <= MAX_SPI_SSEL))
+ ret = peripheral_request(
+ ssel[drv_data->master->bus_num][i-1], DRV_NAME);
chip->chip_select_requested = 1;
}
@@ -329,7 +338,6 @@ static void u8_reader(struct driver_data *drv_data)
write_TDBR(0x);
dummy_read();
-
while (drv_data->rx < drv_data->rx_end - 1) {
while (!(read_STAT() & BIT_STAT_RXS))
continue;
@@ -640,7 +648,6 @@ static void pump_transfers(unsigned long data)
message = drv_data->cur_msg;
transfer = drv_data->cur_transfer;
chip = drv_data->cur_chip;
-
/*
* if msg is error or done, report it back using complete() callback
*/
@@ -1202,17 +1209,20 @@ static inline int destroy_queue(struct driver_data
*drv_data)
return 0;
}
-static int setup_pin_mux(int action)
+static int setup_pin_mux(int action, int bus_num)
{
- u16 pin_req[] = {P_SPI0_SCK, P_SPI0_MISO, P_SPI0_MOSI, 0};
+ u16 pin_req[3][4] = {
+ {P_SPI0_SCK, P_SPI0_MISO, P_SPI0_MOSI, 0},
+ {P_SPI1_SCK, P_SPI1_MISO, P_SPI1_MOSI, 0},
+ {P_SPI2_SCK, P_SPI2_MISO, P_SPI2_MOSI, 0},
+ };
if (action) {
- if (peripheral_request_list(pin_req, DRV_NAME)) {
+ if (peripheral_request_list(pin_req[bus_num], DRV_NAME))
return -EFAULT;
- }
} else {
- peripheral_free_list(pin_req);
+ peripheral_free_list(pin_req[bus_num]);
}
return 0;
@@ -1236,11 +1246,6 @@ static int __init bfin5xx_spi_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- if (setup_pin_mux(1)) {
- dev_err(&pdev->dev, ": Requesting Peripherals failed\n");
- goto out_error;
- }
-
drv_data = spi_master_get_devdata(master);
drv_data->master = master;
drv_data->master_info = platform_info;
@@ -1295,6 +1300,11 @@ static int __init bfin5xx_spi_probe(struct
platform_device *pdev)
goto out_error_queue_alloc;
}
+ if (setup_pin_mux(1, master->bus_num)) {
+ dev_err(&pdev->dev, ": Requesting Peripherals failed\n");
+ goto out_error;
+ }
+
dev_info(dev, "%s, Version %s, regs_base @ 0x%08x\n",
DRV_DESC, DRV_VERSION, spi_regs_base);
return status;
@@ -1337,7 +1347,7 @@ static int __devexit bfin5xx_spi_remove(struct
platform_device *pdev)
/* Disconnect from the SPI framework */
spi_unregister_master(drv_data->master);
- setup_pin_mux(0);
+ setup_pin_mux(0, drv_data->master->bus_num);
/* Prevent double remove */
platform_set_drvdata(pdev, NULL);
--
1.5.3.4
-
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
[PATCH 08/10] Blackfin SPI driver: Move GPIO config to setup and cleanup
From: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 52 +++-
1 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index ecfb7c5..c1516cb 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -136,7 +136,6 @@ struct chip_data {
u16 flag;
u8 chip_select_num;
- u8 chip_select_requested;
u8 n_bytes;
u8 width; /* 0 or 1 */
u8 enable_dma;
@@ -216,19 +215,7 @@ static int restore_state(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
int ret = 0;
- u16 ssel[3][MAX_SPI_SSEL] = {
- {P_SPI0_SSEL1, P_SPI0_SSEL2, P_SPI0_SSEL3,
- P_SPI0_SSEL4, P_SPI0_SSEL5,
- P_SPI0_SSEL6, P_SPI0_SSEL7},
-
- {P_SPI1_SSEL1, P_SPI1_SSEL2, P_SPI1_SSEL3,
- P_SPI1_SSEL4, P_SPI1_SSEL5,
- P_SPI1_SSEL6, P_SPI1_SSEL7},
-
- {P_SPI2_SSEL1, P_SPI2_SSEL2, P_SPI2_SSEL3,
- P_SPI2_SSEL4, P_SPI2_SSEL5,
- P_SPI2_SSEL6, P_SPI2_SSEL7},
- };
+
/* Clear status and disable clock */
write_STAT(BIT_STAT_CLR);
bfin_spi_disable(drv_data);
@@ -239,17 +226,6 @@ static int restore_state(struct driver_data *drv_data)
write_BAUD(chip->baud);
cs_active(chip);
- if (!chip->chip_select_requested) {
- int i = chip->chip_select_num;
-
- dev_dbg(&drv_data->pdev->dev, "chip select number is %d\n", i);
- if ((i > 0) && (i <= MAX_SPI_SSEL))
- ret = peripheral_request(
- ssel[drv_data->master->bus_num][i-1], DRV_NAME);
-
- chip->chip_select_requested = 1;
- }
-
if (ret)
dev_dbg(&drv_data->pdev->dev,
": request chip select number %d failed\n",
@@ -981,6 +957,22 @@ static int transfer(struct spi_device *spi, struct
spi_message *msg)
return 0;
}
+#define MAX_SPI_SSEL 7
+
+static u16 ssel[3][MAX_SPI_SSEL] = {
+ {P_SPI0_SSEL1, P_SPI0_SSEL2, P_SPI0_SSEL3,
+ P_SPI0_SSEL4, P_SPI0_SSEL5,
+ P_SPI0_SSEL6, P_SPI0_SSEL7},
+
+ {P_SPI1_SSEL1, P_SPI1_SSEL2, P_SPI1_SSEL3,
+ P_SPI1_SSEL4, P_SPI1_SSEL5,
+ P_SPI1_SSEL6, P_SPI1_SSEL7},
+
+ {P_SPI2_SSEL1, P_SPI2_SSEL2, P_SPI2_SSEL3,
+ P_SPI2_SSEL4, P_SPI2_SSEL5,
+ P_SPI2_SSEL6, P_SPI2_SSEL7},
+};
+
/* first setup for new devices */
static int setup(struct spi_device *spi)
{
@@ -1109,6 +1101,12 @@ static int setup(struct spi_device *spi)
spi_set_ctldata(spi, chip);
+ dev_dbg(&spi->dev, "chip select number is %d\n", chip->chip_select_num);
+ if ((chip->chip_select_num > 0)
+ && (chip->chip_select_num <= spi->master->num_chipselect))
+ peripheral_request(ssel[spi->master->bus_num]
+ [chip->chip_select_num-1], DRV_NAME);
+
return 0;
}
@@ -1120,6 +1118,10 @@ static void cleanup(struct spi_device *spi)
{
struct chip_data *chip = spi_get_ctldata(spi);
+ if ((chip->chip_select_num > 0)
+ && (chip->chip_select_num <= spi->master->num_chipselect))
+
peripheral_free(ssel[spi->master->bus_num][chip->chip_select_num-1]);
+
kfree(chip);
}
--
1.5.3.4
-
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 09/10] Blackfin SPI driver: Fix SPI driver to work with SPI flash ST25P16 on bf548
From: Sonic Zhang <[EMAIL PROTECTED]>
Current SPI driver enables SPI controller and set the SPI baud register
for each SPI transfer. But, they should never be changed within a SPI
message session, in which seveal SPI transfers are pumped. This patch
move move SPI setting to the begining of a message session. And never
disables SPI controller until an error occurs.
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 162 -
1 files changed, 87 insertions(+), 75 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index c1516cb..0cdfc2b 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -222,9 +222,13 @@ static int restore_state(struct driver_data *drv_data)
dev_dbg(&drv_data->pdev->dev, "restoring spi ctl state\n");
/* Load the registers */
- write_CTRL(chip->ctl_reg);
+ cs_deactive(chip);
write_BAUD(chip->baud);
- cs_active(chip);
+ chip->ctl_reg &= (~BIT_CTL_TIMOD);
+ chip->ctl_reg |= (chip->width << 8);
+ write_CTRL(chip->ctl_reg);
+
+ bfin_spi_enable(drv_data);
if (ret)
dev_dbg(&drv_data->pdev->dev,
@@ -271,6 +275,7 @@ static void u8_writer(struct driver_data *drv_data)
{
dev_dbg(&drv_data->pdev->dev,
"cr8-s is 0x%x\n", read_STAT());
+
while (drv_data->tx < drv_data->tx_end) {
write_TDBR(*(u8 *) (drv_data->tx));
while (read_STAT() & BIT_STAT_TXS)
@@ -293,16 +298,16 @@ static void u8_cs_chg_writer(struct driver_data *drv_data)
write_TDBR(*(u8 *) (drv_data->tx));
while (read_STAT() & BIT_STAT_TXS)
continue;
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
cs_deactive(chip);
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
++drv_data->tx;
}
- cs_deactive(chip);
+ /* poll for SPI completion before returning */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
}
static void u8_reader(struct driver_data *drv_data)
@@ -314,6 +319,7 @@ static void u8_reader(struct driver_data *drv_data)
write_TDBR(0x);
dummy_read();
+
while (drv_data->rx < drv_data->rx_end - 1) {
while (!(read_STAT() & BIT_STAT_RXS))
continue;
@@ -331,23 +337,30 @@ static void u8_cs_chg_reader(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
- while (drv_data->rx < drv_data->rx_end) {
- cs_active(chip);
+ /* clear TDBR buffer before read(else it will be shifted out) */
+ write_TDBR(0x);
- read_RDBR();/* kick off */
- while (!(read_STAT() & BIT_STAT_RXS))
- continue;
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
- *(u8 *) (drv_data->rx) = read_SHAW();
+ cs_active(chip);
+ dummy_read();
+
+ while (drv_data->rx < drv_data->rx_end - 1) {
cs_deactive(chip);
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
+
+ while (!(read_STAT() & BIT_STAT_RXS))
+ continue;
+ cs_active(chip);
+ *(u8 *) (drv_data->rx) = read_RDBR();
++drv_data->rx;
}
cs_deactive(chip);
+ while (!(read_STAT() & BIT_STAT_RXS))
+ continue;
+ *(u8 *) (drv_data->rx) = read_SHAW();
+ ++drv_data->rx;
}
static void u8_duplex(struct driver_data *drv_data)
@@ -355,7 +368,7 @@ static void u8_duplex(struct driver_data *drv_data)
/* in duplex mode, clk is triggered by writing of TDBR */
while (drv_data->rx < drv_data->rx_end) {
write_TDBR(*(u8 *) (drv_data->tx));
- while (!(read_STAT() & BIT_STAT_SPIF))
+ while (read_STAT() & BIT_STAT_TXS)
continue;
while (!(read_STAT() & BIT_STAT_RXS))
continue;
@@ -363,6 +376,10 @@ static void u8_duplex(struct driver_data *drv_data)
++drv_data->rx;
++drv_data->tx;
}
+
+ /* poll for SPI completion before returning */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
}
static void u8_cs_chg_duplex(struct driver_data *drv_data)
@@ -372,9 +389,8 @@ static void u8_cs_chg_duplex(struct driver_data *drv_data)
while (drv_data->rx < drv_data->rx_end) {
cs_active(chip);
-
write_TDBR(*(u8 *) (drv_data->tx));
- while (!(read_STAT() & BIT_STAT_SPIF))
+ while (read_STAT() & BIT_STAT_TXS)
[PATCH 10/10] Blackfin SPI driver: Clean up useless wait in bfin SPI driver
From: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 84 -
1 files changed, 52 insertions(+), 32 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 0cdfc2b..bfeaa7c 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -276,22 +276,26 @@ static void u8_writer(struct driver_data *drv_data)
dev_dbg(&drv_data->pdev->dev,
"cr8-s is 0x%x\n", read_STAT());
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
while (drv_data->tx < drv_data->tx_end) {
write_TDBR(*(u8 *) (drv_data->tx));
while (read_STAT() & BIT_STAT_TXS)
continue;
++drv_data->tx;
}
-
- /* poll for SPI completion before returning */
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
}
static void u8_cs_chg_writer(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
while (drv_data->tx < drv_data->tx_end) {
cs_active(chip);
@@ -304,10 +308,6 @@ static void u8_cs_chg_writer(struct driver_data *drv_data)
udelay(chip->cs_chg_udelay);
++drv_data->tx;
}
-
- /* poll for SPI completion before returning */
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
}
static void u8_reader(struct driver_data *drv_data)
@@ -315,6 +315,10 @@ static void u8_reader(struct driver_data *drv_data)
dev_dbg(&drv_data->pdev->dev,
"cr-8 is 0x%x\n", read_STAT());
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
/* clear TDBR buffer before read(else it will be shifted out) */
write_TDBR(0x);
@@ -337,6 +341,10 @@ static void u8_cs_chg_reader(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
/* clear TDBR buffer before read(else it will be shifted out) */
write_TDBR(0x);
@@ -365,6 +373,10 @@ static void u8_cs_chg_reader(struct driver_data *drv_data)
static void u8_duplex(struct driver_data *drv_data)
{
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
/* in duplex mode, clk is triggered by writing of TDBR */
while (drv_data->rx < drv_data->rx_end) {
write_TDBR(*(u8 *) (drv_data->tx));
@@ -376,16 +388,16 @@ static void u8_duplex(struct driver_data *drv_data)
++drv_data->rx;
++drv_data->tx;
}
-
- /* poll for SPI completion before returning */
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
}
static void u8_cs_chg_duplex(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
while (drv_data->rx < drv_data->rx_end) {
cs_active(chip);
@@ -402,10 +414,6 @@ static void u8_cs_chg_duplex(struct driver_data *drv_data)
++drv_data->rx;
++drv_data->tx;
}
-
- /* poll for SPI completion before returning */
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
}
static void u16_writer(struct driver_data *drv_data)
@@ -413,22 +421,26 @@ static void u16_writer(struct driver_data *drv_data)
dev_dbg(&drv_data->pdev->dev,
"cr16 is 0x%x\n", read_STAT());
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
while (drv_data->tx < drv_data->tx_end) {
write_TDBR(*(u16 *) (drv_data->tx));
while ((read_STAT() & BIT_STAT_TXS))
continue;
drv_data->tx += 2;
}
-
- /* poll for SPI completion before returning */
- while (!(read_STAT() & BIT_STAT_SPIF))
- continue;
}
static void u16_cs_chg_writer(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
+ /* poll for SPI completion before start */
+ while (!(read_STAT() & BIT_STAT_SPIF))
+ continue;
+
while (drv_data->tx < drv_data->tx_end) {
cs_active(chip);
@@ -441,10 +453,6 @@ static void u16_cs_chg_writer(struct driver_data *drv_data)
[PATCH 06/10] Blackfin SPI driver: update spi driver to support multi-ports
update spi driver to support multi-ports by add platform_resource,
tested on STAMP537+SPI_MMC, other boards need more testing
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 124 ++---
1 files changed, 83 insertions(+), 41 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 1a83656..891d263 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -13,6 +13,8 @@
* March 10, 2006 bfin5xx_spi.c Created. (Luke Yang)
* August 7, 2006 added full duplex mode (Axel Weiss & Luke Yang)
* July 17, 2007 add support for BF54x SPI0 controller (Bryan Wu)
+ * July 30, 2007 add platfrom_resource interface to support multi-port
+ * SPI controller (Bryan Wu)
*
* Copyright 2004-2007 Analog Devices Inc.
*
@@ -50,18 +52,25 @@
#include
#include
-MODULE_AUTHOR("Bryan Wu, Luke Yang");
-MODULE_DESCRIPTION("Blackfin BF5xx SPI Contoller Driver");
+#define DRV_NAME "bfin-spi"
+#define DRV_AUTHOR "Bryan Wu, Luke Yang"
+#define DRV_DESC "Blackfin BF5xx on-chip SPI Contoller Driver"
+#define DRV_VERSION"1.0"
+
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
MODULE_LICENSE("GPL");
-#define DRV_NAME "bfin-spi-master"
#define IS_DMA_ALIGNED(x) (((u32)(x)&0x07)==0)
+static u32 spi_dma_ch;
+static u32 spi_regs_base;
+
#define DEFINE_SPI_REG(reg, off) \
static inline u16 read_##reg(void) \
- { return bfin_read16(SPI0_REGBASE + off); } \
+ { return bfin_read16(spi_regs_base + off); } \
static inline void write_##reg(u16 v) \
- {bfin_write16(SPI0_REGBASE + off, v); }
+ {bfin_write16(spi_regs_base + off, v); }
DEFINE_SPI_REG(CTRL, 0x00)
DEFINE_SPI_REG(FLAG, 0x04)
@@ -573,10 +582,10 @@ static irqreturn_t dma_irq_handler(int irq, void *dev_id)
struct chip_data *chip = drv_data->cur_chip;
dev_dbg(&drv_data->pdev->dev, "in dma_irq_handler\n");
- clear_dma_irqstat(CH_SPI);
+ clear_dma_irqstat(spi_dma_ch);
/* Wait for DMA to complete */
- while (get_dma_curr_irqstat(CH_SPI) & DMA_RUN)
+ while (get_dma_curr_irqstat(spi_dma_ch) & DMA_RUN)
continue;
/*
@@ -586,12 +595,12 @@ static irqreturn_t dma_irq_handler(int irq, void *dev_id)
* register until it goes low for 2 successive reads
*/
if (drv_data->tx != NULL) {
- while ((bfin_read_SPI_STAT() & TXS) ||
- (bfin_read_SPI_STAT() & TXS))
+ while ((read_STAT() & TXS) ||
+ (read_STAT() & TXS))
continue;
}
- while (!(bfin_read_SPI_STAT() & SPIF))
+ while (!(read_STAT() & SPIF))
continue;
bfin_spi_disable(drv_data);
@@ -610,8 +619,8 @@ static irqreturn_t dma_irq_handler(int irq, void *dev_id)
/* free the irq handler before next transfer */
dev_dbg(&drv_data->pdev->dev,
"disable dma channel irq%d\n",
- CH_SPI);
- dma_disable_irq(CH_SPI);
+ spi_dma_ch);
+ dma_disable_irq(spi_dma_ch);
return IRQ_HANDLED;
}
@@ -726,19 +735,19 @@ static void pump_transfers(unsigned long data)
if (drv_data->cur_chip->enable_dma && drv_data->len > 6) {
write_STAT(BIT_STAT_CLR);
- disable_dma(CH_SPI);
- clear_dma_irqstat(CH_SPI);
+ disable_dma(spi_dma_ch);
+ clear_dma_irqstat(spi_dma_ch);
bfin_spi_disable(drv_data);
/* config dma channel */
dev_dbg(&drv_data->pdev->dev, "doing dma transfer\n");
if (width == CFG_SPI_WORDSIZE16) {
- set_dma_x_count(CH_SPI, drv_data->len);
- set_dma_x_modify(CH_SPI, 2);
+ set_dma_x_count(spi_dma_ch, drv_data->len);
+ set_dma_x_modify(spi_dma_ch, 2);
dma_width = WDSIZE_16;
} else {
- set_dma_x_count(CH_SPI, drv_data->len);
- set_dma_x_modify(CH_SPI, 1);
+ set_dma_x_count(spi_dma_ch, drv_data->len);
+ set_dma_x_modify(spi_dma_ch, 1);
dma_width = WDSIZE_8;
}
@@ -753,9 +762,10 @@ static void pump_transfers(unsigned long data)
/* no irq in autobuffer mode */
dma_config =
(DMAFLOW_AUTO | RESTART | dma_width | DI_EN);
- set_dma_config(CH_SPI, dma_config);
- set_dma_start_addr(CH_SPI, (unsigned long)drv_data->tx);
- enable_dma(CH_SPI);
+ set_dma_config(spi_dma_ch, dma_config);
+ set_dma_start_addr(spi_dma_ch,
+ (unsign
[PATCH 05/10] Blackfin SPI driver: prevent people from setting bits in ctl_reg
From: Mike Frysinger <[EMAIL PROTECTED]>
Prevent people from setting bits in ctl_reg that the SPI
framework already handles, hopefully we can one day drop
ctl_reg completely
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 7093065..1a83656 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -996,6 +996,16 @@ static int setup(struct spi_device *spi)
/* chip_info isn't always needed */
if (chip_info) {
+ /* Make sure people stop trying to set fields via ctl_reg when
they
+* should actually be using common SPI framework. Currently we
let
+* through: WOM EMISO PSSE GM SZ TIMOD. Not sure if a user
actually
+* needs/uses any of these, but let's assume (for now) they do.
+*/
+ if (chip_info->ctl_reg & (SPE | MSTR | CPOL | CPHA | LSBF |
SIZE)) {
+ dev_err(&spi->dev, "do not set bits in ctl_reg that the
SPI framework provides\n");
+ return -EINVAL;
+ }
+
chip->enable_dma = chip_info->enable_dma != 0
&& drv_data->master_info->enable_dma;
chip->ctl_reg = chip_info->ctl_reg;
--
1.5.3.4
-
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 04/10] Blackfin SPI driver: Blackfin SPI driver does not respect the per-transfer cs_change field
Add cs_active/cs_deactive functions and try to catch the cs_change flag.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 76 -
1 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 2f46283..7093065 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -115,6 +115,7 @@ struct driver_data {
size_t rx_map_len;
size_t tx_map_len;
u8 n_bytes;
+ int cs_change;
void (*write) (struct driver_data *);
void (*read) (struct driver_data *);
void (*duplex) (struct driver_data *);
@@ -179,6 +180,26 @@ static int flush(struct driver_data *drv_data)
return limit;
}
+/* Chip select operation functions for cs_change flag */
+static void cs_active(struct chip_data *chip)
+{
+ u16 flag = read_FLAG();
+
+ flag |= chip->flag;
+ flag &= ~(chip->flag << 8);
+
+ write_FLAG(flag);
+}
+
+static void cs_deactive(struct chip_data *chip)
+{
+ u16 flag = read_FLAG();
+
+ flag |= (chip->flag << 8);
+
+ write_FLAG(flag);
+}
+
#define MAX_SPI0_SSEL 7
/* stop controller and re-config current chip*/
@@ -198,7 +219,7 @@ static int restore_state(struct driver_data *drv_data)
/* Load the registers */
write_CTRL(chip->ctl_reg);
write_BAUD(chip->baud);
- write_FLAG(chip->flag);
+ cs_active(chip);
if (!chip->chip_select_requested) {
int i = chip->chip_select_num;
@@ -273,20 +294,20 @@ static void u8_cs_chg_writer(struct driver_data *drv_data)
struct chip_data *chip = drv_data->cur_chip;
while (drv_data->tx < drv_data->tx_end) {
- write_FLAG(chip->flag);
+ cs_active(chip);
write_TDBR(*(u8 *) (drv_data->tx));
while (read_STAT() & BIT_STAT_TXS)
continue;
while (!(read_STAT() & BIT_STAT_SPIF))
continue;
- write_FLAG(0xFF00 | chip->flag);
+ cs_deactive(chip);
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
++drv_data->tx;
}
- write_FLAG(0xFF00);
+ cs_deactive(chip);
}
@@ -318,7 +339,7 @@ static void u8_cs_chg_reader(struct driver_data *drv_data)
struct chip_data *chip = drv_data->cur_chip;
while (drv_data->rx < drv_data->rx_end) {
- write_FLAG(chip->flag);
+ cs_active(chip);
read_RDBR();/* kick off */
while (!(read_STAT() & BIT_STAT_RXS))
@@ -326,13 +347,13 @@ static void u8_cs_chg_reader(struct driver_data *drv_data)
while (!(read_STAT() & BIT_STAT_SPIF))
continue;
*(u8 *) (drv_data->rx) = read_SHAW();
- write_FLAG(0xFF00 | chip->flag);
+ cs_deactive(chip);
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
++drv_data->rx;
}
- write_FLAG(0xFF00);
+ cs_deactive(chip);
}
@@ -356,7 +377,7 @@ static void u8_cs_chg_duplex(struct driver_data *drv_data)
struct chip_data *chip = drv_data->cur_chip;
while (drv_data->rx < drv_data->rx_end) {
- write_FLAG(chip->flag);
+ cs_active(chip);
write_TDBR(*(u8 *) (drv_data->tx));
@@ -365,15 +386,14 @@ static void u8_cs_chg_duplex(struct driver_data *drv_data)
while (!(read_STAT() & BIT_STAT_RXS))
continue;
*(u8 *) (drv_data->rx) = read_RDBR();
- write_FLAG(0xFF00 | chip->flag);
+ cs_deactive(chip);
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
++drv_data->rx;
++drv_data->tx;
}
- write_FLAG(0xFF00);
-
+ cs_deactive(chip);
}
static void u16_writer(struct driver_data *drv_data)
@@ -398,20 +418,20 @@ static void u16_cs_chg_writer(struct driver_data
*drv_data)
struct chip_data *chip = drv_data->cur_chip;
while (drv_data->tx < drv_data->tx_end) {
- write_FLAG(chip->flag);
+ cs_active(chip);
write_TDBR(*(u16 *) (drv_data->tx));
while ((read_STAT() & BIT_STAT_TXS))
continue;
while (!(read_STAT() & BIT_STAT_SPIF))
continue;
- write_FLAG(0xFF00 | chip->flag);
+ cs_deactive(chip);
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
drv_data->tx += 2;
}
- write_FLAG(0xFF00);
+ cs_deactive(chip);
}
static void u16_reader(struct driver_data *drv_data)
@@ -438,7 +458,7 @@ static void u16_cs_ch
[PATCH 01/10] Blackfin SPI driver: Initial supporting BF54x in SPI driver
- support BF54x SPI0
- clean up some code
- will support multiports in the future
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 130 +++
include/asm-blackfin/mach-bf548/defBF54x_base.h | 17 +++
2 files changed, 80 insertions(+), 67 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index f540ed7..2992ada 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -1,17 +1,20 @@
/*
- * File: drivers/spi/bfin5xx_spi.c
- * Based on: N/A
- * Author: Luke Yang (Analog Devices Inc.)
+ * File: drivers/spi/bfin5xx_spi.c
+ * Maintainer:
+ * Bryan Wu <[EMAIL PROTECTED]>
+ * Original Author:
+ * Luke Yang (Analog Devices Inc.)
*
- * Created: March. 10th 2006
- * Description: SPI controller driver for Blackfin 5xx
- * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ * Created:March. 10th 2006
+ * Description:SPI controller driver for Blackfin BF5xx
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
*
* Modified:
* March 10, 2006 bfin5xx_spi.c Created. (Luke Yang)
* August 7, 2006 added full duplex mode (Axel Weiss & Luke Yang)
+ * July 17, 2007 add support for BF54x SPI0 controller (Bryan Wu)
*
- * Copyright 2004-2006 Analog Devices Inc.
+ * Copyright 2004-2007 Analog Devices Inc.
*
* This program is free software ; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -31,28 +34,27 @@
#include
#include
+#include
#include
+#include
#include
+#include
#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
-#include
-#include
#include
-
+#include
#include
-MODULE_AUTHOR("Luke Yang");
-MODULE_DESCRIPTION("Blackfin 5xx SPI Contoller");
+MODULE_AUTHOR("Bryan Wu, Luke Yang");
+MODULE_DESCRIPTION("Blackfin BF5xx SPI Contoller Driver");
MODULE_LICENSE("GPL");
+#define DRV_NAME "bfin-spi-master"
#define IS_DMA_ALIGNED(x) (((u32)(x)&0x07)==0)
#define DEFINE_SPI_REG(reg, off) \
@@ -125,6 +127,7 @@ struct chip_data {
u16 flag;
u8 chip_select_num;
+ u8 chip_select_requested;
u8 n_bytes;
u8 width; /* 0 or 1 */
u8 enable_dma;
@@ -189,53 +192,37 @@ static void restore_state(struct driver_data *drv_data)
bfin_spi_disable(drv_data);
dev_dbg(&drv_data->pdev->dev, "restoring spi ctl state\n");
-#if defined(CONFIG_BF534) || defined(CONFIG_BF536) || defined(CONFIG_BF537)
- dev_dbg(&drv_data->pdev->dev,
- "chip select number is %d\n", chip->chip_select_num);
-
- switch (chip->chip_select_num) {
- case 1:
- bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3c00);
- SSYNC();
- break;
-
- case 2:
- case 3:
- bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PJSE_SPI);
- SSYNC();
- bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3800);
- SSYNC();
- break;
-
- case 4:
- bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PFS4E_SPI);
- SSYNC();
- bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3840);
- SSYNC();
- break;
+ if (!chip->chip_select_requested) {
- case 5:
- bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PFS5E_SPI);
- SSYNC();
- bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3820);
- SSYNC();
- break;
+ dev_dbg(&drv_data->pdev->dev,
+ "chip select number is %d\n", chip->chip_select_num);
- case 6:
- bfin_write_PORT_MUX(bfin_read_PORT_MUX() | PFS6E_SPI);
- SSYNC();
- bfin_write_PORTF_FER(bfin_read_PORTF_FER() | 0x3810);
- SSYNC();
- break;
+ switch (chip->chip_select_num) {
+ case 1:
+ peripheral_request(P_SPI0_SSEL1, DRV_NAME);
+ break;
+ case 2:
+ peripheral_request(P_SPI0_SSEL2, DRV_NAME);
+ break;
+ case 3:
+ peripheral_request(P_SPI0_SSEL3, DRV_NAME);
+ break;
+ case 4:
+ peripheral_request(P_SPI0_SSEL4, DRV_NAME);
+ break;
+ case 5:
+ peripheral_request(P_SPI0_SSEL5, DRV_NAME);
+ break;
+ case 6:
+ peripheral_request(P_SPI0_SSEL6, DRV_NAME);
+ break;
+ case 7:
+ peripheral_request(P_SPI0_SSEL7, DRV_NAME);
+ break;
+ }
- case 7:
-
[PATCH 03/10] Blackfin SPI driver: add error handing
- add error handling in SPI bus driver with selecting clients
- use proper defines to access Blackfin MMRs
- remove useless SSYNCs
Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/spi/spi_bfin5xx.c | 107 +++--
1 files changed, 45 insertions(+), 62 deletions(-)
diff --git a/drivers/spi/spi_bfin5xx.c b/drivers/spi/spi_bfin5xx.c
index 8041b89..2f46283 100644
--- a/drivers/spi/spi_bfin5xx.c
+++ b/drivers/spi/spi_bfin5xx.c
@@ -59,10 +59,9 @@ MODULE_LICENSE("GPL");
#define DEFINE_SPI_REG(reg, off) \
static inline u16 read_##reg(void) \
-{ return *(volatile unsigned short*)(SPI0_REGBASE + off); } \
+ { return bfin_read16(SPI0_REGBASE + off); } \
static inline void write_##reg(u16 v) \
-{*(volatile unsigned short*)(SPI0_REGBASE + off) = v;\
- SSYNC();}
+ {bfin_write16(SPI0_REGBASE + off, v); }
DEFINE_SPI_REG(CTRL, 0x00)
DEFINE_SPI_REG(FLAG, 0x04)
@@ -145,7 +144,6 @@ static void bfin_spi_enable(struct driver_data *drv_data)
cr = read_CTRL();
write_CTRL(cr | BIT_CTL_ENABLE);
- SSYNC();
}
static void bfin_spi_disable(struct driver_data *drv_data)
@@ -154,7 +152,6 @@ static void bfin_spi_disable(struct driver_data *drv_data)
cr = read_CTRL();
write_CTRL(cr & (~BIT_CTL_ENABLE));
- SSYNC();
}
/* Caculate the SPI_BAUD register value based on input HZ */
@@ -182,52 +179,44 @@ static int flush(struct driver_data *drv_data)
return limit;
}
+#define MAX_SPI0_SSEL 7
+
/* stop controller and re-config current chip*/
-static void restore_state(struct driver_data *drv_data)
+static int restore_state(struct driver_data *drv_data)
{
struct chip_data *chip = drv_data->cur_chip;
+ int ret = 0;
+ u16 ssel[MAX_SPI0_SSEL] = {P_SPI0_SSEL1, P_SPI0_SSEL2, P_SPI0_SSEL3,
+ P_SPI0_SSEL4, P_SPI0_SSEL5,
+ P_SPI0_SSEL6, P_SPI0_SSEL7,};
/* Clear status and disable clock */
write_STAT(BIT_STAT_CLR);
bfin_spi_disable(drv_data);
dev_dbg(&drv_data->pdev->dev, "restoring spi ctl state\n");
+ /* Load the registers */
+ write_CTRL(chip->ctl_reg);
+ write_BAUD(chip->baud);
+ write_FLAG(chip->flag);
+
if (!chip->chip_select_requested) {
+ int i = chip->chip_select_num;
- dev_dbg(&drv_data->pdev->dev,
- "chip select number is %d\n", chip->chip_select_num);
-
- switch (chip->chip_select_num) {
- case 1:
- peripheral_request(P_SPI0_SSEL1, DRV_NAME);
- break;
- case 2:
- peripheral_request(P_SPI0_SSEL2, DRV_NAME);
- break;
- case 3:
- peripheral_request(P_SPI0_SSEL3, DRV_NAME);
- break;
- case 4:
- peripheral_request(P_SPI0_SSEL4, DRV_NAME);
- break;
- case 5:
- peripheral_request(P_SPI0_SSEL5, DRV_NAME);
- break;
- case 6:
- peripheral_request(P_SPI0_SSEL6, DRV_NAME);
- break;
- case 7:
- peripheral_request(P_SPI0_SSEL7, DRV_NAME);
- break;
- }
+ dev_dbg(&drv_data->pdev->dev, "chip select number is %d\n", i);
+
+ if ((i > 0) && (i <= MAX_SPI0_SSEL))
+ ret = peripheral_request(ssel[i-1], DRV_NAME);
chip->chip_select_requested = 1;
}
- /* Load the registers */
- write_CTRL(chip->ctl_reg);
- write_BAUD(chip->baud);
- write_FLAG(chip->flag);
+ if (ret)
+ dev_dbg(&drv_data->pdev->dev,
+ ": request chip select number %d failed\n",
+ chip->chip_select_num);
+
+ return ret;
}
/* used to kick off transfer in rx mode */
@@ -285,7 +274,6 @@ static void u8_cs_chg_writer(struct driver_data *drv_data)
while (drv_data->tx < drv_data->tx_end) {
write_FLAG(chip->flag);
- SSYNC();
write_TDBR(*(u8 *) (drv_data->tx));
while (read_STAT() & BIT_STAT_TXS)
@@ -293,13 +281,13 @@ static void u8_cs_chg_writer(struct driver_data *drv_data)
while (!(read_STAT() & BIT_STAT_SPIF))
continue;
write_FLAG(0xFF00 | chip->flag);
- SSYNC();
+
if (chip->cs_chg_udelay)
udelay(chip->cs_chg_udelay);
++drv_data->tx;
}
write_FLAG(0xFF00);
- SSYNC();
+
}
static void u8_reader(struct driver_data *drv_data)
@@ -331,7 +319,6 @@ static void u8_cs_chg_
[PATCH 00/10] Blackfin SPI driver updates for 2.6.24
- add BF54x support - add multi SPI ports support - fixup some bugs - 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: 2.6.23 spinlock hang in kswapd under heavy disk write loads
On Friday 12 October 2007 02:23, Mr. Berkley Shands wrote: > With DEBUG_SLAB on, I can run only a very short time under 2.6.23 > before a kernel panic. > > [ 626.028180] eth0: too many iterations (6) in nv_nic_irq. > [ 626.167583] eth0: too many iterations (6) in nv_nic_irq. > [ 626.206729] eth0: too many iterations (6) in nv_nic_irq. > [ 626.400171] eth0: too many iterations (6) in nv_nic_irq. > [ 626.446374] eth0: too many iterations (6) in nv_nic_irq. > > followed by the crash at > forcedeth:nv_nic_irq_optimized+0x89 > handle_IRQ_event+0x25 > handle_edge_IRQ+0xe3 > do_IRQ OK, thanks. Probably we should try to fix this problem before attempting the more elusive looking corruption. CC'ed forcedeth maintainer and netdev. Can you reiterate what your hardware is (including lspci)? - 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 1/9] Blackfin SPI driver: use new GPIO API and add error handling
On Thu, 2007-10-11 at 14:46 -0700, David Brownell wrote:
> On Thursday 11 October 2007, Bryan Wu wrote:
> > @@ -1182,12 +1198,9 @@ static int __init bfin5xx_spi_probe(struct
> > platform_device *pdev)
> > return -ENOMEM;
> > }
> >
> > - if (peripheral_request(P_SPI0_SCK, DRV_NAME) ||
> > -peripheral_request(P_SPI0_MISO, DRV_NAME) ||
> > -peripheral_request(P_SPI0_MOSI, DRV_NAME) ) {
> > -
> > + if (setup_pin_mux(1)) {
> > dev_err(&pdev->dev, ": Requesting Peripherals failed\n");
> > - goto out_error_queue_alloc;
> > + goto out_error;
> > }
> >
> > drv_data = spi_master_get_devdata(master);
>
>
> This doesn't apply against 2.6.23 ... ?
Oops, I missed the first patch in this patch series.
It will be sent as soon as possible.
Thanks a lot
-Bryan
-
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: [GIT PULL] please pull infiniband.git for-linus
On Thu, 11 Oct 2007, David Miller wrote: > > Even if you're confident there won't be merge issues, could you just > wait for the net-2.6 stuff to go in first? I pulled the net stuff first, and merged the IB stuff afterwards. No conflicts in IB, but there *were* conflicts with the networking pull for other reasons. That horrid, horrid mess that is called include/linux/mod_devicetable.h and scripts/mod/file2alias.c must go at some point. The thing is unmaintainable. Different maintainers add their own structures to both, and functions to both, and it's just messy. That's not how maintainable and modularized code should be written. Now it broke on sdio vs ssb, but there was actually a conflict earlier with the Kbuild merge (which I aborted for other reasons), so this file really is starting to be a problem. The merge was fairly straightforward and stupid - it's not like the code added is *complicated*, but all those small functions and structrues are set up to be a maze of very similar lines, so the merge is actually much worse than it should be - because there is inherent similarity, some lines are automatically auto-merged, making the result just harder to visualize. So I merged it all, and I don't expect any problems, but I'm hoping somebody is thinking about that mod_devicetable.h/file2alias.c mess. I'm not entirely sure who to blame on that thing. I'm adding Greg to the Cc, on the assumption that blaming him is usually the right thing to do ;) Oh, and obviously, the NAPI changes may well have resulted in a merge that had no actual *conflicts* in it, but whether the end result works or not (and whether any IB drivers need updating due to the NAPI changes), I cannot tell. I've pushed out my tree, so people who are competent or just morbidly curious should start looking at it: it's got the following things merged now: - x86 merge - mmc - v4l-dvb - blackfin - avr32 - block layer updates - Jeff's dmi-const - Purdie's blacklight and led trees - ide - mips - net - infiniband and it all builds for me, but hey, I don't use half of it. Oh, btw, one final note: because of just a *ton* of renames, if you actually want git to do rename-detection for you and do automatic merges across those x86 renames, you should likely add [diff] renamelimit=0 to your .gitconfig file. Otherwise, the rename detection heuristics may end up saying "I'm not going to even bother finding renames in that mess". (That final note really shouldn't affect any normal users, but I thought I'd mention it in case somebody is going to want git to merge things across the x86 merge, and gets stuck not realizing why some versions of git might not notice the renames). Linus - 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 1/2] bug.h: Introduce HAVE_ARCH_WARN
On Thu, Oct 11, 2007 at 12:12:11PM -0500, Olof Johansson wrote: > HAVE_ARCH_WARN is used to determine if an arch already has a __WARN() > macro, or if a generic one is needed. > > With this, some of the arch-specific WARN_ON() implementations can be > made common instead (see follow-up patch for powerpc). > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > sh bits are fine. Acked-by: Paul Mundt <[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: [PATCH] Reserve N process to root
Please don't trim CC lists On Oct 11, 2007, at 17:02:37, Al Boldi wrote: David Newall wrote: [EMAIL PROTECTED] wrote: What David meant was that "root will always have a slot" doesn't *actually* help unless you *also* have a way to actually *spawn* such a process. In order to do the ps, kill, and so on that you need to recover, you need to already have either a root shell available, or a way to *get* a root shell that doesn't rely on a non-root process (so /bin/su doesn't help here). That's right, although it's worse than that. You need to have a process with CAP_SYS_ADMIN. If root processes normally have that capability then the reserved slots may well disappear before you notice a problem. If root processes normally don't have it, then you need to guarantee that one is already running. I once posted a patch to handle this DoS, but, as usual, it wasn't accepted. Go figure... This isn't really necessary any more with the new CFS scheduler. If you want to prevent excess memory usage then you limit memory usage, not process count, so just set the system max process count to something absurdly high and leave the user counts down at the maximum a user might run. Then as long as the sum of the user processes is less than the max number of processes (which you just set absurdly high or unlimited), you may still log in. With the per-user scheduling enabled CFS allows you to run an optimistically-real-time game as one user and several thousand busy-loops as another user and get almost picture perfect 50% CPU distribution between the users. To me that seems a much better DoS-prevention system than limits which don't scale based on how many people are requesting resources. Cheers, Kyle Moffett - 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/2] [V3] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
allows for more flexibility in the note type for the state of 'extended
floating point' implementations in coredumps. New note types can now be
added with an appropriate #define.
This does #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all
current users so there's are no change in behaviour.
This will let us use different note types on powerpc for the
Altivec/VMX state that some PowerPC cpus have (G4, PPC970, POWER6) and
for the SPE (signal processing extension) state that some embedded
PowerPC cpus from Freescale have.
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
---
arch/ia64/ia32/elfcore32.h |1 +
arch/x86_64/ia32/ia32_binfmt.c |1 +
fs/binfmt_elf.c|8
fs/binfmt_elf_fdpic.c |8
include/asm-i386/elf.h |1 +
5 files changed, 11 insertions(+), 8 deletions(-)
Index: linux/arch/ia64/ia32/elfcore32.h
===
--- linux.orig/arch/ia64/ia32/elfcore32.h
+++ linux/arch/ia64/ia32/elfcore32.h
@@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
}
#define ELF_CORE_COPY_XFPREGS 1
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
static inline int
elf_core_copy_task_xfpregs(struct task_struct *tsk, elf_fpxregset_t *xfpu)
{
Index: linux/arch/x86_64/ia32/ia32_binfmt.c
===
--- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
+++ linux/arch/x86_64/ia32/ia32_binfmt.c
@@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
}
#define ELF_CORE_COPY_XFPREGS 1
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
static inline int
elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t *xfpu)
{
Index: linux/fs/binfmt_elf.c
===
--- linux.orig/fs/binfmt_elf.c
+++ linux/fs/binfmt_elf.c
@@ -1411,7 +1411,7 @@ struct elf_thread_status
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
- elf_fpxregset_t xfpu; /* NT_PRXFPREG */
+ elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
#endif
struct memelfnote notes[3];
int num_notes;
@@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
- fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
- &t->xfpu);
+ fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
+ sizeof(t->xfpu), &t->xfpu);
t->num_notes++;
sz += notesize(&t->notes[2]);
}
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, str
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
Index: linux/fs/binfmt_elf_fdpic.c
===
--- linux.orig/fs/binfmt_elf_fdpic.c
+++ linux/fs/binfmt_elf_fdpic.c
@@ -1417,7 +1417,7 @@ struct elf_thread_status
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
- elf_fpxregset_t xfpu; /* NT_PRXFPREG */
+ elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
#endif
struct memelfnote notes[3];
int num_notes;
@@ -1453,8 +1453,8 @@ static int elf_dump_thread_status(long s
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
- fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
- &t->xfpu);
+ fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
+ sizeof(t->xfpu), &t->xfpu);
t->num_notes++;
sz += notesize(&t->notes[2]);
}
@@ -1690,7 +1690,7 @@ static int elf_fdpic_core_dump(long sign
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
Index: linux/include/asm-i386/elf.h
===
--- linux.orig/include/asm-i386/elf.h
+++ linux/include/asm-i386/elf.h
@@ -129,6 +129,7 @@ extern int dump_task_extended_fpu (struc
#define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk, elf_regs)
#define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk, elf_fpregs)
#define ELF_CORE_COPY_XFPREGS(tsk, elf_xfpregs) dump_t
Re: [ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus
From: Roland Dreier <[EMAIL PROTECTED]> Date: Thu, 11 Oct 2007 19:21:06 -0700 > I'm not sure what you mean. During the 2.6.23 cycle I've been sending > any patches that potentially could conflict with the net-2.6 tree to > you and Jeff so that you can merge them upstream via your tree. Or do > you mean Jeff should become the maintainer of drivers/infiniband?? Not the maintainer, I'm just saying you should gateway your patches through him. - 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 1/2] [V2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
Sorry for the patch noise but please disregard this patch - a line is longer
than 80 characters and I'd hate to be brought up on that...
V3 will be the perfect version then :)
Thanks and apologies again!
Mark.
Mark Nelson wrote:
> Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
> allows for more flexibility in the note type for the state of 'extended
> floating point' implementations in coredumps. New note types can now be
> added with an appropriate #define.
>
> This does #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all
> current users so there's are no change in behaviour.
>
> This will let us use different note types on powerpc for the
> Altivec/VMX state that some PowerPC cpus have (G4, PPC970, POWER6) and
> for the SPE (signal processing extension) state that some embedded
> PowerPC cpus from Freescale have.
>
> Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
> ---
> arch/ia64/ia32/elfcore32.h |1 +
> arch/x86_64/ia32/ia32_binfmt.c |1 +
> fs/binfmt_elf.c|8
> fs/binfmt_elf_fdpic.c |6 +++---
> include/asm-i386/elf.h |1 +
> 5 files changed, 10 insertions(+), 7 deletions(-)
>
> Index: linux/arch/ia64/ia32/elfcore32.h
> ===
> --- linux.orig/arch/ia64/ia32/elfcore32.h
> +++ linux/arch/ia64/ia32/elfcore32.h
> @@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
> }
>
> #define ELF_CORE_COPY_XFPREGS 1
> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
> static inline int
> elf_core_copy_task_xfpregs(struct task_struct *tsk, elf_fpxregset_t *xfpu)
> {
> Index: linux/arch/x86_64/ia32/ia32_binfmt.c
> ===
> --- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
> +++ linux/arch/x86_64/ia32/ia32_binfmt.c
> @@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
> }
>
> #define ELF_CORE_COPY_XFPREGS 1
> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
> static inline int
> elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t *xfpu)
> {
> Index: linux/fs/binfmt_elf.c
> ===
> --- linux.orig/fs/binfmt_elf.c
> +++ linux/fs/binfmt_elf.c
> @@ -1411,7 +1411,7 @@ struct elf_thread_status
> elf_fpregset_t fpu; /* NT_PRFPREG */
> struct task_struct *thread;
> #ifdef ELF_CORE_COPY_XFPREGS
> - elf_fpxregset_t xfpu; /* NT_PRXFPREG */
> + elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
> #endif
> struct memelfnote notes[3];
> int num_notes;
> @@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
>
> #ifdef ELF_CORE_COPY_XFPREGS
> if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
> - fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
> - &t->xfpu);
> + fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
> + sizeof(t->xfpu), &t->xfpu);
> t->num_notes++;
> sz += notesize(&t->notes[2]);
> }
> @@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, str
> #ifdef ELF_CORE_COPY_XFPREGS
> if (elf_core_copy_task_xfpregs(current, xfpu))
> fill_note(notes + numnote++,
> - "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
> + "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
> #endif
>
> fs = get_fs();
> Index: linux/fs/binfmt_elf_fdpic.c
> ===
> --- linux.orig/fs/binfmt_elf_fdpic.c
> +++ linux/fs/binfmt_elf_fdpic.c
> @@ -1417,7 +1417,7 @@ struct elf_thread_status
> elf_fpregset_t fpu; /* NT_PRFPREG */
> struct task_struct *thread;
> #ifdef ELF_CORE_COPY_XFPREGS
> - elf_fpxregset_t xfpu; /* NT_PRXFPREG */
> + elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
> #endif
> struct memelfnote notes[3];
> int num_notes;
> @@ -1453,7 +1453,7 @@ static int elf_dump_thread_status(long s
>
> #ifdef ELF_CORE_COPY_XFPREGS
> if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
> - fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
> + fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
> sizeof(t->xfpu),
the line above is the offender...
> &t->xfpu);
> t->num_notes++;
> sz += notesize(&t->notes[2]);
> @@ -1690,7 +1690,7 @@ static int elf_fdpic_core_dump(long sign
> #ifdef ELF_CORE_COPY_XFPREGS
> if (elf_core_copy_task_xfpregs(current, xfpu))
> fill_note(notes + numnote++,
> - "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
> + "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
> #endif
>
> fs = get_fs();
> Index: linux/include/asm-i386/elf.h
>
Re: [PATCH 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
On Thu, Oct 11, 2007 at 10:04:19PM -0400, Kyle McMartin wrote: > On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote: > > Olof Johansson writes: > > > > > Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about > > > 4K text on a ppc64_defconfig. The main reason seems to be that prepping > > > the arguments to the conditional trap instructions is more work than > > > just doing a compare and branch. > > > > It might be more instructions but it takes fewer cycles, I would > > expect. Do you have the actual instruction sequences to compare? > > > > I really hope WARN_ON/BUG_ON aren't hotpaths on powerpc. ;-) Not the taken branch of them, no. :) But making it past them as fast as possible when they're not tripping is always good. -Olof - 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/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
> > 4K text on a ppc64_defconfig. The main reason seems to be that prepping
> > the arguments to the conditional trap instructions is more work than
> > just doing a compare and branch.
>
> It might be more instructions but it takes fewer cycles, I would
> expect. Do you have the actual instruction sequences to compare?
Sure. Just looking at a couple of cases:
On range comparisons such as (a < CONST):
* without this patch, you end up with a comparison, then a cr-to-cr op +
mfcr + mask operation + tdnei.
* with the patch, you get a comparison and a conditional branch with
twi out of line.
On multiple comparisons like WARN_ON( a || b), it seems that there's an
added li to make the tdnei always hit for the first case. There it uses
a regular conditional branch, so no real difference in generated code
besides that.
Code examples. This was with a ppc64_defconfig, so CONFIG_POWER4_ONLY
wasn't enabled. It uses mfocrf when it is, which is alot cheaper. Still,
the rest of the code sequence is the same:
void irq_free_virt(unsigned int virq, unsigned int count)
{
unsigned long flags;
unsigned int i;
WARN_ON (virq < NUM_ISA_INTERRUPTS);
WARN_ON (count == 0 || (virq + count) > irq_virq_count);
spin_lock_irqsave(&irq_big_lock, flags);
Without the patch:
c000b33c <.irq_free_virt>:
c000b33c: 7c 08 02 a6 mflrr0
c000b340: 2b 83 00 0f cmplwi cr7,r3,15
c000b344: fb c1 ff f0 std r30,-16(r1)
c000b348: fb e1 ff f8 std r31,-8(r1)
c000b34c: 7c 9e 23 78 mr r30,r4
c000b350: 7c 7f 1b 78 mr r31,r3
c000b354: 4f dd e8 42 crnot 4*cr7+eq,4*cr7+gt
c000b358: f8 01 00 10 std r0,16(r1)
c000b35c: f8 21 ff 81 stdur1,-128(r1)
c000b360: 7c 00 00 26 mfcrr0
c000b364: 54 00 ff fe rlwinm r0,r0,31,31,31
c000b368: 0b 00 00 00 tdnei r0,0
c000b36c: 2f a4 00 00 cmpdi cr7,r4,0
c000b370: 38 00 00 01 li r0,1
c000b374: 41 9e 00 1c beq cr7,c000b390
<.irq_free_virt+0x54>
c000b378: e9 22 80 d8 ld r9,-32552(r2)
c000b37c: 7d 63 22 14 add r11,r3,r4
c000b380: 80 09 00 00 lwz r0,0(r9)
c000b384: 7f 8b 00 40 cmplw cr7,r11,r0
c000b388: 7c 00 00 26 mfcrr0
c000b38c: 54 00 f7 fe rlwinm r0,r0,30,31,31
c000b390: 0b 00 00 00 tdnei r0,0
c000b394: e8 62 80 f8 ld r3,-32520(r2)
c000b398: 48 54 4c b1 bl c0550048
<._spin_lock_irqsave>
c000b39c: 60 00 00 00 nop
With the patch:
c000b0b0 <.irq_free_virt>:
c000b0b0: 7c 08 02 a6 mflrr0
c000b0b4: 2b 83 00 0f cmplwi cr7,r3,15
c000b0b8: fb c1 ff f0 std r30,-16(r1)
c000b0bc: fb e1 ff f8 std r31,-8(r1)
c000b0c0: 7c 9e 23 78 mr r30,r4
c000b0c4: 7c 7f 1b 78 mr r31,r3
c000b0c8: f8 01 00 10 std r0,16(r1)
c000b0cc: f8 21 ff 81 stdur1,-128(r1)
c000b0d0: 41 bd 00 08 bgt cr7,c000b0d8
<.irq_free_virt+0x28>
c000b0d4: 0f e0 00 00 twi 31,r0,0
c000b0d8: 2f be 00 00 cmpdi cr7,r30,0
c000b0dc: 41 9e 00 18 beq cr7,c000b0f4
<.irq_free_virt+0x44>
c000b0e0: e9 22 80 d8 ld r9,-32552(r2)
c000b0e4: 7d 7f f2 14 add r11,r31,r30
c000b0e8: 80 09 00 00 lwz r0,0(r9)
c000b0ec: 7f 8b 00 40 cmplw cr7,r11,r0
c000b0f0: 40 bd 00 08 ble cr7,c000b0f8
<.irq_free_virt+0x48>
c000b0f4: 0f e0 00 00 twi 31,r0,0
c000b0f8: e8 62 80 f8 ld r3,-32520(r2)
c000b0fc: 48 54 3f 75 bl c054f070
<._spin_lock_irqsave>
c000b100: 60 00 00 00 nop
-
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 002/002] Create/delete kmem_cache_node for SLUB on memory online callback
This is to make kmem_cache_nodes of all SLUBs for new node when
memory-hotadd is called. This fixes panic due to access NULL pointer at
discard_slab() after memory hot-add.
If pages on the new node available, slub can use it before making
new kmem_cache_nodes. So, this callback should be called
BEFORE pages on the node are available.
When memory online is called, slab_mem_going_online_callback() is
called to make kmem_cache_node(). if it (or other callbacks) fails,
then slab_mem_offline_callback() is called for rollback.
In memory offline, slab_mem_going_offline_callback() is called to
shrink cache, then slab_mem_offline_callback() is called later.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
mm/slub.c | 117 ++
1 file changed, 117 insertions(+)
Index: current/mm/slub.c
===
--- current.orig/mm/slub.c 2007-10-11 20:31:37.0 +0900
+++ current/mm/slub.c 2007-10-11 21:58:10.0 +0900
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/*
* Lock order:
@@ -2711,6 +2712,120 @@ int kmem_cache_shrink(struct kmem_cache
}
EXPORT_SYMBOL(kmem_cache_shrink);
+#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
+static int slab_mem_going_offline_callback(void *arg)
+{
+ struct kmem_cache *s;
+ struct memory_notify *marg = arg;
+ int local_node, offline_node = marg->status_change_nid;
+
+ if (offline_node < 0)
+ /* node has memory yet. nothing to do. */
+ return 0;
+
+ down_read(&slub_lock);
+ list_for_each_entry(s, &slab_caches, list) {
+ local_node = page_to_nid(virt_to_page(s));
+ if (local_node == offline_node)
+ /* This slub is on the offline node. */
+ return -EBUSY;
+ }
+ up_read(&slub_lock);
+
+ kmem_cache_shrink_node(s, offline_node);
+
+ return 0;
+}
+
+static void slab_mem_offline_callback(void *arg)
+{
+ struct kmem_cache_node *n;
+ struct kmem_cache *s;
+ struct memory_notify *marg = arg;
+ int offline_node;
+
+ offline_node = marg->status_change_nid;
+
+ if (offline_node < 0)
+ /* node has memory yet. nothing to do. */
+ return;
+
+ down_read(&slub_lock);
+ list_for_each_entry(s, &slab_caches, list) {
+ n = get_node(s, offline_node);
+ if (n) {
+ /*
+* if n->nr_slabs > 0, offline_pages() must be fail,
+* because the node is used by slub yet.
+*/
+ BUG_ON(atomic_read(&n->nr_slabs));
+
+ s->node[offline_node] = NULL;
+ kmem_cache_free(kmalloc_caches, n);
+ }
+ }
+ up_read(&slub_lock);
+}
+
+static int slab_mem_going_online_callback(void *arg)
+{
+ struct kmem_cache_node *n;
+ struct kmem_cache *s;
+ struct memory_notify *marg = arg;
+ int nid = marg->status_change_nid;
+
+ /* If the node already has memory, then nothing is necessary. */
+ if (nid < 0)
+ return 0;
+
+ /*
+* New memory will be onlined on the node which has no memory so far.
+* New kmem_cache_node is necssary for it.
+*/
+ down_read(&slub_lock);
+ list_for_each_entry(s, &slab_caches, list) {
+ /*
+* XXX: The new node's memory can't be allocated yet,
+* kmem_cache_node will be allocated other node.
+*/
+ n = kmem_cache_alloc(kmalloc_caches, GFP_KERNEL);
+ if (!n)
+ return -ENOMEM;
+ init_kmem_cache_node(n);
+ s->node[nid] = n;
+ }
+ up_read(&slub_lock);
+
+ return 0;
+}
+
+static int slab_memory_callback(struct notifier_block *self,
+ unsigned long action, void *arg)
+{
+ int ret = 0;
+
+ switch (action) {
+ case MEM_GOING_ONLINE:
+ ret = slab_mem_going_online_callback(arg);
+ break;
+ case MEM_GOING_OFFLINE:
+ ret = slab_mem_going_offline_callback(arg);
+ break;
+ case MEM_OFFLINE:
+ case MEM_CANCEL_ONLINE:
+ slab_mem_offline_callback(arg);
+ break;
+ case MEM_ONLINE:
+ case MEM_CANCEL_OFFLINE:
+ break;
+ }
+
+ ret = notifier_from_errno(ret);
+ return ret;
+}
+
+#endif /* CONFIG_MEMORY_HOTPLUG */
+
/
* Basic setup of slabs
***/
@@ -2741,6 +2856,8 @@ void __init kmem_cache_init(void)
sizeof(struct kmem_cache_
Re: [PATCH] __do_softirq() loop cleanup
On Wed, Oct 10, 2007 at 02:16:19PM +0200, Johannes Weiner wrote: > Hi, > > This changes __do_softirq() to use a C looping construct instead of > simulating one by means of goto. > > Signed-off-by: Johannes Weiner <[EMAIL PROTECTED]> > I've read over the logic three times and it seems to keep with the original design. So unless I missed something ... Acked-by: Steven Rostedt <[EMAIL PROTECTED]> -- Steve - 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 001/002] extract kmem_cache_shrink
Make kmem_cache_shrink_node() for callback routine of memory hotplug
notifier. This is just extract a part of kmem_cache_shrink().
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
mm/slub.c | 111 ++
1 file changed, 61 insertions(+), 50 deletions(-)
Index: current/mm/slub.c
===
--- current.orig/mm/slub.c 2007-10-11 20:30:45.0 +0900
+++ current/mm/slub.c 2007-10-11 21:58:47.0 +0900
@@ -2626,6 +2626,56 @@ void kfree(const void *x)
}
EXPORT_SYMBOL(kfree);
+static inline void __kmem_cache_shrink_node(struct kmem_cache *s, int node,
+ struct list_head *slabs_by_inuse)
+{
+ struct kmem_cache_node *n;
+ int i;
+ struct page *page;
+ struct page *t;
+ unsigned long flags;
+
+ n = get_node(s, node);
+
+ if (!n->nr_partial)
+ return;
+
+ for (i = 0; i < s->objects; i++)
+ INIT_LIST_HEAD(slabs_by_inuse + i);
+
+ spin_lock_irqsave(&n->list_lock, flags);
+
+ /*
+* Build lists indexed by the items in use in each slab.
+*
+* Note that concurrent frees may occur while we hold the
+* list_lock. page->inuse here is the upper limit.
+*/
+ list_for_each_entry_safe(page, t, &n->partial, lru) {
+ if (!page->inuse && slab_trylock(page)) {
+ /*
+* Must hold slab lock here because slab_free
+* may have freed the last object and be
+* waiting to release the slab.
+*/
+ list_del(&page->lru);
+ n->nr_partial--;
+ slab_unlock(page);
+ discard_slab(s, page);
+ } else
+ list_move(&page->lru, slabs_by_inuse + page->inuse);
+ }
+
+ /*
+* Rebuild the partial list with the slabs filled up most
+* first and the least used slabs at the end.
+*/
+ for (i = s->objects - 1; i >= 0; i--)
+ list_splice(slabs_by_inuse + i, n->partial.prev);
+
+ spin_unlock_irqrestore(&n->list_lock, flags);
+}
+
/*
* kmem_cache_shrink removes empty slabs from the partial lists and sorts
* the remaining slabs by the number of items in use. The slabs with the
@@ -2636,68 +2686,29 @@ EXPORT_SYMBOL(kfree);
* being allocated from last increasing the chance that the last objects
* are freed in them.
*/
-int kmem_cache_shrink(struct kmem_cache *s)
+int kmem_cache_shrink_node(struct kmem_cache *s, int node)
{
- int node;
- int i;
- struct kmem_cache_node *n;
- struct page *page;
- struct page *t;
struct list_head *slabs_by_inuse =
kmalloc(sizeof(struct list_head) * s->objects, GFP_KERNEL);
- unsigned long flags;
if (!slabs_by_inuse)
return -ENOMEM;
flush_all(s);
- for_each_node_state(node, N_NORMAL_MEMORY) {
- n = get_node(s, node);
-
- if (!n->nr_partial)
- continue;
-
- for (i = 0; i < s->objects; i++)
- INIT_LIST_HEAD(slabs_by_inuse + i);
-
- spin_lock_irqsave(&n->list_lock, flags);
-
- /*
-* Build lists indexed by the items in use in each slab.
-*
-* Note that concurrent frees may occur while we hold the
-* list_lock. page->inuse here is the upper limit.
-*/
- list_for_each_entry_safe(page, t, &n->partial, lru) {
- if (!page->inuse && slab_trylock(page)) {
- /*
-* Must hold slab lock here because slab_free
-* may have freed the last object and be
-* waiting to release the slab.
-*/
- list_del(&page->lru);
- n->nr_partial--;
- slab_unlock(page);
- discard_slab(s, page);
- } else {
- list_move(&page->lru,
- slabs_by_inuse + page->inuse);
- }
- }
-
- /*
-* Rebuild the partial list with the slabs filled up most
-* first and the least used slabs at the end.
-*/
- for (i = s->objects - 1; i >= 0; i--)
- list_splice(slabs_by_inuse + i, n->partial.prev);
-
- spin_unlock_irqrestore(&n->list_lock, flags);
- }
+ if (node >= 0)
+ __kmem_cache_shrink_node(s, node, slabs_by_inuse);
[Patch 000/002] Make kmem_cache_node for SLUB on memory online to avoid panic(take 2)
This patch set is to fix panic due to access NULL pointer of SLUB. When new memory is hot-added on the new node (or memory less node), kmem_cache_node for the new node is not prepared, and panic occurs by it. So, kmem_cache_node should be created for the node before new memory is available on the node. Incidentally, it is freed on memory offline if it becomes not necessary. This is the first user of the callback of memory notifier, and requires its rearrange patch set. This patch set is for 2.6.23-rc8-mm2. I tested this patch on my ia64 box. Please apply. Bye. -- 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/
[Patch 002/002] rearrange patch for notifier of memory hotplug
Current memory notifier has some defects yet. (Fortunately, nothing uses it.)
This patch is to fix and rearrange for them.
- Add information of start_pfn, nr_pages, and node id if node status is
changes from/to memoryless node for callback functions.
Callbacks can't do anything without those information.
- Add notification going-online status.
It is necessary for creating per node structure before the node's
pages are available.
- Move GOING_OFFLINE status notification after page isolation.
It is good place for return memory like cache for callback,
because returned page is not used again.
- Make CANCEL events for rollingback when error occurs.
- Delete MEM_MAPPING_INVALID notification. It will be not used.
- Fix compile error of (un)register_memory_notifier().
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
drivers/base/memory.c |9 +
include/linux/memory.h | 27 +++
mm/memory_hotplug.c| 48 +---
3 files changed, 61 insertions(+), 23 deletions(-)
Index: current/drivers/base/memory.c
===
--- current.orig/drivers/base/memory.c 2007-10-11 14:33:02.0 +0900
+++ current/drivers/base/memory.c 2007-10-11 14:33:07.0 +0900
@@ -137,7 +137,7 @@ static ssize_t show_mem_state(struct sys
return len;
}
-static inline int memory_notify(unsigned long val, void *v)
+int memory_notify(unsigned long val, void *v)
{
return blocking_notifier_call_chain(&memory_chain, val, v);
}
@@ -183,7 +183,6 @@ memory_block_action(struct memory_block
break;
case MEM_OFFLINE:
mem->state = MEM_GOING_OFFLINE;
- memory_notify(MEM_GOING_OFFLINE, NULL);
start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
ret = remove_memory(start_paddr,
PAGES_PER_SECTION << PAGE_SHIFT);
@@ -191,7 +190,6 @@ memory_block_action(struct memory_block
mem->state = old_state;
break;
}
- memory_notify(MEM_MAPPING_INVALID, NULL);
break;
default:
printk(KERN_WARNING "%s(%p, %ld) unknown action: %ld\n",
@@ -199,11 +197,6 @@ memory_block_action(struct memory_block
WARN_ON(1);
ret = -EINVAL;
}
- /*
-* For now, only notify on successful memory operations
-*/
- if (!ret)
- memory_notify(action, NULL);
return ret;
}
Index: current/include/linux/memory.h
===
--- current.orig/include/linux/memory.h 2007-10-11 14:33:02.0 +0900
+++ current/include/linux/memory.h 2007-10-11 15:19:31.0 +0900
@@ -41,18 +41,15 @@ struct memory_block {
#defineMEM_ONLINE (1<<0) /* exposed to userspace */
#defineMEM_GOING_OFFLINE (1<<1) /* exposed to userspace */
#defineMEM_OFFLINE (1<<2) /* exposed to userspace */
+#defineMEM_GOING_ONLINE(1<<3)
+#defineMEM_CANCEL_ONLINE (1<<4)
+#defineMEM_CANCEL_OFFLINE (1<<5)
-/*
- * All of these states are currently kernel-internal for notifying
- * kernel components and architectures.
- *
- * For MEM_MAPPING_INVALID, all notifier chains with priority >0
- * are called before pfn_to_page() becomes invalid. The priority=0
- * entry is reserved for the function that actually makes
- * pfn_to_page() stop working. Any notifiers that want to be called
- * after that should have priority <0.
- */
-#defineMEM_MAPPING_INVALID (1<<3)
+struct memory_notify {
+ unsigned long start_pfn;
+ unsigned long nr_pages;
+ int status_change_nid;
+};
struct notifier_block;
struct mem_section;
@@ -69,12 +66,18 @@ static inline int register_memory_notifi
static inline void unregister_memory_notifier(struct notifier_block *nb)
{
}
+static inline int memory_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
+extern int register_memory_notifier(struct notifier_block *nb);
+extern void unregister_memory_notifier(struct notifier_block *nb);
extern int register_new_memory(struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
-
+extern int memory_notify(unsigned long val, void *v);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<= end_pfn);
/* at least, alignment against pageblock is necessary */
@@ -480,11 +502,27 @@ int offline_pages(unsigned long start_pf
we assume this for now. .*/
if (!test_pag
[Patch 001/002] Make description of memory hotplug notifier in document
Add description about event notification callback routine to the document.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
Documentation/memory-hotplug.txt | 56 ---
1 file changed, 53 insertions(+), 3 deletions(-)
Index: current/Documentation/memory-hotplug.txt
===
--- current.orig/Documentation/memory-hotplug.txt
+++ current/Documentation/memory-hotplug.txt
@@ -2,7 +2,8 @@
Memory Hotplug
==
-Last Updated: Jul 28 2007
+Created: Jul 28 2007
+Add description of notifier of memory hotplug Oct 11 2007
This document is about memory hotplug including how-to-use and current status.
Because Memory Hotplug is still under development, contents of this text will
@@ -24,7 +25,8 @@ be changed often.
6.1 Memory offline and ZONE_MOVABLE
6.2. How to offline memory
7. Physical memory remove
-8. Future Work List
+8. Memory hotplug event notifier
+9. Future Work List
Note(1): x86_64's has special implementation for memory hotplug.
This text does not describe it.
@@ -307,8 +309,68 @@ Need more implementation yet
- Notification completion of remove works by OS to firmware.
- Guard from remove if not yet.
+
+8. Memory hotplug event notifier
+
+Memory hotplug has event notifer. There are 6 types of notification.
+
+MEMORY_GOING_ONLINE
+ This is notified before memory online. If some structures must be prepared
+ for new memory, it should be done at this event's callback.
+ The new onlining memory can't be used yet.
+
+MEMORY_CANCEL_ONLINE
+ If memory online fails, this event is notified for rollback of setting at
+ MEMORY_GOING_ONLINE.
+ (Currently, this event is notified only the case which a callback routine
+ of MEMORY_GOING_ONLINE fails).
+
+MEMORY_ONLINE
+ This event is called when memory online is completed. The page allocator uses
+ new memory area before this notification. In other words, callback routine
+ use new memory area via page allocator.
+ The failures of callbacks of this notification will be ignored.
+
+MEMORY_GOING_OFFLINE
+ This is notified on halfway of memory offline. The offlining pages are
+ isolated. In other words, the page allocater doesn't allocate new pages from
+ offlining memory area at this time. If callback routine freed some pages,
+ they are not used by the page allocator.
+ This is good place for shrinking cache. (If possible, it is desirable to
+ migrate to other area.)
+
+MEMORY_CANCEL_OFFLINE
+ If memory offline fails, this event is notified for rollback against
+ MEMORY_GOING_OFFLINE. The page allocator will use target memory area after
+ this callback again.
+
+MEMORY_OFFLINE
+ This is notified after memory offline completed. The failures of callbacks
+ of this notification will be ignored. Callback routine can return structures
+ for offlined memory.
+ If the node which has offlined memory,
+
+A callback routine can be registered by
+ hotplug_memory_notifier(callback_func, priority).
+
+The second argument of callback function (action) is event types of above.
+The third argument is passed by pointer of struct memory_notify.
+
+struct memory_notify {
+ unsigned long start_pfn;
+ unsigned long nr_pages;
+ int status_change_nid;
+};
+start_pfn is start pfn of online/offline memory.
+nr_pages is # of pages of online/offline memory.
+status_change_nid is set node id when N_HIGH_MEMORY of nodemask is (will be)
+set/clear. It means a new(memoryless) node gets new memory by online and a
+node lose all memory. If this is -1, then nodemask status is not changed.
+If status_changed_nid >= 0, callback should create/discard structures for the
+node if necessary.
+
--
-8. Future Work
+9. Future Work
--
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
sysctl or new control file.
--
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: [ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus
> > This will get the batch of changes queued up for the 2.6.24 merge > > window (although I still have a few more things to merge later, once > > Dave Miller's networking tree has landed too): > > Roland are you absolutely sure this won't create merge conflicts with > my 8MB net-2.6 merge, inside of which there are many infiniband > driver changes? I'm not absolutely sure of anything but I have merged our two git trees quite a few times during the 2.6.23 cycle and I have not seen any conflicts. Unless you've added some more IB changes very recently I don't think there should be any problem. > I really wish you would submit your inifiniband work through normal > network driver channels, such as Jeff Garzik. Jeff has been syncing > on almost a daily basis with me so that I wouldn't have to worry about > changes coming out of left field and adding additional merge issues > for an already difficult merge. I'm not sure what you mean. During the 2.6.23 cycle I've been sending any patches that potentially could conflict with the net-2.6 tree to you and Jeff so that you can merge them upstream via your tree. Or do you mean Jeff should become the maintainer of drivers/infiniband?? Can't you guys just keep the networking stuff contained in its little box so it doesn't create maintenance problems for InfiniBand stuff? > Even if you're confident there won't be merge issues, could you just > wait for the net-2.6 stuff to go in first? I don't mind waiting but I guess it's up to Linus really. - R. - 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 000/002] Rearrange notifier of memory hotplug
Hello. This patch set is to rearrange event notifier for memory hotplug, because the old notifier has some defects. For example, there is no information like new memory's pfn and # of pages for callback functions. Fortunately, nothing uses this notifier so far, there is no impact by this change. (SLUB will use this after this patch set to make kmem_cache_node structure). In addition, descriptions of notifer is added to memory hotplug document. This patch was a part of patch set to make kmem_cache_node of SLUB to avoid panic of memory online. But, I think this change becomes not only for SLUB but also for others. So, I extracted this from it. This patch set is for 2.6.23-rc8-mm2. I tested this patch on my ia64 box. Please apply. Bye. -- 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/
[PATCH 1/2] [V2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
allows for more flexibility in the note type for the state of 'extended
floating point' implementations in coredumps. New note types can now be
added with an appropriate #define.
This does #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all
current users so there's are no change in behaviour.
This will let us use different note types on powerpc for the
Altivec/VMX state that some PowerPC cpus have (G4, PPC970, POWER6) and
for the SPE (signal processing extension) state that some embedded
PowerPC cpus from Freescale have.
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
---
arch/ia64/ia32/elfcore32.h |1 +
arch/x86_64/ia32/ia32_binfmt.c |1 +
fs/binfmt_elf.c|8
fs/binfmt_elf_fdpic.c |6 +++---
include/asm-i386/elf.h |1 +
5 files changed, 10 insertions(+), 7 deletions(-)
Index: linux/arch/ia64/ia32/elfcore32.h
===
--- linux.orig/arch/ia64/ia32/elfcore32.h
+++ linux/arch/ia64/ia32/elfcore32.h
@@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
}
#define ELF_CORE_COPY_XFPREGS 1
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
static inline int
elf_core_copy_task_xfpregs(struct task_struct *tsk, elf_fpxregset_t *xfpu)
{
Index: linux/arch/x86_64/ia32/ia32_binfmt.c
===
--- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
+++ linux/arch/x86_64/ia32/ia32_binfmt.c
@@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
}
#define ELF_CORE_COPY_XFPREGS 1
+#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
static inline int
elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t *xfpu)
{
Index: linux/fs/binfmt_elf.c
===
--- linux.orig/fs/binfmt_elf.c
+++ linux/fs/binfmt_elf.c
@@ -1411,7 +1411,7 @@ struct elf_thread_status
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
- elf_fpxregset_t xfpu; /* NT_PRXFPREG */
+ elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
#endif
struct memelfnote notes[3];
int num_notes;
@@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
- fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
- &t->xfpu);
+ fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
+ sizeof(t->xfpu), &t->xfpu);
t->num_notes++;
sz += notesize(&t->notes[2]);
}
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, str
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
Index: linux/fs/binfmt_elf_fdpic.c
===
--- linux.orig/fs/binfmt_elf_fdpic.c
+++ linux/fs/binfmt_elf_fdpic.c
@@ -1417,7 +1417,7 @@ struct elf_thread_status
elf_fpregset_t fpu; /* NT_PRFPREG */
struct task_struct *thread;
#ifdef ELF_CORE_COPY_XFPREGS
- elf_fpxregset_t xfpu; /* NT_PRXFPREG */
+ elf_fpxregset_t xfpu; /* ELF_CORE_XFPREG_TYPE */
#endif
struct memelfnote notes[3];
int num_notes;
@@ -1453,7 +1453,7 @@ static int elf_dump_thread_status(long s
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
- fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
+ fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
sizeof(t->xfpu),
&t->xfpu);
t->num_notes++;
sz += notesize(&t->notes[2]);
@@ -1690,7 +1690,7 @@ static int elf_fdpic_core_dump(long sign
#ifdef ELF_CORE_COPY_XFPREGS
if (elf_core_copy_task_xfpregs(current, xfpu))
fill_note(notes + numnote++,
- "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+ "LINUX", ELF_CORE_XFPREG_TYPE, sizeof(*xfpu), xfpu);
#endif
fs = get_fs();
Index: linux/include/asm-i386/elf.h
===
--- linux.orig/include/asm-i386/elf.h
+++ linux/include/asm-i386/elf.h
@@ -129,6 +129,7 @@ extern int dump_task_extended_fpu (struc
#define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk, elf_regs)
#define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk, elf_fpregs)
#define ELF_CORE_COPY_XFPREGS(tsk, elf_xfpregs) dump_task_extended_fpu(tsk,
elf_xfpregs)
+#define ELF
Re: gigabit ethernet power consumption
Kok, Auke <[EMAIL PROTECTED]> wrote: > K.Prasad wrote: >> Without the side-effect of experiencing a link-flap when switching to a >> lower-speed (with its toll in terms of down-time for auto-negotiation, >> STP, etc), the Interrupt Moderation Algorithm dynamically adjusts the >> number of interrupts based on traffic - and presumably consume less >> power. For an "Optimise for Power" kind of profile - the driver can be >> loaded with a higher throttle rate during boot-time. > > We're changing this to be run-time adjustable in newer drivers. > > However, the power consumed by your nic staying in gigabit mode is much > greater in the long run then what you can save by trying to scrounge for > milliwatts reducing interrupts generated by the nic. By default it already > moderates them somewhat. Practically this feature is really not useful for > powersaving, it just won't add up to actual benefits in a real life situtation > I think. Just a thought: How much power does a non-connected NIC consume, and can you save power by forcing 10 MBit until a link is detected (doubling negotiation time)? -- Top 100 things you don't want the sysadmin to say: 22. hey, what does mkfs do? Friß, Spammer: [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: [GIT PULL] kbuild updates
On Wed, 10 Oct 2007, Sam Ravnborg wrote: > > This set of commits are the kbuild stuff that does not > conflict with the pending x86 merge. Hmm. It does for me, actually. I fixed up the trivial conflict in the main Makefile, but that seems to leave $(ARCH) entirely undefined in my case, so the end result doesn't work. That seems to have nothing to do with my conflict fixup, but is something else. It also gets a trivial conflict with the 'mmc' pull I just did, but that didn't seem problematic (mmc added a new case to scripts/mod/file2alias.c, and you added a free, both at the end of the same function) - but the x86 merge conflict means that I decided that I'll let you sort it out. It's probably really trivial, but I'll merge the other stuff I have pending instead. Linus - 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/
2.6.23-rt1
We are pleased to announce the 2.6.23-rt1 tree, which can be downloaded from the location: http://www.kernel.org/pub/linux/kernel/projects/rt/ Changes since 2.6.23-rc9-rt2 - updated to 2.6.23 - spin_trylock_irqsave macro fix (Sébastien Dugué) - move rcu_preempt_boost init earlier (Steven Rostedt) - rt task send IPI condition update (Mike Kravetz) to build a 2.6.23-rt1 tree, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.23-rt1.bz2 The broken out patches are also available. -- Steve - 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/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote: > Olof Johansson writes: > > > Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about > > 4K text on a ppc64_defconfig. The main reason seems to be that prepping > > the arguments to the conditional trap instructions is more work than > > just doing a compare and branch. > > It might be more instructions but it takes fewer cycles, I would > expect. Do you have the actual instruction sequences to compare? > I really hope WARN_ON/BUG_ON aren't hotpaths on powerpc. ;-) Cheers, Kyle - 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: Linux 2.6.23
On Wednesday 10 October 2007 20:14, Ingo Molnar wrote: > * Nicholas Miell <[EMAIL PROTECTED]> wrote: > > Does CFS still generate the following sysbench graphs with 2.6.23, or > > did that get fixed? > > > > http://people.freebsd.org/~kris/scaling/linux-pgsql.png > > http://people.freebsd.org/~kris/scaling/linux-mysql.png > > as far as my testsystem goes, v2.6.23 beats v2.6.22.9 in sysbench: > > http://redhat.com/~mingo/misc/sysbench.jpg > > As you can see it in the graph, v2.6.23 schedules much more consistently > too. [ v2.6.22 has a small (but potentially statistically insignificant) > edge at 4-6 clients, and CFS has a slightly better peak (which is > statistically insignificant). ] > > ( Config is at http://redhat.com/~mingo/misc/config, system is Core2Duo > 1.83 GHz, mysql-5.0.45, glibc-2.6. Nothing fancy either in the config > nor in the setup - everything is pretty close to the defaults. ) > > i'm aware of a 2.6.21 vs. 2.6.23 sysbench regression report, and it > apparently got resolved after various changes to the test environment: > >http://jeffr-tech.livejournal.com/10103.html > > " [] has virtually no dropoff and performs better under load than >the default 2.6.21 scheduler. " (paraphrased) ;) I think you snipped the important bit: "the peak is terrible but it has virtually no dropoff and performs better under load than the default 2.6.21 scheduler." (verbatim) The dropoff under load was due to trivially avoided mmap_sem contention in the kernel and glibc (and not-very-scalable mysql heap locking), rather than specifically anything the scheduler was doing wrong, I think (when the scheduler chose to start preempting threads holding locks, then performance would tank. Exactly when that point was reached, and what happens afterwards was probably just luck.) - 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 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
Kumar Gala wrote:
>
> On Oct 11, 2007, at 2:15 AM, [EMAIL PROTECTED] wrote:
>
>> Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code which
>> allows for more flexibility in the note type for the state of 'extended
>> floating point' implementations in coredumps. New note types can now be
>> added with an appropriate #define.
>>
>> #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
>> there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled to
> the x86 specific name?
>
>>
>> Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
>> ---
>> arch/ia64/ia32/elfcore32.h |1 +
>> arch/x86_64/ia32/ia32_binfmt.c |1 +
>> fs/binfmt_elf.c|4 ++--
>> include/asm-i386/elf.h |1 +
>> 4 files changed, 5 insertions(+), 2 deletions(-)
>>
>> Index: linux/arch/ia64/ia32/elfcore32.h
>> ===
>> --- linux.orig/arch/ia64/ia32/elfcore32.h
>> +++ linux/arch/ia64/ia32/elfcore32.h
>> @@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
>> }
>>
>> #define ELF_CORE_COPY_XFPREGS 1
>> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
>> static inline int
>> elf_core_copy_task_xfpregs(struct task_struct *tsk, elf_fpxregset_t
>> *xfpu)
>> {
>> Index: linux/arch/x86_64/ia32/ia32_binfmt.c
>> ===
>> --- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
>> +++ linux/arch/x86_64/ia32/ia32_binfmt.c
>> @@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
>> }
>>
>> #define ELF_CORE_COPY_XFPREGS 1
>> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
>> static inline int
>> elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t *xfpu)
>> {
>> Index: linux/fs/binfmt_elf.c
>> ===
>> --- linux.orig/fs/binfmt_elf.c
>> +++ linux/fs/binfmt_elf.c
>> @@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
>>
>> #ifdef ELF_CORE_COPY_XFPREGS
>> if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
>> -fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
>> - &t->xfpu);
>> +fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
>> + sizeof(t->xfpu), &t->xfpu);
>> t->num_notes++;
>> sz += notesize(&t->notes[2]);
>> }
>
> You've only fixed up one of 4 NT_PRXFPREG uses in the kernel.
Ooops... Right you are - very good pickup :) Fixed in a new version (will send
promptly).
Thanks!
Mark.
>
> Also, I'm not a fan of your proposed mechanism to "overload" the
> elf_fpxregset_t. I'd rather see us introduce a new elf_vecregset_t and
> have it typedef'd to be elf_fpxregset_t on i386, x86_64, ia64
>
>> Index: linux/include/asm-i386/elf.h
>> ===
>> --- linux.orig/include/asm-i386/elf.h
>> +++ linux/include/asm-i386/elf.h
>> @@ -129,6 +129,7 @@ extern int dump_task_extended_fpu (struc
>> #define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk,
>> elf_regs)
>> #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk,
>> elf_fpregs)
>> #define ELF_CORE_COPY_XFPREGS(tsk, elf_xfpregs)
>> dump_task_extended_fpu(tsk, elf_xfpregs)
>> +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
>>
>> #define VDSO_HIGH_BASE(__fix_to_virt(FIX_VDSO))
>> #define VDSO_CURRENT_BASE((unsigned long)current->mm->context.vdso)
>>
>> --
>> ___
>> Linuxppc-dev mailing list
>> [EMAIL PROTECTED]
>> https://ozlabs.org/mailman/listinfo/linuxppc-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/
Re: [PATCH 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
Olof Johansson writes: > Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about > 4K text on a ppc64_defconfig. The main reason seems to be that prepping > the arguments to the conditional trap instructions is more work than > just doing a compare and branch. It might be more instructions but it takes fewer cycles, I would expect. Do you have the actual instruction sequences to compare? Paul. - 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] task containersv11 add tasks file interface fix for cpusets
> Since we know that the tasks are not running, and that we have > exclusive access to the tasks in the control group we can take action > as if we were the actual tasks themselves. Which should simplify > locking. The Big Kernel Lock (BKL), born again, as a Medium Sized Cgroup Lock ? This only simplifies things if it enables us to remove finer grain locking, but some finer grain locking is essential for performance on higher processor count systems (which if Intel and AMD have their way, will be just about any system bigger than a cell phone.) There is no escaping actually having to think about these things, and clearly understand and document what locks what. Locks don't just guard code sections, and they don't just guard particular data items. Rather, in my view, they ensure certain invariants on your data. Non-atomic code sections that depend on, or modify, data subject to such invariants must be done while holding the appropriate lock. One is guaranteed not to see the invariant violated while holding the lock, nor to expose others to temporary violations of the invariant done while locked. In this case, we have multiple copies of cpumasks in task structs and cpusets that must honor the invariant that they are equal or subsets of, cpu_online_map. Changes to the set of online CPUs must hold some lock, apparently sched_hotcpu_mutex, until all those cpumasks are adjusted to once again honor, this invariant. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - 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: [GIT PULL] please pull infiniband.git for-linus
From: Roland Dreier <[EMAIL PROTECTED]> Date: Thu, 11 Oct 2007 18:08:52 -0700 > This will get the batch of changes queued up for the 2.6.24 merge > window (although I still have a few more things to merge later, once > Dave Miller's networking tree has landed too): Roland are you absolutely sure this won't create merge conflicts with my 8MB net-2.6 merge, inside of which there are many infiniband driver changes? I really wish you would submit your inifiniband work through normal network driver channels, such as Jeff Garzik. Jeff has been syncing on almost a daily basis with me so that I wouldn't have to worry about changes coming out of left field and adding additional merge issues for an already difficult merge. Even if you're confident there won't be merge issues, could you just wait for the net-2.6 stuff to go in first? Thanks. - 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/
[GIT PULL] please pull infiniband.git for-linus
Linus, please pull from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This tree is also available from kernel.org mirrors at: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will get the batch of changes queued up for the 2.6.24 merge window (although I still have a few more things to merge later, once Dave Miller's networking tree has landed too): Ali Ayoub (1): IB/sa: Error handling thinko fix Anton Blanchard (3): IB/fmr_pool: Clean up some error messages in fmr_pool.c IB/ehca: Make output clearer by removing some debug messages IB/ehca: Export module parameters in sysfs Arthur Jones (4): IB/ipath: iba6110 rev4 GPIO counters support IB/ipath: Use counters in ipath_poll and cleanup interrupts in ipath_close IB/ipath: iba6110 rev4 no longer needs recv header overrun workaround IB/ipath: Indicate a couple of chip bugs to userspace Dave Olson (5): IB/ipath: Verify host bus bandwidth to chip will not limit performance IB/ipath: Correctly describe workaround for TID write chip bug IB/ipath: Future proof eeprom checksum code (contents reading) IB/ipath: Fix QHT7040 serial number check IB/ipath: Minor fix to ordering of freeing and zeroing of tid pages. Dotan Barak (2): mlx4_core: Use enum value GO_BIT_TIMEOUT_MSECS IPoIB/cm: Clean up initialization of QP attr in ipoib_cm_create_tx_qp() Eli Cohen (3): IPoIB: Fix typo to end statement with ';' instead of ',' IPoIB: Fix error path memory leak IB/mthca: Mark error paths as unlikely() in post_srq_recv functions Hoang-Nam Nguyen (4): IB/ehca: Use remap_4k_pfn() to map firmware contexts to user space IB/ehca: Fix large page HW cap defines IB/ehca: Fix mem leak of firmware ctrlblock in ehca_create_srq() IB/ehca: Adjust 64-bit alignment of create QP response for userspace Jack Morgenstein (5): IB/mlx4: Display misc device information under /sys/class/infiniband/ mlx4_core: Support ICM tables in coherent memory mlx4_core: Write MTTs from CPU instead with of WRITE_MTT FW command IB/mlx4: Implement FMRs mlx4_core: Increase max number of QPs per multicast group to 56 Joachim Fenkes (11): IB/ehca: Refactor hvcall tracing IB/ehca: Print return codes as signed decimal integers IB/ehca: ehca_gen_warn() should always print IB/ehca: Add check for max #SGE to create_qp() IB/ehca: Path migration support IB/ehca: Serialize MR alloc and MR free hvCalls IB/ehca: Replace get_paca()->paca_index by the more portable raw_smp_processor_id() IB/ehca: Bump version number and change its format IB/umem: Add hugetlb flag to struct ib_umem IB/ehca: Only use MR large pages for hugetlb regions IB/ehca: Return srq_attr->max_sge in ehca_query_srq() Michael Albaugh (2): IB/ipath: Maintain active time on all chips IB/ipath: Better handling of unexpected GPIO interrupts Michael S. Tsirkin (2): mlx4_core: Enable MSI-X by default IB/mthca: Enable MSI-X by default Or Gerlitz (1): IPoIB: Allow setting policy to ignore multicast groups Peter Oruba (1): IB/mthca: Use PCI-X/PCI-Express read control interfaces Ralph Campbell (13): IB/core: Fix handling of multicast response failures IB/ipath: Performance optimization for CPU differences IB/ipath: Change UD to queue work requests like RC & UC IB/ipath: Remove unneeded code for ipathfs IB/ipath: UC RDMA WRITE with IMMEDIATE doesn't send the immediate IB/ipath: Remove redundant code IB/ipath: Generate flush CQE when QP is in error state IB/ipath: Implement IB_EVENT_QP_LAST_WQE_REACHED IB/ipath: Optimize completion queue entry insertion and polling IB/ipath: Add ability to set the LMC via the sysfs debugging interface IB/ipath: Remove duplicate copy of LMC IB/ipath: Fix IB_EVENT_PORT_ERR event IB/ipath: Remove redundant link state checks Roland Dreier (18): IPoIB: Make sure no receives are handled when stopping device IB: find_first_zero_bit() takes unsigned pointer mlx4_core: Don't free special QPs in QP number bitmap IB/mlx4: Use __set_data_seg() in mlx4_ib_post_recv() IB/ehca: Include from ehca_classes.h IB/mlx4: Fix up SRQ limit_watermark endianness IB/iser: Remove unnecessary includes mlx4_core: Change capability decoding: SRC->XRC IB/umad: Add P_Key index support IB/umad: Fix bit ordering and 32-on-64 problems on big endian systems IB/uverbs: Make ib_uverbs_release_event_file() static mlx4_core: Reserve the correct number of MTT segments mlx4_core: Fix meaning of dev->caps.reserved_mtts IB/mthca: Increase max number of QPs per multicast group to 56 IB/mthca: Use mmiowb() to avoid firmware commands getting jumbled up mlx4_core: Use mmi
Re: [PATCH net-2.6.24] remove bogus qeth type check
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 11 Oct 2007 17:52:24 -0700 > On Thu, 11 Oct 2007 17:24:54 -0700 (PDT) > David Miller <[EMAIL PROTECTED]> wrote: > > > With the way you set up headerops in the driver, the only way > > to preserve the ARPHRD_IEEE802_TR guard, is to keep the > > test that you added to qeth_hard_header_parse(). ... > > Dave, you right, that is why I put that test in. Should have kept > the staging tree and notes around longer. Thanks for confirming. - 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 net-2.6.24] remove bogus qeth type check
On Thu, 11 Oct 2007 17:24:54 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Thu, 11 Oct 2007 13:24:58 -0700
>
> > Not sure why this crept in with hard-header-ops change.
> > Just kill it. Need to start doing cross-compiles for s390...
> >
> > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
> >
> > --- a/drivers/s390/net/qeth_main.c 2007-10-10 08:26:48.0 -0700
> > +++ b/drivers/s390/net/qeth_main.c 2007-10-11 13:21:17.0 -0700
> > @@ -6581,9 +6581,6 @@ qeth_hard_header_parse(const struct sk_b
> > const struct qeth_card *card;
> > const struct ethhdr *eth;
> >
> > - if (dev->type != ARPHRD_IEEE802_TR)
> > - return 0;
> > -
> > card = qeth_get_card_from_dev(skb->dev);
> > if (card->options.layer2)
> > goto haveheader;
>
> Stephen this change is not right.
>
> In order to preserve the semantics that existed before your
> headerops changes, this test must be there. From the original
> qeth_main.c code:
>
> if (qeth_get_netdev_flags(card) & IFF_NOARP) {
> dev->rebuild_header = NULL;
> dev->hard_header = NULL;
> dev->header_cache_update = NULL;
> dev->hard_header_cache = NULL;
> }
> ...
> if (card->options.fake_ll &&
> (qeth_get_netdev_flags(card) & IFF_NOARP))
> dev->hard_header = qeth_fake_header;
> if (dev->type == ARPHRD_IEEE802_TR)
> dev->hard_header_parse = NULL;
> else
> dev->hard_header_parse = qeth_hard_header_parse;
>
> With the way you set up headerops in the driver, the only way
> to preserve the ARPHRD_IEEE802_TR guard, is to keep the
> test that you added to qeth_hard_header_parse().
>
> Andrew, please go back to using the first patch you wrote to
> fix the build, alternative resync with net-2.6.git as that
> version of the build fix is there too.
Dave, you right, that is why I put that test in. Should have kept
the staging tree and notes around longer.
--
Stephen Hemminger <[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: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland
On Thu, 11 Oct 2007, Ryan Finnie wrote:
> On 10/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > shit. That's a nasty bug. Really userspace should be testing for -1, but
> > the msync() library function should only ever return 0 or -1.
> >
> > Does this fix it?
> >
> > --- a/mm/page-writeback.c~a
> > +++ a/mm/page-writeback.c
> > @@ -850,8 +850,10 @@ retry:
> >
> > ret = (*writepage)(page, wbc, data);
> >
> > - if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE))
> > + if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
> > unlock_page(page);
> > + ret = 0;
> > + }
> > if (ret || (--(wbc->nr_to_write) <= 0))
> > done = 1;
> > if (wbc->nonblocking && bdi_write_congested(bdi)) {
> > _
> >
>
> Pekka Enberg replied with an identical patch a few days ago, but for
> some reason the same condition flows up to msync as -1 EIO instead of
> AOP_WRITEPAGE_ACTIVATE with that patch applied. The last part of the
> thread is below. Thanks.
Each time I sit down to follow what's going on with writepage and
unionfs and msync, I get distracted: I really haven't researched
this properly.
But I keep suspecting that the answer might be the patch below (which
rather follows what drivers/block/rd.c is doing). I'm especially
worried that, rather than just AOP_WRITEPAGE_ACTIVATE being returned
to userspace, bad enough in itself, you might be liable to hit that
BUG_ON(page_mapped(page)). shmem_writepage does not expect to be
called by anyone outside mm/vmscan.c, but unionfs can now get to it?
Please let us know if this patch does fix it:
then I'll try harder to work out what goes on.
Thanks,
Hugh
--- 2.6.23/mm/shmem.c 2007-10-09 21:31:38.0 +0100
+++ linux/mm/shmem.c2007-10-12 01:25:46.0 +0100
@@ -916,6 +916,11 @@ static int shmem_writepage(struct page *
struct inode *inode;
BUG_ON(!PageLocked(page));
+ if (!wbc->for_reclaim) {
+ set_page_dirty(page);
+ unlock_page(page);
+ return 0;
+ }
BUG_ON(page_mapped(page));
mapping = page->mapping;
-
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: kernel panic when loading built-in E1000's driver.
Thank you for your reply. As the commonsense, what is the difference between module and built-in driver? As I know, cleanup function of built-in driver will not be called. What is the other difference? Thanks! Dafu On 10/10/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Wed, 10 Oct 2007, Dafu wrote: > > > When I run linux kernel ver2.6.10 built by myself, there was a kernel > > panic when loading E1000 device driver. (See the details below.) > > Hi, > > 2.6.10 is a pretty ancient kernel, a load of bugfixes happened since then. > Please recent kernel first. > > -- > Jiri Kosina > - 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 net-2.6.24] remove bogus qeth type check
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007 13:24:58 -0700
> Not sure why this crept in with hard-header-ops change.
> Just kill it. Need to start doing cross-compiles for s390...
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
>
> --- a/drivers/s390/net/qeth_main.c2007-10-10 08:26:48.0 -0700
> +++ b/drivers/s390/net/qeth_main.c2007-10-11 13:21:17.0 -0700
> @@ -6581,9 +6581,6 @@ qeth_hard_header_parse(const struct sk_b
> const struct qeth_card *card;
> const struct ethhdr *eth;
>
> - if (dev->type != ARPHRD_IEEE802_TR)
> - return 0;
> -
> card = qeth_get_card_from_dev(skb->dev);
> if (card->options.layer2)
> goto haveheader;
Stephen this change is not right.
In order to preserve the semantics that existed before your
headerops changes, this test must be there. From the original
qeth_main.c code:
if (qeth_get_netdev_flags(card) & IFF_NOARP) {
dev->rebuild_header = NULL;
dev->hard_header = NULL;
dev->header_cache_update = NULL;
dev->hard_header_cache = NULL;
}
...
if (card->options.fake_ll &&
(qeth_get_netdev_flags(card) & IFF_NOARP))
dev->hard_header = qeth_fake_header;
if (dev->type == ARPHRD_IEEE802_TR)
dev->hard_header_parse = NULL;
else
dev->hard_header_parse = qeth_hard_header_parse;
With the way you set up headerops in the driver, the only way
to preserve the ARPHRD_IEEE802_TR guard, is to keep the
test that you added to qeth_hard_header_parse().
Andrew, please go back to using the first patch you wrote to
fix the build, alternative resync with net-2.6.git as that
version of the build fix is there too.
Thans.
-
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: Scsi on sparc build break in 2.6.23.
On Fri, 12 Oct 2007 01:56:59 +0200 Adrian Bunk wrote: > On Thu, Oct 11, 2007 at 05:37:30PM -0500, Rob Landley wrote: > > On Thursday 11 October 2007 10:21:49 am Adrian Bunk wrote: > > > I assume you have the full .config in your build directory, and could > > > have taken it from there? > > > > Actually I don't. (The extracted source tree is in a temporary directory > > which the script deletes afterwards unless I tell it not to. I just > > followed > > my own instructions to create the .config and attach it, but I see that > > James > > Bottomley already diagnosed it and you came up with a patch. Off to try > > it...) > > I was able to follow your instructions for generating it. > > But I hope you got my point that it's much easier to debug such issues > when you generate the .config yourself and attach it when sending the > bug report. I use the mini-config method quite a bit (probably not as much as Rob does), but I agree with Adrian, it should have just been included here in full (not mini). --- ~Randy - 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: solved: 2.6.23 && fglrx && s2ram
On Fri, Oct 12, 2007 at 01:49:07AM +0200, Michael Leun wrote: > On Fri, 12 Oct 2007 01:31:17 +0200 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > On Friday, 12 October 2007 00:07, Michael Leun wrote: > > > Hello, > > > > > > (please, don't blame me for using the binary only driver, I will > > > happily switch to a open source one once it properly runs mplayer, > > > e.g.). > > > > > > Renaming the config options for suspend/sleep broke fglrx power > > > management. > > > > It looks like your patch is against the fglrx driver, isn't it? > > It is - I should have mentioned that, sorry. This makes it 100% off-topic for linux-kernel - please send patches for illegal modules to the vendors of these modules and not here. > MfG, > > Michael Leun cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: Invalid PnP ACPI reserved MMIO areas on Supermicro boards
Len Brown wrote: On Tuesday 09 October 2007 20:01, Robert Hancock wrote: Some people with certain Supermicro boards (at least the H8DCE, it seems) have reported that the sata_nv driver fails to attach to some of the controllers due to resource conflicts: https://bugzilla.redhat.com/show_bug.cgi?id=280641 https://bugzilla.redhat.com/show_bug.cgi?id=313491 Essentially since about 2.6.22 or so (before which we apparently didn't handle PnpACPI reserved MMIO regions?) we get: So if you boot with "pnpacpi=off" then the board is happy? -Len Apparently yes - see new comments in: https://bugzilla.redhat.com/show_bug.cgi?id=280641 A patch has also been proposed to ignore motherboard resources that overlap PCI BARs here: https://bugzilla.redhat.com/show_bug.cgi?id=313491 pnp: 00:09: iomem range 0xdfefd000-0xdfefd3ff has been reserved pnp: 00:09: iomem range 0xdfefe000-0xdfefe3ff has been reserved when the CK804 SATA controllers have as their BIOS-assigned resources: 80:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Super Micro Computer Inc Unknown device 1011 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin A routed to IRQ 46 Region 0: I/O ports at e400 [size=8] Region 1: I/O ports at e000 [size=4] Region 2: I/O ports at dc00 [size=8] Region 3: I/O ports at d800 [size=4] Region 4: I/O ports at d400 [size=16] Region 5: Memory at dfefd000 (32-bit, non-prefetchable) and 80:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Super Micro Computer Inc Unknown device 1011 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin A routed to IRQ 45 Region 0: I/O ports at f800 [size=8] Region 1: I/O ports at f400 [size=4] Region 2: I/O ports at f000 [size=8] Region 3: I/O ports at ec00 [size=4] Region 4: I/O ports at e800 [size=16] Region 5: Memory at dfefe000 (32-bit, non-prefetchable) [size=4K] And so of course we get: sata_nv :80:07.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:07.0 ACPI: PCI interrupt for device :80:07.0 disabled sata_nv: probe of :80:07.0 failed with error -16 ACPI: PCI Interrupt Link [LT2E] enabled at IRQ 45 ACPI: PCI Interrupt :80:08.0[A] -> Link [LT2E] -> GSI 45 (level, low) -> IRQ 45 sata_nv :80:08.0: Using ADMA mode PCI: Unable to reserve mem region #6:[EMAIL PROTECTED] for device :80:08.0 ACPI: PCI interrupt for device :80:08.0 disabled sata_nv: probe of :80:08.0 failed with error -16 So essentially the BIOS has erroneously reserved the SATA controller's BARs in the ACPI motherboard resources, preventing the driver from attaching to the device. Any ideas on what we can do about this? -Get Supermicro to fix the BIOS - already tried, it seems -System-specific quirk to ignore these resource reservations? -Try to move the PCI resources if they conflict with the ACPI resource reservations? I wonder how Windows deals with this, if it even does on these boards? - 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: Scsi on sparc build break in 2.6.23.
On Thu, Oct 11, 2007 at 05:37:30PM -0500, Rob Landley wrote: > On Thursday 11 October 2007 10:21:49 am Adrian Bunk wrote: > > I assume you have the full .config in your build directory, and could > > have taken it from there? > > Actually I don't. (The extracted source tree is in a temporary directory > which the script deletes afterwards unless I tell it not to. I just followed > my own instructions to create the .config and attach it, but I see that James > Bottomley already diagnosed it and you came up with a patch. Off to try > it...) I was able to follow your instructions for generating it. But I hope you got my point that it's much easier to debug such issues when you generate the .config yourself and attach it when sending the bug report. > Rob cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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] Add Documentation/RCU/00-Index
On Thu, Oct 11, 2007 at 06:23:27PM -0500, Rob Landley wrote: > From: Rob Landley <[EMAIL PROTECTED]> > > Add Documentation/RCU/00-INDEX Good addition!!! Acked-by: Paul E. McKenney <[EMAIL PROTECTED]> > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > --- > > Documentation/RCU/00-INDEX | 22 ++ > 1 file changed, 22 insertions(+) > > --- /dev/null 2007-04-23 10:59:00.0 -0500 > +++ hg/Documentation/RCU/00-INDEX 2007-10-11 18:17:26.0 -0500 > @@ -0,0 +1,22 @@ > +00-INDEX > + - This file > +arrayRCU.txt > + - Using RCU to Protect Read-Mostly Arrays > +checklist.txt > + - Review Checklist for RCU Patches > +listRCU.txt > + - Using RCU to Protect Read-Mostly Linked Lists > +NMI-RCU.txt > + - Using RCU to Protect Dynamic NMI Handlers > +rcuref.txt > + - Reference-count design for elements of lists/arrays protected by RCU > +rcu.txt > + - RCU Concepts > +RTFP.txt > + - List of RCU papers (bibliography) going back to 1980. > +torture.txt > + - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST) > +UP.txt > + - RCU on Uniprocessor Systems > +whatisRCU.txt > + - What is RCU? > > -- > "One of my most productive days was throwing away 1000 lines of code." > - Ken Thompson. - 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: solved: 2.6.23 && fglrx && s2ram
On Fri, 12 Oct 2007 01:31:17 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > Hi, > > On Friday, 12 October 2007 00:07, Michael Leun wrote: > > Hello, > > > > (please, don't blame me for using the binary only driver, I will > > happily switch to a open source one once it properly runs mplayer, > > e.g.). > > > > Renaming the config options for suspend/sleep broke fglrx power > > management. > > It looks like your patch is against the fglrx driver, isn't it? It is - I should have mentioned that, sorry. -- MfG, Michael Leun - 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] modpost problem when symbols move from one module to another
The v4l-dvb tree recently renamed a module and this caused some problems
with modpost creating incorrect module dependencies. This patch fixes that
problem. It should be explained thoroughly in the patch description.modpost: Fix problem with out of date Module.symvers
When part of build an external module tree, modpost first reads in the
kernel's and then the external tree's Module.symvers files. From these files
it establishes a symbol => module mapping. When it later reads in each module
built and processes the symbols it finds, it discovers the symbol=>module
mapping from Module.symvers and leaves it as it is.
The problem comes with a module has been re-named or a symbol has moved from
one module to another, since the Module.symvers file was generated. modpost
does not update the symbol=>module mapping when it finds the new location of
the symbol when scanning the newly built modules. This results in the module
containing incorrect dependency information and the new Module.symvers file
written by modpost will also contain the incorrect mappings, perpetuating the
problem to the next build, and so on.
When building the out of kernel development tree for kernel subsystem, like
v4l-dvb or ALSA, deleting the external Module.symvers file before building
(which the kernel build system doesn't do and shouldn't be necessary anyway),
won't fix the problem. modpost still reads the kernel's Module.symvers, and
since we a building a kernel subsystem, it will define the same symbols as the
external modules.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
diff -r 79f0ea1e0e70 scripts/mod/modpost.c
--- a/scripts/mod/modpost.c Tue Oct 09 21:00:40 2007 +
+++ b/scripts/mod/modpost.c Thu Oct 11 15:20:01 2007 -0700
@@ -268,6 +268,9 @@ static struct symbol *sym_add_exported(c
"was in %s%s\n", mod->name, name,
s->module->name,
is_vmlinux(s->module->name) ?"":".ko");
+ } else {
+ /* In case Modules.symvers was out of date */
+ s->module = mod;
}
}
s->preloaded = 0;
