* [RFC/POC] multiple CONFIG y/m/n
From: Randy.Dunlap @ 2006-04-07 5:41 UTC (permalink / raw)
To: lkml; +Cc: zippel
In doing lots of kernel build testing, I often want to enable all options
in a sub-menu and their sub-sub-menus. Sound is one of the worst^W longest
of these, so I chose a shorter (easier) one to practice on: parport.
For PARPORT, this isn't terribly needed; it's just being a guinea pig
for me. The point is to be able to enable all applicable options at
one time (one line or one click).
So if no (top-level of a CONFIG, like CONFIG_PARPORT) options are enabled,
you can step thru the entire menu and sub-menus, taking a few minutes
sometimes (see SOUND or USB), or the kconfig system could enable some
way to do this for us. For version 1, all that I have done is modify
driver/parport/Kconfig -- no code changes. I haven't even looked at the
source code to see if that would be the right thing to do. I'm just
taken liberties with the famous Kconfig "select" to make it work.
I can already see that I find this useful, but is there a good (better)
way to implement this in kconfig?
As it is here, PARPORT_ENABLE_ALL tracks PARPORT (y/m/n) when the former
is enabled/configured. The downside of this Kconfig usage is that almost
all lines of "depends" are duplicated as "select" (and that it uses "select").
It would be good if there was some way to automate this.
Comments?
---
~Randy
---
drivers/parport/Kconfig | 17 +++++++++++++++++
1 files changed, 17 insertions(+)
--- linux-2617-rc1.orig/drivers/parport/Kconfig
+++ linux-2617-rc1/drivers/parport/Kconfig
@@ -151,5 +151,22 @@ config PARPORT_1284
transfer modes. Also say Y if you want device ID information to
appear in /proc/sys/dev/parport/*/autoprobe*. It is safe to say N.
+config PARPORT_ENABLE_ALL
+ tristate "Enable all (non-BROKEN) PARPORT options"
+ depends on PARPORT
+ select PARPORT_PC if (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV
+ select PARPORT_SERIAL if SERIAL_8250 && PARPORT_PC && PCI
+ select PARPORT_PC_FIFO if PARPORT_PC && EXPERIMENTAL
+ select PARPORT_PC_SUPERIO if PARPORT_PC && EXPERIMENTAL
+ select PARPORT_PC_PCMCIA if PCMCIA && PARPORT_PC
+ select PARPORT_ARC if ARM && PARPORT
+ select PARPORT_IP32 if SGI_IP32 && PARPORT && EXPERIMENTAL
+ select PARPORT_AMIGA if AMIGA && PARPORT
+ select PARPORT_MFC3 if ZORRO && PARPORT
+ select PARPORT_ATARI if ATARI && PARPORT
+ select PARPORT_GSC if PARPORT && GSC
+ select PARPORT_SUNBPP if SBUS && PARPORT && EXPERIMENTAL
+ select PARPORT_1284 if PARPORT
+
endmenu
^ permalink raw reply
* Re: + pg_uncached-is-ia64-only.patch added to -mm tree
From: KAMEZAWA Hiroyuki @ 2006-04-07 5:40 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, jbarnes, jes, nickpiggin, tony.luck, mm-commits
In-Reply-To: <20060406215242.245340de.akpm@osdl.org>
On Thu, 6 Apr 2006 21:52:42 -0700
Andrew Morton <akpm@osdl.org> wrote:
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> -#define FLAGS_RESERVED 32
> +#define FLAGS_RESERVED 24
>
Oh..we get more 8bits flags on 64bit machines !!!
but could you reserve 30bits now ?
This is my understanding..
==
At the first look, SPARSEMEM with ia64
#define SECTION_SIZE_BITS (30)
#define MAX_PHYSMEM_BITS (50)
so SECTIONS_SHIFT = 50 - 30 = 20bits.
20bits of page->flags is used for SPARSEMEM's section id.
sgi have NODES_SHIFT=8, and always ZONES_SHIFT=2 .
At worst, 20 + 8 + 2 = 30bits should be used. but..
extra code is here..
==
#if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= FLAGS_RESERVED
#define NODES_WIDTH NODES_SHIFT
#else
#define NODES_WIDTH 0
#endif
==
So, node-id is not encoded into flags.
In this case,
==
<snip>
#define FLAGS_HAS_NODE (NODES_WIDTH > 0 || NODES_SHIFT == 0)
<snip>
static inline unsigned long page_to_nid(struct page *page)
{
if (FLAGS_HAS_NODE)
return (page->flags >> NODES_PGSHIFT) & NODES_MASK;
else
return page_zone(page)->zone_pgdat->node_id;
}
==
page_zone(page) looks up zone from zone_table[].
If FLAGS_HAS_NODE=0, zone_table indexing is this.
==
(page->flags >> (offset of zone bit)) & ((1 << (SECTIONS_SHIFT + ZONES_SHIFT)) - 1)
See above, SECTIONS_SHIFT + ZONES_SHIFT = 22bits.
so, many ia64 people has to use 32M(22bits * 8bytes) zone_table[] ???
please fix if I'm wrong ...this is complicated.
-Kame
^ permalink raw reply
* Re: wait4/waitpid/waitid oddness
From: Kyle Moffett @ 2006-04-07 5:38 UTC (permalink / raw)
To: Joshua Hudson; +Cc: Albert Cahalan, linux-kernel
In-Reply-To: <bda6d13a0604061909u69dd8453me4c9b96cca8d34f5@mail.gmail.com>
On Apr 6, 2006, at 22:09:48, Joshua Hudson wrote:
> I'm the guy who removed the check in link() about source is a
> directory, found out what broke, and am working on a patch to fix
> all the resulting breakage. Your task is apt to be a lot simpler.
I seem to recall the reason why hardlinking directories was
prohibited had something more to do with some unfixable races and
deadlocks in the kernel; not to mention creating self-referential
directory trees that are never freed and chew up disk space.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH] kzalloc: use in alloc_netdev
From: David S. Miller @ 2006-04-07 5:38 UTC (permalink / raw)
To: blaisorblade; +Cc: akpm, linux-kernel
In-Reply-To: <20060407053204.11316.44763.stgit@zion.home.lan>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Date: Fri, 07 Apr 2006 07:32:05 +0200
> From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
>
> Noticed this use, fixed it.
>
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Applied, thanks.
^ permalink raw reply
* [ANNOUNCE] Kernbench v0.41
From: Con Kolivas @ 2006-04-07 5:33 UTC (permalink / raw)
To: linux list, ck list
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
Kernbench is a cpu throughput benchmark originally devised and used by Martin
J.Bligh. It is designed to compare kernel changes on the same machine.
It runs a kernel compile at various numbers of concurrent jobs: 1/2 number of
cpus, optimal (default is 4xnumber of cpus) and maximal job count. Optionally
it can also run single threaded. It then prints out a number of useful
statistics for the average of each group of runs and logs them to
kernbench.log
http://kernbench.kolivas.org
Direct download:
http://www.kernel.org/pub/linux/kernel/people/ck/apps/kernbench/kernbench-0.41.tar.bz2
Changes:
v0.41 Fixed make oldconfig
v0.40 Made all runs use the oldconfig if it exists. Changed to only do one
warmup run before all the benchmarks. Added logging to kernbench.log
Cleaned up the code substantially to reuse code where possible.
Added standard deviation statistics courtesy of Peter Williams
-ck
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] mpparse: prevent table index out-of-bounds
From: John Z. Bohach @ 2006-04-07 5:34 UTC (permalink / raw)
To: linux-kernel, akpm
In-Reply-To: <20060406131805.d6eb0fe7.rdunlap@xenotime.net>
On Thursday 06 April 2006 13:18, Randy.Dunlap wrote:
> On Thu, 6 Apr 2006 09:18:45 -0700 John Z. Bohach wrote:
>
> Re: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module)
> kernel oops)
>
> > I found the root cause, but don't know if its worth fixing. If the board
> > has more than 32 PCI busses on it, the mptable bus array will overwrite
> > its bounds for the PCI busses, and stomp on anything that's after it. In
> > this case, what got stomped on is the PAGE_KERNEL_EXEC variable, which
> > changed the bit-field settings for the page tables (cleared the 'present'
> > bit, and screwed up the rest), hence accounting for the page fault.
>
> Well, > 32 busses or just one busid value >= 32.
>
> > This can only happen if there are more than 32 PCI busses, so I'd say its
> > an _extremely_ rare condition on a desktop system. At any rate, the fix
> > would simply be to change the value of the #define in the mptable.h
> > header file (I forget which exactly, but its easy to find) from 32 to
> > 256. The side effect of that is that the kernel data area would grow, and
> > mostly be a total waste, since I can't fathom a desktop system with more
> > than 32 PCI busses. On arch's where more than 32 PCI busses are likely,
> > the #define is already 256.
>
> I think that the kernel init code should detect and prevent the
> data corruption. Here's a patch to do that, by ignoring busses
> whose busid value is too large.
Yeah, I follow your thinking, and was about to do the same thing, until
I consulted the book of armaments, in this case, the MP Spec. ver. 1.4.
Section 4.3.2, Bus Entries, Bus ID:
"An integer that identifies the bus entry. The BIOS assigns identifiers
starting at zero, sequentially."
Given this, I considered the kernel adequate. Nevertheless, your patch is a good
defensive programming method against buggy BIOS's. I haven't actually tested it,
but it looks like it'll be okay.
--john
^ permalink raw reply
* Re: mdadm > 2.2 ver1 superblock regression?
From: Mike Snitzer @ 2006-04-07 5:34 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <17461.60755.831530.37888@cse.unsw.edu.au>
On 4/7/06, Neil Brown <neilb@suse.de> wrote:
> On Friday April 7, neilb@suse.de wrote:
> >
> > Seeing this hasn't made it into a released kernel yet, I might just
> > change it. But I'll have to make sure that old mdadm's don't mess
> > things up ... I wonder how I will do that :-(
> >
> > Thanks for the report.
>
> Yes, try 2.4.1 (just released).
Works great.. thanks for the extremely quick response and fix.
Mike
^ permalink raw reply
* [PATCH] kzalloc: use in alloc_netdev
From: Paolo 'Blaisorblade' Giarrusso @ 2006-04-07 5:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Noticed this use, fixed it.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
net/core/dev.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 434220d..dfb6299 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3100,12 +3100,11 @@ struct net_device *alloc_netdev(int size
alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST;
alloc_size += sizeof_priv + NETDEV_ALIGN_CONST;
- p = kmalloc(alloc_size, GFP_KERNEL);
+ p = kzalloc(alloc_size, GFP_KERNEL);
if (!p) {
printk(KERN_ERR "alloc_dev: Unable to allocate device.\n");
return NULL;
}
- memset(p, 0, alloc_size);
dev = (struct net_device *)
(((long)p + NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST);
^ permalink raw reply related
* Re: [PATCH] crypto: add alignment handling to digest layer
From: Atsushi Nemoto @ 2006-04-07 5:27 UTC (permalink / raw)
To: herbert; +Cc: linux-kernel, linux-crypto, akpm
In-Reply-To: <20060406232454.GA27623@gondor.apana.org.au>
On Fri, 7 Apr 2006 09:24:54 +1000, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Another thing, could you pleas change the stack allocation in final so
> that it does it like cbc_process_decrypt? The reason is that gcc is too
> stupid to not allocate that buffer unconditionally.
I can do it, but it will add another overhead. (we must call
crypto_tfm_alg_digestsize() unconditionally)
It seems modern gcc (at least gcc 3.4 on i386 and mips) can allocate
the buffer conditionally. It is better to optimize for newer gcc,
isn't it?
---
Atsushi Nemoto
^ permalink raw reply
* [PATCH] deinline a few large inlines in DRM code
From: Denis Vlasenko @ 2006-04-07 5:26 UTC (permalink / raw)
To: David Airlie, linux-kernel, Dave Jones
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]
This is what we have now:
Large inlines with multiple callers:
Size Uses Wasted Name and definition
===== ==== ====== ================================================
322 5 1208 drm_core_ioremap drivers/char/drm/drmP.h
258 5 952 drm_core_ioremapfree drivers/char/drm/drmP.h
148 4 384 drm_ioremapfree drivers/char/drm/drm_memory.h
147 3 254 drm_ioremap drivers/char/drm/drm_memory.h
This patch moves a few large functions from drm_memory.h
to drm_memory.c, with the following effect:
# size org/*.ko new/*.ko | sort -t/ -k2
text data bss dec hex filename
46305 1304 20 47629 ba0d new/drm.ko
46367 1304 20 47691 ba4b org/drm.ko
12969 1372 0 14341 3805 new/i810.ko
14712 1372 0 16084 3ed4 org/i810.ko
16447 1364 0 17811 4593 new/i830.ko
18198 1364 0 19562 4c6a org/i830.ko
11875 1324 0 13199 338f new/i915.ko
13025 1324 0 14349 380d org/i915.ko
23936 29288 0 53224 cfe8 new/mga.ko
27280 29288 0 56568 dcf8 org/mga.ko
Please apply.
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda
[-- Attachment #2: 2.6.16.drm_inline.patch --]
[-- Type: text/x-diff, Size: 8529 bytes --]
# size org/* new/* | sort -t/ -k2
text data bss dec hex filename
46305 1304 20 47629 ba0d new/drm.ko
46367 1304 20 47691 ba4b org/drm.ko
12969 1372 0 14341 3805 new/i810.ko
14712 1372 0 16084 3ed4 org/i810.ko
16447 1364 0 17811 4593 new/i830.ko
18198 1364 0 19562 4c6a org/i830.ko
11875 1324 0 13199 338f new/i915.ko
13025 1324 0 14349 380d org/i915.ko
23936 29288 0 53224 cfe8 new/mga.ko
27280 29288 0 56568 dcf8 org/mga.ko
diff -urpN linux-2.6.16.org/drivers/char/drm/drm_memory.c linux-2.6.16.drm/drivers/char/drm/drm_memory.c
--- linux-2.6.16.org/drivers/char/drm/drm_memory.c Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.drm/drivers/char/drm/drm_memory.c Thu Apr 6 21:03:39 2006
@@ -139,6 +139,71 @@ void drm_free_pages(unsigned long addres
}
#if __OS_HAS_AGP
+/*
+ * Find the drm_map that covers the range [offset, offset+size).
+ */
+drm_map_t *drm_lookup_map(unsigned long offset,
+ unsigned long size, drm_device_t * dev)
+{
+ struct list_head *list;
+ drm_map_list_t *r_list;
+ drm_map_t *map;
+
+ list_for_each(list, &dev->maplist->head) {
+ r_list = (drm_map_list_t *) list;
+ map = r_list->map;
+ if (!map)
+ continue;
+ if (map->offset <= offset
+ && (offset + size) <= (map->offset + map->size))
+ return map;
+ }
+ return NULL;
+}
+
+void *agp_remap(unsigned long offset, unsigned long size,
+ drm_device_t * dev)
+{
+ unsigned long *phys_addr_map, i, num_pages =
+ PAGE_ALIGN(size) / PAGE_SIZE;
+ struct drm_agp_mem *agpmem;
+ struct page **page_map;
+ void *addr;
+
+ size = PAGE_ALIGN(size);
+
+#ifdef __alpha__
+ offset -= dev->hose->mem_space->start;
+#endif
+
+ for (agpmem = dev->agp->memory; agpmem; agpmem = agpmem->next)
+ if (agpmem->bound <= offset
+ && (agpmem->bound + (agpmem->pages << PAGE_SHIFT)) >=
+ (offset + size))
+ break;
+ if (!agpmem)
+ return NULL;
+
+ /*
+ * OK, we're mapping AGP space on a chipset/platform on which memory accesses by
+ * the CPU do not get remapped by the GART. We fix this by using the kernel's
+ * page-table instead (that's probably faster anyhow...).
+ */
+ /* note: use vmalloc() because num_pages could be large... */
+ page_map = vmalloc(num_pages * sizeof(struct page *));
+ if (!page_map)
+ return NULL;
+
+ phys_addr_map =
+ agpmem->memory->memory + (offset - agpmem->bound) / PAGE_SIZE;
+ for (i = 0; i < num_pages; ++i)
+ page_map[i] = pfn_to_page(phys_addr_map[i] >> PAGE_SHIFT);
+ addr = vmap(page_map, num_pages, VM_IOREMAP, PAGE_AGP);
+ vfree(page_map);
+
+ return addr;
+}
+
/** Wrapper around agp_allocate_memory() */
DRM_AGP_MEM *drm_alloc_agp(drm_device_t * dev, int pages, u32 type)
{
@@ -163,4 +228,56 @@ int drm_unbind_agp(DRM_AGP_MEM * handle)
return drm_agp_unbind_memory(handle);
}
#endif /* agp */
+
+void *drm_ioremap(unsigned long offset, unsigned long size,
+ drm_device_t * dev)
+{
+ if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture) {
+ drm_map_t *map = drm_lookup_map(offset, size, dev);
+
+ if (map && map->type == _DRM_AGP)
+ return agp_remap(offset, size, dev);
+ }
+ return ioremap(offset, size);
+}
+EXPORT_SYMBOL(drm_ioremap);
+
+void *drm_ioremap_nocache(unsigned long offset,
+ unsigned long size, drm_device_t * dev)
+{
+ if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture) {
+ drm_map_t *map = drm_lookup_map(offset, size, dev);
+
+ if (map && map->type == _DRM_AGP)
+ return agp_remap(offset, size, dev);
+ }
+ return ioremap_nocache(offset, size);
+}
+
+void drm_ioremapfree(void *pt, unsigned long size,
+ drm_device_t * dev)
+{
+ /*
+ * This is a bit ugly. It would be much cleaner if the DRM API would use separate
+ * routines for handling mappings in the AGP space. Hopefully this can be done in
+ * a future revision of the interface...
+ */
+ if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture
+ && ((unsigned long)pt >= VMALLOC_START
+ && (unsigned long)pt < VMALLOC_END)) {
+ unsigned long offset;
+ drm_map_t *map;
+
+ offset = drm_follow_page(pt) | ((unsigned long)pt & ~PAGE_MASK);
+ map = drm_lookup_map(offset, size, dev);
+ if (map && map->type == _DRM_AGP) {
+ vunmap(pt);
+ return;
+ }
+ }
+
+ iounmap(pt);
+}
+EXPORT_SYMBOL(drm_ioremapfree);
+
#endif /* debug_memory */
diff -urpN linux-2.6.16.org/drivers/char/drm/drm_memory.h linux-2.6.16.drm/drivers/char/drm/drm_memory.h
--- linux-2.6.16.org/drivers/char/drm/drm_memory.h Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.drm/drivers/char/drm/drm_memory.h Thu Apr 6 19:18:53 2006
@@ -60,67 +60,11 @@
/*
* Find the drm_map that covers the range [offset, offset+size).
*/
-static inline drm_map_t *drm_lookup_map(unsigned long offset,
- unsigned long size, drm_device_t * dev)
-{
- struct list_head *list;
- drm_map_list_t *r_list;
- drm_map_t *map;
-
- list_for_each(list, &dev->maplist->head) {
- r_list = (drm_map_list_t *) list;
- map = r_list->map;
- if (!map)
- continue;
- if (map->offset <= offset
- && (offset + size) <= (map->offset + map->size))
- return map;
- }
- return NULL;
-}
-
-static inline void *agp_remap(unsigned long offset, unsigned long size,
- drm_device_t * dev)
-{
- unsigned long *phys_addr_map, i, num_pages =
- PAGE_ALIGN(size) / PAGE_SIZE;
- struct drm_agp_mem *agpmem;
- struct page **page_map;
- void *addr;
-
- size = PAGE_ALIGN(size);
-
-#ifdef __alpha__
- offset -= dev->hose->mem_space->start;
-#endif
+drm_map_t *drm_lookup_map(unsigned long offset,
+ unsigned long size, drm_device_t * dev);
- for (agpmem = dev->agp->memory; agpmem; agpmem = agpmem->next)
- if (agpmem->bound <= offset
- && (agpmem->bound + (agpmem->pages << PAGE_SHIFT)) >=
- (offset + size))
- break;
- if (!agpmem)
- return NULL;
-
- /*
- * OK, we're mapping AGP space on a chipset/platform on which memory accesses by
- * the CPU do not get remapped by the GART. We fix this by using the kernel's
- * page-table instead (that's probably faster anyhow...).
- */
- /* note: use vmalloc() because num_pages could be large... */
- page_map = vmalloc(num_pages * sizeof(struct page *));
- if (!page_map)
- return NULL;
-
- phys_addr_map =
- agpmem->memory->memory + (offset - agpmem->bound) / PAGE_SIZE;
- for (i = 0; i < num_pages; ++i)
- page_map[i] = pfn_to_page(phys_addr_map[i] >> PAGE_SHIFT);
- addr = vmap(page_map, num_pages, VM_IOREMAP, PAGE_AGP);
- vfree(page_map);
-
- return addr;
-}
+void *agp_remap(unsigned long offset, unsigned long size,
+ drm_device_t * dev);
static inline unsigned long drm_follow_page(void *vaddr)
{
@@ -152,51 +96,11 @@ static inline unsigned long drm_follow_p
#endif
-static inline void *drm_ioremap(unsigned long offset, unsigned long size,
- drm_device_t * dev)
-{
- if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture) {
- drm_map_t *map = drm_lookup_map(offset, size, dev);
-
- if (map && map->type == _DRM_AGP)
- return agp_remap(offset, size, dev);
- }
- return ioremap(offset, size);
-}
-
-static inline void *drm_ioremap_nocache(unsigned long offset,
- unsigned long size, drm_device_t * dev)
-{
- if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture) {
- drm_map_t *map = drm_lookup_map(offset, size, dev);
-
- if (map && map->type == _DRM_AGP)
- return agp_remap(offset, size, dev);
- }
- return ioremap_nocache(offset, size);
-}
+void *drm_ioremap(unsigned long offset, unsigned long size,
+ drm_device_t * dev);
-static inline void drm_ioremapfree(void *pt, unsigned long size,
- drm_device_t * dev)
-{
- /*
- * This is a bit ugly. It would be much cleaner if the DRM API would use separate
- * routines for handling mappings in the AGP space. Hopefully this can be done in
- * a future revision of the interface...
- */
- if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture
- && ((unsigned long)pt >= VMALLOC_START
- && (unsigned long)pt < VMALLOC_END)) {
- unsigned long offset;
- drm_map_t *map;
-
- offset = drm_follow_page(pt) | ((unsigned long)pt & ~PAGE_MASK);
- map = drm_lookup_map(offset, size, dev);
- if (map && map->type == _DRM_AGP) {
- vunmap(pt);
- return;
- }
- }
+void *drm_ioremap_nocache(unsigned long offset,
+ unsigned long size, drm_device_t * dev);
- iounmap(pt);
-}
+void drm_ioremapfree(void *pt, unsigned long size,
+ drm_device_t * dev);
^ permalink raw reply
* [PATCH] powerpc: remove io_page_mask
From: Michael Neuling @ 2006-04-07 5:23 UTC (permalink / raw)
To: paulus, linuxppc-dev
From: Anton Blanchard <anton@samba.org>
Cleanup patch which removes the io_page_mask. It fixes the reset on
some e1000 devices which is needed for clean kexec reboots. The legacy
devices which broke with this patch (parallel port and PC speaker) have
now been fixed in Linus' tree.
Signed-off-by: Anton Blanchard <anton@samba.org>
Ack-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/iomap.c | 2 --
arch/powerpc/kernel/pci_64.c | 30 +++---------------------------
arch/powerpc/platforms/iseries/pci.c | 3 ---
arch/powerpc/platforms/maple/pci.c | 3 ---
arch/powerpc/platforms/powermac/pci.c | 3 ---
include/asm-powerpc/eeh.h | 15 +++------------
include/asm-powerpc/io.h | 6 ------
7 files changed, 6 insertions(+), 56 deletions(-)
Index: linux-2.6-powerpc/arch/powerpc/kernel/iomap.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/kernel/iomap.c
+++ linux-2.6-powerpc/arch/powerpc/kernel/iomap.c
@@ -106,8 +106,6 @@ EXPORT_SYMBOL(iowrite32_rep);
void __iomem *ioport_map(unsigned long port, unsigned int len)
{
- if (!_IO_IS_VALID(port))
- return NULL;
return (void __iomem *) (port+pci_io_base);
}
Index: linux-2.6-powerpc/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/kernel/pci_64.c
+++ linux-2.6-powerpc/arch/powerpc/kernel/pci_64.c
@@ -42,14 +42,6 @@
unsigned long pci_probe_only = 1;
int pci_assign_all_buses = 0;
-/*
- * legal IO pages under MAX_ISA_PORT. This is to ensure we don't touch
- * devices we don't have access to.
- */
-unsigned long io_page_mask;
-
-EXPORT_SYMBOL(io_page_mask);
-
#ifdef CONFIG_PPC_MULTIPLATFORM
static void fixup_resource(struct resource *res, struct pci_dev *dev);
static void do_bus_setup(struct pci_bus *bus);
@@ -1104,8 +1096,6 @@ void __init pci_setup_phb_io(struct pci_
pci_process_ISA_OF_ranges(isa_dn, hose->io_base_phys,
hose->io_base_virt);
of_node_put(isa_dn);
- /* Allow all IO */
- io_page_mask = -1;
}
}
@@ -1232,27 +1222,13 @@ static void phbs_remap_io(void)
static void __devinit fixup_resource(struct resource *res, struct pci_dev *dev)
{
struct pci_controller *hose = pci_bus_to_host(dev->bus);
- unsigned long start, end, mask, offset;
+ unsigned long offset;
if (res->flags & IORESOURCE_IO) {
offset = (unsigned long)hose->io_base_virt - pci_io_base;
- start = res->start += offset;
- end = res->end += offset;
-
- /* Need to allow IO access to pages that are in the
- ISA range */
- if (start < MAX_ISA_PORT) {
- if (end > MAX_ISA_PORT)
- end = MAX_ISA_PORT;
-
- start >>= PAGE_SHIFT;
- end >>= PAGE_SHIFT;
-
- /* get the range of pages for the map */
- mask = ((1 << (end+1)) - 1) ^ ((1 << start) - 1);
- io_page_mask |= mask;
- }
+ res->start += offset;
+ res->end += offset;
} else if (res->flags & IORESOURCE_MEM) {
res->start += hose->pci_mem_offset;
res->end += hose->pci_mem_offset;
Index: linux-2.6-powerpc/arch/powerpc/platforms/iseries/pci.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/platforms/iseries/pci.c
+++ linux-2.6-powerpc/arch/powerpc/platforms/iseries/pci.c
@@ -45,8 +45,6 @@
#include "call_pci.h"
#include "iommu.h"
-extern unsigned long io_page_mask;
-
/*
* Forward declares of prototypes.
*/
@@ -277,7 +275,6 @@ void iSeries_pcibios_init(void)
{
iomm_table_initialize();
find_and_init_phbs();
- io_page_mask = -1;
}
/*
Index: linux-2.6-powerpc/arch/powerpc/platforms/maple/pci.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/platforms/maple/pci.c
+++ linux-2.6-powerpc/arch/powerpc/platforms/maple/pci.c
@@ -437,9 +437,6 @@ void __init maple_pci_init(void)
/* Tell pci.c to not change any resource allocations. */
pci_probe_only = 1;
-
- /* Allow all IO */
- io_page_mask = -1;
}
int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev, int channel)
Index: linux-2.6-powerpc/arch/powerpc/platforms/powermac/pci.c
===================================================================
--- linux-2.6-powerpc.orig/arch/powerpc/platforms/powermac/pci.c
+++ linux-2.6-powerpc/arch/powerpc/platforms/powermac/pci.c
@@ -1068,9 +1068,6 @@ void __init pmac_pci_init(void)
/* Tell pci.c to not use the common resource allocation mechanism */
pci_probe_only = 1;
- /* Allow all IO */
- io_page_mask = -1;
-
#else /* CONFIG_PPC64 */
init_p2pbridge();
fixup_nec_usb2();
Index: linux-2.6-powerpc/include/asm-powerpc/eeh.h
===================================================================
--- linux-2.6-powerpc.orig/include/asm-powerpc/eeh.h
+++ linux-2.6-powerpc/include/asm-powerpc/eeh.h
@@ -293,8 +293,6 @@ static inline void eeh_memcpy_toio(volat
static inline u8 eeh_inb(unsigned long port)
{
u8 val;
- if (!_IO_IS_VALID(port))
- return ~0;
val = in_8((u8 __iomem *)(port+pci_io_base));
if (EEH_POSSIBLE_ERROR(val, u8))
return eeh_check_failure((void __iomem *)(port), val);
@@ -303,15 +301,12 @@ static inline u8 eeh_inb(unsigned long p
static inline void eeh_outb(u8 val, unsigned long port)
{
- if (_IO_IS_VALID(port))
- out_8((u8 __iomem *)(port+pci_io_base), val);
+ out_8((u8 __iomem *)(port+pci_io_base), val);
}
static inline u16 eeh_inw(unsigned long port)
{
u16 val;
- if (!_IO_IS_VALID(port))
- return ~0;
val = in_le16((u16 __iomem *)(port+pci_io_base));
if (EEH_POSSIBLE_ERROR(val, u16))
return eeh_check_failure((void __iomem *)(port), val);
@@ -320,15 +315,12 @@ static inline u16 eeh_inw(unsigned long
static inline void eeh_outw(u16 val, unsigned long port)
{
- if (_IO_IS_VALID(port))
- out_le16((u16 __iomem *)(port+pci_io_base), val);
+ out_le16((u16 __iomem *)(port+pci_io_base), val);
}
static inline u32 eeh_inl(unsigned long port)
{
u32 val;
- if (!_IO_IS_VALID(port))
- return ~0;
val = in_le32((u32 __iomem *)(port+pci_io_base));
if (EEH_POSSIBLE_ERROR(val, u32))
return eeh_check_failure((void __iomem *)(port), val);
@@ -337,8 +329,7 @@ static inline u32 eeh_inl(unsigned long
static inline void eeh_outl(u32 val, unsigned long port)
{
- if (_IO_IS_VALID(port))
- out_le32((u32 __iomem *)(port+pci_io_base), val);
+ out_le32((u32 __iomem *)(port+pci_io_base), val);
}
/* in-string eeh macros */
Index: linux-2.6-powerpc/include/asm-powerpc/io.h
===================================================================
--- linux-2.6-powerpc.orig/include/asm-powerpc/io.h
+++ linux-2.6-powerpc/include/asm-powerpc/io.h
@@ -37,12 +37,6 @@
extern unsigned long isa_io_base;
extern unsigned long pci_io_base;
-extern unsigned long io_page_mask;
-
-#define MAX_ISA_PORT 0x10000
-
-#define _IO_IS_VALID(port) ((port) >= MAX_ISA_PORT || (1 << (port>>PAGE_SHIFT)) \
- & io_page_mask)
#ifdef CONFIG_PPC_ISERIES
/* __raw_* accessors aren't supported on iSeries */
This is a
^ permalink raw reply
* Re: fs/binfmt_elf.c:maydump()
From: David S. Miller @ 2006-04-07 5:18 UTC (permalink / raw)
To: dan; +Cc: linux-kernel
In-Reply-To: <20060406.153518.60508780.davem@davemloft.net>
From: "David S. Miller" <davem@davemloft.net>
Date: Thu, 06 Apr 2006 15:35:18 -0700 (PDT)
> With this patch applied, yes, it includes the complete text segments of
> every executable and shared library mapped into the program which is
> dumping core.
I did some more research and the 2.4.x kernel currently does
the test like this:
static inline int maydump(struct vm_area_struct *vma)
{
/*
* If we may not read the contents, don't allow us to dump
* them either. "dump_write()" can't handle it anyway.
*/
if (!(vma->vm_flags & VM_READ))
return 0;
/* Do not dump I/O mapped devices! -DaveM */
if (vma->vm_flags & VM_IO)
return 0;
#if 1
if (vma->vm_flags & (VM_WRITE|VM_GROWSUP|VM_GROWSDOWN))
return 1;
if (vma->vm_flags & (VM_READ|VM_EXEC|VM_EXECUTABLE|VM_SHARED))
return 0;
#endif
return 1;
}
Ok, if it's not readable don't put it into the core file, fine.
If it's an I/O mapping, skip it too, also makes sense.
The next check forces dumping of any wriable or stack segments.
The function always terminates at the next check, because VM_READ
is guarenteed to be set if we get here. The first thing we
checked is if VM_READ was clear at the very top of the function.
Yikes...
Anyways, so what's exactly happening in 2.6.x right now?
static int maydump(struct vm_area_struct *vma)
{
/* Do not dump I/O mapped devices or special mappings */
if (vma->vm_flags & (VM_IO | VM_RESERVED))
return 0;
/* Dump shared memory only if mapped from an anonymous file. */
if (vma->vm_flags & VM_SHARED)
return vma->vm_file->f_dentry->d_inode->i_nlink == 0;
/* If it hasn't been written to, don't write it out */
if (!vma->anon_vma)
return 0;
return 1;
}
Skip reserved or I/O mappings, ok.
Else skip shared mappings of non-anonymous files. I'm not so sure
about this check.
Else skip any mapping not written to yet. I still think at this
point the logic is wrong.
How about something like the following patch? If it's executable
and not written to, skip it. This would skip the main executable
image and all text segments of the shared libraries mapped in.
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 537893a..9ec5c2b 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1167,8 +1167,10 @@ static int maydump(struct vm_area_struct
if (vma->vm_flags & VM_SHARED)
return vma->vm_file->f_dentry->d_inode->i_nlink == 0;
- /* If it hasn't been written to, don't write it out */
- if (!vma->anon_vma)
+ /* If it is executable and hasn't been written to,
+ * don't write it out.
+ */
+ if ((vma->vm_flags & VM_EXEC) && !vma->anon_vma)
return 0;
return 1;
^ permalink raw reply related
* Dual Core CPU on Abit NI8-Board
From: Frank von Daak @ 2006-04-07 5:07 UTC (permalink / raw)
To: linux-acpi
Hello!
I've a problem with my configuration and maybe someone of you can help me out.
My system looks like this:
Abit NI8 SLI mother board
CPU Pentium-D 2,8 GHz (dual-core)
1 GB DDR2-RAM (one module)
2x GeForc7800GTX grahpics adapter (to connect three monitors)
kernel 2.6.17-rc1 (vanilla)
My problem ist, that a "cat /proc/cpuinfo" show's just one cpu-core if I boot
with ACPI enabled.
If I disable ACPI by removing it from kernel or by passing 'append="acpi=off"'
to my lilo.conf, the system is going unstable. It is freezing sporadical
without any trace output. The freezes occur after a short time, especialy
when I run OpenGL-applications - but also without OpenGL!
I have collected some information about my system here:
--------------------------------------------------------------
dmesg's output with acpi-debug enabled in kernel:
http://www.kpage.de/dmesg_acpi3.txt
My kernels ".config"-file:
http://www.kpage.de/config.txt
The output of "cat /proc/interrupts" when ACPI is enabled:
http://www.kpage.de/interrupts_acpi3.txt
The output of "cat /proc/interrupts" when ACPI is disabled:
http://www.kpage.de/interrupts_noacpi3.txt
The output of "cat /proc/cpuinfo" if ACPI is enabled:
http://www.kpage.de/cpuinfo_acpi3.txt
The output of "cat /proc/cpuinfo" if ACPI is disabled:
http://www.kpage.de/cpuinfo_noacpi3.txt
And last, but not least: the output of "acpidump":
http://www.kpage.de/acpidump.txt
--------------------------------------------------------------
I've started a discussion about this problem on the linux-smp mailinglist. You
can find some more information about what I've done by now here:
http://marc.theaimsgroup.com/?l=linux-smp&m=114421848813280&w=2
I have also contacted nvidia and abit - without response from abit by the
time...
Who can give me a little help?
Thank you very much!!!
Greetings
Frank
--
Name: Frank von Daak
^ permalink raw reply
* Re: + pg_uncached-is-ia64-only.patch added to -mm tree
From: David S. Miller @ 2006-04-07 4:59 UTC (permalink / raw)
To: linux-kernel, akpm
Cc: kamezawa.hiroyu, jbarnes, jes, nickpiggin, tony.luck, mm-commits
In-Reply-To: <20060406215242.245340de.akpm@osdl.org>
From: Andrew Morton <akpm@osdl.org>
Date: Thu, 6 Apr 2006 21:52:42 -0700
> It's easier to change FLAGS_RESERVED ;)
It reminds me that I need to do something about the fact that
Sparc64 makes use of bits 24-->32 currently to record the cpu
that performs cpu stores into and thus dirties the D-cache for
a pagecache page.
^ permalink raw reply
* debug unresolved in the tokliBIOS.lib while generating binary for the 55xx using the codegen toll
From: prafulla chandra vejendla @ 2006-04-07 4:56 UTC (permalink / raw)
To: linux-omap-open-source
Hi all,
i am using the DSP GATEWAY to communicate between the ARM and DSP processor.
i am using the gateway version 3.1 for my linux 2.6.11.3
i have generated the tokliBIOS.lib using the ccs version 3.1 . this
generated library i am using in the make file for generating the user binary
executables. but i got error message like "*debug unresolved in the
tokliBIOS.lib*".
why it is comming ?? is there any relation between the error and the ccs
version.??
in the tokliBIOS.lib generation pdf procedure is mentioned for the ccs
version 2.20. what could be the changes that i need to made to generate the
same tokliBIOS.lib using the ccs version 3.1 .
what could be the problem??
thanks in advance
--prafulla chandra
^ permalink raw reply
* Re: + pg_uncached-is-ia64-only.patch added to -mm tree
From: Andrew Morton @ 2006-04-07 4:52 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, jbarnes, jes, nickpiggin, tony.luck, mm-commits
In-Reply-To: <20060407134827.91a47e69.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> Hi, Andrew
>
> On Thu, 06 Apr 2006 21:20:26 -0700
> akpm@osdl.org wrote:
>
> >
> > The patch titled
> >
> > PG_uncached is ia64 only
> >
> > has been added to the -mm tree. Its filename is
> >
> > pg_uncached-is-ia64-only.patch
> >
> > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> > out what to do about this
> >
>
> in include/linux/mmzone.h
> ==
> #elif BITS_PER_LONG == 64
> /*
> * with 64 bit flags field, there's plenty of room.
> */
> #define FLAGS_RESERVED 32
>
> #else
OK.
>
> it looks this is used here.
>
> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > FLAGS_RESERVED
> #error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > FLAGS_RESERVED
> #endif
>
> I'm not sure but please compile check FLAGS_RESRVED with SPARSEMEM or
>
Yes, that test won't trigger.
>
> #if (BITS_PER_LONG > 32) /* 64-bit only flags. we can use full
> low 32bits */
> #define PG_uncached 31
> #endif
>
> Hm..Is this ugly ? :(
It's easier to change FLAGS_RESERVED ;)
diff -puN include/linux/page-flags.h~pg_uncached-is-ia64-only include/linux/page-flags.h
--- devel/include/linux/page-flags.h~pg_uncached-is-ia64-only 2006-04-06 21:50:51.000000000 -0700
+++ devel-akpm/include/linux/page-flags.h 2006-04-06 21:50:51.000000000 -0700
@@ -7,6 +7,8 @@
#include <linux/percpu.h>
#include <linux/cache.h>
+#include <linux/types.h>
+
#include <asm/pgtable.h>
/*
@@ -86,7 +88,10 @@
#define PG_mappedtodisk 16 /* Has blocks allocated on-disk */
#define PG_reclaim 17 /* To be reclaimed asap */
#define PG_nosave_free 18 /* Free, should not be written */
-#define PG_uncached 19 /* Page has been mapped as uncached */
+
+#if (BITS_PER_LONG > 32)
+#define PG_uncached 32 /* Page has been mapped as uncached */
+#endif
/*
* Global page accounting. One instance per CPU. Only unsigned longs are
diff -puN include/linux/mmzone.h~pg_uncached-is-ia64-only include/linux/mmzone.h
--- devel/include/linux/mmzone.h~pg_uncached-is-ia64-only 2006-04-06 21:50:56.000000000 -0700
+++ devel-akpm/include/linux/mmzone.h 2006-04-06 21:51:12.000000000 -0700
@@ -457,7 +457,7 @@ extern struct zone *next_zone(struct zon
/*
* with 64 bit flags field, there's plenty of room.
*/
-#define FLAGS_RESERVED 32
+#define FLAGS_RESERVED 24
#else
_
^ permalink raw reply
* [lm-sensors] [PATCH 2/2 RESEND] hwmon: add vt1211 documentation
From: Juerg Haefliger @ 2006-04-07 4:51 UTC (permalink / raw)
To: lm-sensors
This patch adds documentation for the new vt1211 Super-IO driver.
Signed-off-by: Juerg Haefliger <juergh at gmail.com
<http://lists.lm-sensors.org/mailman/listinfo/lm-sensors>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060407/b0488e51/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hwmon-vt1211-documentation.patch
Type: application/octet-stream
Size: 7490 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060407/b0488e51/hwmon-vt1211-documentation.obj
^ permalink raw reply
* Re: + pg_uncached-is-ia64-only.patch added to -mm tree
From: KAMEZAWA Hiroyuki @ 2006-04-07 4:48 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, jbarnes, jes, nickpiggin, tony.luck, mm-commits
In-Reply-To: <200604070421.k374LXFs011197@shell0.pdx.osdl.net>
Hi, Andrew
On Thu, 06 Apr 2006 21:20:26 -0700
akpm@osdl.org wrote:
>
> The patch titled
>
> PG_uncached is ia64 only
>
> has been added to the -mm tree. Its filename is
>
> pg_uncached-is-ia64-only.patch
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
in include/linux/mmzone.h
==
#elif BITS_PER_LONG == 64
/*
* with 64 bit flags field, there's plenty of room.
*/
#define FLAGS_RESERVED 32
#else
==
it looks this is used here.
#if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > FLAGS_RESERVED
#error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > FLAGS_RESERVED
#endif
I'm not sure but please compile check FLAGS_RESRVED with SPARSEMEM or
just
#if (BITS_PER_LONG > 32) /* 64-bit only flags. we can use full
low 32bits */
#define PG_uncached 31
#endif
Hm..Is this ugly ? :(
-Kame
>
> From: Andrew Morton <akpm@osdl.org>
>
> As Nick points out, only ia64 uses PG_uncached. So we can push it up into the
> higher 32-bits of page->flgs and make room for another flag on 32-bit
> machines.
>
> Cc: "Luck, Tony" <tony.luck@intel.com>
> Cc: Jesse Barnes <jbarnes@sgi.com>
> Cc: Jes Sorensen <jes@trained-monkey.org>
> Cc: Nick Piggin <nickpiggin@yahoo.com.au>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> include/linux/page-flags.h | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletion(-)
>
> diff -puN include/linux/page-flags.h~pg_uncached-is-ia64-only include/linux/page-flags.h
> --- devel/include/linux/page-flags.h~pg_uncached-is-ia64-only 2006-04-06 21:17:16.000000000 -0700
> +++ devel-akpm/include/linux/page-flags.h 2006-04-06 21:18:31.000000000 -0700
> @@ -7,6 +7,8 @@
>
> #include <linux/percpu.h>
> #include <linux/cache.h>
> +
> +#include <asm/types.h>
> #include <asm/pgtable.h>
>
> /*
> @@ -86,7 +88,10 @@
> #define PG_mappedtodisk 16 /* Has blocks allocated on-disk */
> #define PG_reclaim 17 /* To be reclaimed asap */
> #define PG_nosave_free 18 /* Free, should not be written */
> -#define PG_uncached 19 /* Page has been mapped as uncached */
> +
> +#if (BITS_PER_LONG > 32)
> +#define PG_uncached 32 /* Page has been mapped as uncached */
> +#endif
>
> /*
> * Global page accounting. One instance per CPU. Only unsigned longs are
> _
>
> Patches currently in -mm which might be from akpm@osdl.org are
>
> select-warning-fixes.patch
> config_net=n-build-fix.patch
> git-acpi.patch
> acpi-update-asus_acpi-driver-registration-fix.patch
> acpi-memory-hotplug-cannot-manage-_crs-with-plural-resoureces.patch
> catch-notification-of-memory-add-event-of-acpi-via-container-driver-register-start-func-for-memory-device.patch
> catch-notification-of-memory-add-event-of-acpi-via-container-driveravoid-redundant-call-add_memory.patch
> sony_apci-resume.patch
> powernow-k8-crash-workaround.patch
> git-drm.patch
> bt866-build-fix.patch
> connector-exports.patch
> git-ia64.patch
> git-libata-all.patch
> pci-error-recovery-e1000-network-device-driver.patch
> pcmcia-remove-unneeded-forward-declarations.patch
> git-scsi-misc.patch
> megaraid-unused-variable.patch
> git-sas-jg.patch
> git-sas-jg-build-hack.patch
> git-watchdog.patch
> arm-add_memory-build-fix.patch
> acx1xx-wireless-driver.patch
> ext3-ext3-in-kernel-block-number-type-fixes-fix.patch
> sync_file_range-use-unsigned-for-flags.patch
> timer-initialisation-fix.patch
> timer-initialisation-fix-tidy.patch
> s3c24xx-gpio-led-support-tidy.patch
> make-tty_insert_flip_string_flags-a-non-gpl-export.patch
> prune_one_dentry-tweaks.patch
> sys_kexec_load-naming-fixups.patch
> hangcheck-remove-monotomic_clock-on-x86.patch
> knfsd-nfsd4-limit-number-of-delegations-handed-out-fix.patch
> pi-futex-futex-code-cleanups-fix.patch
> reiser4.patch
> kgdb-core-lite-add-reboot-command.patch
> kgdb-8250-fix.patch
> nr_blockdev_pages-in_interrupt-warning.patch
> device-suspend-debug.patch
> revert-tty-buffering-comment-out-debug-code.patch
> slab-leaks3-default-y.patch
> x86-kmap_atomic-debugging.patch
> pg_uncached-is-ia64-only.patch
>
> -
> To unsubscribe from this list: send the line "unsubscribe mm-commits" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ANNOUNCE: mdadm 2.4.1 - A tool for managing Soft RAID under Linux
From: Neil Brown @ 2006-04-07 4:41 UTC (permalink / raw)
To: linux-raid
I am pleased to announce the availability of
mdadm version 2.4.1
It is available at the usual places:
http://www.cse.unsw.edu.au/~neilb/source/mdadm/
and
http://www.{countrycode}.kernel.org/pub/linux/utils/raid/mdadm/
mdadm is a tool for creating, managing and monitoring
device arrays using the "md" driver in Linux, also
known as Software RAID arrays.
2.4.1 primarily fixes an alignment problem in the version-1
superblock. This is an incompatible change relating to
raid5-reshape. Read the change log below.
Changelog Entries:
- Honour --write-mostly when adding to an array without persistent
superblocks.
- Fix alignment problem in version-1 superblocks.
NOTE: This is an incompatable change affecting raid5 reshape.
If you want to reshape a raid5 using version-1 superblocks,
use 2.6.17-rc2 or later, and mdadm-2.4.1 or later.
Development of mdadm is sponsored by
SUSE Labs, Novell Inc.
NeilBrown 7th April 2006
^ permalink raw reply
* Re: mdadm > 2.2 ver1 superblock regression?
From: Neil Brown @ 2006-04-07 4:40 UTC (permalink / raw)
To: Mike Snitzer, linux-raid
In-Reply-To: <17461.49011.622350.590931@cse.unsw.edu.au>
On Friday April 7, neilb@suse.de wrote:
>
> Seeing this hasn't made it into a released kernel yet, I might just
> change it. But I'll have to make sure that old mdadm's don't mess
> things up ... I wonder how I will do that :-(
>
> Thanks for the report.
Yes, try 2.4.1 (just released).
Thanks again,
NeilBrown
^ permalink raw reply
* please ...Clarify me Regarding "PPTP PASS THRU" with 4 modules Loaded
From: vasudevan @ 2006-04-07 4:39 UTC (permalink / raw)
To: netfilter
Hi,
Can you please mention me how are these modules loaded help me in "PPTP
PASS THROUGH". The modules as stated below.
Can you please explain the usage of these modules in Connection tracking
and NAT support for PPTP.
The loaded modules are as follows
ip_conntrack_proto_gre
ip_conntrack_pptp
ip_nat_proto_gre
ip_nat_pptp
Thanks in advance,
Vasudevan N.
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 4:38 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 06:38 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 02:35
----------------------------------------------------------------------
Try adding { .subvendor = 0x1043, .subdevice = 0x81b9, .action =
VIA_DXS_SRC } to the PCI ids in via82xx.c for the first device.
As for the "VIA high definition audio controller", I think that's a new
device that isn't supported yet. tiwai?
----------------------------------------------------------------------
mborsick - 04-07-06 06:38
----------------------------------------------------------------------
As I am a step above novice when it comes to Linux, where exactly do I find
via82xx.c file? I am assuming the kernel, but at this point, you have
me...
<G>
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* vfs_rmdir race with nfsd
From: YAMAMOTO Takashi @ 2006-04-07 4:33 UTC (permalink / raw)
To: nfs
[-- Attachment #1: Type: Text/Plain, Size: 408 bytes --]
hi,
the attached diff is to fix a race with nfsd.
if someone (ie. nfsd) dget the dentry in the meantime,
it can stay unhashed and can cause directory dentry aliases later.
i chose this mailing list because i think it can't happen without
nfsd involved.
although the diff is against a locally modified version of 2.4.24,
i think that the same problem exists in both of 2.4.30 and 2.6.16.
YAMAMOTO Takashi
[-- Attachment #2: a.diff --]
[-- Type: Text/Plain, Size: 306 bytes --]
--- ./fs/namei.c.BACKUP Wed Apr 5 19:43:27 2006
+++ ./fs/namei.c Thu Apr 6 12:08:15 2006
@@ -1424,6 +1424,8 @@ int vfs_rmdir(struct inode *dir, struct
if (!error) {
inode_dir_notify(dir, DN_DELETE);
d_delete(dentry);
+ } else if (d_unhashed(dentry)) {
+ d_rehash(dentry);
}
dput(dentry);
^ permalink raw reply
* [lm-sensors] [PATCH 1/2 RESEND] hwmon: new vt1211 driver
From: Juerg Haefliger @ 2006-04-07 4:28 UTC (permalink / raw)
To: lm-sensors
Incorporated suggestions made by Rudolf Marek.
This is a new driver for the VIA vt1211 Super-IO chip. It is a rewrite of the
existing vt1211 driver (by Mark D. Studebaker and Lars Ekman) that has been
around for a while but never made it into the main kernel tree. It is
implemented as a platform driver and therefore requires the latest CVS version
of lm_sensors to function properly.
Signed-off-by: Juerg Haefliger <juergh at gmail.com
<http://lists.lm-sensors.org/mailman/listinfo/lm-sensors>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060407/8aeac2fa/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hwmon-vt1211-new-driver.patch
Type: application/octet-stream
Size: 36195 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060407/8aeac2fa/hwmon-vt1211-new-driver-0001.obj
^ permalink raw reply
* [PATCH] md: Make sure 64bit fields in version-1 metadata are 64-bit aligned.
From: NeilBrown @ 2006-04-07 4:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-raid, linux-kernel
In-Reply-To: <20060407142239.19652.patches@notabene>
This patch should go in 2.6.17-rc2 if at all possible. If the problem
gets left much longer, a more ugly solution might be needed.
### Comments for Changeset
reshape_position is a 64bit field that was not 64bit aligned.
So swap with new_level.
NOTE: this is a user-visible change. However:
- The bad code has not appeared in a released kernel
- This code is still marked 'experimental'
- This only affects version-1 superblock, which are not in wide use
- These field are only used (rather than simply reported) by user-space
tools in extemely rare circumstances : after a reshape crashes in the
first second of the reshape process.
So I believe that, at this stage, the change is safe. Especially if
people heed the 'help' message on use mdadm-2.4.1.
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output
./drivers/md/Kconfig | 11 ++++++-----
./include/linux/raid/md_p.h | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff ./drivers/md/Kconfig~current~ ./drivers/md/Kconfig
--- ./drivers/md/Kconfig~current~ 2006-04-07 14:15:42.000000000 +1000
+++ ./drivers/md/Kconfig 2006-04-07 14:16:35.000000000 +1000
@@ -139,11 +139,12 @@ config MD_RAID5_RESHAPE
is online. However it is still EXPERIMENTAL code. It should
work, but please be sure that you have backups.
- You will need a version of mdadm newer than 2.3.1. During the
- early stage of reshape there is a critical section where live data
- is being over-written. A crash during this time needs extra care
- for recovery. The newer mdadm takes a copy of the data in the
- critical section and will restore it, if necessary, after a crash.
+ You will need mdadm verion 2.4.1 or later to use this
+ feature safely. During the early stage of reshape there is
+ a critical section where live data is being over-written. A
+ crash during this time needs extra care for recovery. The
+ newer mdadm takes a copy of the data in the critical section
+ and will restore it, if necessary, after a crash.
The mdadm usage is e.g.
mdadm --grow /dev/md1 --raid-disks=6
diff ./include/linux/raid/md_p.h~current~ ./include/linux/raid/md_p.h
--- ./include/linux/raid/md_p.h~current~ 2006-04-07 14:11:53.000000000 +1000
+++ ./include/linux/raid/md_p.h 2006-04-07 14:14:48.000000000 +1000
@@ -227,8 +227,8 @@ struct mdp_superblock_1 {
*/
/* These are only valid with feature bit '4' */
- __u64 reshape_position; /* next address in array-space for reshape */
__u32 new_level; /* new level we are reshaping to */
+ __u64 reshape_position; /* next address in array-space for reshape */
__u32 delta_disks; /* change in number of raid_disks */
__u32 new_layout; /* new layout */
__u32 new_chunk; /* new chunk size (bytes) */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.