* see info
From: Rupinder Merkle @ 2006-04-03 16:37 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 130 bytes --]
Get ready in 15 minutes - d C x i j a n l o i k s x S a O f F s T n T k
a i b f s go to the site <http://qyhu37.mycarandr.com>
[-- Attachment #2: Type: text/html, Size: 1080 bytes --]
^ permalink raw reply
* Re: patch : hdaps on Thinkpad R52
From: Frank Gevaerts @ 2006-04-03 16:35 UTC (permalink / raw)
To: Jean Delvare; +Cc: Frank Gevaerts, Robert Love, linux-kernel
In-Reply-To: <20060401170422.cc2ff8c2.khali@linux-fr.org>
On Sat, Apr 01, 2006 at 05:04:22PM +0200, Jean Delvare wrote:
> Hi Frank,
>
> > # dmidecode 2.8
> > (...)
> > System Information
> > Manufacturer: IBM
> > Product Name: 1846AQG
> > Version: ThinkPad H
>
> OK, so as strange as it sounds, that's really the string as stored in
> the DMI table. How odd... You have to understand that I'm a bit
> reluctant to adding it officially to the hdaps driver, given that it
> clearly looks like a bogus table in your laptop. I guess that you only
> have one laptop with this string?
I just had a mail from another R52 user, reporting that his system
(also 1846AQG) also reports ThinkPad H.
Frank
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
^ permalink raw reply
* [PATCH] Replace xmalloc+memset(0) with xcalloc.
From: Peter Eriksen @ 2006-04-03 16:35 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Mon Apr 3 19:30:46 2006 +0100
Subject: [PATCH] Replace xmalloc+memset(0) with xcalloc.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
Is something like this considered a cleaup?
Regards,
Peter
apply.c | 9 +++------
blob.c | 3 +--
commit.c | 3 +--
convert-objects.c | 3 +--
http-push.c | 6 ++----
object.c | 6 ++----
read-tree.c | 9 +++------
tag.c | 3 +--
tree.c | 7 ++-----
update-index.c | 6 ++----
10 files changed, 18 insertions(+), 37 deletions(-)
d5c82aa8a2b9d776bb30efac17d15a8a596b47f4
diff --git a/apply.c b/apply.c
index c50b3a6..6623ae7 100644
--- a/apply.c
+++ b/apply.c
@@ -924,8 +924,7 @@ static int parse_single_patch(char *line
struct fragment *fragment;
int len;
- fragment = xmalloc(sizeof(*fragment));
- memset(fragment, 0, sizeof(*fragment));
+ fragment = xcalloc(1, sizeof(*fragment));
len = parse_fragment(line, size, patch, fragment);
if (len <= 0)
die("corrupt patch at line %d", linenr);
@@ -1651,8 +1650,7 @@ static void add_index_file(const char *p
if (!write_index)
return;
- ce = xmalloc(ce_size);
- memset(ce, 0, ce_size);
+ ce = xcalloc(1, ce_size);
memcpy(ce->name, path, namelen);
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = htons(namelen);
@@ -1808,8 +1806,7 @@ static int apply_patch(int fd, const cha
struct patch *patch;
int nr;
- patch = xmalloc(sizeof(*patch));
- memset(patch, 0, sizeof(*patch));
+ patch = xcalloc(1, sizeof(*patch));
nr = parse_chunk(buffer + offset, size, patch);
if (nr < 0)
break;
diff --git a/blob.c b/blob.c
index 84ec121..c1fdd86 100644
--- a/blob.c
+++ b/blob.c
@@ -8,8 +8,7 @@ struct blob *lookup_blob(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct blob *ret = xmalloc(sizeof(struct blob));
- memset(ret, 0, sizeof(struct blob));
+ struct blob *ret = xcalloc(1, sizeof(struct blob));
created_object(sha1, &ret->object);
ret->object.type = blob_type;
return ret;
diff --git a/commit.c b/commit.c
index eb42d51..d4976fb 100644
--- a/commit.c
+++ b/commit.c
@@ -73,8 +73,7 @@ struct commit *lookup_commit(const unsig
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct commit *ret = xmalloc(sizeof(struct commit));
- memset(ret, 0, sizeof(struct commit));
+ struct commit *ret = xcalloc(1, sizeof(struct commit));
created_object(sha1, &ret->object);
ret->object.type = commit_type;
return ret;
diff --git a/convert-objects.c b/convert-objects.c
index b49bce2..b2aafbb 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -18,8 +18,7 @@ static struct entry * convert_entry(unsi
static struct entry *insert_new(unsigned char *sha1, int pos)
{
- struct entry *new = xmalloc(sizeof(struct entry));
- memset(new, 0, sizeof(*new));
+ struct entry *new = xcalloc(1, sizeof(struct entry));
memcpy(new->old_sha1, sha1, 20);
memmove(convert + pos + 1, convert + pos, (nr_convert - pos) * sizeof(struct entry *));
convert[pos] = new;
diff --git a/http-push.c b/http-push.c
index ba7d9de..b60fa8d 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1008,8 +1008,7 @@ static int fetch_indices(void)
struct active_request_slot *slot;
struct slot_results results;
- data = xmalloc(4096);
- memset(data, 0, 4096);
+ data = xcalloc(1, 4096);
buffer.size = 4096;
buffer.posn = 0;
buffer.buffer = data;
@@ -2042,8 +2041,7 @@ static void update_remote_info_refs(stru
char *if_header;
struct curl_slist *dav_headers = NULL;
- buffer.buffer = xmalloc(4096);
- memset(buffer.buffer, 0, 4096);
+ buffer.buffer = xcalloc(1, 4096);
buffer.size = 4096;
buffer.posn = 0;
remote_ls("refs/", (PROCESS_FILES | RECURSIVE),
diff --git a/object.c b/object.c
index c9ca481..71e15e1 100644
--- a/object.c
+++ b/object.c
@@ -85,8 +85,7 @@ struct object_refs *alloc_object_refs(un
struct object_refs *refs;
size_t size = sizeof(*refs) + count*sizeof(struct object *);
- refs = xmalloc(size);
- memset(refs, 0, size);
+ refs = xcalloc(1, size);
refs->count = count;
return refs;
}
@@ -178,8 +177,7 @@ struct object *lookup_unknown_object(con
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- union any_object *ret = xmalloc(sizeof(*ret));
- memset(ret, 0, sizeof(*ret));
+ union any_object *ret = xcalloc(1, sizeof(*ret));
created_object(sha1, &ret->object);
ret->object.type = NULL;
return &ret->object;
diff --git a/read-tree.c b/read-tree.c
index eaff444..58e5636 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -133,11 +133,9 @@ #endif
pathlen = strlen(first);
ce_size = cache_entry_size(baselen + pathlen);
- src = xmalloc(sizeof(struct cache_entry *) * src_size);
- memset(src, 0, sizeof(struct cache_entry *) * src_size);
+ src = xcalloc(src_size, sizeof(struct cache_entry *));
- subposns = xmalloc(sizeof(struct tree_list_entry *) * len);
- memset(subposns, 0, sizeof(struct tree_list_entry *) * len);
+ subposns = xcalloc(len, sizeof(struct tree_list_entry *));
if (cache_name && !strcmp(cache_name, first)) {
any_files = 1;
@@ -177,8 +175,7 @@ #endif
else
ce_stage = 2;
- ce = xmalloc(ce_size);
- memset(ce, 0, ce_size);
+ ce = xcalloc(1, ce_size);
ce->ce_mode = create_ce_mode(posns[i]->mode);
ce->ce_flags = create_ce_flags(baselen + pathlen,
ce_stage);
diff --git a/tag.c b/tag.c
index ac0e573..f390ee7 100644
--- a/tag.c
+++ b/tag.c
@@ -19,8 +19,7 @@ struct tag *lookup_tag(const unsigned ch
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tag *ret = xmalloc(sizeof(struct tag));
- memset(ret, 0, sizeof(struct tag));
+ struct tag *ret = xcalloc(1, sizeof(struct tag));
created_object(sha1, &ret->object);
ret->object.type = tag_type;
return ret;
diff --git a/tree.c b/tree.c
index 87e0d74..d599fb5 100644
--- a/tree.c
+++ b/tree.c
@@ -18,10 +18,8 @@ static int read_one_entry(unsigned char
len = strlen(pathname);
size = cache_entry_size(baselen + len);
- ce = xmalloc(size);
+ ce = xcalloc(1, size);
- memset(ce, 0, size);
-
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = create_ce_flags(baselen + len, stage);
memcpy(ce->name, base, baselen);
@@ -130,8 +128,7 @@ struct tree *lookup_tree(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tree *ret = xmalloc(sizeof(struct tree));
- memset(ret, 0, sizeof(struct tree));
+ struct tree *ret = xcalloc(1, sizeof(struct tree));
created_object(sha1, &ret->object);
ret->object.type = tree_type;
return ret;
diff --git a/update-index.c b/update-index.c
index 797245a..1efac27 100644
--- a/update-index.c
+++ b/update-index.c
@@ -114,8 +114,7 @@ static int add_file_to_cache(const char
namelen = strlen(path);
size = cache_entry_size(namelen);
- ce = xmalloc(size);
- memset(ce, 0, size);
+ ce = xcalloc(1, size);
memcpy(ce->name, path, namelen);
ce->ce_flags = htons(namelen);
fill_stat_cache_info(ce, &st);
@@ -312,8 +311,7 @@ static int add_cacheinfo(unsigned int mo
len = strlen(path);
size = cache_entry_size(len);
- ce = xmalloc(size);
- memset(ce, 0, size);
+ ce = xcalloc(1, size);
memcpy(ce->sha1, sha1, 20);
memcpy(ce->name, path, len);
--
1.3.0.rc1.g40e9
^ permalink raw reply related
* Re: accessed/dirty bit handler tuning
From: Zoltan Menyhart @ 2006-04-03 16:33 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <44157CF1.5060902@bull.net>
Luck, Tony wrote:
>>It is very much curious having so few dirty and i-access traps...
>
>
> Your data collection code has races (ld8, add, st8 on one cpu can
> race with another cpu doing the same). So you'll undercount whenever
> a race happens.
>
> Perhaps you should use per-cpu counters to collect the values, and
> then sum for each cpu in the syscall() before reporting to the user?
It was not very important to count the events precisely.
The lesson I learnt is the VHPT miss handler is the most important
(maybe the D-ACCESS trap handler), the others are "neglectable".
(I have not counted yet the handlers not doing a purge.)
The problem is that the most frequently used trap handler contains
the unsafe walk of the
rx = IA64_KR_PT_BASE -> pgd[i] -> pud[j] -> pmd[k] -> pte[l]
chain...
Zoltan
^ permalink raw reply
* Re: Changes over dmix: 1.0.11rc4 and future
From: Lee Revell @ 2006-04-03 16:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h3bgvc739.wl%tiwai@suse.de>
On Mon, 2006-04-03 at 11:59 +0200, Takashi Iwai wrote:
>
> If you still get an error regarding variable_buffer_size, just remove
> that line.
>
> And note that this won't work with emu10k1.
I now get:
Playing WAVE '/usr/share/sounds/error.wav' : Signed 16 bit Little
Endian, Rate 44100 Hz, Mono
ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not
usable
aplay: set_params:879: Broken configuration for this PCM: no
configurations available
Which I think is normal as hw:0,0 on the emu10k1 is only a stereo
device.
Lee
-------------------------------------------------------
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
* Re: Overhead of Using a Stackable File System(Wrapfs)
From: Erez Zadok @ 2006-04-03 16:27 UTC (permalink / raw)
To: UZAIR LAKHANI; +Cc: linux-fsdevel
In-Reply-To: <20060402093211.27655.qmail@web37911.mail.mud.yahoo.com>
You can find a lot of papers spanning several years and covering a wide
variety of stackable file systems, with detailed performance evaluations,
here:
http://www.filesystems.org/
Erez.
^ permalink raw reply
* Re: git-svn and svn sw --relocate
From: Nicolas Vilz 'niv' @ 2006-04-03 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060402222100.GA17888@localdomain>
Eric Wong wrote:
> Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
>>i have now my repository locally and i want to get it remotely on a
>>server, in order to have a few collaborators...
>>
>>the steps on the svn-side are clear. But what do i have todo on the
>>git-svn-side of this life?
>>
>>does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
>
>
> Yes, you'll need to do that in .git/git-svn/tree and also update
> .git/git-svn/info/url by hand.
Will there be any other sha1-sums for that repository so that i have to
merge them again and again? This issue occured to me the last time i
encountered the git-svn-change with the external sources, where i had to
repair my external git-svn-tree, which resulted in new sha1sums
somehow... that was very unpleasant to my collegue..
Although the uuids there should remain the same... so i think, that
would be no problem to try.
Thanks for the tip.
Nicolas
^ permalink raw reply
* [PATCH] fix MIPS PFN/page borkage (take 2)
From: Dave Hansen @ 2006-04-03 16:21 UTC (permalink / raw)
To: ralf; +Cc: linux-kernel, Dave Hansen
The "unify PFN_* macros" patch screwed up and somehow modified
the MIPS code where it shouldn't have. This backs those changes
back out.
Also remember to include the new header in the MIPS files.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---
work-dave/arch/mips/mips-boards/generic/memory.c | 5 +++--
work-dave/arch/mips/mips-boards/sim/sim_mem.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff -puN arch/mips/mips-boards/generic/memory.c~unify_PFN_macros arch/mips/mips-boards/generic/memory.c
--- work/arch/mips/mips-boards/generic/memory.c~unify_PFN_macros 2006-04-03 09:09:42.000000000 -0700
+++ work-dave/arch/mips/mips-boards/generic/memory.c 2006-04-03 09:20:36.000000000 -0700
@@ -22,6 +22,7 @@
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/bootmem.h>
+#include <linux/pfn.h>
#include <linux/string.h>
#include <asm/bootinfo.h>
@@ -106,10 +107,10 @@ struct prom_pmemblock * __init prom_getm
mdesc[3].type = yamon_dontuse;
mdesc[3].base = 0x00100000;
- mdesc[3].size = CPHYSADDR(PAGE_ALIGN(&_end)) - mdesc[3].base;
+ mdesc[3].size = CPHYSADDR(PFN_ALIGN(&_end)) - mdesc[3].base;
mdesc[4].type = yamon_free;
- mdesc[4].base = CPHYSADDR(PAGE_ALIGN(&_end));
+ mdesc[4].base = CPHYSADDR(PFN_ALIGN(&_end));
mdesc[4].size = memsize - mdesc[4].base;
return &mdesc[0];
diff -puN arch/mips/mips-boards/sim/sim_mem.c~unify_PFN_macros arch/mips/mips-boards/sim/sim_mem.c
--- work/arch/mips/mips-boards/sim/sim_mem.c~unify_PFN_macros 2006-04-03 09:09:42.000000000 -0700
+++ work-dave/arch/mips/mips-boards/sim/sim_mem.c 2006-04-03 09:20:46.000000000 -0700
@@ -17,6 +17,7 @@
*/
#include <linux/init.h>
#include <linux/mm.h>
+#include <linux/pfn.h>
#include <linux/bootmem.h>
#include <asm/bootinfo.h>
@@ -61,10 +62,10 @@ struct prom_pmemblock * __init prom_getm
mdesc[2].type = simmem_reserved;
mdesc[2].base = 0x00100000;
- mdesc[2].size = CPHYSADDR(PAGE_ALIGN(&_end)) - mdesc[2].base;
+ mdesc[2].size = CPHYSADDR(PFN_ALIGN(&_end)) - mdesc[2].base;
mdesc[3].type = simmem_free;
- mdesc[3].base = CPHYSADDR(PAGE_ALIGN(&_end));
+ mdesc[3].base = CPHYSADDR(PFN_ALIGN(&_end));
mdesc[3].size = memsize - mdesc[3].base;
return &mdesc[0];
_
^ permalink raw reply
* Re: [PATCHSET] libata: improve ata_bus_probe failure handling, take 2
From: Jeff Garzik @ 2006-04-03 16:20 UTC (permalink / raw)
To: Greg Freemyer; +Cc: albertl, Tejun Heo, linux-ide, alan
In-Reply-To: <87f94c370604030737y7ef96ed8g5d887ff768845956@mail.gmail.com>
Greg Freemyer wrote:
> On 4/3/06, Jeff Garzik <jgarzik@pobox.com> wrote:
>
>> For the record, I do consider irq-pio upstream ready. It still needs to
>> wait for Tejun's EH work to make it upstream, to give upstream people
>> the test sets of
>>
>> - prep EH (2.6.17-rc1)
>> - EH
>> - NCQ
>> - irq-pio
>>
>> Since each of these sets is staged, upstream testers will be able to say
>> "2.6.17-rc1 works, but 2.6.18-git1 doesn't", which gives us a lot of
>> good info.
>>
>> Jeff
>
> So for those of us anxiously waiting for the above great enhancements
> it looks like it will be 5 months or so before it is in a released
> vanilla kernel? ie. assuming 2 1/2 months per kernel release.
Heavens no :)
The stages above just need to be separated out by a few 2.6.X-gitX or
2.6.X-rcX releases.
Jeff
^ permalink raw reply
* creating partition mappings with different delimiters
From: Eddie Williams @ 2006-04-03 16:19 UTC (permalink / raw)
To: dm-devel
Where/how does kpartx determine the default delimiter when creating the
partition mappings and nodes?
With Red Hat EL 4 Update 3 during bootup the partition mappings are
getting created in rc.sysinit. However I find that some of the mappings
have no delimiter while some have 'p' as the delimiter. I prefer 'p' as
the delimiter.
I have been unsuccessful at finding where kpartx (or is it dmsetup) is
determining what delimiter to use.
Eddie
^ permalink raw reply
* Re: _machine removal breaks kexec?
From: Benjamin Herrenschmidt @ 2006-04-03 16:16 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060403014044.GA4704@krispykreme>
On Mon, 2006-04-03 at 11:40 +1000, Anton Blanchard wrote:
> Hi,
>
> It looks like the _machine removal broke kexec:
>
> # kexec -l vmlinux
> /proc/device-tree/chosen/linux,platform: No such file or directory
>
> The kexec tools seem to want the linux,platform property:
>
> /* if LPAR, no need to read any more from /chosen */
> if (platform != PLATFORM_PSERIES) {
> closedir(cdir);
> continue;
> }
Damn.... the platform numbers are gone, we need to fix that. (And nobody
complained when I posted the patch twice over the past couple of monthes
btw).
I suppose kexec needs to look for /rtas/hypertas or such ..
Ben.
^ permalink raw reply
* Re: [PATCH] fix MIPS PFN/page borkage
From: Ralf Baechle @ 2006-04-03 16:16 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel
In-Reply-To: <20060403161131.0790DD9A@localhost.localdomain>
On Mon, Apr 03, 2006 at 09:11:31AM -0700, Dave Hansen wrote:
> The "unify PFN_* macros" patch screwed up and somehow modified
> the MIPS code where it shouldn't have. This backs those changes
> back out.
You need to include <linux/pfn.h> for this to build.
Ralf
^ permalink raw reply
* Re: alsa cvs broken
From: Takashi Iwai @ 2006-04-03 16:15 UTC (permalink / raw)
To: Rene Herman; +Cc: Jaroslav Kysela, James Courtier-Dutton, alsa-devel
In-Reply-To: <443147CC.40905@keyaccess.nl>
At Mon, 03 Apr 2006 18:05:32 +0200,
Rene Herman wrote:
>
> Jaroslav Kysela wrote:
>
> > I must say that git looks too much "kernel" oriented and sometimes
> > hard-to-use. Mercurial has my sympatics, because it uses Python (on
> > other hand, it might imply some performance issues).
> >
> > I would start with mercurial and we'll see then.
>
> Mind a vote against mercurial, and for GIT? Not because I think GIT is
> necesarily (and at the moment) better -- I in fact don't know either yet
> in any detail.
>
> GIT is the kernel SCM though and unless it's really significantly worse,
> I believe it's better to simply use it. I've been looking to get into
> ALSA a bit for example, and I'd really not appreciate having to learn
> yet another SCM when I'm going to be making use of GIT for all the other
> kernel stuff anyway.
It's true that git would be in favor from the kernel viewpoint.
However, ALSA has pretty many other stuff. The kernel code is even a
small part.
What I'm not quite sure is the push-functionality of git. If we have
a main development tree, the patches are pushed by multiple
developers. It's a different use from kernel trees.
If the multiple push works fine with git, I have nothing against it at
all.
> GIT is also still picking up speed. Keith Packard was even converting X
> CVS for example. Mercurial might be good I guess, but it's also very
> likely going to be one of those "oh no, not yet another" ones, maybe
> even keeping potential developers away.
We can anyway provide a nightly tarball for lazy developers :)
Let's evaluate both first.
Takashi
-------------------------------------------------------
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
* Re: False OOM with swappiness == 0
From: Mikulas Patocka @ 2006-04-03 16:13 UTC (permalink / raw)
To: LKML
In-Reply-To: <Pine.LNX.4.64.0604031811270.7588@artax.karlin.mff.cuni.cz>
> Hi
>
> On one our server we've seen that OOM killer kills a process even if there's
> plenty of free swap space. The server had swappiness set to 0 which probably
> triggered the bug.
>
> Mikulas
I forgot to tell kernel version: 2.6.15-gentoo-r1. Dual Opteron with 4G
RAM.
Mikulas
^ permalink raw reply
* Re: [linux-usb-devel] Problems with USB setup with Linux 2.6.16
From: Mark Lord @ 2006-04-03 16:12 UTC (permalink / raw)
To: Joshua Kwan; +Cc: Alan Stern, linux-kernel, linux-usb-devel
In-Reply-To: <44309821.1090600@triplehelix.org>
Joshua Kwan wrote:
> On 04/02/2006 07:09 PM, Alan Stern wrote:
>> If you were to continue looking farther down in the log, you would find
>> that ehci-hcd sees all those devices. Those that can run at high speed
>> continue using the EHCI controller. For those that can't, the switch is
>> reset and they get reconnected to their UHCI controller.
>
> That makes sense - that is indeed what happens when it DOES work (i.e.
> with 2.6.15), but the fact is that they don't come back in 2.6.16. I
> will try building ehci-hcd in and see what happens.
Around 2.6.13, I noticed that EHCI stopped working after a suspend/resume
(to/from RAM) cycle. So I updated my suspend script to unload/reload EHCI
each time, which fixed the problem for me. My script still does that.
Dunno if it's fixed in mainline or not.
Does unloading/reloading EHCI help you?
rmmod ehci_hcd ; modprobe ehci_hcd
Cheers
^ permalink raw reply
* False OOM with swappiness == 0
From: Mikulas Patocka @ 2006-04-03 16:12 UTC (permalink / raw)
To: LKML
Hi
On one our server we've seen that OOM killer kills a process even if
there's plenty of free swap space. The server had swappiness set to 0
which probably triggered the bug.
Mikulas
^ permalink raw reply
* [PATCH] fix MIPS PFN/page borkage
From: Dave Hansen @ 2006-04-03 16:11 UTC (permalink / raw)
To: ralf; +Cc: linux-kernel, Dave Hansen
The "unify PFN_* macros" patch screwed up and somehow modified
the MIPS code where it shouldn't have. This backs those changes
back out.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---
work-dave/arch/mips/mips-boards/generic/memory.c | 4 ++--
work-dave/arch/mips/mips-boards/sim/sim_mem.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff -puN arch/mips/mips-boards/generic/memory.c~unify_PFN_macros arch/mips/mips-boards/generic/memory.c
--- work/arch/mips/mips-boards/generic/memory.c~unify_PFN_macros 2006-04-03 09:09:42.000000000 -0700
+++ work-dave/arch/mips/mips-boards/generic/memory.c 2006-04-03 09:09:42.000000000 -0700
@@ -106,10 +106,10 @@ struct prom_pmemblock * __init prom_getm
mdesc[3].type = yamon_dontuse;
mdesc[3].base = 0x00100000;
- mdesc[3].size = CPHYSADDR(PAGE_ALIGN(&_end)) - mdesc[3].base;
+ mdesc[3].size = CPHYSADDR(PFN_ALIGN(&_end)) - mdesc[3].base;
mdesc[4].type = yamon_free;
- mdesc[4].base = CPHYSADDR(PAGE_ALIGN(&_end));
+ mdesc[4].base = CPHYSADDR(PFN_ALIGN(&_end));
mdesc[4].size = memsize - mdesc[4].base;
return &mdesc[0];
diff -puN arch/mips/mips-boards/sim/sim_mem.c~unify_PFN_macros arch/mips/mips-boards/sim/sim_mem.c
--- work/arch/mips/mips-boards/sim/sim_mem.c~unify_PFN_macros 2006-04-03 09:09:42.000000000 -0700
+++ work-dave/arch/mips/mips-boards/sim/sim_mem.c 2006-04-03 09:09:42.000000000 -0700
@@ -61,10 +61,10 @@ struct prom_pmemblock * __init prom_getm
mdesc[2].type = simmem_reserved;
mdesc[2].base = 0x00100000;
- mdesc[2].size = CPHYSADDR(PAGE_ALIGN(&_end)) - mdesc[2].base;
+ mdesc[2].size = CPHYSADDR(PFN_ALIGN(&_end)) - mdesc[2].base;
mdesc[3].type = simmem_free;
- mdesc[3].base = CPHYSADDR(PAGE_ALIGN(&_end));
+ mdesc[3].base = CPHYSADDR(PFN_ALIGN(&_end));
mdesc[3].size = memsize - mdesc[3].base;
return &mdesc[0];
_
^ permalink raw reply
* Re: [RFC] install_session_keyring
From: Suzanne Wood @ 2006-04-03 16:11 UTC (permalink / raw)
To: dhowells; +Cc: linux-kernel, paulmck
> From David Howells Mon Apr 3 01:46:08 2006
> Suzanne Wood <suzannew@cs.pdx.edu> wrote:
> > In a study of the control flow graph dumps to check that
> > an rcu_assign_pointer() with a given argument type has
> > preceded a call to rcu_dereference(), I've come across
> > install_session_keyring() of security/keys/process_keys.c.
> > We note that although no rcu_read_lock() is in place
> > locally or in the function's kernel callers, siglock
> > likely addresses that. While the rcu_dereference() would
> > indicate a desire for 'old' to persist, synchronize_rcu()
> > is called prior to key_put(old) which "disposes of
> > reference to a key." The order of events with a use of
> > the copy of the pointer following synchronize_rcu() is
> > what I question.
> Are you simply suggesting that the rcu_dereference() in:
> /* install the keyring */
> spin_lock_irqsave(&tsk->sighand->siglock, flags);
> old = rcu_dereference(tsk->signal->session_keyring);
> rcu_assign_pointer(tsk->signal->session_keyring, keyring);
> spin_unlock_irqrestore(&tsk->sighand->siglock, flags);
> is unnecessary?
Since RCU is applicable in read intensive environments and I
look for rcu_dereference() on the read side to be paired with
rcu_assign_pointer() on the update side, I wonder if key_put()
might be redundant or risky after synchronize_rcu(), because
key_put() opens with if(key) and employs atomic_dec_and_test(&key->usage))
before schedule_work(&key_cleanup_task). If the memory referenced
by old has already been reclaimed which appears is made possible by
synchronize_rcu(), it seems that there is a contention here.
Yes, so I guess you mean to get rid of 'old' altogether and the three
lines that refer to it. But I think the original intent was to have
the former session keyring persist to some extent.
Thanks.
Suzanne
> If so, I think you are right since the pointer is only changed with the
> siglock held[*], and so modify/modify conflict isn't a problem and doesn't
> need memory barriers.
> [*] Apart from during the exit() cleanup, when I don't think this should be a
> problem anyway.
> David
^ permalink raw reply
* [PATCH] Remove some dead code from xenconsole
From: Anthony Liguori @ 2006-04-03 16:11 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 130 bytes --]
Remove some bit rot from the changes to the console driver over the 3.0
series. Only compile tested.
Regards,
Anthony Liguori
[-- Attachment #2: xenconsole-dead-code.diff --]
[-- Type: text/plain, Size: 1322 bytes --]
# HG changeset patch
# User Anthony Liguori <anthony@codemonkey.ws>
# Node ID e3e364456cac763c144468591df0528536b8cff4
# Parent 4ad317429111d43cc99810af25b3faf6ffed4209
Remove some dead code from the consoled client.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
diff -r 4ad317429111 -r e3e364456cac tools/console/client/main.c
--- a/tools/console/client/main.c Sun Apr 2 16:16:53 2006 +0100
+++ b/tools/console/client/main.c Mon Apr 3 11:06:59 2006 -0500
@@ -36,7 +36,6 @@
#include <errno.h>
#include <pty.h>
-#include "xenctrl.h"
#include "xs.h"
#define ESCAPE_CHARACTER 0x1d
@@ -92,7 +91,7 @@
tcsetattr(fd, TCSAFLUSH, old);
}
-static int console_loop(int xc_handle, domid_t domid, int fd)
+static int console_loop(int fd)
{
int ret;
@@ -161,7 +160,6 @@
{
struct termios attr;
int domid;
- int xc_handle;
char *sopt = "h";
int ch;
int opt_ind=0;
@@ -206,11 +204,6 @@
err(errno, "Could not contact XenStore");
}
- xc_handle = xc_interface_open();
- if (xc_handle == -1) {
- err(errno, "xc_interface_open()");
- }
-
signal(SIGTERM, sighandler);
path = xs_get_domain_path(xs, domid);
@@ -260,7 +253,7 @@
free(path);
init_term(STDIN_FILENO, &attr);
- console_loop(xc_handle, domid, spty);
+ console_loop(spty);
restore_term(STDIN_FILENO, &attr);
return 0;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH -rt] have highres runqueue adjust_prio
From: Steven Rostedt @ 2006-04-03 16:07 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Ingo Molnar, LKML
Currently, the low res runqueue in hrtimers calls adjust prio, but the
high res does not.
-- Steve
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Index: linux-2.6.16-rt11/kernel/hrtimer.c
===================================================================
--- linux-2.6.16-rt11.orig/kernel/hrtimer.c 2006-03-30 08:28:18.000000000 -0500
+++ linux-2.6.16-rt11/kernel/hrtimer.c 2006-03-30 10:41:38.000000000 -0500
@@ -951,6 +951,7 @@
BUG_ON(hrtimer_active(timer));
enqueue_hrtimer(timer, base);
}
+ hrtimer_adjust_softirq_prio(base);
}
set_curr_timer(base, NULL);
spin_unlock_irq(&base->lock);
^ permalink raw reply
* [PATCH] UML - TLS fixlets
From: Jeff Dike @ 2006-04-03 15:07 UTC (permalink / raw)
To: torvalds; +Cc: Blaisorblade, linux-kernel, user-mode-linux-devel
Two small TLS fixes -
arch/um/os-Linux/sys-i386/tls.c uses errno and -E* so it should include
errno.h
__setup_host_supports_tls returns 1, but as an initcall, it should return 0
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Index: linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/os-Linux/sys-i386/tls.c 2006-04-03 09:39:23.000000000 -0400
+++ linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c 2006-04-03 09:39:42.000000000 -0400
@@ -1,3 +1,4 @@
+#include <errno.h>
#include <linux/unistd.h>
#include "sysdep/tls.h"
#include "user_util.h"
Index: linux-2.6.16/arch/um/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/sys-i386/tls.c 2006-04-03 09:39:15.000000000 -0400
+++ linux-2.6.16/arch/um/sys-i386/tls.c 2006-04-03 09:39:43.000000000 -0400
@@ -378,7 +378,7 @@ static int __init __setup_host_supports_
} else
printk(KERN_ERR " Host TLS support NOT detected! "
"TLS support inside UML will not work\n");
- return 1;
+ return 0;
}
__initcall(__setup_host_supports_tls);
^ permalink raw reply
* [uml-devel] [PATCH] UML - TLS fixlets
From: Jeff Dike @ 2006-04-03 15:07 UTC (permalink / raw)
To: torvalds; +Cc: Blaisorblade, linux-kernel, user-mode-linux-devel
Two small TLS fixes -
arch/um/os-Linux/sys-i386/tls.c uses errno and -E* so it should include
errno.h
__setup_host_supports_tls returns 1, but as an initcall, it should return 0
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Index: linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/os-Linux/sys-i386/tls.c 2006-04-03 09:39:23.000000000 -0400
+++ linux-2.6.16/arch/um/os-Linux/sys-i386/tls.c 2006-04-03 09:39:42.000000000 -0400
@@ -1,3 +1,4 @@
+#include <errno.h>
#include <linux/unistd.h>
#include "sysdep/tls.h"
#include "user_util.h"
Index: linux-2.6.16/arch/um/sys-i386/tls.c
===================================================================
--- linux-2.6.16.orig/arch/um/sys-i386/tls.c 2006-04-03 09:39:15.000000000 -0400
+++ linux-2.6.16/arch/um/sys-i386/tls.c 2006-04-03 09:39:43.000000000 -0400
@@ -378,7 +378,7 @@ static int __init __setup_host_supports_
} else
printk(KERN_ERR " Host TLS support NOT detected! "
"TLS support inside UML will not work\n");
- return 1;
+ return 0;
}
__initcall(__setup_host_supports_tls);
-------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: alsa cvs broken
From: Rene Herman @ 2006-04-03 16:05 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Takashi Iwai, James Courtier-Dutton, alsa-devel
In-Reply-To: <Pine.LNX.4.61.0604031458460.9509@tm8103.perex-int.cz>
Jaroslav Kysela wrote:
> I must say that git looks too much "kernel" oriented and sometimes
> hard-to-use. Mercurial has my sympatics, because it uses Python (on
> other hand, it might imply some performance issues).
>
> I would start with mercurial and we'll see then.
Mind a vote against mercurial, and for GIT? Not because I think GIT is
necesarily (and at the moment) better -- I in fact don't know either yet
in any detail.
GIT is the kernel SCM though and unless it's really significantly worse,
I believe it's better to simply use it. I've been looking to get into
ALSA a bit for example, and I'd really not appreciate having to learn
yet another SCM when I'm going to be making use of GIT for all the other
kernel stuff anyway.
GIT is also still picking up speed. Keith Packard was even converting X
CVS for example. Mercurial might be good I guess, but it's also very
likely going to be one of those "oh no, not yet another" ones, maybe
even keeping potential developers away.
Rene.
-------------------------------------------------------
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
* [PATCH] - add symmetry to para and fully virtualized domain shutdown/reboot
From: Ben Thomas @ 2006-04-03 15:57 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]
Add code to make handling domain poweroff/reboot symmetrical
between paravirtualized and fully virtualized.
A paravirtualized domain uses sched_op to shut down and set the
reason code. This will send a VIRQ_DOM_EXC, which can be
handled in dom0 by control software. In some ways, this resembles
SIGCHILD/waitpid, and is a reasonable model.
The fully virtualized case has qemu invoke xm directly. This is a
different path than paravirtualized. It also removes
decision and policy making choices from the rest of the control
software and places it within qemu. When any dom0 logic
eventually gets a VIRQ_DOM_EXC, the information about the
domain is gone having been destroyed by xm.
It would be useful if all shutdown/reboot operations were
symmetrical from domain 0's point of view. One approach
would be to redefine sched_op to handle other domains than
the current domain, but this seemed excessive. Another
approach, which is what this patch implements, adds
a DOM0 hypervisor call very similar to the existing
DOM0_DESTROYDOMAIN, called DOM0_SHUTDOWNDOMAIN, which handles
the shutdown and reason -- basically, just like a
paravirtualized system.
Like DOM0_DESTROYDOMAIN, add a xenctrl wrapper, and have qemu
call it.
With this change, both domain types shutdown/reboot using
the same dom0 management logic. All control decisions are
removed from qemu, which now simply handles the request
and reason. At a very high level, the flow is "notify of
shutdown and reason", "send VIRQ_DOM_EXC", process, and
destroy domain. Paravirtualized and fully-virtualized
domains would differ slightly in the first step of
notification. Paravirtualized continues to use sched_op,
fully virtualized uses DOM0_SHUTDOWNDOMAIN. The rest
of the steps would be identical in both cases.
Or, back to the opening sentence, make the operations as
symmetrical as possible.
(As a freebie, #if 0 some very verbose logging code in qemu.
Totally unrelated, but as long as I was there...)
Signed-off-by: Ben Thomas (ben@virtualiron.com)
--
------------------------------------------------------------------------
Ben Thomas Virtual Iron Software
bthomas@virtualiron.com Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851
[-- Attachment #2: shutdown.patch --]
[-- Type: text/x-patch, Size: 5608 bytes --]
diff -r 4ad317429111 tools/ioemu/target-i386-dm/helper2.c
--- a/tools/ioemu/target-i386-dm/helper2.c Sun Apr 2 16:16:53 2006 +0100
+++ b/tools/ioemu/target-i386-dm/helper2.c Mon Apr 3 11:22:29 2006 -0400
@@ -409,12 +409,20 @@ void
void
destroy_hvm_domain(void)
{
- extern FILE* logfile;
- char destroy_cmd[32];
-
- sprintf(destroy_cmd, "xm destroy %d", domid);
- if (system(destroy_cmd) == -1)
- fprintf(logfile, "%s failed.!\n", destroy_cmd);
+ int xcHandle;
+ int sts;
+
+ xcHandle = xc_interface_open();
+ if (xcHandle < 0)
+ fprintf(logfile, "Cannot acquire xenctrl handle\n");
+ else {
+ sts = xc_domain_shutdown(xcHandle, domid, SHUTDOWN_poweroff);
+ if (sts != 0)
+ fprintf(logfile, "? xc_domain_shutdown failed to issue poweroff, sts %d\n", sts);
+ else
+ fprintf(logfile, "Issued domain %d poweroff\n", domid);
+ xc_interface_close(xcHandle);
+ }
}
fd_set wakeup_rfds;
@@ -480,13 +488,24 @@ int main_loop(void)
static void qemu_hvm_reset(void *unused)
{
- char cmd[64];
+ int xcHandle;
+ int sts;
/* pause domain first, to avoid repeated reboot request*/
xc_domain_pause(xc_handle, domid);
- sprintf(cmd, "xm shutdown -R %d", domid);
- system(cmd);
+ xcHandle = xc_interface_open();
+ if (xcHandle < 0)
+ fprintf(logfile, "Cannot acquire xenctrl handle\n");
+ else {
+ sts = xc_domain_shutdown(xcHandle, domid, SHUTDOWN_reboot);
+ if (sts != 0)
+ fprintf(logfile, "? xc_domain_shutdown failed to issue reboot, sts %d\n", sts);
+ else
+ fprintf(logfile, "Issued domain %d reboot\n", domid);
+ xc_interface_close(xcHandle);
+ }
+
}
CPUState * cpu_init()
diff -r 4ad317429111 tools/ioemu/vl.c
--- a/tools/ioemu/vl.c Sun Apr 2 16:16:53 2006 +0100
+++ b/tools/ioemu/vl.c Mon Apr 3 11:22:29 2006 -0400
@@ -2556,8 +2556,10 @@ static int set_mm_mapping(int xc_handle,
return -1;
}
+#if 0 /* Enable for debugging -- generates many lines in log file */
for (i = 0; i < nr_pages; i++)
fprintf(stderr, "set_map result i %x result %lx\n", i, extent_start[i]);
+#endif
return 0;
}
diff -r 4ad317429111 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c Sun Apr 2 16:16:53 2006 +0100
+++ b/tools/libxc/xc_domain.c Mon Apr 3 11:22:29 2006 -0400
@@ -55,6 +55,17 @@ int xc_domain_destroy(int xc_handle,
DECLARE_DOM0_OP;
op.cmd = DOM0_DESTROYDOMAIN;
op.u.destroydomain.domain = (domid_t)domid;
+ return do_dom0_op(xc_handle, &op);
+}
+
+int xc_domain_shutdown(int xc_handle,
+ uint32_t domid,
+ int reason)
+{
+ DECLARE_DOM0_OP;
+ op.cmd = DOM0_SHUTDOWNDOMAIN;
+ op.u.shutdowndomain.domain = (domid_t)domid;
+ op.u.shutdowndomain.shutdown_reason = reason;
return do_dom0_op(xc_handle, &op);
}
diff -r 4ad317429111 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h Sun Apr 2 16:16:53 2006 +0100
+++ b/tools/libxc/xenctrl.h Mon Apr 3 11:22:29 2006 -0400
@@ -205,6 +205,21 @@ int xc_domain_unpause(int xc_handle,
*/
int xc_domain_destroy(int xc_handle,
uint32_t domid);
+
+/**
+ * This function will shutdown a domain. This is intended for use in
+ * fully-virtualized domains where this operation is analogous to the
+ * sched_op operations in a paravirtualized domain. The caller is
+ * expected to give the reason for the shutdown.
+ *
+ * @parm xc_handle a handle to an open hypervisor interface
+ * @parm domid the domain id to destroy
+ * @parm reason is the reason (SHUTDOWN_xxx) for the shutdown
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_shutdown(int xc_handle,
+ uint32_t domid,
+ int reason);
int xc_vcpu_setaffinity(int xc_handle,
uint32_t domid,
diff -r 4ad317429111 xen/common/dom0_ops.c
--- a/xen/common/dom0_ops.c Sun Apr 2 16:16:53 2006 +0100
+++ b/xen/common/dom0_ops.c Mon Apr 3 11:22:29 2006 -0400
@@ -682,6 +682,23 @@ long do_dom0_op(GUEST_HANDLE(dom0_op_t)
break;
#endif
+ case DOM0_SHUTDOWNDOMAIN:
+ {
+ struct domain *d = find_domain_by_id(op->u.shutdowndomain.domain);
+ ret = -ESRCH;
+ if ( d != NULL )
+ {
+ ret = -EINVAL;
+ if ( d != current->domain )
+ {
+ domain_shutdown(d, op->u.shutdowndomain.shutdown_reason);
+ ret = 0;
+ }
+ put_domain(d);
+ }
+ }
+ break;
+
default:
ret = arch_do_dom0_op(op, u_dom0_op);
break;
diff -r 4ad317429111 xen/include/public/dom0_ops.h
--- a/xen/include/public/dom0_ops.h Sun Apr 2 16:16:53 2006 +0100
+++ b/xen/include/public/dom0_ops.h Mon Apr 3 11:22:29 2006 -0400
@@ -470,6 +470,15 @@ typedef struct dom0_hypercall_init {
unsigned long mfn; /* machine frame to be initialised */
} dom0_hypercall_init_t;
DEFINE_GUEST_HANDLE(dom0_hypercall_init_t);
+
+#define DOM0_SHUTDOWNDOMAIN 49
+typedef struct dom0_shutdowndomain {
+ /* IN variables. */
+ domid_t domain; /* domain to be affected */
+ int shutdown_reason; /* SHUTDOWN_xxx reason code */
+} dom0_shutdowndomain_t;
+
+DEFINE_GUEST_HANDLE(dom0_shutdowndomain_t);
typedef struct dom0_op {
uint32_t cmd;
@@ -512,6 +521,7 @@ typedef struct dom0_op {
struct dom0_irq_permission irq_permission;
struct dom0_iomem_permission iomem_permission;
struct dom0_hypercall_init hypercall_init;
+ struct dom0_shutdowndomain shutdowndomain;
uint8_t pad[128];
} u;
} dom0_op_t;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* how to use v4l / em2820 | em2840
From: Rakotomandimby Mihamina @ 2006-04-03 16:00 UTC (permalink / raw)
To: linux-kernel
Hi,
I just bougth a Pinnacle Dazzle DV90 USB device:
http://www.mwave.com/mwave/skusearch.hmx?SCriteria=3491061&CartID=done&nextloc=
It is known to work on Linux:
http://www.linuxhq.com/kernel/v2.6/15/Documentation/video4linux/CARDLIST.em28xx
The problem... I did not find any documentation about how to use the
module, to acquire some video + audio with this device.
- I should load em2820
- What others modules have I got to load too?
- Then what command line to perform to save the capture to a file?
( what is the /dev/foo/bar? ....)
I dont use any particular distribution for the moment, but ask to all
the MLs.
Thank you for your help.
The reply-to is set to me first but I will merge all the information
into a tutorial if I get ver it.
--
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
^ 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.