* Re: [Qemu-devel] [PULL] tcg/interpreter: Add TCG + interpreter for bytecode
From: Anthony Liguori @ 2011-10-31 21:38 UTC (permalink / raw)
To: Stefan Weil; +Cc: Blue Swirl, QEMU Developers, Aurelien Jarno
In-Reply-To: <4EAF13A8.5020303@weilnetz.de>
On 10/31/2011 04:31 PM, Stefan Weil wrote:
> Hi,
>
> this is a 3rd version of the patch series which adds support for
> QEMU on any host by using a TCG interpreter (TCI).
>
> Version 2 was sent to the list and is available here:
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02504.html
>
> The new version removed the TRACE macros which I used during development.
> They are no longer needed. This fixes malc's feedback.
>
> Patches 1, 2, 5 and 6 are only rebased.
>
> Patch 1 is useful even without TCI and improves the handling of a
> special case needed for PPC hosts.
>
> Please tell me if I should send the complete patches to qemu-devel.
>
> I'd appreciate if the series could be pulled before QEMU 1.0 to form
> a base for further development of TCI.
I'll defer to Blue and/or Aurelien here as I don't know enough about TCG to
really review this series.
But I'd recommend waiting to pull this until after 1.1 opens up. This is the
sort of thing that 1) people are likely to actually use and 2) could use a full
development cycle of testing to get hardened before showing up in a release.
I'd feel better about pulling this into 1.0 if it was guarded by a configure
option and disabled by default just to enforce that it's an experimental feature.
Regards,
Anthony Liguori
>
> Regards,
> Stefan Weil
>
>
> The following changes since commit ff74c5a9a91c6dbf1017195462aa4176f7381240:
>
> Merge remote-tracking branch 'riku/linux-user-for-upstream' into staging
> (2011-10-31 15:05:40 -0500)
>
> are available in the git repository at:
>
> git://qemu.weilnetz.de/qemu.git tci
>
> Stefan Weil (6):
> tcg: TCG targets may define tcg_qemu_tb_exec
> tcg: Make ARRAY_SIZE(tcg_op_defs) globally available
> tcg: Add bytecode generator for tcg interpreter
> tcg: Add interpreter for bytecode
> tcg: Add tci disassembler
> tcg: Add tcg interpreter to configure / make
>
> Makefile.target | 4 +
> configure | 34 ++-
> dis-asm.h | 1 +
> disas.c | 4 +-
> dyngen-exec.h | 12 +-
> exec-all.h | 22 +-
> tcg/ppc/tcg-target.h | 4 +
> tcg/tcg.c | 1 +
> tcg/tcg.h | 12 +-
> tcg/tci/README | 130 ++++++
> tcg/tci/tcg-target.c | 906 +++++++++++++++++++++++++++++++++++++
> tcg/tci/tcg-target.h | 160 +++++++
> tci-dis.c | 59 +++
> tci.c | 1208 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 14 files changed, 2545 insertions(+), 12 deletions(-)
> create mode 100644 tcg/tci/README
> create mode 100644 tcg/tci/tcg-target.c
> create mode 100644 tcg/tci/tcg-target.h
> create mode 100644 tci-dis.c
> create mode 100644 tci.c
>
>
>
^ permalink raw reply
* [GIT PULL] regulator updates for 3.2
From: Mark Brown @ 2011-10-31 21:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Liam Girdwood, linux-kernel
Please pull from the tree below to get updates to the regulator API for
version 3.2. Since Liam has been slammed with work until very recently
and is still catching up on things like restoring hosting for his git
trees after the kernel.org breakin I'm sending the request instead of
him; hopefully he'll get things sorted out soon but we weren't sure
that'd happen during the merge window.
This has been a quiet release cycle for the regulator API - nothing much
going on in the core and not many driver updates. The biggest things
are that we've got a new gpio-regulator driver (for devices that select
voltages with GPIOs) and the tps65023 driver gained support for TPS65020
as well. The two commits from Marcus Folkesson with the same subject
are actually separate commits with similar changelogs.
The following changes since commit 322a8b034003c0d46d39af85bf24fee27b902f48:
Linux 3.1-rc1 (2011-08-07 18:23:30 -0700)
are available in the git repository at:
git://opensource.wolfsonmicro.com/regulator.git for-linus
Axel Lin (4):
regulator: tps65912: Remove unused define of TPS65912_MAX_REG_ID
regulator: 88pm8607: Fix off-by-one value range checking in the case of no id is matched
regulator: Ensure enough enable time for max8649
regulator: tps6507x: Remove num_voltages array
H Hartley Sweeten (1):
regulator: remove duplicate REG_CTRL2 defines in tps65023
Heiko Stübner (3):
regulator: Add driver for gpio-controlled regulators
regulator: gpio-regulator add dependency on GENERIC_GPIO
regulator: Fix possible nullpointer dereference in regulator_enable()
Marcus Folkesson (5):
regulator: tps65023: Fixes i2c configuration issues
regulator: tps65023: Fixes i2c configuration issues
regulator: tps65023: Set missing bit for update core-voltage
regulator: tps65023: Setting correct core regulator for tps65021
regulator: tps65023: Added support for the similiar TPS65020 chip
Mark Brown (5):
regulator: Add debugfs file showing the supply map table
regulator: Fix some bitrot in the machine driver documentation
regulator: Clarify documentation for regulator-regulator supplies
regulator: Add module.h include to gpio-regulator
regulator: Constify constraints name
MyungJoo Ham (1):
regulator: max8952: removed unused mutex.
Randy Dunlap (2):
regulator: aat2870-regulator.c needs module.h
regulator: fix regulator/consumer.h kernel-doc warning
Xin Xie (1):
regulator: tps6586x: add SMx slew rate setting
Documentation/power/regulator/machine.txt | 19 +-
drivers/regulator/88pm8607.c | 2 +-
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/aat2870-regulator.c | 1 +
drivers/regulator/core.c | 43 ++++-
drivers/regulator/gpio-regulator.c | 358 +++++++++++++++++++++++++++++
drivers/regulator/max8649.c | 2 +-
drivers/regulator/max8952.c | 3 -
drivers/regulator/tps65023-regulator.c | 183 +++++++++++++--
drivers/regulator/tps6507x-regulator.c | 8 +-
drivers/regulator/tps6586x-regulator.c | 32 +++-
drivers/regulator/tps65912-regulator.c | 2 -
include/linux/mfd/tps6586x.h | 16 ++
include/linux/regulator/consumer.h | 2 +-
include/linux/regulator/gpio-regulator.h | 87 +++++++
include/linux/regulator/machine.h | 2 +-
17 files changed, 722 insertions(+), 49 deletions(-)
create mode 100644 drivers/regulator/gpio-regulator.c
create mode 100644 include/linux/regulator/gpio-regulator.h
^ permalink raw reply
* [RFC][PATCH] clocksource: Avoid selecting mult values that might overflow when adjusted
From: John Stultz @ 2011-10-31 21:40 UTC (permalink / raw)
To: LKML; +Cc: John Stultz, Yong Zhang, David Daney, Thomas Gleixner
Here's another rev of my earlier patch. Let me know if it helps.
-john
For some frequqencies, the clocks_calc_mult_shift() function will
unfortunately select mult values very close to 0xffffffff. This
has the potential to overflow when NTP adjusts the clock, adding
to the mult value.
This patch adds a clocksource.maxadj value, which provides
an approximation of an 11% adjustment(NTP limits adjustments to
500ppm and the tick adjustment is limited to 10%), which could
be made to the clocksource.mult value. This is then used to both
check that the current mult value won't overflow/underflow, as
well as warning us if the timekeeping_adjust() code pushes over
that 11% boundary.
UNTESTED! NOT FOR INCLUSION (YET)!
CC: Yong Zhang <yong.zhang0@gmail.com>
CC: David Daney <ddaney.cavm@gmail.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Chen Jie <chenj@lemote.com>
Reported-by: zhangfx <zhangfx@lemote.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
include/linux/clocksource.h | 3 ++-
kernel/time/clocksource.c | 37 +++++++++++++++++++++++++++----------
kernel/time/timekeeping.c | 3 +++
3 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 139c4db..c86c940 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -156,6 +156,7 @@ extern u64 timecounter_cyc2time(struct timecounter *tc,
* @mult: cycle to nanosecond multiplier
* @shift: cycle to nanosecond divisor (power of two)
* @max_idle_ns: max idle time permitted by the clocksource (nsecs)
+ * @maxadj maximum adjustment value to mult (~11%)
* @flags: flags describing special properties
* @archdata: arch-specific data
* @suspend: suspend function for the clocksource, if necessary
@@ -172,7 +173,7 @@ struct clocksource {
u32 mult;
u32 shift;
u64 max_idle_ns;
-
+ u32 maxadj;
#ifdef CONFIG_ARCH_CLOCKSOURCE_DATA
struct arch_clocksource_data archdata;
#endif
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index cf52fda..2982996 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -503,25 +503,26 @@ static u64 clocksource_max_deferment(struct clocksource *cs)
/*
* Calculate the maximum number of cycles that we can pass to the
* cyc2ns function without overflowing a 64-bit signed result. The
- * maximum number of cycles is equal to ULLONG_MAX/cs->mult which
- * is equivalent to the below.
- * max_cycles < (2^63)/cs->mult
- * max_cycles < 2^(log2((2^63)/cs->mult))
- * max_cycles < 2^(log2(2^63) - log2(cs->mult))
- * max_cycles < 2^(63 - log2(cs->mult))
- * max_cycles < 1 << (63 - log2(cs->mult))
+ * maximum number of cycles is equal to ULLONG_MAX/(cs->mult+cs->maxadj)
+ * which is equivalent to the below.
+ * max_cycles < (2^63)/(cs->mult + cs->maxadj)
+ * max_cycles < 2^(log2((2^63)/(cs->mult + cs->maxadj)))
+ * max_cycles < 2^(log2(2^63) - log2(cs->mult + cs->maxadj))
+ * max_cycles < 2^(63 - log2(cs->mult + cs->maxadj))
+ * max_cycles < 1 << (63 - log2(cs->mult + cs->maxadj))
* Please note that we add 1 to the result of the log2 to account for
* any rounding errors, ensure the above inequality is satisfied and
* no overflow will occur.
*/
- max_cycles = 1ULL << (63 - (ilog2(cs->mult) + 1));
+ max_cycles = 1ULL << (63 - (ilog2(cs->mult + cs->maxadj) + 1));
/*
* The actual maximum number of cycles we can defer the clocksource is
* determined by the minimum of max_cycles and cs->mask.
*/
max_cycles = min_t(u64, max_cycles, (u64) cs->mask);
- max_nsecs = clocksource_cyc2ns(max_cycles, cs->mult, cs->shift);
+ max_nsecs = clocksource_cyc2ns(max_cycles, cs->mult+cs->maxadj,
+ cs->shift);
/*
* To ensure that the clocksource does not wrap whilst we are idle,
@@ -640,7 +641,6 @@ static void clocksource_enqueue(struct clocksource *cs)
void __clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32 freq)
{
u64 sec;
-
/*
* Calc the maximum number of seconds which we can run before
* wrapping around. For clocksources which have a mask > 32bit
@@ -661,6 +661,23 @@ void __clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32 freq)
clocks_calc_mult_shift(&cs->mult, &cs->shift, freq,
NSEC_PER_SEC / scale, sec * scale);
+
+ /*
+ * for clocksources that have large mults, to avoid overflow.
+ * Since mult may be adjusted by ntp, add an safety extra margin
+ *
+ * We won't try to correct for more then 11% adjustments (110,000 ppm),
+ * which approximates to 1/8 or 1/2^3. Thus 1 << (shift - 3) is the
+ * largest mult adjustment we'll support.
+ */
+ cs->maxadj = 1 << (cs->shift-3);
+ while ((cs->mult + cs->maxadj < cs->mult)
+ || (cs->mult - cs->maxadj > cs->mult)) {
+ cs->mult >>= 1;
+ cs->shift--;
+ cs->maxadj = 1 << (cs->shift-3);
+ }
+
cs->max_idle_ns = clocksource_max_deferment(cs);
}
EXPORT_SYMBOL_GPL(__clocksource_updatefreq_scale);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 2b021b0e..d37c9e3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -820,6 +820,9 @@ static void timekeeping_adjust(s64 offset)
} else
return;
+ WARN_ONCE(timekeeper.mult+adj >
+ timekeeper.clock->mult + timekeeper.clock->maxadj,
+ "Adjusting more then 11%%");
timekeeper.mult += adj;
timekeeper.xtime_interval += interval;
timekeeper.xtime_nsec -= offset;
--
1.7.3.2.146.gca209
^ permalink raw reply related
* Phoronix Xen vs KVM vs Virtualbox benchmark with Ubuntu 11.10
From: Pasi Kärkkäinen @ 2011-10-31 21:40 UTC (permalink / raw)
To: xen-devel
Hello,
http://www.phoronix.com/scan.php?page=article&item=ubuntu_1110_xenkvm&num=1
Ubuntu 11.10 with Xen 4.1.1 and Linux 3.0.
Xen seems to be doing very poorly on that benchmark.
If someone has time to repeat that benchmark it would be good..
Comparing the results to those from Stefano from XenSummit 2011 NA there has be something wrong..
the results at XenSummit were pretty much the opposite compared to those by Phoronix.
-- Pasi
^ permalink raw reply
* [U-Boot] [PATCH v2] arm: Correct build error introduced by getenv_ulong() patch
From: Mike Frysinger @ 2011-10-31 21:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ04KHxvyYebLHiFYta6bpqrpiGU=TJV9X6D94QnZQnFVw@mail.gmail.com>
On Monday 31 October 2011 17:06:46 Simon Glass wrote:
> On Sun, Oct 30, 2011 at 5:44 PM, Mike Frysinger wrote:
> > On Sunday 23 October 2011 23:44:35 Simon Glass wrote:
> >> --- a/arch/arm/lib/board.c
> >> +++ b/arch/arm/lib/board.c
> >>
> >> flash_size = flash_init();
> >> if (flash_size > 0) {
> >> # ifdef CONFIG_SYS_FLASH_CHECKSUM
> >> + char *s = getenv("flashchecksum");
> >> +
> >> print_size(flash_size, "");
> >> /*
> >> * Compute and print flash CRC if flashchecksum is set to
> >> 'y' *
> >> * NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
> >> */
> >> - s = getenv("flashchecksum");
> >> if (s && (*s == 'y')) {
> >> printf(" CRC: %08X", crc32(0,
> >> (const unsigned char *)
> >> CONFIG_SYS_FLASH_BASE, @@ -566,9 +567,12 @@ void board_init_r(gd_t *id,
> >> ulong dest_addr) /* Initialize from environment */
> >> load_addr = getenv_ulong("loadaddr", 16, load_addr);
> >> #if defined(CONFIG_CMD_NET)
> >> - s = getenv("bootfile");
> >> - if (s != NULL)
> >> - copy_filename(BootFile, s, sizeof(BootFile));
> >> + {
> >> + char *s = getenv("bootfile");
> >> +
> >> + if (s != NULL)
> >> + copy_filename(BootFile, s, sizeof(BootFile));
> >> + }
> >> #endif
> >
> > seems like a better solution would be to use at the top:
> > __maybe_unused char *s;
> >
> > also, shouldn't these be "const char *s" ?
>
> We can certainly do this and I agree it is easier than #ifdefs. Does
> it introduce the possibility that one day the code will stop using the
> variable but it will still be declared? Is the fact that we need the
> #ifdefs an indication that the function should be too long and should
> be refactored? it in fact better to have these explicit so we can see
> them for the ugliness they are?
yes, you're right that it does leave the door open to the variable being
declared, never used, and gcc not emitting a warning about it.
both setups suck, but i'd lean towards the less-ifdef state ... wonder if
Wolfgang has a preference.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/948e5d8d/attachment.pgp
^ permalink raw reply
* Re: [PATCH] regulator: Use regmap_read/write(), regmap_update_bits functions directly
From: Mark Brown @ 2011-10-31 21:38 UTC (permalink / raw)
To: jhbird.choi, lrg; +Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <1319617556-29021-1-git-send-email-jhbird.choi@samsung.com>
On Wed, Oct 26, 2011 at 05:25:56PM +0900, jhbird.choi@samsung.com wrote:
> From: Jonghwan Choi <jhbird.choi@samsung.com>
>
> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Please make sure you CC Liam on all regulator API patches - you should
CC all the maintainers for the subsystem. This needs to be refreshed
against current -next, it won't apply as-is (I suspect the patch is for
3.0 rather than current code).
^ permalink raw reply
* [PATCH] regulator: Use regmap_read/write(), regmap_update_bits functions directly
From: Mark Brown @ 2011-10-31 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319617556-29021-1-git-send-email-jhbird.choi@samsung.com>
On Wed, Oct 26, 2011 at 05:25:56PM +0900, jhbird.choi at samsung.com wrote:
> From: Jonghwan Choi <jhbird.choi@samsung.com>
>
> Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Please make sure you CC Liam on all regulator API patches - you should
CC all the maintainers for the subsystem. This needs to be refreshed
against current -next, it won't apply as-is (I suspect the patch is for
3.0 rather than current code).
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 21:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ0Scvb2WyxcydL1PFC=x5Xggj44OCFpDPutd-XRgUWO-g@mail.gmail.com>
On Monday 31 October 2011 16:47:08 Simon Glass wrote:
> On Mon, Oct 31, 2011 at 1:44 PM, Mike Frysinger wrote:
> > On Monday 31 October 2011 15:11:35 Simon Glass wrote:
> >> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger wrote:
> >> > If we move the local funcs to the top of the file, and use the
> >> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
> >> > duplicated prototypes.
> >> >
> >> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> >>
> >> This is much cleaner - is the correct style to put attribute tags on
> >> the previous line?
> >
> > when responding to add your own, there isn't any real protocol. just
> > normal e-mail etiquette (no top posting/etc...). patchwork/humans will
> > do the right thing when manually updating the changelog.
>
> Actually I meant the __maybe_unused tag before the function name.
ah. i'm not sure there is a hard rule here. i did that because one line
would make the func def too long to fit.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/0b6ba257/attachment.pgp
^ permalink raw reply
* Re: [PATCH] bluez4_4.95.bb: new recipe for building bluez-4.95
From: Preskovsky, Vita @ 2011-10-31 21:18 UTC (permalink / raw)
To: Paul Menzel; +Cc: openembedded-devel@lists.openembedded.org
In-Reply-To: <1319974939.4242.19.camel@mattotaupa>
Paul,
I'm subscribed to the list and receive mails from it, but I'm new to arago and openembeded.
I have a question about the right way to define DEFAULT_PREFERENCE in recipes.
In all bluez4_4.x recipes there is definition of default preference as
DEFAULT_PREFERENCE = "-1", and bitbake takes the last one.
In the last recipe version 4.89 they defined also angstrom default preference:
DEFAULT_PREFERENCE_angstrom = "1"
So everyone, working under angstrom, as we do, compiles with the version 4.89.
We chose to work with version 4.95 (despite existence of 4.96) but we don't want this recipe will be compiled as default, only for those who will compile this recipe for specific machine as am180x-evm.
So instead of DEFAULT_PREFERENCE_angstrom I can define DEFAULT_PREFERENCE_am180x-evm = "1", that meets our goal.
Is this way more appropriate than I did previously?
Thank you,
Vita.
-----Original Message-----
From: Paul Menzel [mailto:paulepanter@users.sourceforge.net]
Sent: Sunday, October 30, 2011 1:42 PM
To: openembedded-devel@lists.openembedded.org
Cc: Preskovsky, Vita; Vita Preskovsky
Subject: Re: [oe] [PATCH] bluez4_4.95.bb: new recipe for building bluez-4.95
Dear Vita,
are you reading the list or do I have to add your address to the CC field?
Am Sonntag, den 30.10.2011, 10:58 +0100 schrieb Preskovsky, Vita:
> Please see my answers bellow.
thank you for your answer.
> -----Original Message-----
> Sent: Tuesday, October 11, 2011 4:32 PM
> Subject: Re: [oe] [PATCH] bluez4_4.95.bb: new recipe for building
> bluez-4.95
>
> Dear Vita,
>
>
> thank you for your patch.
>
> Am Dienstag, den 11.10.2011, 11:08 +0200 schrieb Vita Preskovsky:
>
> Using
>
> bluez4: Add version 4.95
>
> as the commit summary would be cleaner. Use `git commit --amend` to change that.
>
> Additionally you should elaborate more in the commit message what the patch is doing.
>
> 1. Have you tested it? Is it just an upgrade because of or does
> version
> 4.91 in the repository have any short comings so that it should be removed?
>
> I tested this recipe, and the reason I added this version is that we want to use this version of Bluez in our release.
I guess you tested it using Ȧngström, so the old recipe can be removed.
Please note that oe-core already has version 4.96.
> > Signed-off-by: Vita Preskovsky <vitap@ti.com>
> > ---
> > recipes/bluez/bluez4_4.95.bb | 30 ++++++++++++++++++++++++++++++
> > 1 files changed, 30 insertions(+), 0 deletions(-) create mode
> > 100644 recipes/bluez/bluez4_4.95.bb
> >
> > diff --git a/recipes/bluez/bluez4_4.95.bb
> > b/recipes/bluez/bluez4_4.95.bb new file mode 100644 index
> > 0000000..a682d6a
> > --- /dev/null
> > +++ b/recipes/bluez/bluez4_4.95.bb
> > @@ -0,0 +1,30 @@
> > +require bluez4.inc
> > +SRC_URI = "\
> > + http://www.kernel.org/pub/linux/bluetooth/bluez-${PV}.tar.gz \
>
> 2. As far as I know kernel.org after the compromise presently does not provide that archive. So the recipe will not build unless there is a mirror somewhere. Do you know of a mirror?
>
> There are two possible locations for this package:
> http://www.mirrorservice.org/sites/ftp.kernel.org/pub/linux/bluetooth/bluez-4.95.tar.gz
>
> http://www.angstrom-distribution.org/unstable/sources/bluez-4.95.tar.g
> z I changed the SRC_URI in my working directory for the first location
> and it worked fine. So with what location do you prefer the recipe will be released?
I am unsure about the policy myself and I do not think an “OE mirror”
has that particular archive.
> > + file://bluetooth.conf \
> > +"
> > +
> > +SRC_URI[md5sum] = "341294b2849a04a4afff5c96bfbf30b2"
> > +SRC_URI[sha256sum] = "d6ea9de410fc2bcd2620d709c2202893b218e2e6a55c3c0ce6bebd27fa4120f6"
> > +
> > +DEFAULT_PREFERENCE = "-1"
>
> 3. Why?
> > +DEFAULT_PREFERENCE_angstrom = "1"
>
> 4. Have you talked to the Ȧngström maintainers?
>
> These two variables are defined in the previous version of bluez4 recipe: bluez4_4.89.bb. Without these two definitions in my recipe bitbake prefers the old recipe upon mine, which doesn't leave me a choice but to define these variables.
The “correct” way would be to first add that recipe and then afterward sent a patch to change the preferences which the Ȧngström maintainers have to acknowledge.
> > +
> > +DEPENDS += "libsndfile1"
> > +
> > +PR = "${INC_PR}.0"
> > +
> > +# Not all distros have a recent enough udev BTUDEV = "
> > +--disable-udevrules"
> > +BTUDEV_angstrom = " --enable-udevrules"
> > +BTUDEV_shr = " --enable-udevrules"
> > +
> > +EXTRA_OECONF += "${BTUDEV}"
> > +do_configure_append(){
> > + echo "#define LIBUDEV_I_KNOW_THE_API_IS_SUBJECT_TO_CHANGE" >>
> > +${S}/config.h }
> > +
> > +FILES_${PN}-dbg += "\
> > + ${base_libdir}/udev/.debug \
> > + ${libdir}/*/.debug \
> > +"
>
> Otherwise this recipe looks good. Is it planned for branch 2011.03-maintenance?
Thanks,
Paul
^ permalink raw reply
* [PATCH 1/3] ARM: tegra: paz00: add support for wakeup gpio key
From: Marc Dietrich @ 2011-10-31 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB86D@HQMAIL01.nvidia.com>
On Monday 31 October 2011 13:13:15 Stephen Warren wrote:
> Marc Dietrich wrote at Monday, October 31, 2011 1:59 PM:
> > This adds support for a wakeup gpio which is connected to the
> > embedded controller. This will be used later on for wakeup from suspend.
> >
> > Signed-off-by: Marc Dietrich <marvin24@gmx.de>
>
> Acked-by: Stephen Warren <swarren@nvidia.com>
>
> (Feel free to include that tag in any future postings unless there are
> significant changes that would merit my reviewing it again)
ok, will do for v4 ;-)
^ permalink raw reply
* Re: [PATCH 1/3] ARM: tegra: paz00: add support for wakeup gpio key
From: Marc Dietrich @ 2011-10-31 21:36 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Olof Johansson, Colin Cross, linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173EDAB86D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Monday 31 October 2011 13:13:15 Stephen Warren wrote:
> Marc Dietrich wrote at Monday, October 31, 2011 1:59 PM:
> > This adds support for a wakeup gpio which is connected to the
> > embedded controller. This will be used later on for wakeup from suspend.
> >
> > Signed-off-by: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>
>
> Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> (Feel free to include that tag in any future postings unless there are
> significant changes that would merit my reviewing it again)
ok, will do for v4 ;-)
^ permalink raw reply
* Re: [patchset 0/8] pnfs-obj: Move to ORE for v3.2 merge window
From: Boaz Harrosh @ 2011-10-31 21:34 UTC (permalink / raw)
To: Trond Myklebust; +Cc: NFS list, open-osd, linux-fsdevel
In-Reply-To: <4EAEDFA6.4080303@panasas.com>
On 10/31/2011 10:49 AM, Boaz Harrosh wrote:
> On 10/29/2011 10:24 AM, Trond Myklebust wrote:
>> Hi Boaz,
>>
>> Have you tested these patches in linux-next? If so, I can pull them in
>> from open-osd.org and send them with the next merge. If not, I think
>> patches (as soon as possible!) would be better. I'll commit them to
>> nfs-for-next, and we can try to get them in...
>>
>> Cheers
>> Trond
>>
>
> Hi Trond.
>
> These patches where in next since before the BAT when I sent them to the
> list, then based on my exofs tree. I have now rebased on Linus master
> based on my pull bits and Yours, and again they where in next since
> Thursday. But the big question is did we have linux-next in that time
> frame because I thought Stephen was on vacation and the last linux-next
> was around Oct 20th?
>
> Any way both our bits where in Linux next since Oct 16. The patches are
> rebased but completely unchanged.
>
> Is there some tests I should make, other then compile oldmodconfig x86_64
> and x86_32? I wish I had setup for more compilers.
>
> But I'd say the risk is very low since the exact patches did sit in next.
> And after rebase I run a compile and a short test run.
>
> Any way I can post the patches. Give me an hour
> Boaz
>
Hi trond
I just re-checked. Compiled both i386 an x86_64 allmodconfig and even
merge with latest linus tree. I sign on these patches.
Again they were in linux-next as is, untouched based on exofs tree.
And now based on Linus/master [f362f98] They compile and run.
I'll re-post them just in case you decide to need them, as reply to
this mail.
Thanks
Boaz
^ permalink raw reply
* Re: [patchset 0/8] pnfs-obj: Move to ORE for v3.2 merge window
From: Boaz Harrosh @ 2011-10-31 21:34 UTC (permalink / raw)
To: Trond Myklebust; +Cc: NFS list, open-osd, linux-fsdevel
In-Reply-To: <4EAEDFA6.4080303-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
On 10/31/2011 10:49 AM, Boaz Harrosh wrote:
> On 10/29/2011 10:24 AM, Trond Myklebust wrote:
>> Hi Boaz,
>>
>> Have you tested these patches in linux-next? If so, I can pull them in
>> from open-osd.org and send them with the next merge. If not, I think
>> patches (as soon as possible!) would be better. I'll commit them to
>> nfs-for-next, and we can try to get them in...
>>
>> Cheers
>> Trond
>>
>
> Hi Trond.
>
> These patches where in next since before the BAT when I sent them to the
> list, then based on my exofs tree. I have now rebased on Linus master
> based on my pull bits and Yours, and again they where in next since
> Thursday. But the big question is did we have linux-next in that time
> frame because I thought Stephen was on vacation and the last linux-next
> was around Oct 20th?
>
> Any way both our bits where in Linux next since Oct 16. The patches are
> rebased but completely unchanged.
>
> Is there some tests I should make, other then compile oldmodconfig x86_64
> and x86_32? I wish I had setup for more compilers.
>
> But I'd say the risk is very low since the exact patches did sit in next.
> And after rebase I run a compile and a short test run.
>
> Any way I can post the patches. Give me an hour
> Boaz
>
Hi trond
I just re-checked. Compiled both i386 an x86_64 allmodconfig and even
merge with latest linus tree. I sign on these patches.
Again they were in linux-next as is, untouched based on exofs tree.
And now based on Linus/master [f362f98] They compile and run.
I'll re-post them just in case you decide to need them, as reply to
this mail.
Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch 1/1] net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
From: akpm @ 2011-10-31 21:33 UTC (permalink / raw)
To: kaber; +Cc: davem, netdev, netfilter-devel, akpm, alex, stable, stable
From: Alex Bligh <alex@alex.org.uk>
Subject: net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
Problem:
A repeatable Oops can be caused if a container with networking
unshared is destroyed when it has nf_conntrack entries yet to expire.
A copy of the oops follows below. A perl program generating the oops
repeatably is attached inline below.
Analysis:
The oops is called from cleanup_net when the namespace is
destroyed. conntrack iterates through outstanding events and calls
death_by_timeout on each of them, which in turn produces a call to
ctnetlink_conntrack_event. This calls nf_netlink_has_listeners, which
oopses because net->nfnl is NULL.
The perl program generates the container through fork() then
clone(NS_NEWNET). I does not explicitly set up netlink
explicitly set up netlink, but I presume it was set up else net->nfnl
would have been NULL earlier (i.e. when an earlier connection
timed out). This would thus suggest that net->nfnl is made NULL
during the destruction of the container, which I think is done by
nfnetlink_net_exit_batch.
I can see that the various subsystems are deinitialised in the opposite
order to which the relevant register_pernet_subsys calls are called,
and both nf_conntrack and nfnetlink_net_ops register their relevant
subsystems. If nfnetlink_net_ops registered later than nfconntrack,
then its exit routine would have been called first, which would cause
the oops described. I am not sure there is anything to prevent this
happening in a container environment.
Whilst there's perhaps a more complex problem revolving around ordering
of subsystem deinit, it seems to me that missing a netlink event on a
container that is dying is not a disaster. An early check for net->nfnl
being non-NULL in ctnetlink_conntrack_event appears to fix this. There
may remain a potential race condition if it becomes NULL immediately
after being checked (I am not sure any lock is held at this point or
how synchronisation for subsystem deinitialization works).
Patch:
The patch attached should apply on everything from 2.6.26 (if not before)
onwards; it appears to be a problem on all kernels. This was taken against
Ubuntu-3.0.0-11.17 which is very close to 3.0.4. I have torture-tested it
with the above perl script for 15 minutes or so; the perl script hung the
machine within 20 seconds without this patch.
Applicability:
If this is the right solution, it should be applied to all stable kernels
as well as head. Apart from the minor overhead of checking one variable
against NULL, it can never 'do the wrong thing', because if net->nfnl
is NULL, an oops will inevitably result. Therefore, checking is a reasonable
thing to do unless it can be proven than net->nfnl will never be NULL.
Check net->nfnl for NULL in ctnetlink_conntrack_event to avoid Oops on
container destroy
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Cc: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>
Cc: <stable@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/netfilter/nf_conntrack_netlink.c | 5 +++++
1 file changed, 5 insertions(+)
diff -puN net/netfilter/nf_conntrack_netlink.c~net-netfilter-nf_conntrack_netlinkc-fix-oops-on-container-destroy net/netfilter/nf_conntrack_netlink.c
--- a/net/netfilter/nf_conntrack_netlink.c~net-netfilter-nf_conntrack_netlinkc-fix-oops-on-container-destroy
+++ a/net/netfilter/nf_conntrack_netlink.c
@@ -570,6 +570,11 @@ ctnetlink_conntrack_event(unsigned int e
return 0;
net = nf_ct_net(ct);
+
+ /* container deinit, netlink may have died before death_by_timeout */
+ if (!net->nfnl)
+ return 0;
+
if (!item->report && !nfnetlink_has_listeners(net, group))
return 0;
_
^ permalink raw reply
* Re: Question: kick SDIO irq when resume
From: Nicolas Pitre @ 2011-10-31 21:33 UTC (permalink / raw)
To: Jun Nie; +Cc: Bing Zhao, frankh, yongd, tianfh, njun, linux-mmc
In-Reply-To: <CAGA24MLv9Z8USwCeGdKgW06Fdz7b55qyS-m03hVHkun-7i0TFA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2100 bytes --]
On Mon, 31 Oct 2011, Jun Nie wrote:
> 2011/10/31 Nicolas Pitre <nicolas.pitre@linaro.org>:
> > On Mon, 31 Oct 2011, Jun Nie wrote:
> >
> >> Hi Nico,
> >> We are debugging fake SDIO irq when 8787 SDIO card resume and
> >> found below patch. The issue is that 8787 driver can not handle card
> >> irq if neither 8787 nor host trigger resume event in some cases. Do
> >> you remember what SDIO card need below patch? What's your idea on this
> >> issue? How about add a SDIO function flag to decide the irq thread
> >> kick off in resume?
> >
> > This is needed because in some cases the card interrupt is already
> > consumed for the wake-up event. Kicking this thread shouldn't cause any
> > issue though, as the card is just polled for the actual presence of an
> > IRQ ...
> >
> > ... or maybe not. In this case commit 06e8935feb "optimized SDIO IRQ
> > handling for single irq" may certainly cause problems.
> >
> > The fix here would be to clear card->sdio_single_irq before calling
> > mmc_signal_sdio_irq() in mmc_sdio_resume() and restore its original
> > value eventually, or better yet ignore that flag when the IRQ thread is
> > ran for the first time after a resume.
> 8787 case(bug) is similar with sdio_signel_irq case, but not same.
> 8787 can not response to reading sdio card interrupt status correctly
> if 8787 is still in suspend mode. The read operation will get value of
> previous CMD52 read, no matter previous CMD52 is for what purpose. So
> host should avoid read from 8787 before call sdio function resume in
> normal resume process. Otherwise, 8787 may lead lead host to handle
> fake interrupt and result further error.
> >
> > In any case you may disable that optimization in the IRQ demux handler
> > to see if this fixes your problem.
> So the fix to 8787 is either adding a flag, such as NO_LOST_WAKEUP_IRQ
> for func/card, or moving kick off to after sdio function resume. I do
> not know which one you prefer.
Moving the kick-off after the resume will be a good thing, and it should
also be conditional on the presence of CCCR_INTx being non zero.
Nicolas
^ permalink raw reply
* Re: [PATCH v2] ext4: Create helper function for EXT4_IO_END_UNWRITTEN and i_aiodio_unwritten.
From: Ted Ts'o @ 2011-10-31 21:32 UTC (permalink / raw)
To: Tao Ma; +Cc: linux-ext4, Eric Sandeen
In-Reply-To: <1317375716-6125-1-git-send-email-tm@tao.ma>
On Fri, Sep 30, 2011 at 05:41:56PM +0800, Tao Ma wrote:
> From: Tao Ma <boyu.mt@taobao.com>
>
> EXT4_IO_END_UNWRITTEN flag set and the increase of i_aiodio_unwritten
> should be done simultaneously since ext4_end_io_nolock always clear the
> flag and decrease the counter in the same time.
>
> We have found some bugs that the flag is set while leaving
> i_aiodio_unwritten unchanged(commit 32c80b32c053d). So this patch just tries
> to create a helper function to wrap them to avoid any future bug.
> The idea is inspired by Eric.
>
> Cc: Eric Sandeen <sandeen@redhat.com>
> Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Thanks, applied.
- Ted
^ permalink raw reply
* [Qemu-devel] [PULL] tcg/interpreter: Add TCG + interpreter for bytecode
From: Stefan Weil @ 2011-10-31 21:31 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Blue Swirl, QEMU Developers
Hi,
this is a 3rd version of the patch series which adds support for
QEMU on any host by using a TCG interpreter (TCI).
Version 2 was sent to the list and is available here:
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02504.html
The new version removed the TRACE macros which I used during development.
They are no longer needed. This fixes malc's feedback.
Patches 1, 2, 5 and 6 are only rebased.
Patch 1 is useful even without TCI and improves the handling of a
special case needed for PPC hosts.
Please tell me if I should send the complete patches to qemu-devel.
I'd appreciate if the series could be pulled before QEMU 1.0 to form
a base for further development of TCI.
Regards,
Stefan Weil
The following changes since commit ff74c5a9a91c6dbf1017195462aa4176f7381240:
Merge remote-tracking branch 'riku/linux-user-for-upstream' into
staging (2011-10-31 15:05:40 -0500)
are available in the git repository at:
git://qemu.weilnetz.de/qemu.git tci
Stefan Weil (6):
tcg: TCG targets may define tcg_qemu_tb_exec
tcg: Make ARRAY_SIZE(tcg_op_defs) globally available
tcg: Add bytecode generator for tcg interpreter
tcg: Add interpreter for bytecode
tcg: Add tci disassembler
tcg: Add tcg interpreter to configure / make
Makefile.target | 4 +
configure | 34 ++-
dis-asm.h | 1 +
disas.c | 4 +-
dyngen-exec.h | 12 +-
exec-all.h | 22 +-
tcg/ppc/tcg-target.h | 4 +
tcg/tcg.c | 1 +
tcg/tcg.h | 12 +-
tcg/tci/README | 130 ++++++
tcg/tci/tcg-target.c | 906 +++++++++++++++++++++++++++++++++++++
tcg/tci/tcg-target.h | 160 +++++++
tci-dis.c | 59 +++
tci.c | 1208
++++++++++++++++++++++++++++++++++++++++++++++++++
14 files changed, 2545 insertions(+), 12 deletions(-)
create mode 100644 tcg/tci/README
create mode 100644 tcg/tci/tcg-target.c
create mode 100644 tcg/tci/tcg-target.h
create mode 100644 tci-dis.c
create mode 100644 tci.c
^ permalink raw reply
* Re: [Qemu-devel] [libvirt] RFC decoupling VM NIC provisioning fromVM NIC connection to backend networks
From: Christian Benvenuti (benve) @ 2011-10-31 21:30 UTC (permalink / raw)
To: Markus Armbruster, Daniel P. Berrange
Cc: libvir-list, David Wang (dwang2), Ram Durairaj (radurair),
qemu-devel, Sumit Naiksatam (snaiksat)
In-Reply-To: <m3bosx8del.fsf@blackfin.pond.sub.org>
> -----Original Message-----
> From: qemu-devel-bounces+benve=cisco.com@nongnu.org
[mailto:qemu-devel-
> bounces+benve=cisco.com@nongnu.org] On Behalf Of Markus Armbruster
> Sent: Monday, October 31, 2011 7:05 AM
> To: Daniel P. Berrange
> Cc: libvir-list@redhat.com; David Wang (dwang2); Ram Durairaj
> (radurair); qemu-devel@nongnu.org; Sumit Naiksatam (snaiksat)
> Subject: Re: [Qemu-devel] [libvirt] RFC decoupling VM NIC provisioning
> fromVM NIC connection to backend networks
>
> "Daniel P. Berrange" <berrange@redhat.com> writes:
>
> > On Fri, Oct 28, 2011 at 04:15:41PM -0700, Sumit Naiksatam (snaiksat)
> wrote:
> >> Hi,
> >>
> >> In its current implementation Libvirt makes sure that the network
> >> interfaces that it passes/provision to a VM (for example to qemu[-
> kvm])
> >> are already connected to its backend (interfaces/networks) by the
> time
> >> the VM starts its boot process. In a non virtualized setup it would
> be
> >> like booting a machine with the Ethernet cable already plugged into
> a
> >> router/switch port. While in a non virtualized setup you can boot a
> >> machine first (with no physical connection to a router/switch) and
> later
> >> connect its NIC/s to the switch/router, when you boot a VM via
> Libvirt
> >> it is not possible to decouple the two actions (VM boot, cable
> >> plug/unplug).
> >>
> >> An example of case where the capability of decoupling the two
> actions
> >> mentioned above is a requirement in Quantum/NetStack which is the
> >> network service leveraged by OpenStack. The modular design of
> OpenStack
> >> allows you to:
> >> - provision VMs with NIC/s
> >> - create networks
> >> - create ports on networks
> >> - plug/unplug a VM NIC into/from a given port on a network (at
> runtime)
> >>
> >> Note that this runtime plug/unplug requirement has nothing to do
> with
> >> hot plug/unplug of NICs.
> >> The idea is more that of decoupling the provisioning of a VM from
> the
> >> connection of the VM to the network/s.
> >> This would make it possible to change (at run-time too) the
networks
> the
> >> NIC/s of a given VM are connected to.
> >>
> >> For example, when a VM boots, its interfaces should be in link down
> >> state if the network admin has not connected the VM NIC/s to any
> >> "network" yet.
> >> Even though libvirt already provides a way to change the link state
> of
> >> an a VM NIC, link state and physical connection are two different
> things
> >> and should be manageable independently.
> >>
> >> Ideally the configuration syntax should be interface type and
> hypervisor
> >> type agnostic.
> >>
> >> Let's take QEMU[-kvm] as an example - when Libvirt starts a QEMU
VM,
> it
> >> passes to QEMU a number of file descriptors that map to host
backend
> >> interfaces (for example macvtap interfaces).
> >>
> >> In order to introduce this runtime plug/unplug capability, we need
a
> >> mechanism that permits to delay the binding between the host
macvtap
> >> interfaces and the guest taps (because you cannot know the fd of
the
> >> macvtap interfaces before you create them). This means you need a
> >> mechanism that allows you to change such fd/s at runtime:
> >>
> >> - you can close/reset an fd (ie, when you disconnect a VM NIC from
> its
> >> network)
> >> - you can open/set an fd (ie, when you connect a VM NIC to a
> network)
> >>
> >> This could probably be a libvirt command that translates to a QEMU
> >> monitor command.
> >>
> >> Can the runtime plug/unplug capability described above be achieved
> >> (cleanly) with another mechanism?
> >>
> >> Is anybody working on implementing something similar?
> >
> > No, but I've long thought about doing this & it is quite
> straightforward
> > todo really. Ordinarily when we start QEMU we do
> >
> > qemu ... -device e1000,id=nic0,netdev=netdevnic0 \
> > -netdev user,id=netdevnic0
> >
> > Todo what you describe we need to be able to:
> >
> > 1. Start QEMU with a NIC, but no netdev
> > 2. Add a netdev to running QEMU.
> > 3. Remove a netdev from a running QEMU
> > 4. Associate a netdev with a NIC in running QEMU
> >
> > We can do 1:
> >
> > $ qemu ... -device e1000,id=nic0
> >
> > But QEMU prints an annoying warning
> >
> > Warning: nic nic0 has no peer
> >
> > We can do 2 via the monitor:
> >
> > (qemu) netdev_add type=user,id=netdevnic0
> >
> > We can do 3 via the monitor:
> >
> > (qemu) netdev_del netdevnic0
> >
> >
> > The problem is 4 - AFAICT we can't connect the existing NIC upto the
> newly
> > hotplugged netdev, since we can't update the 'netdev' property in
the
> NIC
> > device.
>
> Yes, that's the missing piece.
Can we go ahead and add this missing piece to QEMU?
Is there any concern on the QEMU side?
/Chris
> > Also if we delete the netdev, we can't clear out the
'netdev'
> > property in the NIC, so its dangling to a netdev that no longer
> exists.
>
> Err, this sounds like we had a dangling pointer there. We don't.
>
> Until commit a083a89d, netdev_del disconnected the backend netdev from
> the frontend NIC (assigning null to property "netdev"), then deleted
> the
> netdev.
>
> Since then, we delay the actual deletion until the NIC goes away,
> because "removing host netdev peer while guest is active leads to
> guest-visible inconsistency and/or crashes".
>
> I figure that needs to be fixed differently to enable dynamic network
> backend switching.
>
> > The latter is fairly harmless, since we can just re-use the name if
> adding
> > a new backend later. The first problem is a bit of a pain, unless we
> plug
> > in a 'user' backend on the CLI, and immediately netdev_del it before
> starting
> > the CPUs. Ideally we'd have some way to set qdev properties for
> devices so we
> > can associate the NIC with the new netdev.
> >
> > eg when adding a netdev:
> >
> > (qemu) netdev_add type=user,id=netdevnic0
> > (qemu) set nic0 netdev=netdevnic0
> >
> > Or removing one
> >
> > (qemu) netdev_add netdevnic0
> > (qemu) unset nic0 netdev
>
> Please work with Anthony to get this use case covered in QOM.
>
> > WRT to libvirt XML config. Normally you specifiy a NIC like
> >
> > <interface type='network'>
> > <mac address='52:54:00:0f:7d:ad'/>
> > <source network='default'/>
> > <model type='virtio'/>
> > </interface>
> >
> > To boot a guest without any netdev backend present, we'd introduce a
> > new network type="none". eg
> >
> > <interface type='none'>
> > <mac address='52:54:00:0f:7d:ad'/>
> > <model type='virtio'/>
> > </interface>
> >
> > The existing API 'virDomainUpdateDevice', can then be used to
change
> > the interface config on the fly, adding or removing the netdev by
> > passing in new XML with a different 'type' attribute & <source>
> > element.
> >
> > Finally, when adding & removing the netdev backends to a running
> guest,
> > we likely want to be able to set the NIC's link carrier, so the
> guest
> > OS sees that it has lost / gain its network connection & will thus
> > retry DHCP / IPv6 autoconfig. There is already a QEMU montior
command
> > 'set_link' for changing the NIC link carrier. A minor problem is
> that,
> > AFAICT, we can't specify the link carrier state on the command line
> > when specifying the NIC hardware, eg we would want something like
> > this when starting a guest without a netdev back
> >
> > qemu ... -device e1000,id=nic0,link=down
>
> Should be easy enough to do.
>
> > And when adding a netdev we would do
> >
> > (qemu) netdev_add user,id=netdevnic0
> > (qemu) set nic0 netdev=netdevnic0
> > (qemu) set_link nic0 up
> >
> > Or when removing a netdev
> >
> > (qemu) set_link nic0 down
> > (qemu) unset nic0 netdev
> > (qemu) netdev_del user,id=netdevnic0
^ permalink raw reply
* [PANIC] : kernel BUG at drivers/md/raid5.c:2756!
From: Manish Katiyar @ 2011-10-31 21:29 UTC (permalink / raw)
To: neilb, linux-raid; +Cc: Manish Katiyar
I was running following script (trying to reproduce an ext4 error
reported in another thread) and the kernel dies with below error.
The place where it crashes is :-
2746 static void handle_parity_checks6(raid5_conf_t *conf, struct
stripe_head *sh,
2747 struct stripe_head_state *s,
2748 int disks)
2749 {
.....
2754 set_bit(STRIPE_HANDLE, &sh->state);
2755
2756 BUG_ON(s->failed > 2); <============== !!!!
[ 9663.343974] md/raid:md11: Disk failure on loop3, disabling device.[
9663.343976] md/raid:md11: Operation continuing on 4 devices.[
9668.547289] ------------[ cut here ]------------[ 9668.547327] kernel
BUG at drivers/md/raid5.c:2756![ 9668.547356] invalid opcode: 0000
[#1] SMP [ 9668.547388] Modules linked in: parport_pc ppdev
snd_hda_codec_hdmi snd_hda_codec_conexant aesni_intel cryptd aes_i586
aes_generic nfsd exportfs btusb nfs bluetooth lockd fscache
auth_rpcgss nfs_acl sunrpc binfmt_misc joydev snd_hda_intel
snd_hda_codec fuse snd_hwdep thinkpad_acpi snd_pcm snd_seq_midi
uvcvideo snd_rawmidi snd_seq_midi_event arc4 snd_seq videodev i915
iwlagn mxm_wmi drm_kms_helper drm snd_timer psmouse snd_seq_device
serio_raw mac80211 snd tpm_tis tpm nvram tpm_bios intel_ips cfg80211
soundcore i2c_algo_bit snd_page_alloc video lp parport usbhid hid
raid10 raid456 async_raid6_recov async_pq ahci libahci firewire_ohci
firewire_core crc_itu_t sdhci_pci sdhci e1000e raid6_pq async_xor xor
async_memcpy async_tx raid1 raid0 multipath linear[ 9668.547951] [
9668.547964] Pid: 6067, comm: md11_raid6 Tainted: G W
3.1.0-rc3+ #0 LENOVO 2537GH6/2537GH6[ 9668.548021] EIP:
0060:[<f878d590>] EFLAGS: 00010202 CPU: 3[ 9668.548056] EIP is at
handle_stripe+0x1e60/0x1e70 [raid456][ 9668.548087] EAX: 00000005 EBX:
ea589e00 ECX: 00000000 EDX: 00000003[ 9668.548121] ESI: 00000006 EDI:
df059590 EBP: ded39f00 ESP: ded39e30[ 9668.548155] DS: 007b ES: 007b
FS: 00d8 GS: 00e0 SS: 0068[ 9668.548186] Process md11_raid6 (pid:
6067, ti=ded38000 task=e364b2c0 task.ti=ded38000)[ 9668.548228]
Stack:[ 9668.548241] ded39e38 c10167e8 00000002 c107ce85 00000001
ded39e4c 00009258 00000000[ 9668.548303] df0595b8 ded39e60 ea589e00
fffffffc 00000007 ea589f28 ea589e00 df059590[ 9668.548364] 00000000
e36b1d50 ded39e7c 00000000 00000000 00000000 00000000 00000007[
9668.548424] Call Trace:[ 9668.548447] [<c10167e8>] ?
sched_clock+0x8/0x10[ 9668.548477] [<c107ce85>] ?
sched_clock_cpu+0xe5/0x150[ 9668.548509] [<f8787f39>] ?
__release_stripe+0x109/0x160 [raid456][ 9668.548545] [<f8787fce>] ?
release_stripe+0x3e/0x50 [raid456][ 9668.548580] [<f878f47a>]
raid5d+0x3aa/0x510 [raid456][ 9668.548611] [<c107698d>] ?
finish_wait+0x4d/0x70[ 9668.548641] [<c13fc3fd>]
md_thread+0xed/0x120[ 9668.548669] [<c1076890>] ?
add_wait_queue+0x50/0x50[ 9668.548697] [<c13fc310>] ?
md_rdev_init+0x120/0x120[ 9668.548725] [<c107608d>]
kthread+0x6d/0x80[ 9668.548750] [<c1076020>] ?
flush_kthread_worker+0x80/0x80[ 9668.548784] [<c15419be>]
kernel_thread_helper+0x6/0x10[ 9668.548814] Code: 44 01 40 f0 80 88 80
00 00 00 02 f0 80 88 80 00 00 00 20 8b 45 98 e9 7a f3 ff ff 0f 0b c7
40 38 03 00 00 00 b8 03 00 00 00 eb b4 <0f> 0b 0f 0b 0f 0b 0f 0b [
9668.549063] md: md11: resync done.[ 9668.549087] 90 8d b4 26 00 00 00
00 55 89 e5 57 56 [ 9668.549159] EIP: [<f878d590>]
handle_stripe+0x1e60/0x1e70 [raid456] SS:ESP 0068:ded39e30[
9668.935138] ---[ end trace e71016c3ebaeb3bd ]---
The script to reproduce is :
/home/mkatiyar> cat a.ksh
#!/bin/ksh
SUDO=sudo
cmd() {
sudo $*
}
device=/dev/md11
cd
cmd mdadm --stop $device
cmd mdadm --remove $device
cmd umount /tmp/b
for i in `seq 1 7`
do
cmd losetup -d /dev/loop$i
done
mkdir -p /tmp/a
mkdir -p /tmp/b
cd /tmp/a
for i in `seq 1 7`
do
cmd rm /tmp/a/raid-$i
cmd dd if=/dev/zero of=/tmp/a/raid-$i bs=4k count=25000
cmd losetup /dev/loop$i /tmp/a/raid-$i
done
cmd mdadm --create $device --level=6 --raid-devices=7 /dev/loop[1-7]
cmd cat /proc/mdstat
cmd mkfs.ext4 -b 4096 -i 4096 -m 0 $device
cmd mount $device /tmp/b
cmd mdadm --manage $device --fail /dev/loop1
cmd mdadm --manage $device --fail /dev/loop2
cmd dmesg -c > /dev/null 2>&1
cmd dd if=/dev/zero of=/tmp/b/testfile bs=1k count=1000 &
cmd mdadm --manage $device --fail /dev/loop3
PS : I'm not part of the list, so please keep me in cc in the response.
--
Thanks -
Manish
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2] tcp: Export TCP Delayed ACK parameters to user
From: Rick Jones @ 2011-10-31 21:29 UTC (permalink / raw)
To: Daniel Baluta
Cc: David Miller, eric.dumazet, kuznet, jmorris, yoshfuji, kaber,
netdev, luto
In-Reply-To: <CAEnQRZAGc42q1LCEDs=QigLkXeHBui=KnAm5=5xrEzvA-LDcGg@mail.gmail.com>
On 10/31/2011 01:02 PM, Daniel Baluta wrote:
> On Mon, Oct 31, 2011 at 8:10 PM, Rick Jones<rick.jones2@hp.com> wrote:
>> Whether tracked as bytes or segments, my take is that to ask applications to
>> have to think about another non-portable socket option is ungood. I would
>> suggest taking the time to work-out the automagic heuristic to drop the
>> deferred ACK count on connections where it being large is un-desirable and
>> then not need to worry about the limits being global.
>
> Your suggestion deserves further investigation, it looks tricky to
> find a good heuristic for increasing/decreasing the ACK deferred count.
Well, presumably you can observe the behaviour of some HP-UX and/or
Solaris receivers to get some ideas.
>> If I recall correctly, in one of your earlier posts you mentioned something
>> about a 20% performance boost. What were the specific conditions of that
>> testing? Was it over a setup where the receiver already had LRO/GRO or was
>> it over a more plain receiver NIC without that functionality?
>
> If I remember correctly on the receiver side there was no LRO/GRO, but we
> tweaked some of /proc/sys/net/ipv4 parameters (e.g tcp_rmem).
> Also, the traffic was highly unidirectional with many clients feeding multimedia
> content to a server.
>
> Anyhow, we used our custom kernel which is an older kernel version.
> Are there any recommended benchmarks/tools for testing this kind of parameters?
Well, the last time I was tilting after the ACK avoidance windmill I
used my favorite tool, netperf. I believe I posted some HP-UX data
showing the effect of different values of tcp_deferred_ack_max. Both on
throughput, and on CPU utilization/service demand. Of course, I have
something of a bias in that regard :)
rick jones
^ permalink raw reply
* Re: cfg80211 events
From: Franky Lin @ 2011-10-31 21:28 UTC (permalink / raw)
To: Daniel Wolstenholme; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB1eQC7cXz0GpGrX7d8_nL_8d8ZAgxSzXUxqDhR7PiSSJysOoQ@mail.gmail.com>
On 10/27/2011 03:27 PM, Daniel Wolstenholme wrote:
> Hi all,
>
> I'm working with the Broadcom brcmfmac driver, and I'm attempting to improve
> event reporting, but I'm finding there's not that much documentation on
> wireless events. One big problem I'm having is that I'm using the cfg80211
> interface, but when I run "iw event -t -f", I don't see the events showing
> up. Another question I have is: is there a way to send events with
> arbitrary strings from the driver through to userspace?
>
> Any pointers would be greatly appreciated.
>
> Dan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi Dan,
Just curious, on what kind of hardware platform are you using brcmfmac?
Thanks,
Franky
^ permalink raw reply
* Re: [lm-sensors] [PATCH 3/3] hwmon: (w83627ehf) Add support for the
From: Guenter Roeck @ 2011-10-31 21:27 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20111031152342.15f99729@endymion.delvare>
Hi Jean,
On Mon, 2011-10-31 at 17:03 -0400, Jean Delvare wrote:
> On Mon, 31 Oct 2011 08:45:52 -0700, Guenter Roeck wrote:
> > Not sure if moving NCT677[56] to a separate driver would make much of a
> > difference in the complexity of this one.
>
> The W83627UHG is clearly on the side of the W83627DHG. The decision of
> splitting NCT677[56] support to a separate driver is unrelated IMHO.
> The rationale is that the w83627ehf driver code has become quite
> complex (it's the 3rd hwmon driver by size out of 117!) and a lot of the
> code recently added only applies to the NCT677[56]. If future devices
> are almost compatible with the NCT677[56] but not quite, things will
> only become worse.
>
There is at least one new Nuvoton chip which is completely microcode
programmed (NCT6681D). Nuvoton advertises it as "the first IC of
Nuvoton`s new product line, or eSIO". Not entirely sure what that means,
but it almost looks like we may have reached the end of the hard-core
LPC devices.
Two other currently not supported chips are NCT5577D, which seems to be
a variant of NCT677[56]F, and W83527HG, which seems to be somewhere in
between NCT6775F and earlier chips.
> With separate drivers, the code would become easier to read IMHO.
> Obviously this implies some code duplication but I believe we reached
> the point where this should be considered. Another benefit is that we
> could then have separate maintainers for the two drivers, so better
> load balancing.
>
Agreed.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH] bonding:update speed/duplex for NETDEV_CHANGE
From: Jay Vosburgh @ 2011-10-31 21:23 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Weiping Pan, netdev, andy, linux-kernel
In-Reply-To: <1320094108.2735.15.camel@bwh-desktop>
Ben Hutchings <bhutchings@solarflare.com> wrote:
>On Mon, 2011-10-31 at 13:32 -0700, Jay Vosburgh wrote:
>[...]
>> This particular case arises only during enslavement. The call
>> to bond_update_speed_duplex call has failed, but the device is marked by
>> bonding to be up. Bonding complains that the device isn't down, but it
>> cannot get speed and duplex, and therefore is assuming them to be
>> 100/Full.
>>
>> The catch is that this happens only for the ARP monitor, because
>> it initially presumes a slave to be up regardless of actual carrier
>> state (for historical reasons related to very old 10 or 10/100 drivers,
>> prior to the introduction of netif_carrier_*).
>
>Right, I gathered that. Is there any reason to use the ARP monitor when
>all slaves support link state notification? Maybe the bonding
>documentation should recommend miimon in section 7, not just in section
>2.
The ARP monitor can validate that traffic actually flows from
the slave to some destination in the switch domain (and back), so, for
example, it's useful in cases that multiple switch hops exist between
the host and the local router. A link failure in the middle of the path
won't affect carrier on the local device, but still may cause a
communications break.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 5/6] target-mips: Adding support for Cavium specific instructions
From: Andreas Färber @ 2011-10-31 20:24 UTC (permalink / raw)
To: Khansa Butt; +Cc: qemu-devel
In-Reply-To: <CAAoJSP6yc-myKAB2jcDWm6qht-a+w76-Z_qD0DEtUmSj2PMW5Q@mail.gmail.com>
Am 28.10.2011 06:42, schrieb Khansa Butt:
>
>
> On Sat, Oct 22, 2011 at 4:36 PM, Andreas Färber <andreas.faerber@web.de
> <mailto:andreas.faerber@web.de>> wrote:
>
> Am 22.10.2011 12:11, schrieb khansa@kics.edu.pk
> <mailto:khansa@kics.edu.pk>:
HTML again :(
> > From: Khansa Butt <khansa@kics.edu.pk <mailto:khansa@kics.edu.pk>>
>
> Commit message should mention here at least that new registers are
> introduced and that load/save format is being changed.
>
> > Signed-off-by: Khansa Butt <khansa@kics.edu.pk
> <mailto:khansa@kics.edu.pk>>
> > Signed-off-by: Ehsan Ul Haq <ehsan.ulhaq@kics.edu.pk
> <mailto:ehsan.ulhaq@kics.edu.pk>>
> > Signed-off-by: Abdul Qadeer <qadeer@kics.edu.pk
> <mailto:qadeer@kics.edu.pk>>
> > Signed-off-by: Abdul Waheed <awaheed@kics.edu.pk
> <mailto:awaheed@kics.edu.pk>>
> > ---
>
> > diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> > index 79e2558..9180ee9 100644
> > --- a/target-mips/cpu.h
> > +++ b/target-mips/cpu.h
> > @@ -173,6 +173,13 @@ struct TCState {
> > target_ulong CP0_TCSchedule;
> > target_ulong CP0_TCScheFBack;
> > int32_t CP0_Debug_tcstatus;
> > + /* Multiplier registers for Octeon */
> > + target_ulong MPL0;
> > + target_ulong MPL1;
> > + target_ulong MPL2;
> > + target_ulong P0;
> > + target_ulong P1;
> > + target_ulong P2;
> > };
> >
> > typedef struct CPUMIPSState CPUMIPSState;
>
> > diff --git a/target-mips/machine.c b/target-mips/machine.c
> > index be72b36..a274ce2 100644
> > --- a/target-mips/machine.c
> > +++ b/target-mips/machine.c
> > @@ -25,6 +25,12 @@ static void save_tc(QEMUFile *f, TCState *tc)
> > qemu_put_betls(f, &tc->CP0_TCSchedule);
> > qemu_put_betls(f, &tc->CP0_TCScheFBack);
> > qemu_put_sbe32s(f, &tc->CP0_Debug_tcstatus);
> > + qemu_put_betls(f, &tc->MPL0);
> > + qemu_put_betls(f, &tc->MPL1);
>
> MPL2 is not being saved but loaded below.
>
> > + qemu_put_betls(f, &tc->P0);
> > + qemu_put_betls(f, &tc->P1);
> > + qemu_put_betls(f, &tc->P2);
> > +
> > }
> >
> > static void save_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
> > @@ -173,6 +179,12 @@ static void load_tc(QEMUFile *f, TCState *tc)
> > qemu_get_betls(f, &tc->CP0_TCSchedule);
> > qemu_get_betls(f, &tc->CP0_TCScheFBack);
> > qemu_get_sbe32s(f, &tc->CP0_Debug_tcstatus);
> > + qemu_get_betls(f, &tc->MPL0);
> > + qemu_get_betls(f, &tc->MPL1);
> > + qemu_get_betls(f, &tc->MPL2);
> > + qemu_get_betls(f, &tc->P0);
> > + qemu_get_betls(f, &tc->P1);
> > + qemu_get_betls(f, &tc->P2);
> > }
> >
> > static void load_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
>
> You're saving new fields, so you'll need to bump the version somewhere.
> For loading, since you're adding at the end, you might be able to make
> your additions conditional on the to-be-bumped version.
>
>
> I 'm not able to understand " bump the version somewhere" kindly
> explain this.
"Somewhere" indicates I don't know the exact line for mips. Compare the
recent patch to arm_gic.
The general idea is that QEMU needs to be able to load files saved with
an older version, the file format is therefore versioned. If you
unconditionally try to load your new registers, you break loading older
files that don't include them.
> I'm wondering whether those register and serialization additions could
> and should be limited to TARGET_MIPS64.
>
> you want me to limit these registers to TARGET_OCTEON
No, there shouldn't be a TARGET_OCTEON, there's no Octeon-specific
executable.
My point is, IIUC, qemu-system-mips will never have Octeon registers
because they're in qemu-system-mips64 only. So without #ifdef it would
save and load unused registers.
Andreas
^ permalink raw reply
* Re: [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic
From: Philip Balister @ 2011-10-31 21:18 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <j8mn18$usd$1@dough.gmane.org>
On 10/31/2011 01:48 PM, Koen Kooi wrote:
> Op 31-10-11 17:24, Paul Menzel schreef:
>> Am Montag, den 31.10.2011, 11:50 +0100 schrieb Koen Kooi:
>>> Op 29-10-11 14:33, Paul Menzel schreef:
>>>> Dear Martin, dear Denis,
>>>>
>>>>
>>>> Am Samstag, den 29.10.2011, 12:29 +0200 schrieb Martin Jansa:
>>>>> From: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>>>>>
>>>>> Added LIC_FILES_CHKSUM, and fixed LICENSE
>>>>>
>>>>> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>>>
>>>> NACK.
>>>>
>>>> please add the version you import and the commit ID you import from.
>>>> This is all written in the guide lines [1]!
>>>
>>> And as I've said before, meta-oe is not oe-dev, so you can't use take
>>> the old 'rules' and apply them to meta-oe 1:1!
>
>> The guide lines I referred to [1] have been written for OE-core. ;-)
>
> Yes, and oe-core still isn't meta-oe
Why would we need different guidelines?
Philip
^ 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.