* [PATCH] xc_core.c - Fix order of evaluation issue in xc_domain_dumpcore
From: Ben Thomas @ 2006-03-09 1:41 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Fix order-of-evaluation issue in xc_domain_dumpcore. The intent is
to move blocks of memory 4096 pages at a time, and a buffer is
allocated for this. Unfortunately, the #define is without
parentheses and %/* are the same order and evaluated left to right.
Result: very big buffer being used 4 pages at a time. Luckily,
the fix is simple.
Signed-off-by: Ben Thomas (bthomas@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: xc_core.patch --]
[-- Type: text/x-patch, Size: 382 bytes --]
diff -r 96678f701d42 tools/libxc/xc_core.c
--- a/tools/libxc/xc_core.c Mon Mar 6 11:12:48 2006 -0500
+++ b/tools/libxc/xc_core.c Wed Mar 8 20:36:21 2006 -0500
@@ -6,7 +6,7 @@
#include <zlib.h>
/* number of pages to write at a time */
-#define DUMP_INCREMENT 4 * 1024
+#define DUMP_INCREMENT (4 * 1024)
#define round_pgup(_p) (((_p)+(PAGE_SIZE-1))&PAGE_MASK)
static int
[-- 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
* Re: [BUG] Performance issues if DCCP packets are routed
From: Ian McDonald @ 2006-03-09 1:41 UTC (permalink / raw)
To: dccp
In-Reply-To: <cbec11ac0603081740o2004650dr8a91de3dd9418189@mail.gmail.com>
What I neglected to say is that TCP works fine and it is very low latency...
On 3/9/06, Ian McDonald <imcdnzl@gmail.com> wrote:
> I've been testing DCCP using netem for quite a while now - just about
> always with loss and delay. This works really well.
>
> A few weeks ago I noticed that if netem isn't turned on but traffic
> still goes between boxes through a router the performance is abysmal -
> can be as low as 20K per second instead of 100 Mbit and there is much
> data loss.
>
> I had assumed that this was a recent regression so parked it until I
> had time to test. However I just tested with a clean 2.6.14 and the
> problem persists....
>
> The test setup is
>
> 10.0.1.31 ----- 10.0.1.33/10.0.2.33 ------- 10.0.2.32
>
> and the command is just:
> (from 10.0.1.31) ./ttcp_acme -c -l500 -n10000 -t 10.0.2.32
> and
> (from 10.0.2.32) ./ttcp_acme -c -l500 -n10000 -r
>
> the following setup works fine:
> 10.0.1.31 ----- 10.0.1.33
> ./ttcp_acme -c -l500 -n10000 -t 10.0.1.33
> and
> ./ttcp_acme -c -l500 -n10000 -r
>
> I'll add this to my list of bugs to look at at some stage (along with
> updating tx buffering, CCID2 not working with loss/delay) but
> interested in seeing if others have similar problems?
>
> Ian
> --
> Ian McDonald
> Web: http://wand.net.nz/~iam4
> Blog: http://imcdnzl.blogspot.com
> WAND Network Research Group
> Department of Computer Science
> University of Waikato
> New Zealand
>
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* Re: [PATCH 01/16] RTC Subsystem, library functions
From: Alessandro Zummo @ 2006-03-09 1:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, akpm
In-Reply-To: <20060309012850.GY4006@stusta.de>
On Thu, 9 Mar 2006 02:28:50 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> On Mon, Mar 06, 2006 at 02:50:09AM +0100, Alessandro Zummo wrote:
> >...
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-rtc/drivers/rtc/Kconfig 2006-03-05 02:48:31.000000000 +0100
> > @@ -0,0 +1,6 @@
> > +#
> > +# RTC class/drivers configuration
> > +#
> > +
> > +config RTC_LIB
> > + bool
> >...
>
> I'd still say this should be a tristate (a MODULE_LICENSE("GPL") in
> rtc-lib.c seems to be the only other change required for this).
right, I forgot to modify this. applied :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* [BUG] Performance issues if DCCP packets are routed
From: Ian McDonald @ 2006-03-09 1:40 UTC (permalink / raw)
To: dccp
I've been testing DCCP using netem for quite a while now - just about
always with loss and delay. This works really well.
A few weeks ago I noticed that if netem isn't turned on but traffic
still goes between boxes through a router the performance is abysmal -
can be as low as 20K per second instead of 100 Mbit and there is much
data loss.
I had assumed that this was a recent regression so parked it until I
had time to test. However I just tested with a clean 2.6.14 and the
problem persists....
The test setup is
10.0.1.31 ----- 10.0.1.33/10.0.2.33 ------- 10.0.2.32
and the command is just:
(from 10.0.1.31) ./ttcp_acme -c -l500 -n10000 -t 10.0.2.32
and
(from 10.0.2.32) ./ttcp_acme -c -l500 -n10000 -r
the following setup works fine:
10.0.1.31 ----- 10.0.1.33
./ttcp_acme -c -l500 -n10000 -t 10.0.1.33
and
./ttcp_acme -c -l500 -n10000 -r
I'll add this to my list of bugs to look at at some stage (along with
updating tx buffering, CCID2 not working with loss/delay) but
interested in seeing if others have similar problems?
Ian
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* how to select the filesystem for nand flash?
From: zhuzhenhua @ 2006-03-09 1:48 UTC (permalink / raw)
To: linux-mips
In the linux, I find there are two solutions for nand flash: one is
YAFFS2/JFFS2 + MTD, other is EXT2/EXT3+FTL. Because we have to
implement vfat based FTL for our u-disk,so i wonder if the ext2/ext3
+ FTL is stable enough to be root filesystem?
thanks for any hints.
Best Regards
Zhuzhenhua
^ permalink raw reply
* Re: [PATCH] compat. ifconf: fix limits
From: Randy.Dunlap @ 2006-03-09 1:41 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-fsdevel, Alexandra.Kossovsky, ak, akpm, torvalds
In-Reply-To: <20060308.164627.81771250.davem@davemloft.net>
On Wed, 08 Mar 2006 16:46:27 -0800 (PST) David S. Miller wrote:
> From: "Randy.Dunlap" <rdunlap@xenotime.net>
> Date: Wed, 8 Mar 2006 09:16:08 -0800
>
> > From: Randy Dunlap <rdunlap@xenotime.net>
> >
> > A recent change to compat. dev_ifconf() in fs/compat_ioctl.c
> > causes ifconf data to be truncated 1 entry too early when copying it
> > to userspace. The correct amount of data (length) is returned,
> > but the final entry is empty (zero, not filled in).
> > The for-loop 'i' check should use <= to allow the final struct
> > ifreq32 to be copied. I also used the ifconf-corruption program
> > in kernel bugzilla #4746 to make sure that this change does not
> > re-introduce the corruption.
> >
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
>
> Good catch, applied. Thanks Randy.
>
> Is this one relevant for -stable?
Yes, IMO. Have to wait for it to be merged upstream, right?
---
~Randy
^ permalink raw reply
* Re: [PATCH 01/16] RTC Subsystem, library functions
From: Adrian Bunk @ 2006-03-09 1:28 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: linux-kernel, akpm, akpm
In-Reply-To: <20060306015009.110961000@towertech.it>
On Mon, Mar 06, 2006 at 02:50:09AM +0100, Alessandro Zummo wrote:
>...
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-rtc/drivers/rtc/Kconfig 2006-03-05 02:48:31.000000000 +0100
> @@ -0,0 +1,6 @@
> +#
> +# RTC class/drivers configuration
> +#
> +
> +config RTC_LIB
> + bool
>...
I'd still say this should be a tristate (a MODULE_LICENSE("GPL") in
rtc-lib.c seems to be the only other change required for this).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [2.6 patch] add a proper prototype for setup_arch()
From: Adrian Bunk @ 2006-03-09 1:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ben Dooks, linux-kernel, ben
In-Reply-To: <20060305230321.6ce3ea57.akpm@osdl.org>
On Sun, Mar 05, 2006 at 11:03:21PM -0800, Andrew Morton wrote:
> Ben Dooks <ben-linux@fluff.org> wrote:
> >
> > When running sparse over an ARM build of 2.6.16-rc5, I came
> > across this error, which is due to setup_arch() being used
> > be init/main.c, but not being defined in any headers.
> >
> > This patch adds setup_arch() definition to include/linux/init.h
> >
> > The warning is:
> > arch/arm/kernel/setup.c:730:13: warning: symbol 'setup_arch' was not declared. Should it be static?
> >
> > ...
> >
> > --- linux-2.6.16-rc5/include/linux/init.h 2006-02-28 09:05:02.000000000 +0000
> > +++ linux-2.6.16-rc5-fixes/include/linux/init.h 2006-03-05 20:39:21.000000000 +0000
> > @@ -69,6 +69,10 @@ extern initcall_t __security_initcall_st
> >
> > /* Defined in init/main.c */
> > extern char saved_command_line[];
> > +
> > +/* used by init/main.c */
> > +extern void setup_arch(char **);
>
> There are already declarations of setup_arch in include/asm-ppc and
> include/asm-powerpc. Different declarations.
These are struct members, not function prototypes.
> Plus there's an unneeded-with-this-patch declaration in init/main.c.
Updated patch below.
cu
Adrian
<-- snip -->
This patch adds a proper prototype for setup_arch() in init.h .
This patch is based on a patch by Ben Dooks <ben-linux@fluff.org>.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/init.h | 4 ++++
init/main.c | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.16-rc5-mm3-full/include/linux/init.h.old 2006-03-08 23:32:22.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/include/linux/init.h 2006-03-08 23:32:26.000000000 +0100
@@ -69,6 +69,10 @@
/* Defined in init/main.c */
extern char saved_command_line[];
+
+/* used by init/main.c */
+extern void setup_arch(char **);
+
#endif
#ifndef MODULE
--- linux-2.6.16-rc5-mm3-full/init/main.c.old 2006-03-08 23:35:40.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/init/main.c 2006-03-08 23:35:45.000000000 +0100
@@ -324,8 +324,6 @@
}
__setup("rdinit=", rdinit_setup);
-extern void setup_arch(char **);
-
#ifndef CONFIG_SMP
#ifdef CONFIG_X86_LOCAL_APIC
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Linus Torvalds @ 2006-03-09 1:27 UTC (permalink / raw)
To: Paul Mackerras
Cc: akpm, linux-arch, linux-kernel, mingo, Alan Cox, linuxppc64-dev
In-Reply-To: <17423.32792.500628.226831@cargo.ozlabs.ibm.com>
On Thu, 9 Mar 2006, Paul Mackerras wrote:
>
> ... and x86 mmiowb is a no-op. It's not x86 that I think is buggy.
x86 mmiowb would have to be a real op too if there were any multi-pathed
PCI buses out there for x86, methinks.
Basically, the issue boils down to one thing: no "normal" barrier will
_ever_ show up on the bus on x86 (ie ia64, afaik). That, together with any
situation where there are multiple paths to one physical device means that
mmiowb() _has_ to be a special op, and no spinlocks etc will _ever_ do the
serialization you look for.
Put another way: the only way to avoid mmiowb() being special is either
one of:
(a) have the bus fabric itself be synchronizing
(b) pay a huge expense on the much more critical _regular_ barriers
Now, I claim that (b) is just broken. I'd rather take the hit when I need
to, than every time.
Now, (a) is trivial for small cases, but scales badly unless you do some
fancy footwork. I suspect you could do some scalable multi-pathable
version with using similar approaches to resolving device conflicts as the
cache coherency protocol does (or by having a token-passing thing), but it
seems SGI's solution was fairly well thought out.
That said, when I heard of the NUMA IO issues on the SGI platform, I was
initially pretty horrified. It seems to have worked out ok, and as long as
we're talking about machines where you can concentrate on validating just
a few drivers, it seems to be a good tradeoff.
Would I want the hard-to-think-about IO ordering on a regular desktop
platform? No.
Linus
^ permalink raw reply
* Re: [PATCH] Define flush_wc, a way to flush write combining store buffers
From: Bryan O'Sullivan @ 2006-03-09 1:26 UTC (permalink / raw)
To: Andi Kleen; +Cc: Benjamin Herrenschmidt, akpm, paulus, bcrl, linux-kernel
In-Reply-To: <200603081538.32234.ak@suse.de>
On Wed, 2006-03-08 at 15:38 +0100, Andi Kleen wrote:
> Hmm, I reread the thread and with the "i don't need a flush, just ordering"
> part of your description it makes sense.
Actually, the sfence architecturally guarantees a WC store buffer flush
on x86_64 too, which I need. Obviously, on CPUs that don't have WC
on-chip, this is not an issue.
> My second objection still stands though. Maybe we should add this as
> part of a generic portable PAT/WC infrastructure. But isolated
> it doesn't make sense.
Fine. I'll put it in the driver for now, and work on the generic WC
infrastructure in parallel.
<b
--
Bryan O'Sullivan <bos@pathscale.com>
^ permalink raw reply
* Re: SCSI behind PCIE bridge only detected using pci=noacpi
From: Shaohua Li @ 2006-03-09 1:09 UTC (permalink / raw)
To: Thomas Renninger; +Cc: linux-acpi
In-Reply-To: <200603081954.44195.trenn@suse.de>
Thomas Renninger wrote:
> Should this work or is this really not supported via ACPI?
>
> I expect this is the relevant output:
>
> ACPI: PCI Root Bridge [PCI1] (0001:40)
> PCI: Multiple domains not supported
> ACPI Error (pci_root-0279): Bus 0001:40 not present in PCI
> namespace<7>Losing some ticks... checking if CPU frequency changed.
>
> [20060127]
> ACPI Exception (pci_bind-0156): AE_NOT_FOUND, Invalid ACPI-PCI context
> for parent device PCI1 [20060127]
> ACPI Exception (pci_bind-0156): AE_NOT_FOUND, Invalid ACPI-PCI context
> for parent device PCI1 [20060127]
> ACPI: PCI Root Bridge [PCI2] (0002:80)
> PCI: Multiple domains not supported
> ACPI Error (pci_root-0279): Bus 0002:80 not present in PCI namespace
> [20060127]
> ACPI Exception (pci_bind-0156): AE_NOT_FOUND, Invalid ACPI-PCI context
> for parent device PCI2 [20060127]
> ACPI Exception (pci_bind-0156): AE_NOT_FOUND, Invalid ACPI-PCI context
> for parent device PCI2 [20060127]
>
> With pci=noacpi the SCSI disk/controller works fine.
> Without even the controller is not recognised.
IIRC, -mm tree has the x86 multiple domains support patch. Without that
patch all pci devices of non-zero domains can't be found.
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Paul Mackerras @ 2006-03-09 1:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: akpm, linux-arch, linux-kernel, mingo, Alan Cox, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.64.0603081652430.32577@g5.osdl.org>
Linus Torvalds writes:
> > If you ask me, the need for mmiowb on some platforms merely shows that
> > those platforms' implementations of spinlocks and read*/write* are
> > buggy...
>
> You could also state that same as
>
> "If you ask me, the need for mmiowb on some platforms merely shows
> that those platforms perform like a bat out of hell, and I think
> they should be slower"
>
> because the fact is, x86 memory barrier rules are just about optimal for
> performance.
... and x86 mmiowb is a no-op. It's not x86 that I think is buggy.
Paul.
^ permalink raw reply
* Re: problem with duplicate sysfs directories and files
From: Greg KH @ 2006-03-09 1:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: maneesh, linux-kernel, mochel
In-Reply-To: <20060308010205.7e989a5a.akpm@osdl.org>
On Wed, Mar 08, 2006 at 01:02:05AM -0800, Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
> >
> > Hi,
> >
> > I spent some time tonight trying to track down how to fix the issue of
> > duplicate sysfs files and/or directories. This happens when you try to
> > create a kobject with the same name in the same directory. The creation
> > of the second kobject will fail, but the directory will remain in sysfs.
> >
> > Now I know this isn't a normal operation, but it would be good to fix
> > this eventually. I traced the issue down to fs/sysfs/dir.c:create_dir()
> > and the check for:
> > if (error && (error != -EEXIST)) {
> >
> > Problem is, error is set to -EEXIST, so we don't clean up properly. Now
> > I know we can't just not check for this, as if you do that error
> > cleanup, the original kobject's sysfs entry gets very messed up (ls -l
> > does not like it at all...)
> >
> > But I can't seem to figure out what exactly we need to do to clean up
> > properly here.
> >
> > Do you, or anyone else, have any pointers or ideas?
> >
>
> Emit a loud warning and don't bother cleaning up - leave the current
> behaviour as-is. Whatever takes the least amount code and has the minimum
> end-user impact, IMO.
Yeah, we do give a warning. Well, we used to always do it, but now that
more people are not using kobject_register() but only kobject_add(), it
doesn't always show up...
Here's a patch that I've added to my queue that fixes the warn issue,
but it still would be nice to fix up sysfs someday.
thanks,
greg k-h
---
lib/kobject.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
--- gregkh-2.6.orig/lib/kobject.c
+++ gregkh-2.6/lib/kobject.c
@@ -194,6 +194,17 @@ int kobject_add(struct kobject * kobj)
unlink(kobj);
if (parent)
kobject_put(parent);
+
+ /* be noisy on error issues */
+ if (error == -EEXIST)
+ printk("kobject_add failed for %s with -EEXIST, "
+ "don't try to register things with the "
+ "same name in the same directory.\n",
+ kobject_name(kobj));
+ else
+ printk("kobject_add failed for %s (%d)\n",
+ kobject_name(kobj), error);
+ dump_stack();
}
return error;
@@ -207,18 +218,13 @@ int kobject_add(struct kobject * kobj)
int kobject_register(struct kobject * kobj)
{
- int error = 0;
+ int error = -EINVAL;
if (kobj) {
kobject_init(kobj);
error = kobject_add(kobj);
- if (error) {
- printk("kobject_register failed for %s (%d)\n",
- kobject_name(kobj),error);
- dump_stack();
- } else
+ if (!error)
kobject_uevent(kobj, KOBJ_ADD);
- } else
- error = -EINVAL;
+ }
return error;
}
^ permalink raw reply
* Re: [PATCH] ftruncate on huge page couldn't extend hugetlb file
From: 'David Gibson' @ 2006-03-09 1:03 UTC (permalink / raw)
To: Chen, Kenneth W; +Cc: 'Zhang, Yanmin', linux-kernel
In-Reply-To: <200603090033.k290XBg13472@unix-os.sc.intel.com>
On Wed, Mar 08, 2006 at 04:33:10PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Wednesday, March 08, 2006 4:23 PM
> > > But you already make reservation at mmap time. If you reserve it again
> > > when extending the file, won't you double count?
> >
> > Well, I'd generally expect extending truncate() to come before mmap(),
> > but in any case hugetlb_extend_reservation() is safe against double
> > counting (it's idempotent if called twice with the same number of
> > pages). The semantics are "ensure the this many pages total are
> > guaranteed available, that is, either reserved or already
> > instantiated".
>
> It's kind of peculiar that kernel reserve hugetlb page at the time of
> extending truncate. Maybe there is a close correlation between mmap
> size to the file size. But these two aren't the same and and shouldn't
> be mixed.
Indeed. The fundamental basis of my approach as opposed to that in
apw's old accounting patches is that reservation is related to
filesize, not mmap() size. The only connection to mmap() is that
(shared writable) mmap() on hugetlbfs also extends filesize and
reservation size as a side effect.
There's a slight wrinkle in the different between i_size and reserved
pages. i_size can be extended beyond the "reserved portion" of the
file. We need that behaviour because i_size also acts as a hard
offset limit for MAP_PRIVATE mappings, but privately instantiated
pages don't come from the file's reservation.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Paul Mackerras @ 2006-03-09 1:01 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: David Howells, Matthew Wilcox, Alan Cox, torvalds, akpm, mingo,
linux-arch, linuxppc64-dev, linux-kernel, Paul, E.McKenney,
" <paulmck
In-Reply-To: <20060309020851.D9651@jurassic.park.msu.ru>
Ivan Kokshaysky writes:
> On Thu, Mar 09, 2006 at 09:10:49AM +1100, Paul Mackerras wrote:
> > David Howells writes:
> >
> > > > # define smp_read_barrier_depends() do { } while(0)
> > >
> > > What's this one meant to do?
> >
> > On most CPUs, if you load one value and use the value you get to
> > compute the address for a second load, there is an implicit read
> > barrier between the two loads because of the dependency. That's not
> > true on alpha, apparently, because of the way their caches are
> > structured.
>
> Who said?! ;-)
Paul McKenney, after much discussion with Alpha chip designers IIRC.
> > The smp_read_barrier_depends is a read barrier that you
> > use between two loads when there is already a dependency between the
> > loads, and it is a no-op on everything except alpha (IIRC).
>
> My "Compiler Writer's Guide for the Alpha 21264" says that if the
> result of the first load contributes to the address calculation
> of the second load, then the second load cannot issue until the data
> from the first load is available.
Sure, but because of the partitioned caches on some systems, the
second load can get older data than the first load, even though it
issues later.
If you do:
CPU 0 CPU 1
foo = val;
wmb();
p = &foo;
reg = p;
bar = *reg;
it is apparently possible for CPU 1 to see the new value of p
(i.e. &foo) but an old value of foo (i.e. not val). This can happen
if p and foo are in different halves of the cache on CPU 1, and there
are a lot of updates coming in for the half containing foo but the
half containing p is quiet.
I added Paul McKenney to the cc list so he can correct anything I have
wrong here.
Paul.
^ permalink raw reply
* RE: VMX status report changset 9158:b41ad96f1242
From: Shi, Alex @ 2006-03-09 1:00 UTC (permalink / raw)
To: Daniel Stekloff; +Cc: xen-devel
It is OK from unstable tree 9150. and it was really fail before in our testing. Now the bug was fixed.
Thanks and best regards
Alex shi
Daniel Stekloff wrote:
> Hi,
>
> Are you running 11_create_concurrent_pos.py test with your xm-test
> run? If so, it doesn't seem to be failing for you. It fails for me on
> every run: see bug #562
>
> Thanks,
> Dan
>
>
> On Wed, 2006-03-08 at 18:27 +0800, Shi, Alex wrote:
>> We have tested latest xen on VT platform with Intel 915/E8500
>> chipset and here is the test summary:
>>
>>
>> issues:
>>
>> - guest os cannot reboot as expected
>> - PAE guest can not be created on IA-32e host
>>
>>
>> IA-32:
>> Build&Boot SMP xen0 without problem
>> Can bootup unmodified 2.4/2.6 linux on VMX domain
>> Can bootup unmodified Window XP
>> Can bootup VMX & Xen with different configuration
>> A selected subset of LTP runs well in VMX domain(2.6) subset
>> xm-test runs well
>>
>>
>> IA-32_PAE:
>> Build&Boot SMP xen0 without problem
>> Can bootup unmodified 2.6 linux on VMX domain
>> Can bootup unmodified Window XP
>> Can bootup VMX & Xen with different configuration
>> A selected subset of LTP runs well in VMX domain(2.6)
>>
>>
>>
>> IA-32e:
>> Build&Boot SMP xen0 without problem
>> Can bootup unmodified IA-32/IA-32e linux on VMX domain
>> Can bootup unmodified Window XP
>> Can bootup VMX & xenU with different configuration
>> A selected subset of LTP runs well in VMX domain(2.6)
>>
>>
>>
>> for details
>> ------------------------------------------------------------
>>
>> Platform: IA-32
>> Service OS: FC3, IA-32, SMP
>> Hardware: GS
>> Default guest OS: IA-32, 2.6 kernel
>>
>> 1, one vmx with memory 128M PASS
>> 2, one vmx with memory 256M PASS
>> 3, one vmx with memory 512M PASS
>> 4, one xenU create PASS
>> 5, 2 vmx and 2 xenU coexist PASS
>> 6, four vmx coexist PASS
>> 7, network in VMX domain PASS
>> 8, network in XenU domain PASS
>> 9, one IA-32 window domain PASS
>> 10, 2 IA-32 window domains PASS
>> 11,subset LTP test in VMX domain PASS
>> 12,xenu local migeration PASS
>>
>> =========================================
>> Xm-test execution summary:
>> PASS: 43
>> FAIL: 5
>> XPASS: 0
>> XFAIL: 2
>>
>>
>> Details:
>>
>> XFAIL: 02_network_local_ping_pos
>> ping loopback failed for size 65507. ping eth0 failed for size
>> 65507.
>>
>> XFAIL: 11_network_domU_ping_pos
>> Ping failed for size 65507.
>>
>> FAIL: 01_reboot_basic_pos
>> [Errno 5] Input/output error
>>
>> FAIL: 01_sedf_multi_pos
>> [0] xm sedf returned invalid 256 != 0
>>
>> FAIL: 01_enforce_dom0_cpus_basic_pos
>> /proc/cpuinfo says xend didn't enforce dom0_cpus (2 != 1)
>>
>> Summary Test Report of Last Session
>> ==============================================================================
>> = Total Pass Fail NoResult Crash
>> ==============================================================================
>> =ltp 248 248 0 0 0
>> ==============================================================================
>> =ltp 248 248 0 0 0
>> mm 21 21 0 0 0
>> dio 28 28 0 0 0
>> nptl 1 1 0 0 0
>> math 10 10 0 0 0
>> ipc 8 8 0 0 0
>> pty 3 3 0 0 0
>> quickhit 120 120 0 0 0
>> sched 3 3 0 0 0
>> fs 54 54 0 0 0
>> ==============================================================================
>> =Total 248 248 0 0 0
>>
>>
>> Platform: IA-32_PAE
>> Service OS: FC3, IA-32_PAE, SMP
>> Hardware: GS
>> Default guest OS: IA-32, 2.6 kernel
>>
>> 1, one vmx with memory 256M PASS
>> 2, one vmx with memory 512M PASS
>> 3, one vmx with memory 1500MB PASS
>> 4, one xenU create PASS
>> 5, network in VMX domain PASS
>> 6, network in XenU domain PASS
>> 7, one IA-32 window domain PASS
>> 8, 2 IA-32 window domains PASS
>> 9, xenu local migeration PASS
>> 10, subset LTP test in VMX domain PASS
>>
>>
>> Summary Test Report of Last Session
>> ==============================================================================
>> = Total Pass Fail NoResult Crash
>> ==============================================================================
>> =ltp 248 248 0 0 0
>> ==============================================================================
>> =ltp 248 248 0 0 0
>> mm 21 21 0 0 0
>> dio 28 28 0 0 0
>> nptl 1 1 0 0 0
>> math 10 10 0 0 0
>> ipc 8 8 0 0 0
>> pty 3 3 0 0 0
>> quickhit 120 120 0 0 0
>> sched 3 3 0 0 0
>> fs 54 54 0 0 0
>> ==============================================================================
>> =Total 248 248 0 0 0
>>
>>
>> Platform: IA-32e
>> Service OS: RHEL4U1, IA-32e, SMP
>> Hardware: GS
>> Default guest OS: IA-32e, 2.6 kernel
>>
>>
>> 1, one vmx with memory 128M PASS
>> 2, one vmx with memory 4GM PASS
>> 3, one vmx with memory 512M PASS
>> 4, one xenU create PASS
>> 5, 2 vmx and 2 xenU coexist PASS
>> 6, four vmx coexist PASS
>> 7, network in VMX domain PASS
>> 8, network in XenU domain PASS
>> 9, one 2.4 IA32 VMX domain PASS
>> 10, one 2.6 IA32 VMX domain PASS
>> 11, IA-32 2.4 and 2.6 VMX coexist PASS
>> 12, IA-32 and IA-32e VMX coexist PASS
>> 13,subset LTP test in VMX domain PASS
>> 14, one IA-32 window domain PASS
>> 15, 2 ia32 window domains coexist PASS
>> 16, xenu local migeration PASS
>>
>>
>> Summary Test Report of Last Session
>> ==============================================================================
>> = Total Pass Fail NoResult Crash
>> ==============================================================================
>> =ltp 249 249 0 0 0
>> ==============================================================================
>> =ltp 249 249 0 0 0
>> mm 21 21 0 0 0
>> dio 28 28 0 0 0
>> nptl 1 1 0 0 0
>> math 10 10 0 0 0
>> ipc 8 8 0 0 0
>> pty 3 3 0 0 0
>> quickhit 121 121 0 0 0
>> sched 3 3 0 0 0
>> fs 54 54 0 0 0
>> ==============================================================================
>> =Total 249 249 0 0 0
>>
>> Thanks and best regards
>> Alex shi
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Jesse Barnes @ 2006-03-09 0:59 UTC (permalink / raw)
To: Paul Mackerras
Cc: Matthew Wilcox, Linus Torvalds, David Howells, Alan Cox, akpm,
mingo, linux-arch, linuxppc64-dev, linux-kernel
In-Reply-To: <17423.30924.278031.151438@cargo.ozlabs.ibm.com>
On Wednesday, March 8, 2006 4:37 pm, Paul Mackerras wrote:
> Matthew Wilcox writes:
> > Looking at the SGI implementation, it's smarter than you think.
> > Looks like there's a register in the local I/O hub that lets you
> > determine when this write has been queued in the appropriate
> > host->pci bridge.
>
> Given that mmiowb takes no arguments, how does it know which is the
> appropriate PCI host bridge?
It uses a per-node address space to reference the local bridge. The
local bridge then waits until the remote bridge has acked the write
before, then sets the outstanding write register to the appropriate
value.
Jesse
^ permalink raw reply
* Re: [Xenomai-help] Xenomai vs. RTLinux
From: Jan Kiszka @ 2006-03-09 0:58 UTC (permalink / raw)
To: Christopher Stone; +Cc: xenomai
In-Reply-To: <006f01c64312$a28ab730$a10a10ac@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
Christopher Stone wrote:
>> Is there planned support for native AMD x86_64 support? We have several
>> of these machines on our desktops and would like to upgrade our HWIL
>> machines as well.
>
> [Christopher Stone] I definitely plan to add AMD x86_64 support for my XLM
> project. I have a dual core AMD X2 chip I want to test XLM on. I don't have
> specific dates when it will be available yet.
Ha! Wasn't there somebody recently asking what to contribute? ;)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH] dcdbas: dcdbas_pdev referenced after platform_device_unregister on exit
From: Doug Warzecha @ 2006-03-09 1:03 UTC (permalink / raw)
To: akpm, linux-kernel
smi_data_buf_free() references dcdbas_pdev when calling dma_free_coherent(). In dcdbas_exit(), smi_data_buf_free() is called after platform_device_unregister(dcdbas_pdev).
This patch moves platform_device_unregister(dcdbas_pdev) after smi_data_buf_free() in dcdbas_exit().
Signed-off-by: Doug Warzecha <Douglas_Warzecha@dell.com>
---
--- linux-2.6.16-rc5/drivers/firmware/dcdbas.c.orig 2006-03-07 16:28:18.000000000 -0600
+++ linux-2.6.16-rc5/drivers/firmware/dcdbas.c 2006-03-07 19:38:46.172641512 -0600
@@ -39,7 +39,7 @@
#include "dcdbas.h"
#define DRIVER_NAME "dcdbas"
-#define DRIVER_VERSION "5.6.0-1"
+#define DRIVER_VERSION "5.6.0-2"
#define DRIVER_DESCRIPTION "Dell Systems Management Base Driver"
static struct platform_device *dcdbas_pdev;
@@ -581,9 +581,13 @@ static int __init dcdbas_init(void)
*/
static void __exit dcdbas_exit(void)
{
- platform_device_unregister(dcdbas_pdev);
+ /*
+ * make sure functions that use dcdbas_pdev are called
+ * before platform_device_unregister
+ */
unregister_reboot_notifier(&dcdbas_reboot_nb);
smi_data_buf_free();
+ platform_device_unregister(dcdbas_pdev);
}
module_init(dcdbas_init);
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Jesse Barnes @ 2006-03-09 0:55 UTC (permalink / raw)
To: Paul Mackerras
Cc: David Howells, Linus Torvalds, Alan Cox, akpm, mingo, linux-arch,
linuxppc64-dev, linux-kernel
In-Reply-To: <17423.30789.214209.462657@cargo.ozlabs.ibm.com>
On Wednesday, March 8, 2006 4:35 pm, Paul Mackerras wrote:
> David Howells writes:
> > On NUMA PowerPC, should mmiowb() be a SYNC or an EIEIO instruction
> > then? Those do inter-component synchronisation.
>
> We actually have quite heavy synchronization in read*/write* on PPC,
> and mmiowb can safely be a no-op. It would be nice to be able to have
> lighter-weight synchronization, but I'm sure we would see lots of
> subtle driver bugs cropping up if we did. write* do a full memory
> barrier (sync) after the store, and read* explicitly wait for the data
> to come back before.
>
> If you ask me, the need for mmiowb on some platforms merely shows that
> those platforms' implementations of spinlocks and read*/write* are
> buggy...
Or maybe they just wanted to keep them fast. I don't know why you
compromised so much in your implementation of read/write and
lock/unlock, but given how expensive synchronization is, I'd think it
would be better in the long run to make the barrier types explicit (or
at least a subset of them) to maximize performance. The rules for using
the barriers really aren't that bad... for mmiowb() you basically want
to do it before an unlock in any critical section where you've done PIO
writes.
Of course, that doesn't mean there isn't confusion about existing
barriers. There was a long thread a few years ago (Jes worked it all
out, iirc) regarding some subtle memory ordering bugs in the tty layer
that ended up being due to ia64's very weak spin_unlock ordering
guarantees (one way memory barrier only), but I think that's mainly an
artifact of how ill defined the semantics of the various arch specific
routines are in some cases.
That's why I suggested in an earlier thread that you enumerate all the
memory ordering combinations on ppc and see if we can't define them all.
Then David can roll the implicit ones up into his document, or we can
add the appropriate new operations to the kernel. Really getting
barriers right shouldn't be much harder than getting DMA mapping right,
from a driver writers POV (though people often get that wrong I guess).
Jesse
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Paul Mackerras @ 2006-03-09 0:37 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Linus Torvalds, David Howells, Alan Cox, akpm, mingo, linux-arch,
linuxppc64-dev, linux-kernel
In-Reply-To: <20060308194037.GO7301@parisc-linux.org>
Matthew Wilcox writes:
> Looking at the SGI implementation, it's smarter than you think. Looks
> like there's a register in the local I/O hub that lets you determine
> when this write has been queued in the appropriate host->pci bridge.
Given that mmiowb takes no arguments, how does it know which is the
appropriate PCI host bridge?
Paul.
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-09 0:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, torvalds
In-Reply-To: <20060308080816.GA16866@suse.de>
Olaf Hering writes:
> On Wed, Mar 08, Paul Mackeras wrote:
>
> > powerpc: incorrect rmo_top handling in prom_init
>
> I would leave this one out. It gives the false impression that ibook1
> works ok, while later it will likely eat your filesystem. Its not a
> regression in that sense because 2.6.15 was also broken and noone
> complained.
Ben H and I agree that the fix makes sense and is correct and should
go in for 2.6.16. Your iBook crashes are a separate problem.
Paul.
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Linus Torvalds @ 2006-03-09 0:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: David Howells, Alan Cox, akpm, mingo, linux-arch, linuxppc64-dev,
linux-kernel
In-Reply-To: <17423.30789.214209.462657@cargo.ozlabs.ibm.com>
On Thu, 9 Mar 2006, Paul Mackerras wrote:
>
> If you ask me, the need for mmiowb on some platforms merely shows that
> those platforms' implementations of spinlocks and read*/write* are
> buggy...
You could also state that same as
"If you ask me, the need for mmiowb on some platforms merely shows
that those platforms perform like a bat out of hell, and I think
they should be slower"
because the fact is, x86 memory barrier rules are just about optimal for
performance.
Linus
^ permalink raw reply
* Re: [Xenomai-core] [PATCH] Small doc fix for rtbenchmark.h
From: Jan Kiszka @ 2006-03-09 0:54 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai-core
In-Reply-To: <200603090130.09536.Sebastian.Smolorz@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
Sebastian Smolorz wrote:
> Hi Jan,
>
> here is a fix for the following doxygen warning:
>
> xenomai/include/rtdm/rtbenchmark.h:146: Warning: end of file while inside a
> group
>
> Sebastian
>
>
> ------------------------------------------------------------------------
>
> --- xenomai/include/rtdm/rtbenchmark.h 2006-03-09 01:13:40.000000000 +0100
> +++ rtbenchmark.h 2006-03-09 01:13:24.000000000 +0100
> @@ -138,6 +138,7 @@ typedef struct rtbnch_trace_special {
>
> #define RTBNCH_RTIOC_SPECIAL_TRACE_EX \
> _IOW(RTIOC_TYPE_BENCHMARK, 0x25, struct rtbnch_trace_special)
> +/** @} */
>
> /** @} */
>
Yep, indeed - fixed. Might explain some of the other problems that
popped up today, err, yesterday...
Thanks,
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* 2.6 device mapper performance?
From: Ken Hwang @ 2006-03-09 0:49 UTC (permalink / raw)
To: dm-devel
Hi,
I'm not sure I should ask this question here, if this is not the place then
I apologize. I have a home made NAS with Linux. I use evms to create volume,
put xfs on top of it, and then use samba to share it with Windows clients.
When I was using kernel 2.4 with all the needed patches I could get netbench
106Mbps with 4 clients, and 95Mbps with 8 clients. Recently I upgraded the
same hardware to kernel 2.6 (I also upgraded the related application such as
samba, xfs utility, and dmsetup accordingly). Then I ran netbench again and
got 80Mbps with 4 clients, 53Mbps with 8 clients. Which drop almost 80% (95
vs 53) in 8 clients case.
I then make and mount xfs on another raid5 (which uses the same disk but on
different partitions) and found it got better performance (95Mbps with 4
clients, 85Mbps with 8 clients). In brief:
xfs volume on raid5 md/md1 on sda6/sdb6/sdc6/sdd6 netbench: 95/85Mbps
xfs volume on EVMS volume /dev/evms/volume1 on raid5 md/md3 on
sda8/sdb8/sdc8/sdd8: 80/53Mbps
Do you think the slow down (85 to 53Mbps) was caused by device mapper?
Please advice.
Ken
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.2.0/276 - Release Date: 3/7/2006
^ 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.