* Re: kernel panic
From: Bjorn Helgaas @ 2011-10-25 20:55 UTC (permalink / raw)
To: nick bray; +Cc: linux-kernel, linux-acpi
In-Reply-To: <4EA549C3.4080206@ntlworld.com>
[+linux-acpi]
On Mon, Oct 24, 2011 at 5:19 AM, nick bray <nick.bray1@ntlworld.com> wrote:
> Hi,
> after upgrading to linux kernel 3.xx I get kernel panic on boot unless I
> use ACPI=off in the boot parameters this happens with both Ubuntu 11.10 and
> Fedora 16. The mainboard is an Intel S875WP1-E running a Pentuim 4 3ghz with
> 3gig RAM in single-channel mode. I have performed a Bios upgrade just in
> case tha ACPI tables were corrupt but it makes no difference. Currently
> running 2.6.38-11-generic #50-Ubuntu SMP (Linux Mint) with no issues. I can
> provide a screenshot if you wish but it's looking like it's ACPI related as
> above.
Yes, please provide a screenshot. A serial console log with "acpi=off
ignore_loglevel" would be even better.
Bjorn
^ permalink raw reply
* Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
From: Greg KH @ 2011-10-25 20:54 UTC (permalink / raw)
To: Dave Jones, Nick Bowler, Ben Hutchings, Rusty Russell,
Randy Dunlap, LKML, Debian kernel maintainers
In-Reply-To: <20111025201723.GA25063@redhat.com>
On Tue, Oct 25, 2011 at 04:17:24PM -0400, Dave Jones wrote:
> On Tue, Oct 25, 2011 at 10:04:55PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Oct 25, 2011 at 12:51:42PM -0400, Nick Bowler wrote:
> > > On 2011-10-25 18:05 +0200, Ben Hutchings wrote:
> > > > On Tue, 2011-10-25 at 11:38 -0400, Nick Bowler wrote:
> > > > > This patch prevents the use of lockdep for debugging out of tree
> > > > > modules, which is rather mean.
> > > >
> > > > It was already disabled for staging modules, which seems equally
> > > > unhelpful.
> > >
> > > This is not the case: lockdep works fine with staging modules.
> >
> > Yes, that was fixed a few kernel versions ago.
> >
> > Now you might want to update that fix for the TAINT_OOT_MODULE flag as
> > well, if you feel it is needed.
>
> I'm assuming you mean this patch ?
>
> commit 7816c45bf13255157c00fb8aca86cb64d825e878
> Author: Roland Vossen <rvossen@broadcom.com>
> Date: Thu Apr 7 11:20:58 2011 +0200
>
> modules: Enabled dynamic debugging for staging modules
Hm, this is the patch I was thinking about yes. But as you point out:
> If we want to support out of tree modules with this, should we just nuke the
> whole check, or do we still want to prevent certain types of tainted kernels
> from using this stuff ?
I don't know, there was some reason we didn't want to run dynamic_debug
for "normal" tainted kernel modules, but I can't recall it at the
moment, sorry.
>
> (sidenote: it's not immediately obvious to me that this is the right patch,
> as dynamic debug & lockdep are separate things, though this was the only
> thing in kernel/module.c's history this year that sounds similar)
Perhaps the lockdep thing is totally different. I don't know about that
check.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial/8250_pci: add a quirk for the kt serial controller
From: Greg KH @ 2011-10-25 20:51 UTC (permalink / raw)
To: Dan Williams; +Cc: Greg KH, Nhan H Mai, linux-kernel, linux-serial, alan
In-Reply-To: <1319573794.9320.15.camel@dwillia2-mobl>
On Tue, Oct 25, 2011 at 01:16:34PM -0700, Dan Williams wrote:
> From: Dan Williams <dan.j.williams@intel.com>
> Date: Sun, 23 Oct 2011 15:06:24 -0700
> Subject: [PATCH v2] serial/8250_pci: add a quirk for the kt serial controller
>
> Workaround dropped notifications in the iir register. Prevent reads
> coincident with new interrupt notifications by reading the iir at most
> once per interrupt.
>
> Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Much better.
But.
Do you really think I can apply a patch that looks like this above? I
have to edit the text of the email before I apply it.
Now I'm a bit grumpy about this at the moment as Linus yelled at me for
patches where I missed this on a few for the 3.2 merge window, so I'm
going to push back on people now very hard.
Please send this in a format that I can run 'git am' on the email you
send me. I could not do that here, otherwise we would end up with a
duplicate header in the changelog message.
Yes, it makes you do a bit more work, but when you are handling
thousands of patches like me, you scale better than I do :)
Actually, it's just making you do it properly, along with everyone else,
which is a good thing, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [msysGit] Re: [PATCH/RFC] mingw: implement PTHREAD_MUTEX_INITIALIZER
From: Erik Faye-Lund @ 2011-10-25 20:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, johannes.schindelin
In-Reply-To: <4EA716FC.2010804@kdbg.org>
On Tue, Oct 25, 2011 at 10:07 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 25.10.2011 17:42, schrieb Erik Faye-Lund:
>> On Tue, Oct 25, 2011 at 5:28 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Am 10/25/2011 16:55, schrieb Erik Faye-Lund:
>>>> +int pthread_mutex_lock(pthread_mutex_t *mutex)
>>>> +{
>>>> + if (mutex->autoinit) {
>>>> + if (InterlockedCompareExchange(&mutex->autoinit, -1, 1) != -1) {
>>>> + pthread_mutex_init(mutex, NULL);
>>>> + mutex->autoinit = 0;
>>>> + } else
>>>> + while (mutex->autoinit != 0)
>>>> + ; /* wait for other thread */
>>>> + }
>>>
>>> The double-checked locking idiom. Very suspicious. Can you explain why it
>>> works in this case? Why are no Interlocked functions needed for the other
>>> accesses of autoinit? ("It is volatile" is the wrong answer to this last
>>> question, BTW.)
>>
>> I agree that it should look a bit suspicious; I'm generally skeptical
>> whenever I see 'volatile' in threading-code myself. But I think it's
>> the right answer in this case. "volatile" means that the compiler
>> cannot optimize away accesses, which is sufficient in this case.
>
> No, it is not, and it took me a train ride to see what's wrong. It has
> nothing to do with autoinit, but with all the other memory locations
> that are written. See here, with pthread_mutex_init() inlined:
>
> if (mutex->autoinit) {
>
> Assume two threads enter this block.
>
> if (InterlockedCompareExchange(&mutex->autoinit, -1, 1) != -1) {
>
> Only one thread, A, say on CPU A, will enter this block.
>
> InitializeCriticalSection(&mutex->cs);
>
> Thread A writes some values. Note that there are no memory barriers
> involved here. Not that I know of or that they would be documented.
>
> mutex->autoinit = 0;
>
> And it writes another one. Thread A continues below to contend for the
> mutex it just initialized.
>
> } else
>
> Meanwhile, thread B, say on CPU B, spins in this loop:
>
> while (mutex->autoinit != 0)
> ; /* wait for other thread */
>
> When thread B arrives here, it sees the value of autoinit that thread A
> has written above.
>
> HOWEVER, when it continues, there is NO [*] guarantee that it will also
> see the values that InitializeCriticalSection() has written, because
> there were no memory barriers involved. When it continues, there is a
> chance that it calls EnterCriticalSection() with uninitialized values!
>
Thanks for pointing this out, I completely forgot about write re-ordering.
This is indeed a problem. So, shouldn't replacing "mutex->autoinit =
0;" with "InterlockedExchange(&mutex->autoinit, 0)" solve the problem?
InterlockedExchange generates a full memory barrier:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683590(v=vs.85).aspx
> }
>
>
> [*] If you compile this code with MSVC >= 2005, "No guarantee" is not
> true, it's exactly the opposite because Microsoft extended the meaning
> of 'volatile' to imply a memory barriere.
Do you have a source for this? I'm not saying it isn't true, I just
never heard of this, and would like to read up on it :)
> This is *NOT* true for gcc in
> general. It may be true for MinGW gcc, but I do not know.
>
>> Basically, the thread that gets the original 1 returned from
>> InterlockedCompareExchange is the only one who writes to
>> mutex->autoinit. All other threads only read the value, and the
>> volatile should make sure they actually do. Since all 32-bit reads and
>> writes are atomic on Windows (see
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684122(v=vs.85).aspx
>> "Simple reads and writes to properly-aligned 32-bit variables are
>> atomic operations.") and mutex->autoinit is a LONG, this should be
>> safe AFAICT. In fact, Windows specifically does not have any
>> explicitly atomic writes exactly for this reason.
>
> There is a difference between atomic and coherent: Yes, 32-bit accesses
> are atomic, but they are not automatically coherent: A 32-bit value
> written by one CPU is not instantly visible on the other CPU. 'volatile'
> as per the C lanugage does not add any guarantees that would be of
> interest here. OTOH, Microsoft's definition of 'volatile' does.
>
I never meant to imply this either, I simply forgot about write re-ordering ;)
>> The only ways mutex->autoinit can be updated is:
>> - InterlockedCompareExchange compares it to 1, finds it's identical
>> and inserts -1
>> - intialization is done
>> Both these updates happens from the same thread.
>>
>> Yes, details like this should probably go into the commit message ;)
>
> A comment in the function is preferred!
>
Yes, good point. This is code that looks dangerous (and in this case
potentially was - hopefully eventual future iteration won't be), and
should of course be documented inline...
^ permalink raw reply
* Re: RFC: Partially revert xen-unstable c/s 23071:a3466b005017
From: Ian Campbell @ 2011-10-25 20:51 UTC (permalink / raw)
To: Jonathan Ludlam
Cc: George Dunlap, Keir (Xen.org), xen-devel@lists.xensource.com,
Ian Jackson
In-Reply-To: <4B438545-27B2-4922-9012-FA4FAC7A6EEF@eu.citrix.com>
On Tue, 2011-10-25 at 18:01 +0100, Jonathan Ludlam wrote:
> For reference, here's what's executed when I build the xenctrl package in latest xen-unstable:
>
> ocamlc -g -I ../mmap -w F -warn-error F -c -o xenctrl.cmi xenctrl.mli
> ocamlc -g -I ../mmap -w F -warn-error F -c -o xenctrl.cmo xenctrl.ml
> ocamlc -g -I ../mmap -w F -warn-error F -a -o xenctrl.cma -dllib dllxenctrl_stubs.so -cclib -lxenctrl_stubs xenctrl.cmo
> gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -Wno-unused-but-set-variable -D__XEN_TOOLS__ -MMD -MF .xenctrl_stubs.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -mno-tls-direct-seg-refs -I/usr/lib/ocaml -fPIC -Werror -I../mmap -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/include -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc -I/home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/include -c -o xenctrl_stubs.o xenctrl_stubs.c
> ar rcs libxenctrl_stubs.a xenctrl_stubs.o && ocamlmklib -o `basename libxenctrl_stubs.a .a | sed -e 's/^lib//'` xenctrl_stubs.o
> ocamlopt -g -ccopt " " -dtypes -I ../mmap -cc gcc -w F -warn-error F -c -o xenctrl.cmx xenctrl.ml
> ocamlopt -g -ccopt " " -dtypes -I ../mmap -cc gcc -w F -warn-error F -a -o xenctrl.cmxa -cclib -lxenctrl_stubs -cclib /home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so -cclib /home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc/libxenguest.so xenctrl.cmx
>
> The -cclib arguments specify additional command-line arguments that
> will be passed to gcc. When you're building a library (as we are here)
> they are *not* used unless you link against the library that has been
> produced.
Ah, I was under the impression that it was used at both library build
and link time. It just being the latter simplifies things...
Ian.
> The reason that they are specified is that the ocaml compiler
> will record the -cclib and -ccopt command line arguments in the library.
> When you then link against that library later, it will behave as if those
> arguments were passed on the command line. In this case, it records
> the " -cclib /home/jon/xen-unstable.hg/tools/ocaml/libs/xc/../../../../tools/libxc/libxenctrl.so"
> which is unhelpful. The correct thing to do is to record the eventual
> locations of the libraries. However, there's a slight complication: these
> libraries are used in the compilation of the oxenstored binary. In order
> to prevent it attempting to link against whatever is currently installed
> instead of what's in the tree (which was the original bug), the option
> "-noautolink" can be passed to the ocaml compiler which causes it to
> ignore the recorded -cclib and -ccopt parameters, and we can instead
> pass '-cclib /path/to/.so/file'.
>
> I shall work on a patch :-)
>
> Jon
>
>
>
> On 25 Oct 2011, at 17:11, Ian Jackson wrote:
>
> > George Dunlap writes ("Re: [Xen-devel] RFC: Partially revert xen-unstable c/s 23071:a3466b005017"):
> >> Yes; it hard-codes the full path of the build tree library file.
> >
> > That seems a strange thing for it to do.
> >
> >> You're right, it's actually 23921 that caused the problem. I just did
> >> "hg annotate" and found 23071.
> >
> > Reverting this part of 23921 will just bring back the previous bug,
> > that the build system might pick up libraries in /usr (or somewhere
> > else on the default compile-time linker search path).
> >
> > Is there a way to get the ocaml linker stage to print out the complete
> > link line it's using ? If so it'll probably be possible to spot the
> > difference between the link lines used for the ocaml libraries and
> > those used elsewhere. Then we might understand what to fix.
> >
> > Ian.
>
^ permalink raw reply
* Re: [PATCHv2] msm: boards: Fix fallout from removal of machine_desc in fixup
From: David Brown @ 2011-10-25 20:50 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Russell King, linux-kernel, linux-arm-msm, linux-arm-kernel
In-Reply-To: <1319560519-18899-1-git-send-email-sboyd@codeaurora.org>
On Tue, Oct 25, 2011 at 09:35:19AM -0700, Stephen Boyd wrote:
> After 0744a3ee (ARM: platform fixups: remove mdesc argument to
> fixup function, 2010-12-20) the fixup functions introduced in
> 9e775ad (ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs,
> 2011-08-12) cause warnings like:
>
> arch/arm/mach-msm/board-msm8x60.c:85: warning: initialization
> from incompatible pointer type
>
> Fix them by removing the machine_desc argument from the fixup
> functions.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Yes, these got missed among the merges.
Acked-by: David Brown <davidb@codeaurora.org>
Russell, would you prefer this to go through your tracker, or for me
to push this to Arnd?
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv2] msm: boards: Fix fallout from removal of machine_desc in fixup
From: David Brown @ 2011-10-25 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319560519-18899-1-git-send-email-sboyd@codeaurora.org>
On Tue, Oct 25, 2011 at 09:35:19AM -0700, Stephen Boyd wrote:
> After 0744a3ee (ARM: platform fixups: remove mdesc argument to
> fixup function, 2010-12-20) the fixup functions introduced in
> 9e775ad (ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs,
> 2011-08-12) cause warnings like:
>
> arch/arm/mach-msm/board-msm8x60.c:85: warning: initialization
> from incompatible pointer type
>
> Fix them by removing the machine_desc argument from the fixup
> functions.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Yes, these got missed among the merges.
Acked-by: David Brown <davidb@codeaurora.org>
Russell, would you prefer this to go through your tracker, or for me
to push this to Arnd?
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Re: [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify
From: Ian Campbell @ 2011-10-25 20:50 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Keir (Xen.org), jeremy@goop.org, xen-devel@lists.xensource.com,
Ian Jackson, Konrad Rzeszutek Wilk
In-Reply-To: <4EA71F32.9040208@tycho.nsa.gov>
On Tue, 2011-10-25 at 21:42 +0100, Daniel De Graaf wrote:
> On 10/25/2011 04:27 PM, Ian Campbell wrote:
> > On Tue, 2011-10-25 at 20:41 +0100, Daniel De Graaf wrote:
> >>
> >>>> Hmm. Perhaps have a magic value for refcount (-1?) that indicates
> >> evtchn_get is not
> >>>> available. That would become the default value of refcnt, and
> >> evtchn.c would then
> >>>> use evtchn_make_refcounted() to change the refcount to 1 and allow
> >> _get/_put to work.
> >>>
> >>> How would that work when the IRQ subsystem (so everything is setup
> >> in the kernel)
> >>> gets an event? Would the refcount be for that -1.. oh. You would
> >> only set
> >>> the refcnt when the _get/_put calls are made and not when in-kernel
> >> calls to setup> IRQs are done?
> >>>
> >>
> >> Right. The reference count would be a dual-purpose field indicating if
> >> the event channel is kernel-internal (value -1) or userspace-visible
> >> (reference count > 0). New event channels would start out at -1, and
> >> evtchn.c would change them to 1.
> >
> > Is there any way that the reference count could be made part of the
> > datastructures associated with the /dev/xen/evtchn driver instead of the
> > core evtchn.c stuff? That wouldreduce the chance of current or futures
> > users getting something wrong.
> >
> > Ian.
>
> This would require that the gntdev and gntalloc modules have a dependency
> on the evtchn module, with the evtchn_{get,put} functions moved into that
> module.
Don't they effectively have that already, since the only evtchns you can
use with them have come from that module?
> The only other way would be to add a refcount maintenance
> function pointer to the IRQ data structure, which seems like it would lead
> to more problems than a simple reference count.
>
^ permalink raw reply
* cond_resched_lock and __might_sleep
From: Venkat Subbiah @ 2011-10-25 20:45 UTC (permalink / raw)
To: linux-rt-users@vger.kernel.org
Hello,
I am back porting an RT patch from 2.6.33 version to 2.6.32 version and
this question
is in that context. Thanks in advance for you reply!
cond_resched_lock() calls __might_sleep with PREEMPT_LOCK_OFFSET as 1.
And when
preempt count is equal to 0 it would print the warning like below.
Warning
--------
BUG: sleeping function called from invalid context at fs/jbd/commit.c:902
pcnt: 0 1 in_atomic(): 0, irqs_disabled(): 0, pid: 818, name: kjournald
Q1. Why is it ok for preempt_count to be 1 when irqs are disabled but not
when preempt_count is 1?
I am getting the warning above when
cond_resched_lock(&journal->j_list_lock) is invoked from
journal_commit_transaction(journal_t *journal) in fs/jbd/commit.c:902
cond_resched_lock code
----------------------
#ifdef CONFIG_PREEMPT
#define PREEMPT_LOCK_OFFSET PREEMPT_OFFSET
#else
#define PREEMPT_LOCK_OFFSET 0
#endif
#define cond_resched_lock(lock) ({ \
__might_sleep(__FILE__, __LINE__, PREEMPT_LOCK_OFFSET); \
__cond_resched_lock(lock); \
})
__might_sleep code
--------------------
void __might_sleep(char *file, int line, int preempt_offset)
{
#ifdef in_atomic
static unsigned long prev_jiffy; /* ratelimiting */
if ((preempt_count_equals(preempt_offset) && !irqs_disabled()) ||
system_state != SYSTEM_RUNNING || oops_in_progress)
return;
if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
return;
prev_jiffy = jiffies;
printk(KERN_ERR
"BUG: sleeping function called from invalid context at %s:%d\n",
.......
.......
}
preempt_count_equals() code
----------------------------
#if defined(CONFIG_DEBUG_SPINLOCK_SLEEP) || defined(CONFIG_DEBUG_PREEMPT)
static inline int preempt_count_equals(int preempt_offset)
{
int nested = (preempt_count() & ~PREEMPT_ACTIVE);
#ifndef CONFIG_PREEMPT_RT
nested += rcu_preempt_depth();
#endif
return (nested == preempt_offset);
}
-Venkat
^ permalink raw reply
* [U-Boot] [PATCH] sandbox: Add asm/cache.h for sandbox
From: Anton Staaf @ 2011-10-25 20:48 UTC (permalink / raw)
To: u-boot
This file is required by the new DMA buffer alignment macro.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
---
arch/sandbox/include/asm/cache.h | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644 arch/sandbox/include/asm/cache.h
diff --git a/arch/sandbox/include/asm/cache.h b/arch/sandbox/include/asm/cache.h
new file mode 100644
index 0000000..6e11102
--- /dev/null
+++ b/arch/sandbox/include/asm/cache.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SANDBOX_CACHE_H__
+#define __SANDBOX_CACHE_H__
+
+/*
+ * For native compilation of the sandbox we should still align
+ * the contents of stack buffers to something reasonable. The
+ * GCC macro __BIGGEST_ALIGNMENT__ is defined to be the maximum
+ * required alignment for any basic type. This seems reasonable.
+ */
+#define ARCH_DMA_MINALIGN __BIGGEST_ALIGNMENT__
+
+#endif /* __SANDBOX_CACHE_H__ */
--
1.7.3.1
^ permalink raw reply related
* [xen-4.0-testing test] 9610: regressions - FAIL
From: xen.org @ 2011-10-25 20:47 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 9610 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9610/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 9599
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass
test-amd64-i386-xl-multivcpu 15 guest-stop fail never pass
test-amd64-i386-xl 15 guest-stop fail never pass
test-i386-i386-xl 15 guest-stop fail never pass
test-amd64-amd64-xl 15 guest-stop fail never pass
test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail blocked in 9599
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-rhel6hvm-intel 7 redhat-install fail never pass
test-amd64-i386-rhel6hvm-amd 7 redhat-install fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 7 windows-install fail never pass
test-i386-i386-xl-win 7 windows-install fail never pass
test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass
version targeted for testing:
xen a5cc3b953ed9
baseline version:
xen da9f945b3db8
------------------------------------------------------------
People who touched revisions under test:
Keir Fraser <keir@xen.org>
Wei Huang <wei.huang2@amd.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl fail
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 21551:a5cc3b953ed9
tag: tip
user: Wei Huang <wei.huang2@amd.com>
date: Tue Oct 25 16:44:40 2011 +0100
amd xsave: Move xsave initialization code to a common place
This patch moves xsave/xrstor code to CPU common file. First of all,
it prepares xsave/xrstor support for AMD CPUs. Secondly, Xen would
crash on __context_switch() without this patch on xsave-capable AMD
CPUs. The crash was due to cpu_has_xsave reports true in domain.c
while xsave space wasn't initialized.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
xen-unstable changeset: 22462:98eb4a334b77
xen-unstable date: Tue Dec 07 18:26:38 2010 +0000
changeset: 21550:da9f945b3db8
user: Keir Fraser <keir@xen.org>
date: Mon Oct 24 18:04:42 2011 +0100
Revert xen-unstable:23871:503ee256fecf
Signed-off-by: Keir Fraser <keir@xen.org>
(qemu changes not included)
^ permalink raw reply
* Re: [GIT PULL] 9p changes fro merge window
From: Geert Uytterhoeven @ 2011-10-25 20:46 UTC (permalink / raw)
To: Eric Van Hensbergen; +Cc: Linus Torvalds, V9FS Developers, linux-kernel
In-Reply-To: <CAFkjPTkbEbDp9pOg0mOrCh4BdR0SUrVj_7aJ1yfEsqRjQQcqeQ@mail.gmail.com>
On Tue, Oct 25, 2011 at 22:23, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 3:14 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> On Tue, Oct 25, 2011 at 2:25 AM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>> On Mon, Oct 24, 2011 at 6:28 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>>
>>> (Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)
>>
>> okay. that's weird. I thought linux-next has been pulling from my
>> github tree (I sent an updated URL some time back). I guess I never
>> really checked to make sure he was getting the updated files. I'll
>> rectify this as well.
>
> okay, which linux-next tree are you looking at (and/or which patches
> are they missing)? If I look at
> /pub/scm/linux/kernel/git/next/linux-next.git on kernel.org I see all
> the patches mentioned in my pull. Sorry in advance if I'm doing
> something stupid.
Current linux-next is next-20111025, but the previous one was next-20111014.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Re: [PATCH 1/2] xen/event: Add reference counting to event channel
From: Ian Campbell @ 2011-10-25 20:44 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Ian Jackson, Daniel De Graaf, xen-devel@lists.xensource.com,
Keir (Xen.org), jeremy@goop.org
In-Reply-To: <20111025190944.GF10062@phenom.dumpdata.com>
On Tue, 2011-10-25 at 20:09 +0100, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 25, 2011 at 09:17:15AM +0100, Ian Campbell wrote:
> > On Mon, 2011-10-24 at 21:22 +0100, Konrad Rzeszutek Wilk wrote:
> > >
> > > > +void evtchn_put(unsigned int evtchn)
> > >
> > > The decleration for 'evtchn' is 'unsigned short' so that can be
> > > used instead of 'unsigned int'.
> >
> > I think I nearly made the same comment but then I looked at
> > drivers/xen/events.c and found that it uses "unsigned", "unsigned
> > short", "unsigned int" and "int" fairly interchangeably. The externally
> > visible API (i.e. include/xen/events.h) tends to stick to just "unsigned
> > int" or "int".
> >
> > The problem with the short types is that they don't leave room for an
> > error indication, which is why on the Xen tools (libxc) side we have his
> > piece of minor ugliness:
> > typedef int evtchn_port_or_error_t;
> >
> > The actual hypercall interface uses "typedef uint32_t evtchn_port_t" but
> > AIUI real evtchn values are guaranteed to fit in 31 bits.
>
>
> Oh fun! So we actually have a bug with 'unsigned short' cutting it down
> from 2^31 to 2^16!
The actual maximums are 1024 (on x86_32) and 4096 (on x86_64) so
"guaranteed to fit 31 bits" (which I took from the xenctrl.h comment) is
more a case of definitely big enough. The use of 31 is more of an
allusion to errors being negative, I think.
Ian
^ permalink raw reply
* [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: correctly set the data field in the TT_REPONSE packet
From: Antonio Quartulli @ 2011-10-25 20:42 UTC (permalink / raw)
To: stable; +Cc: b.a.t.m.a.n, Marek Lindner
In-Reply-To: <1319575362-20828-1-git-send-email-ordex@autistici.org>
In the TT_RESPONSE packet, the number of carried entries is not correctly set.
This leads to a wrong interpretation of the packet payload on the receiver side
causing random entries to be added to the global translation table. Therefore
the latter gets always corrupted, triggering a table recovery all the time.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
David S. Miller already merged this patch as
9d8523931f7f5eb8900077f0da0fbe6b8ad0010b in his net-next tree
net/batman-adv/translation-table.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index f599db9..ef1acfd 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -999,7 +999,6 @@ static struct sk_buff *tt_response_fill_table(uint16_t tt_len, uint8_t ttvn,
tt_response = (struct tt_query_packet *)skb_put(skb,
tt_query_size + tt_len);
tt_response->ttvn = ttvn;
- tt_response->tt_data = htons(tt_tot);
tt_change = (struct tt_change *)(skb->data + tt_query_size);
tt_count = 0;
@@ -1025,6 +1024,10 @@ static struct sk_buff *tt_response_fill_table(uint16_t tt_len, uint8_t ttvn,
}
rcu_read_unlock();
+ /* store in the message the number of entries we have successfully
+ * copied */
+ tt_response->tt_data = htons(tt_count);
+
out:
return skb;
}
--
1.7.3.4
^ permalink raw reply related
* [B.A.T.M.A.N.] [PATCH 1/2] batman-adv: fix tt_local_reset_flags() function
From: Antonio Quartulli @ 2011-10-25 20:42 UTC (permalink / raw)
To: stable; +Cc: b.a.t.m.a.n, Marek Lindner
Currently the counter of tt_local_entry structures (tt_local_num) is incremented
each time the tt_local_reset_flags() is invoked causing the node to send wrong
TT_REPONSE packets containing a copy of non-initialised memory thus corrupting
other nodes global translation table and making higher level communication
impossible.
Reported-by: Junkeun Song <jun361@gmail.com>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Acked-by: Junkeun Song <jun361@gmail.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
David S. Miller already merged this patch as
31901264511cf20c5ed33b8649a3ca9ce28df60b in his net-next tree
net/batman-adv/translation-table.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index fb6931d..f599db9 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -1668,6 +1668,8 @@ static void tt_local_reset_flags(struct bat_priv *bat_priv, uint16_t flags)
rcu_read_lock();
hlist_for_each_entry_rcu(tt_local_entry, node,
head, hash_entry) {
+ if (!(tt_local_entry->flags & flags))
+ continue;
tt_local_entry->flags &= ~flags;
atomic_inc(&bat_priv->num_local_tt);
}
--
1.7.3.4
^ permalink raw reply related
* Re: Re: [PATCH 2/2] xen/gnt{dev, alloc}: reserve event channels for notify
From: Daniel De Graaf @ 2011-10-25 20:42 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir (Xen.org), jeremy@goop.org, xen-devel@lists.xensource.com,
Ian Jackson, Konrad Rzeszutek Wilk
In-Reply-To: <1319574443.16747.1.camel@dagon.hellion.org.uk>
On 10/25/2011 04:27 PM, Ian Campbell wrote:
> On Tue, 2011-10-25 at 20:41 +0100, Daniel De Graaf wrote:
>>
>>>> Hmm. Perhaps have a magic value for refcount (-1?) that indicates
>> evtchn_get is not
>>>> available. That would become the default value of refcnt, and
>> evtchn.c would then
>>>> use evtchn_make_refcounted() to change the refcount to 1 and allow
>> _get/_put to work.
>>>
>>> How would that work when the IRQ subsystem (so everything is setup
>> in the kernel)
>>> gets an event? Would the refcount be for that -1.. oh. You would
>> only set
>>> the refcnt when the _get/_put calls are made and not when in-kernel
>> calls to setup> IRQs are done?
>>>
>>
>> Right. The reference count would be a dual-purpose field indicating if
>> the event channel is kernel-internal (value -1) or userspace-visible
>> (reference count > 0). New event channels would start out at -1, and
>> evtchn.c would change them to 1.
>
> Is there any way that the reference count could be made part of the
> datastructures associated with the /dev/xen/evtchn driver instead of the
> core evtchn.c stuff? That wouldreduce the chance of current or futures
> users getting something wrong.
>
> Ian.
This would require that the gntdev and gntalloc modules have a dependency
on the evtchn module, with the evtchn_{get,put} functions moved into that
module. The only other way would be to add a refcount maintenance
function pointer to the IRQ data structure, which seems like it would lead
to more problems than a simple reference count.
--
Daniel De Graaf
National Security Agency
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 03/25] vmstate: make all architectures export a way to migrate cpu's
From: Andreas Färber @ 2011-10-25 20:41 UTC (permalink / raw)
To: quintela
Cc: aliguori, qemu-devel, Alexander Graf, Max Filippov, Michael Walle,
Paul Brook, Aurelien Jarno, Richard Henderson
In-Reply-To: <m3aa8poysw.fsf@neno.neno>
Am 25.10.2011 17:50, schrieb Juan Quintela:
> Andreas Färber <afaerber@suse.de> wrote:
>>> diff --git a/target-m68k/machine.c b/target-m68k/machine.c
>>> index e69de29..86b6fe9 100644
>>> --- a/target-m68k/machine.c
>>> +++ b/target-m68k/machine.c
>>> @@ -0,0 +1,10 @@
>>> +
>>> +#include "hw/hw.h"
>>> +
>>> +/* To make this architecture migratable, we need to define cpu state
>>> + here. Other things need to be done elsewhere */
>>> +
>>> +const VMStateDescription vmstate_cpu = {
>>> + .name = "cpu",
>>> + .unmigratable = 1,
>>> +};
>>
>> Here ...
>>
>>> diff --git a/target-sh4/machine.c b/target-sh4/machine.c
>>> index e69de29..86b6fe9 100644
>>> --- a/target-sh4/machine.c
>>> +++ b/target-sh4/machine.c
>>> @@ -0,0 +1,10 @@
>>> +
>>> +#include "hw/hw.h"
>>> +
>>> +/* To make this architecture migratable, we need to define cpu state
>>> + here. Other things need to be done elsewhere */
>>> +
>>> +const VMStateDescription vmstate_cpu = {
>>> + .name = "cpu",
>>> + .unmigratable = 1,
>>> +};
>>
>> ... and here you sort-of create new files (empty before) without a
>> license header. The contents is trivial right now, but it would get a
>> case for the Wiki trying to figure out what license to put on other
>> people's code.
>
> None of target-*/machine.c files have a license line. I can put the
> normal boilerplate on them, but I have just transformed them, So .. who
> should I put as copyright owner? Puting me is (at least) a bit
> presumptuous, if not just plain false O:-)
Note my comment was specific to those that you did not really transform.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply
* Re: Tuning of exported VM template files (XCP 1.1)
From: Ian Campbell @ 2011-10-25 20:41 UTC (permalink / raw)
To: Mark Schneider
Cc: M. Schneider, Xen-devel@lists.xensource.com,
xen-users@lists.xensource.com
In-Reply-To: <4EA71CA9.8000109@it-infrastrukturen.org>
On Tue, 2011-10-25 at 21:31 +0100, Mark Schneider wrote:
> Hello,
Hi.
Please do not cross post to multiple lists, pick the one which best
suits your question. In this case questions regarding XCP and xe/xapi
are likely best addressed to the xen-api@ list.
Note also that xen-devel@ is a list for the discussion of the
development of Xen and not user support.
Ian.
>
> How can I modify exported VM template (s. attachment) to fit particular
> requirements?
> I would like to install them again after modifications for creating of
> new VMs.
>
> Exported VM templates are binary files (kind of DB). Are there any tools
> to edit such VM template files? I have to use xe CLI / Linux tools
> (can't use XenCenter).
>
> Another possibility would be to export a template from already modified
> installed VM. How? I didn't find any useful information in docs or on
> the net about this topic.
>
> Thank you in advance for any hints.
>
> regards, Mark
>
> --
> ms@it-infrastrukturen.org
>
>
> ps. Example of VM structure
> # ---
> [root@xcp11db02 ~]# xe vm-list name-label=ubuntu11dbrt20 params=
> uuid ( RO) : 4133031a-e064-38e7-416d-72e1eb0a9118
> name-label ( RW): ubuntu11dbrt20
> name-description ( RW): Installed via xe CLI
> user-version ( RW): 1
> is-a-template ( RW): false
> is-a-snapshot ( RO): false
> snapshot-of ( RO):<not in database>
> snapshots ( RO):
> snapshot-time ( RO): 19700101T00:00:00Z
> snapshot-info ( RO):
> parent ( RO): 7c3081c0-5d69-5d9b-3c41-c162ded416ee
> children ( RO):
> is-control-domain ( RO): false
> power-state ( RO): running
> memory-actual ( RO): 8589848576
> memory-target ( RO):<expensive field>
> memory-overhead ( RO): 77594624
> memory-static-max ( RW): 8589934592
> memory-dynamic-max ( RW): 8589934592
> memory-dynamic-min ( RW): 2147483648
> memory-static-min ( RW): 134217728
> suspend-VDI-uuid ( RO):<not in database>
> VCPUs-params (MRW):
> VCPUs-max ( RW): 8
> VCPUs-at-startup ( RW): 4
> actions-after-shutdown ( RW): Destroy
> actions-after-reboot ( RW): Restart
> actions-after-crash ( RW): Restart
> console-uuids (SRO): bd4b277b-6941-7111-7b24-6579ada555ca
> platform (MRW): timeoffset: 0; nx: false; acpi: true; apic: true; pae: true; viridian: true
> allowed-operations (SRO): changing_dynamic_range; hard_reboot; hard_shutdown; pause; snapshot
> current-operations (SRO):
> blocked-operations (MRW):
> allowed-VBD-devices (SRO):<expensive field>
> allowed-VIF-devices (SRO):<expensive field>
> possible-hosts ( RO):<expensive field>
> HVM-boot-policy ( RW): BIOS order
> HVM-boot-params (MRW): order: dc
> HVM-shadow-multiplier ( RW): 1.000
> PV-kernel ( RW):
> PV-ramdisk ( RW):
> PV-args ( RW):
> PV-legacy-args ( RW):
> PV-bootloader ( RW):
> PV-bootloader-args ( RW):
> last-boot-CPU-flags ( RO):
> last-boot-record ( RO):<expensive field>
> resident-on ( RO): 280e2816-2d45-4217-881e-e2ad4b423159
> affinity ( RW):<not in database>
> other-config (MRW): last_shutdown_time: 20111025T18:32:09Z; last_shutdown_action: Restart; last_shutdown_initiator: external; last_shutdown_reason: rebooted; mac_seed: a507ca72-1a89-e83d-a1b1-1ee749e6088f; install-methods: cdrom
> dom-id ( RO): 6
> recommendations ( RO):<restrictions><restriction field="memory-static-max" max="34359738368" /><restriction field="vcpus-max" max="8" /><restriction property="number-of-vbds" max="7" /><restriction property="number-of-vifs" max="7" /></restrictions>
> xenstore-data (MRW):
> ha-always-run ( RW): false
> ha-restart-priority ( RW):
> blobs ( RO):
> start-time ( RO): 20111025T18:32:29Z
> install-time ( RO): 20111024T17:22:55Z
> VCPUs-number ( RO): 4
> VCPUs-utilisation (MRO):<expensive field>
> os-version (MRO):<not in database>
> PV-drivers-version (MRO):<not in database>
> PV-drivers-up-to-date ( RO):<not in database>
> memory (MRO):<not in database>
> disks (MRO):<not in database>
> networks (MRO):<not in database>
> other (MRO):<not in database>
> live ( RO):<not in database>
> guest-metrics-last-updated ( RO):<not in database>
> cooperative ( RO):<expensive field>
> protection-policy ( RW):<not in database>
> is-snapshot-from-vmpp ( RO): false
> tags (SRW):
>
>
^ permalink raw reply
* [U-Boot] [PATCH 01/39] DEBUG: Fix debug macros
From: 馬克泡 @ 2011-10-25 20:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CANr=Z=YuJcr-WGh4+AKyvxX_h1+-LBw8RFMSS2UDYQh_MLfqDw@mail.gmail.com>
Hi all,
2011/10/26 Joe Hershberger <joe.hershberger@gmail.com>:
> On Sun, Oct 23, 2011 at 12:12 PM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Mike Frysinger,
>>
> I'm working on a patch for the net code that benefits from the debugX
> macro. ?Especially for the net code, the debug traces can be
> overwhelming depending on the issue you are looking at. ?I recommend
> we keep it around.
>
> Thanks
> -Joe
I agreed with Joe,
I feel some debug code is necessary to keep it into levels since some
you usually need to split debug level into 2 or 3 to help the debug work.
A device driver which has been commit into the mainline source should be
worked on most of platforms. However, it still might be need to do debug work
on several different platform since the hardware integration might be different
then introduce problem. Hence the debug codes in detail should not be removed
in the mainline code, and it should be labeled with some debug levels.
Those code will help the debug work in future.
Moreover, some device driver will need to be fixed when the hardware
will be fixed
or upgraded and introduce different versions. Those hardware still
follow a common
behaviors, a common set of registers, even the 50% usage of the driver
will be same.
Hence keep debug code in deep level will be help.
We can keep it until someone really have time to fix it.
--
Best regards,
Macpaul Lin
^ permalink raw reply
* Re: Please re-enable the git-commits-head mailing list
From: Boaz Harrosh @ 2011-10-25 20:40 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Linus Torvalds, linux-kernel, Andrew Morton
In-Reply-To: <20111025134800.4da48376@tpl.lwn.net>
On 10/25/2011 12:48 PM, Jonathan Corbet wrote:
> On Tue, 25 Oct 2011 09:57:19 -0700
> Boaz Harrosh <bharrosh@panasas.com> wrote:
>
>> Since the brain stroke of vger.kernel.org we stopped getting any messages on
>> git-commits-head@vger.kernel.org It is important because of the mirroring delay of the gits which
>> can take 24 h in some places. And because it is a very convenient way to look for something or in
>> general keep track of what's going on.
>>
>> Please re-enable it. It should be as simple as:
>> git config --add hooks.mailinglist "git-commits-head@vger.kernel.org"
>
> The commits list was discussed at the kernel summit. The people who
> are working to piece kernel.org together are aware of the value of this
> list and will arrange for it when they can. As I understand it, the
> first priority remains getting the git trees back onto kernel.org to
> support the merge window, though.
>
> jon
Thanks Jonathan.
Most important that it was not forgotten. We can wait a merge window that's
fine.
Thanks
Boaz
^ permalink raw reply
* Re: Linux 3.1 domU + ext3 = WARNING: at fs/ext3/inode.c
From: Christopher S. Aker @ 2011-10-25 20:40 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen devel
In-Reply-To: <20111025201239.GA13747@phenom.dumpdata.com>
On Oct 25, 2011, at 4:12 PM, Konrad Rzeszutek Wilk wrote:
> Oh, so this is 3.1 DomU kernel? And your Dom0 is 2.6.18?
>
> What does the guest show for the disk? As in, is the barrier feature
> enabled?
2.6.18 dom0 and a 3.1.0 domU produces this on domU boot:
EXT3-fs (xvda): using internal journal
Adding 262140k swap on /dev/xvdb. Priority:-1 extents:1 across:262140k SS
blkfront: barrier: empty write xvda op failed
blkfront: xvda: barrier or flush: disabled
end_request: I/O error, dev xvda, sector 1053048
end_request: I/O error, dev xvda, sector 1053048
Buffer I/O error on device xvda, logical block 131631
lost page write due to I/O error on xvda
Aborting journal on device xvda.
EXT3-fs (xvda): error: ext3_journal_start_sb: Detected aborted journal
EXT3-fs (xvda): error: remounting filesystem read-only
On my 3.0 based dom0 with a 3.1.0 domU blkfront doesn't complain - and I *think* 3.1 domU may actually work as expected -- initial tests couldn't get it to trace...
> .. snip
>>
>> Am I barking up the wrong list?
>
> Not sure.. It depends on what your dom0 version is and what
> the backend is? blktap or blkback?
blkback.
We suspected a dom0/domU incompatibility after doing some research. Hopefully this can get resolved within the guest since we have literally thousands of 2.6.18 dom0s deployed and rebooting everyone is not my idea of a good time :)
Thanks,
-Chris
^ permalink raw reply
* Re: [PATCH] completion: fix issue with process substitution not working on Git for Windows
From: Johannes Sixt @ 2011-10-25 20:39 UTC (permalink / raw)
To: Stefan Naewe; +Cc: spearce, git, gitster
In-Reply-To: <1319565695-5976-1-git-send-email-stefan.naewe@gmail.com>
Am 25.10.2011 20:01, schrieb Stefan Naewe:
> Git for Windows comes with a bash that doesn't support process substitution.
> It issues the following error when using git-completion.bash with
> GIT_PS1_SHOWUPSTREAM set:
>
> $ export GIT_PS1_SHOWUPSTREAM=1
> sh.exe": cannot make pipe for process substitution: Function not implemented
> sh.exe": cannot make pipe for process substitution: Function not implemented
> sh.exe": <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n '): ambiguous redirect
>
> Replace the process substitution with a simple "echo $var | while...".
>
> Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
> ---
> contrib/completion/git-completion.bash | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 8648a36..926db80 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -110,6 +110,8 @@ __git_ps1_show_upstream ()
> local upstream=git legacy="" verbose=""
>
> # get some config options from git-config
> + output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> + echo "$output" | \
> while read key value; do
> case "$key" in
> bash.showupstream)
> @@ -125,7 +127,7 @@ __git_ps1_show_upstream ()
> upstream=svn+git # default upstream is SVN if available, else git
> ;;
> esac
> - done < <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')
> + done
>
> # parse configuration values
> for option in ${GIT_PS1_SHOWUPSTREAM}; do
Are you sure that the result still works as intended? The while loop
sets a few variables. When you place it in a pipe, the loop runs in a
subshell, and subsequent code will not see the modified values. Unless
bash knows how to optimize away the subshell, that is.
OTOH, when you use while ...; do ...; done < <(...), the while loop is
not in a subshell.
An alternative is to use: while ...; do ...; done <<< "$output"
BTW, you don't need to protect the end-of-line with a backslash if the
line ends with the pipe symbol.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add code for verify_dump option
From: Jens Axboe @ 2011-10-25 20:39 UTC (permalink / raw)
To: Steven Lang; +Cc: fio@vger.kernel.org
In-Reply-To: <CAAUT-yPmmiUVeKDXLCKzUxL8uyYHgAT_8buF3Oor_rpy7QqBaw@mail.gmail.com>
On 2011-10-25 22:33, Steven Lang wrote:
> The verify_dump option is defined and documented, but does nothing.
> This one-liner enables the option.
>
> One thing I wanted to open a small discussion on is the default
> behavior. When the verify dump behavior was added, it was something
> new, so it seems more sensible to disable it by default to keep the
> old behavior; and had it been in for less time I might have been
> tempted to include that in the patch. However, even ignoring the
> change in behavior, it seems odd and possibly surprising/unexpected to
> someone who does not have experience with fio to have it suddenly spit
> out extra files; all the other options to write files
> (write_iolog/write_bw_log/write_lat_log) only write anything if
> requested. Is there a good argument to why this option would be
> enabled by default?
Thanks, applied. You are right, it probably should have been off by
default, and in fact probably should be even now.
--
Jens Axboe
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 24/25] vmstate: port arm cpu
From: Paul Brook @ 2011-10-25 20:39 UTC (permalink / raw)
To: Richard Henderson; +Cc: Peter Maydell, aliguori, qemu-devel, Juan Quintela
In-Reply-To: <4EA70947.9050904@twiddle.net>
> >> + env->uncached_cpsr = env->cpsr_vmstate & CPSR_M;
> >> + cpsr_write(env, env->cpsr_vmstate, 0xffffffff);
> >
> > [1] Maybe a necessary hack, but still a wart from requiring static table
> > driven vmstate descriptions.
>
> I wonder if we shouldn't make it easier to do what I do for Alpha
> with the rather different hack for the fpcr.
>
> That might avoid some of the other pre/post_load hooks, and the
> extra data fields that requires in the cpu structure.
Sounds reasonable.
Having either woraround is a bit lame. Having ARM and Alpha use different
workarounds for the same problem really sucks.
Paul
^ permalink raw reply
* Re: Mapping of Shared Page in e500 Powerpc kvm
From: Scott Wood @ 2011-10-25 20:38 UTC (permalink / raw)
To: kvm-ppc
In-Reply-To: <loom.20111023T153549-514@post.gmane.org>
On 10/23/2011 08:45 AM, Aashish Mittal wrote:
> Hi
>
> I'm working on powerpc e500 machine (Freescale P2020RDB machine) and
> using the paravirtualization guest support available inside kvm and wanted
> to some bookkeeping of my own on the shared page and from what i
> understood is that a single tlb entry is reserved for the shared page
> (magic page) when running the guest which is never preempted or flushed
> but when i tried printing out the dtlb misses on this shared page it show
> me a large number of dtlb misses on this shared page which means that
> this page is being preempted or flushed out in some way . Can someone pleas
> e clarify this situation if i'm understanding something wrong or is it a bug ?
What kernel are you running, and how many is "a large number"?
The magic page TLB entry will need to be reloaded if the shadow PID gets
invalidated, another guest gets scheduled on that CPU, or if something
like hugetlbfs steps on that TLB entry.
If you're running a kernel that predates shadow PID support, it will be
invalidated (along with everything else in the TLB) whenever you
schedule out or change guest execution mode .
-Scott
^ 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.