* [U-Boot] [PATCH 01/39] DEBUG: Fix debug macros
From: Wolfgang Denk @ 2011-10-24 19:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110241021.15442.marek.vasut@gmail.com>
Dear Marek Vasut,
In message <201110241021.15442.marek.vasut@gmail.com> you wrote:
>
...
> Done, I pushed new patchset right now to git://git.denx.de/u-boot-marex.git ,
> "debug" branch. It's around 50 patches now.
Keep in mind that nobody cares about patches anywhere in any
repository. What has not been sent to the mailing list and thus is
captured in the list archives and patchwork simply does not exist.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can observe a lot just by watchin'. - Yogi Berra
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 3/4] Add cap reduction support to enable use as SUID
From: Anthony Liguori @ 2011-10-24 19:21 UTC (permalink / raw)
To: Corey Bryant; +Cc: Blue Swirl, rmarwah, qemu-devel
In-Reply-To: <4EA5B8E5.6040306@linux.vnet.ibm.com>
On 10/24/2011 02:13 PM, Corey Bryant wrote:
>> Right, it's not desirable, but isn't that the best we can do without
>> libcap or FS capabilities?
>>
>
> I think the best we can do is not let it run in those cases. :) I'd like see if
> others in the community have an opinion on this though.
IMHO, it should work as an setuid binary maintaining root privileges. As long
as it's a small binary (which it is) and is easy to audit, it should be safe.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: linux-next: failed to import the device-mapper quilt series
From: Alasdair G Kergon @ 2011-10-24 19:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20111025061010.26d2b727559242a5d188918e@canb.auug.org.au>
On Tue, Oct 25, 2011 at 06:10:10AM +1100, Stephen Rothwell wrote:
> And indeed, this file does not exist even though this patch is trying to
> patch it (not create it).
Hmmm. Yes, that patch is corrupted. I'll regenerate it.
Alasdair
^ permalink raw reply
* Re: [meta-xfce 3/3] xfce4-datetime-plugin: Initial add git (0.6.1)
From: Andreas Müller @ 2011-10-24 19:21 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1319480673.3483.3.camel@mattotaupa>
On Monday, October 24, 2011 08:24:33 PM Paul Menzel wrote:
> the description could be improved if I am right.
>
> Panel plugin displaying date and time and a calendar when left-clicked.
You are right :-) V2 coming soon.
Andreas
^ permalink raw reply
* [U-Boot] [PATCH] Fix compile issue in arch/arm/lib/board.c
From: Wolfgang Denk @ 2011-10-24 19:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319447521-6020-1-git-send-email-marek.vasut@gmail.com>
Dear Marek Vasut,
In message <1319447521-6020-1-git-send-email-marek.vasut@gmail.com> you wrote:
> The commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 breaks the build of U-Boot
> if CONFIG_CMD_NET is enabled.
>
> arm: Use getenv_ulong() in place of getenv(), strtoul
>
> This changes the board code to use the new getenv_ulong() function.
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> ---
> arch/arm/lib/board.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index c764844..558e973 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -566,7 +566,7 @@ 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");
> + char *s = getenv("bootfile");
Never mix declarations with code.
[no need to resubmit, I applied Simon's patch instead.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If all you have is a hammer, everything looks like a nail.
^ permalink raw reply
* [U-Boot] [PATCH] [BUG] arm, lib: fix compile breakage
From: Wolfgang Denk @ 2011-10-24 19:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110241115.45602.marek.vasut@gmail.com>
Dear Marek Vasut,
In message <201110241115.45602.marek.vasut@gmail.com> you wrote:
>
> I just sent something similar, but please use this one.
It's really interesting to see how many people wake up if they are
affected - and then hack away and send patches without even checing
how many similar patches have been sent before :-(
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every program has at least one bug and can be shortened by at least
one instruction -- from which, by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* [git pull] m68k updates for 3.2
From: Geert Uytterhoeven @ 2011-10-24 19:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg Ungerer, Greg Ungerer, Andrew Morton, Linux/m68k,
Linux Kernel Development
Hi Linus,
This is my first pull request for the m68k changes for 3.2.
I'd also like to get in the long-overdue conversion of m68k to the generic
hardirq framework, but that's pending on (a) a conflict resolution with the
m68knommu tree, and (b) a run in -next. So for now that's still in my
for-3.3 branch.
The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
Linus Torvalds (1):
Linux 3.1
are available in the git repository at:
ra.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
(aka for-3.2)
git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
Finn Thain (2):
m68k/mac: Fix compiler warning in via_read_time()
m68k/mac: Fix mac_irq_pending() for PSC MACE and SCC
Jim Rotmalm (1):
zorro: Fix four checkpatch warnings
Kirill Tkhai (1):
m68k: Finally remove leftover markers sections
arch/m68k/kernel/vmlinux.lds_no.S | 1 -
arch/m68k/mac/macints.c | 2 +-
arch/m68k/mac/misc.c | 40 +++++++++++++++++++++---------------
drivers/zorro/zorro-driver.c | 8 +++---
include/asm-generic/vmlinux.lds.h | 1 -
5 files changed, 28 insertions(+), 24 deletions(-)
Thanks for pulling!
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
* [git pull] m68k updates for 3.2
From: Geert Uytterhoeven @ 2011-10-24 19:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg Ungerer, Greg Ungerer, Andrew Morton, Linux/m68k,
Linux Kernel Development
Hi Linus,
This is my first pull request for the m68k changes for 3.2.
I'd also like to get in the long-overdue conversion of m68k to the generic
hardirq framework, but that's pending on (a) a conflict resolution with the
m68knommu tree, and (b) a run in -next. So for now that's still in my
for-3.3 branch.
The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
Linus Torvalds (1):
Linux 3.1
are available in the git repository at:
ra.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
(aka for-3.2)
git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
Finn Thain (2):
m68k/mac: Fix compiler warning in via_read_time()
m68k/mac: Fix mac_irq_pending() for PSC MACE and SCC
Jim Rotmalm (1):
zorro: Fix four checkpatch warnings
Kirill Tkhai (1):
m68k: Finally remove leftover markers sections
arch/m68k/kernel/vmlinux.lds_no.S | 1 -
arch/m68k/mac/macints.c | 2 +-
arch/m68k/mac/misc.c | 40 +++++++++++++++++++++---------------
drivers/zorro/zorro-driver.c | 8 +++---
include/asm-generic/vmlinux.lds.h | 1 -
5 files changed, 28 insertions(+), 24 deletions(-)
Thanks for pulling!
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
* [U-Boot] [PATCH v2] NS16550: buffer reads
From: Graeme Russ @ 2011-10-24 19:26 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111024184700.080E01408E9B@gemini.denx.de>
Hi Wolfgang,
On 25/10/11 05:46, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <CALButCKD2ucJ0ZUQJpLCP2ABYcCzO-mACa=FPWczCTVeHeoTKg@mail.gmail.com> you wrote:
>>
>>>> If so, could it not be possible that a Kermit/ymodem command followed by a
>>>> time consuming command on the same line cause lost input?
>>>
>>> I don't think so. All serial transfers use a protocol - and when the
>>> transfer is complete, it does not matter any more, because no more
>>> data are flowing.
>>
>> My point is that the transfer turns off flow control - When the transfer
>> completes, flow control will be off when the next command begins to run.
>
> Why would any of the transfer commands actually turn off flow control?
getc() sends an XOFF
> There is no need to do that so far. And even if they do - that's no
> fundamental difference to now, where we are not reading the input
> then, either.
>
>> If the next command is one which takes a long time to execute and it is on
>> the same line as the transfer command (i.e. no \r to send XOFF) and the
>> user types something then that input can be lost.
>
> I don't understand what you mean. We're talking about a single line
> of input here, right? Re-enabling XON is not needed before we're
> ready to read the next line. And during that, no characters would be
> lost because none are sent due to flow control being shut off.
>
>> I think the solution is fairly trivial though - During the processing of
>> commands entered via readline(), cause an XOFF to be sent each time (i.e.
>> immediately before) the command string is dispatched a to the command
>> processor just in case the previous command called getc() (and thus caused
>> an XON to be sent)
>
> This sounds like unneeded overhead to me.
consider the follow (admittedly canned) example:
loadb ; sleep 20
An XOFF will be sent when the user hits 'enter' but loadb will send an XON
when it calls getc(). Now after the transfer is complete, there will have
been no XOFF before the sleep command is run so if the user enters anything
during the sleep command, those characters can be lost
Regards,
Graeme
^ permalink raw reply
* [U-Boot] [PATCH] [BUG] arm, lib: fix compile breakage
From: Albert ARIBAUD @ 2011-10-24 19:26 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111024191209.4F2FD14094B3@gemini.denx.de>
Hi Wolfgang,
Le 24/10/2011 21:12, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4EA59236.4000607@aribaud.net> you wrote:
>>
>> Le 24/10/2011 07:42, Heiko Schocher a ?crit :
>>> since commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 building
>>> arch/arm/lib/board.c breaks if CONFIG_CMD_NET is defined.
>>> Fix this.
>>>
>>> Signed-off-by: Heiko Schocher<hs@denx.de>
>>> Cc: Albert ARIBAUD<albert.u.boot@aribaud.net>
>>> Cc: Simon Glass<sjg@chromium.org>
>>> ---
>>> arch/arm/lib/board.c | 3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>>> index ad02dbd..c1a3f2c 100644
>>> --- a/arch/arm/lib/board.c
>>> +++ b/arch/arm/lib/board.c
>>> @@ -440,6 +440,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
>>> #if !defined(CONFIG_SYS_NO_FLASH)
>>> ulong flash_size;
>>> #endif
>>> +#if defined(CONFIG_CMD_NET)
>>> + char *s;
>>> +#endif
>>>
>>> gd = id;
>>>
>>
>> Applied to u-boot-arm/master, thanks.
>
> Sorry for disagreeing - but I like Simon's patch better than both
> Heiko's and my own, because it does without additional #ifdef.
>
> And sorry again, I pull this directly to get the build issues fixed
> quickly.
That's fine with me. :)
I've removed Heiko's patch from u-boot-arm/master.
(ARM tree custodians -- Cc:ed -- please rebase onto new u-boot-arm/master)
> Best regards,
>
> Wolfgang Denk
Amicalement,
--
Albert.
^ permalink raw reply
* [meta-xfce][V2 1/3] xfce.bbclass: Move static libraries to ${PN}-staticdev
From: Andreas Müller @ 2011-10-24 19:26 UTC (permalink / raw)
To: openembedded-devel
* build tested with fresh build dir
* run tested on overo: applications / all available plugins
Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
---
meta-xfce/classes/xfce.bbclass | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-xfce/classes/xfce.bbclass b/meta-xfce/classes/xfce.bbclass
index 5b12cba..1a13fdc 100644
--- a/meta-xfce/classes/xfce.bbclass
+++ b/meta-xfce/classes/xfce.bbclass
@@ -7,5 +7,6 @@ FILES_${PN} += "${datadir}/icons/* ${datadir}/applications/* ${libdir}/xfce4/mod
FILES_${PN}-doc += "${datadir}/xfce4/doc"
FILES_${PN}-dev += "${libdir}/xfce4/*/*.la"
+FILES_${PN}-staticdev += "${libdir}/xfce4/*/*.a"
FILES_${PN}-dbg += "${libdir}/xfce4/*/.debug"
--
1.7.4.4
^ permalink raw reply related
* [meta-xfce][V2 2/3] xfce-panel-plugin.bbclass: pack modules also from ${libdir}/xfce4/panel-plugins
From: Andreas Müller @ 2011-10-24 19:26 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1319484417-20399-1-git-send-email-schnitzeltony@gmx.de>
* some panel-plugins (e.g xfce4-datetime-plugin) install their modules to
${libdir}/xfce4/panel-plugins
* build tested with fresh build dir
* run tested on overo: applications / all available plugins
Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
---
meta-xfce/classes/xfce-panel-plugin.bbclass | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta-xfce/classes/xfce-panel-plugin.bbclass b/meta-xfce/classes/xfce-panel-plugin.bbclass
index 51e40c9..5b89cdc 100644
--- a/meta-xfce/classes/xfce-panel-plugin.bbclass
+++ b/meta-xfce/classes/xfce-panel-plugin.bbclass
@@ -5,4 +5,5 @@ DEPENDS += "libxfce4ui libxfce4util xfce4-panel"
SRC_URI = "http://archive.xfce.org/src/panel-plugins/${BPN}/${@'${PV}'[0:3]}/${BPN}-${PV}.tar.bz2"
FILES_${PN} += "${datadir}/xfce4/panel-plugins/"
+FILES_${PN} += "${libdir}/xfce4/panel-plugins/*.so"
FILES_${PN}-dbg += "${libexecdir}/xfce4/panel-plugins/.debug"
--
1.7.4.4
^ permalink raw reply related
* [meta-xfce][V2 3/3] xfce4-datetime-plugin: Initial add git (0.6.1)
From: Andreas Müller @ 2011-10-24 19:26 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1319484417-20399-1-git-send-email-schnitzeltony@gmx.de>
Version 0.6.1 was release about 3 years ago. The patch to migrate from
libxfcegui4->libxfce4ui hopefully shall be applied mainline [1]. It would have
caused extra efforts to base the patch on 0.6.1 release.
[1] https://bugzilla.xfce.org/show_bug.cgi?id=8064
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
---
.../datetime/files/port-to-libxfce4ui.patch | 360 ++++++++++++++++++++
.../datetime/xfce4-datetime-plugin_git.bb | 20 ++
2 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 meta-xfce/recipes-panel-plugins/datetime/files/port-to-libxfce4ui.patch
create mode 100644 meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb
diff --git a/meta-xfce/recipes-panel-plugins/datetime/files/port-to-libxfce4ui.patch b/meta-xfce/recipes-panel-plugins/datetime/files/port-to-libxfce4ui.patch
new file mode 100644
index 0000000..aab20ca
--- /dev/null
+++ b/meta-xfce/recipes-panel-plugins/datetime/files/port-to-libxfce4ui.patch
@@ -0,0 +1,360 @@
+From 2041c011c62e13c5bc1f0824733bc34ebb8a8bfe Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmx.de>
+Date: Sun, 23 Oct 2011 20:14:42 +0200
+Subject: [PATCH] port to libxfce4ui
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
+---
+ configure.ac.in | 9 +--
+ panel-plugin/Makefile.am | 8 +-
+ panel-plugin/datetime-dialog.c | 8 +-
+ panel-plugin/datetime.c | 4 +-
+ panel-plugin/xfce46-compat.c | 193 ----------------------------------------
+ panel-plugin/xfce46-compat.h | 20 ----
+ 6 files changed, 11 insertions(+), 231 deletions(-)
+ delete mode 100644 panel-plugin/xfce46-compat.c
+ delete mode 100644 panel-plugin/xfce46-compat.h
+
+diff --git a/configure.ac.in b/configure.ac.in
+index 4d58211..5200268 100644
+--- a/configure.ac.in
++++ b/configure.ac.in
+@@ -31,12 +31,9 @@ XDT_I18N([@LINGUAS@])
+
+ dnl Check for required packages
+ XDT_CHECK_PACKAGE([GTK], [gtk+-2.0], [2.6.0])
+-XDT_CHECK_PACKAGE([LIBXFCEGUI4], [libxfcegui4-1.0], [4.3.99.2])
+-XDT_CHECK_PACKAGE([LIBXFCE4UTIL], [libxfce4util-1.0], [4.3.99.2])
+-XDT_CHECK_PACKAGE([LIBXFCE4PANEL],[libxfce4panel-1.0],[4.3.99.2])
+-
+-dnl check for optional packages/versions
+-XDT_CHECK_OPTIONAL_PACKAGE([LIBXFCE4PANEL_46], [libxfce4panel-1.0], [4.5.92], [libxfce4panel46], [Take advantage of Xfce 4.6 panel changes])
++XDT_CHECK_PACKAGE([LIBXFCE4UI], [libxfce4ui-1], [4.8.0])
++XDT_CHECK_PACKAGE([LIBXFCE4UTIL], [libxfce4util-1.0], [4.8.0])
++XDT_CHECK_PACKAGE([LIBXFCE4PANEL],[libxfce4panel-1.0],[4.8.0])
+
+ #CFLAGS="$CFLAGS -Wall -Werror"
+
+diff --git a/panel-plugin/Makefile.am b/panel-plugin/Makefile.am
+index 4005f85..18bbc7e 100644
+--- a/panel-plugin/Makefile.am
++++ b/panel-plugin/Makefile.am
+@@ -7,16 +7,14 @@ libdatetime_la_SOURCES = \
+ datetime.h \
+ datetime.c \
+ datetime-dialog.h \
+- datetime-dialog.c \
+- xfce46-compat.h \
+- xfce46-compat.c
++ datetime-dialog.c
+
+ libdatetime_la_CFLAGS = \
+ -I$(top_srcdir) \
+ -DLOCALEDIR=\"$(localedir)\" \
+ $(GTK_CFLAGS) \
+ $(LIBXFCE4PANEL_CFLAGS) \
+- $(LIBXFCEGUI4_CFLAGS) \
++ $(LIBXFCE4UI_CFLAGS) \
+ $(LIBXFCE4UTIL_CFLAGS)
+
+ libdatetime_la_LDFLAGS = \
+@@ -31,7 +29,7 @@ endif
+ libdatetime_la_LIBADD = \
+ $(GTK_LIBS) \
+ $(LIBXFCE4PANEL_LIBS) \
+- $(LIBXFCEGUI4_LIBS) \
++ $(LIBXFCE4UI_LIBS) \
+ $(LIBXFCE4UTIL_LIBS)
+
+ desktopdir = $(datadir)/xfce4/panel-plugins
+diff --git a/panel-plugin/datetime-dialog.c b/panel-plugin/datetime-dialog.c
+index 193587e..4ef3ab8 100644
+--- a/panel-plugin/datetime-dialog.c
++++ b/panel-plugin/datetime-dialog.c
+@@ -28,7 +28,7 @@
+ #include <string.h>
+
+ /* xfce includes */
+-#include <libxfcegui4/libxfcegui4.h>
++#include <libxfce4ui/libxfce4ui.h>
+ #include <libxfce4util/libxfce4util.h>
+ #include <libxfce4panel/xfce-panel-plugin.h>
+
+@@ -388,7 +388,7 @@ datetime_properties_dialog(XfcePanelPlugin *plugin, t_datetime * datetime)
+ /*
+ * layout frame
+ */
+- frame = xfce_create_framebox(_("Layout"), &bin);
++ frame = xfce_gtk_frame_box_new(_("Layout"), &bin);
+ gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dlg)->vbox), frame,
+ FALSE, FALSE, 0);
+ gtk_container_set_border_width(GTK_CONTAINER(frame), 6);
+@@ -422,7 +422,7 @@ datetime_properties_dialog(XfcePanelPlugin *plugin, t_datetime * datetime)
+ /*
+ * Date frame
+ */
+- datetime->date_frame = xfce_create_framebox(_("Date"), &bin);
++ datetime->date_frame = xfce_gtk_frame_box_new(_("Date"), &bin);
+ gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dlg)->vbox), datetime->date_frame,
+ FALSE, FALSE, 0);
+ gtk_container_set_border_width(GTK_CONTAINER(datetime->date_frame), 6);
+@@ -525,7 +525,7 @@ datetime_properties_dialog(XfcePanelPlugin *plugin, t_datetime * datetime)
+ /*
+ * time frame
+ */
+- datetime->time_frame = xfce_create_framebox(_("Time"), &bin);
++ datetime->time_frame = xfce_gtk_frame_box_new(_("Time"), &bin);
+ gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dlg)->vbox), datetime->time_frame,
+ FALSE, FALSE, 0);
+ gtk_container_set_border_width(GTK_CONTAINER(datetime->time_frame), 6);
+diff --git a/panel-plugin/datetime.c b/panel-plugin/datetime.c
+index 30ee04a..0738889 100644
+--- a/panel-plugin/datetime.c
++++ b/panel-plugin/datetime.c
+@@ -28,13 +28,11 @@
+ #include <string.h>
+
+ /* xfce includes */
+-#include <libxfcegui4/libxfcegui4.h>
++#include <libxfce4ui/libxfce4ui.h>
+ #include <libxfce4util/libxfce4util.h>
+ #include <libxfce4panel/xfce-panel-plugin.h>
+ #include <libxfce4panel/xfce-panel-convenience.h>
+
+-#include "xfce46-compat.h"
+-
+ #include "datetime.h"
+ #include "datetime-dialog.h"
+
+diff --git a/panel-plugin/xfce46-compat.c b/panel-plugin/xfce46-compat.c
+deleted file mode 100644
+index 97f10b1..0000000
+--- a/panel-plugin/xfce46-compat.c
++++ /dev/null
+@@ -1,193 +0,0 @@
+-/*
+- * Code was taken from libxfce4panel (LGPL2 or any later version),
+- * distributed here under the GPL.
+- *
+- * Copyright (c) 2005-2007 Jasper Huijsmans <jasper@xfce.org>
+- *
+- * 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 Library 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.
+- */
+-
+-#ifdef HAVE_CONFIG_H
+-# include <config.h>
+-#endif
+-
+-#ifndef HAVE_LIBXFCE4PANEL_46
+-
+-#include "xfce46-compat.h"
+-
+-#include <libxfce4panel/xfce-panel-plugin.h>
+-#include <libxfce4panel/xfce-panel-macros.h>
+-
+-/* support macros for debugging */
+-#ifndef NDEBUG
+-#define _panel_assert(expr) g_assert (expr)
+-#define _panel_assert_not_reached() g_assert_not_reached ()
+-#define _panel_return_if_fail(expr) g_return_if_fail (expr)
+-#define _panel_return_val_if_fail(expr, val) g_return_val_if_fail (expr, (val))
+-#else
+-#define _panel_assert(expr) G_STMT_START{ (void)0; }G_STMT_END
+-#define _panel_assert_not_reached() G_STMT_START{ (void)0; }G_STMT_END
+-#define _panel_return_if_fail(expr) G_STMT_START{ (void)0; }G_STMT_END
+-#define _panel_return_val_if_fail(expr, val) G_STMT_START{ (void)0; }G_STMT_END
+-#endif
+-
+-/**
+- * xfce_panel_plugin_arrow_type:
+- * @plugin : an #XfcePanelPlugin
+- *
+- * Determine the #GtkArrowType for a widget that opens a menu and uses
+- * xfce_panel_plugin_position_menu() to position the menu.
+- *
+- * Returns: The #GtkArrowType to use.
+- **/
+-GtkArrowType
+-xfce_panel_plugin_arrow_type (XfcePanelPlugin *plugin)
+-{
+- XfceScreenPosition position;
+- GdkScreen *screen;
+- GdkRectangle geom;
+- gint mon, x, y;
+-
+- if (!GTK_WIDGET_REALIZED (plugin))
+- return GTK_ARROW_UP;
+-
+- position = xfce_panel_plugin_get_screen_position (plugin);
+- switch (position)
+- {
+- /* top */
+- case XFCE_SCREEN_POSITION_NW_H:
+- case XFCE_SCREEN_POSITION_N:
+- case XFCE_SCREEN_POSITION_NE_H:
+- return GTK_ARROW_DOWN;
+-
+- /* left */
+- case XFCE_SCREEN_POSITION_NW_V:
+- case XFCE_SCREEN_POSITION_W:
+- case XFCE_SCREEN_POSITION_SW_V:
+- return GTK_ARROW_RIGHT;
+-
+- /* right */
+- case XFCE_SCREEN_POSITION_NE_V:
+- case XFCE_SCREEN_POSITION_E:
+- case XFCE_SCREEN_POSITION_SE_V:
+- return GTK_ARROW_LEFT;
+-
+- /* bottom */
+- case XFCE_SCREEN_POSITION_SW_H:
+- case XFCE_SCREEN_POSITION_S:
+- case XFCE_SCREEN_POSITION_SE_H:
+- return GTK_ARROW_UP;
+-
+- /* floating */
+- default:
+- /* get the screen information */
+- screen = gtk_widget_get_screen (GTK_WIDGET (plugin));
+- mon = gdk_screen_get_monitor_at_window (screen, GTK_WIDGET (plugin)->window);
+- gdk_screen_get_monitor_geometry (screen, mon, &geom);
+- gdk_window_get_root_origin (GTK_WIDGET (plugin)->window, &x, &y);
+-
+- /* get the position based on the screen position */
+- if (position == XFCE_SCREEN_POSITION_FLOATING_H)
+- return ((y < (geom.y + geom.height / 2)) ? GTK_ARROW_DOWN : GTK_ARROW_UP);
+- else
+- return ((x < (geom.x + geom.width / 2)) ? GTK_ARROW_RIGHT : GTK_ARROW_LEFT);
+- }
+-}
+-
+-
+-
+-/**
+- * xfce_panel_plugin_position_widget:
+- * @plugin : an #XfcePanelPlugin
+- * @menu_widget : a #GtkWidget that will be used as popup menu
+- * @attach_widget : a #GtkWidget relative to which the menu should be positioned
+- * @x : return location for the x coordinate
+- * @y : return location for the y coordinate
+- *
+- * The menu widget is positioned relative to @attach_widget.
+- * If @attach_widget is NULL, the menu widget is instead positioned
+- * relative to @panel_plugin.
+- *
+- * This function is intended for custom menu widgets.
+- * For a regular #GtkMenu you should use xfce_panel_plugin_position_menu()
+- * instead (as callback argument to gtk_menu_popup()).
+- *
+- * See also: xfce_panel_plugin_position_menu().
+- **/
+-void
+-xfce_panel_plugin_position_widget (XfcePanelPlugin *plugin,
+- GtkWidget *menu_widget,
+- GtkWidget *attach_widget,
+- gint *x,
+- gint *y)
+-{
+- GtkRequisition req;
+- GdkScreen *screen;
+- GdkRectangle geom;
+- gint mon;
+-
+- _panel_return_if_fail (XFCE_IS_PANEL_PLUGIN (plugin));
+- _panel_return_if_fail (GTK_IS_WIDGET (menu_widget));
+- _panel_return_if_fail (attach_widget == NULL || GTK_IS_WIDGET (attach_widget));
+-
+- if (attach_widget == NULL)
+- attach_widget = GTK_WIDGET (plugin);
+-
+- if (!GTK_WIDGET_REALIZED (menu_widget))
+- gtk_widget_realize (menu_widget);
+-
+- gtk_widget_size_request (menu_widget, &req);
+- gdk_window_get_origin (attach_widget->window, x, y);
+-
+- switch (xfce_panel_plugin_arrow_type (plugin))
+- {
+- case GTK_ARROW_UP:
+- *y -= req.height;
+- break;
+-
+- case GTK_ARROW_DOWN:
+- *y += attach_widget->allocation.height;
+- break;
+-
+- case GTK_ARROW_LEFT:
+- *x -= req.width;
+- break;
+-
+- default: /* GTK_ARROW_RIGHT and GTK_ARROW_NONE */
+- *x += attach_widget->allocation.width;
+- break;
+- }
+-
+- screen = gtk_widget_get_screen (attach_widget);
+- mon = gdk_screen_get_monitor_at_window (screen, attach_widget->window);
+- gdk_screen_get_monitor_geometry (screen, mon, &geom);
+-
+- /* keep inside the screen */
+- if (*x > geom.x + geom.width - req.width)
+- *x = geom.x + geom.width - req.width;
+- if (*x < geom.x)
+- *x = geom.x;
+- if (*y > geom.y + geom.height - req.height)
+- *y = geom.y + geom.height - req.height;
+- if (*y < geom.y)
+- *y = geom.y;
+-
+- if (G_LIKELY (GTK_IS_MENU (menu_widget)))
+- gtk_menu_set_screen (GTK_MENU (menu_widget), screen);
+- else if (GTK_IS_WINDOW (menu_widget))
+- gtk_window_set_screen (GTK_WINDOW (menu_widget), screen);
+-}
+-
+-#endif
+diff --git a/panel-plugin/xfce46-compat.h b/panel-plugin/xfce46-compat.h
+deleted file mode 100644
+index d385ec4..0000000
+--- a/panel-plugin/xfce46-compat.h
++++ /dev/null
+@@ -1,20 +0,0 @@
+-#ifndef _XFCE46_COMPAT
+-#define _XFCE46_COMPAT
+-
+-#ifdef HAVE_CONFIG_H
+-# include <config.h>
+-#endif
+-
+-#ifndef HAVE_LIBXFCE4PANEL_46
+-
+-#include <gtk/gtk.h>
+-#include <libxfce4panel/xfce-panel-plugin.h>
+-
+-void xfce_panel_plugin_position_widget (XfcePanelPlugin *plugin,
+- GtkWidget *menu_widget,
+- GtkWidget *attach_widget,
+- gint *x,
+- gint *y);
+-
+-#endif
+-#endif
+--
+1.7.4.4
+
diff --git a/meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb b/meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb
new file mode 100644
index 0000000..18dec94
--- /dev/null
+++ b/meta-xfce/recipes-panel-plugins/datetime/xfce4-datetime-plugin_git.bb
@@ -0,0 +1,20 @@
+DESCRIPTION = "Panel plugin displaying date and time and a calendar when left-clicked"
+HOMEPAGE = "http://goodies.xfce.org/projects/panel-plugins/xfce4-datetime-plugin"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
+
+inherit xfce-panel-plugin
+
+SRCREV = "e268210db6a32b2a47c03c63e5908ee3ba9461cc"
+PV = "0.6.1+gitr${SRCPV}"
+S = "${WORKDIR}/git"
+
+SRC_URI = "git://git.xfce.org/panel-plugins/xfce4-datetime-plugin;protocol=git;branch=master \
+ file://port-to-libxfce4ui.patch \
+ "
+SRC_URI[md5sum] = "e82f51ff0e75a63e5cbd139e43e094f9"
+SRC_URI[sha256sum] = "fb340c1c2170d4f33c7f278772966f3c01caaedcd4a7f58f670bf8e28580bb1b"
+
+do_configure_prepend() {
+ NOCONFIGURE=yes ./autogen.sh
+}
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] usb: fix unaligned access
From: Sascha Hauer @ 2011-10-24 19:30 UTC (permalink / raw)
To: Eric Bénard; +Cc: barebox
In-Reply-To: <4EA5B65D.4020405@eukrea.com>
On Mon, Oct 24, 2011 at 09:02:53PM +0200, Eric Bénard wrote:
> Hi,
>
> Le 24/10/2011 20:37, Fabian van der Werf a écrit :
> >
> >Okay, I think it may be a compiler problem. The latest code sourcery
> >compiler builds a barebox that breaks on usb. 2009q1-203 builds fine,
> >however.
> >
> >In the usb code the compiler should be able to figure out that the
> >access is unaligned from the packed structure. So I guess it should
> >split up the access in multiple loads/stores. I will look into the
> >binaries to confirm this. The latest compiler may be broken or maybe
> >the default behaviour has changed because armv7 actually supports
> >unaligned access.
> >
> can't this be the same problem described here with gcc 4.6 :
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552
>
> solved by this patch :
> https://launchpadlibrarian.net/73908303/0001-USB-ehci-remove-structure-packing-from-ehci_def.patch
>
> with the following explanation :
> The kernel source marks ehci_regs as packed. gcc 4.6 treats all
> accesses to packed structures as unaligned and ends up reading the
> status register multiple times.
If Fabians compiler would treat every access to packed structure members
as unaligned everything would be fine. The problem seems to be that it
doesn't treat it as unaligned. Let's wait for Fabians binary analysis.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH 4/9] mm: MIGRATE_CMA migration type added
From: Michal Nazarewicz @ 2011-10-24 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111018130826.GD6660@csn.ul.ie>
> On Thu, Oct 06, 2011 at 03:54:44PM +0200, Marek Szyprowski wrote:
>> The MIGRATE_CMA migration type has two main characteristics:
>> (i) only movable pages can be allocated from MIGRATE_CMA
>> pageblocks and (ii) page allocator will never change migration
>> type of MIGRATE_CMA pageblocks.
>>
>> This guarantees that page in a MIGRATE_CMA page block can
>> always be migrated somewhere else (unless there's no memory left
>> in the system).
On Tue, 18 Oct 2011 06:08:26 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> Or the count is premanently elevated by a device driver for some reason or if
> the page is backed by a filesystem with a broken or unusable migrate_page()
> function. This is unavoidable, I'm just pointing out that you can stil have
> migration failures, particularly if GFP_MOVABLE has been improperly used.
CMA does not handle that well right now. I guess it's something to think about
once the rest is nice and working.
>> It is designed to be used with Contiguous Memory Allocator
>> (CMA) for allocating big chunks (eg. 10MiB) of physically
>> contiguous memory. Once driver requests contiguous memory,
>> CMA will migrate pages from MIGRATE_CMA pageblocks.
>>
>> To minimise number of migrations, MIGRATE_CMA migration type
>> is the last type tried when page allocator falls back to other
>> migration types then requested.
> It would be preferable if you could figure out how to reuse the
> MIGRATE_RESERVE type for just the bitmap.
I'm not entirely sure of what you mean here.
> Like MIGRATE_CMA, it does not
> change type except when min_free_kbytes changes. However, it is
> something that could be done in the future to keep the size of the
> pageblock bitmap where it is now.
>> +enum {
>> + MIGRATE_UNMOVABLE,
>> + MIGRATE_RECLAIMABLE,
>> + MIGRATE_MOVABLE,
>> + MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
>> + MIGRATE_RESERVE = MIGRATE_PCPTYPES,
>> + /*
>> + * MIGRATE_CMA migration type is designed to mimic the way
>> + * ZONE_MOVABLE works. Only movable pages can be allocated
>> + * from MIGRATE_CMA pageblocks and page allocator never
>> + * implicitly change migration type of MIGRATE_CMA pageblock.
>> + *
>> + * The way to use it is to change migratetype of a range of
>> + * pageblocks to MIGRATE_CMA which can be done by
>> + * __free_pageblock_cma() function. What is important though
>> + * is that a range of pageblocks must be aligned to
>> + * MAX_ORDER_NR_PAGES should biggest page be bigger then
>> + * a single pageblock.
>> + */
>> + MIGRATE_CMA,
> This does mean that MIGRATE_CMA also does not have a per-cpu list.
> I don't know if that matters to you but all allocations using
> MIGRATE_CMA will take the zone lock.
This is sort of an artefact of my misunderstanding of pcp lists in the
past. I'll have to re-evaluate the decision not to include CMA on pcp
list.
Still, I think that CMA not being on pcp lists should not be a problem
for us. At least we can try and get CMA running and then consider adding
CMA to pcp lists.
> I'm not sure this can be easily avoided because
> if there is a per-CPU list for MIGRATE_CMA, it might use a new cache
> line for it and incur a different set of performance problems.
>> + MIGRATE_ISOLATE, /* can't allocate from here */
>> + MIGRATE_TYPES
>> +};
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 97254e4..9cf6b2b 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -115,6 +115,16 @@ static bool suitable_migration_target(struct page *page)
>> if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
>> return false;
>>
>> + /* Keep MIGRATE_CMA alone as well. */
>> + /*
>> + * XXX Revisit. We currently cannot let compaction touch CMA
>> + * pages since compaction insists on changing their migration
>> + * type to MIGRATE_MOVABLE (see split_free_page() called from
>> + * isolate_freepages_block() above).
>> + */
>> + if (is_migrate_cma(migratetype))
>> + return false;
>> +
>
> This is another reason why CMA and compaction should be using almost
> identical code. It does mean that the compact_control may need to be
> renamed and get flags to control things like the setting of pageblock
> flags but it would be preferable to having two almost identical pieces
> of code.
I've addressed it in my other mail where I've changed the split_free_page()
to not touch CMA and ISOLATE pageblocks. I think that this change should
make the above comment no longer accurate and the check unnecessary.
>> /* If the page is a large free page, then allow migration */
>> if (PageBuddy(page) && page_order(page) >= pageblock_order)
>> return true;
>> @@ -940,12 +963,12 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
>> /* Find the largest possible block of pages in the other list */
>> for (current_order = MAX_ORDER-1; current_order >= order;
>> --current_order) {
>> - for (i = 0; i < MIGRATE_TYPES - 1; i++) {
>> + for (i = 0; i < ARRAY_SIZE(fallbacks[0]); i++) {
>
> I don't see why this change is necessary.
It changes a sort of a magic number into a value that is calculated
from the array. This makes it resistant to changes in the definition
of the fallbacks array. I think this is a reasonable change.
>> migratetype = fallbacks[start_migratetype][i];
>>
>> /* MIGRATE_RESERVE handled later if necessary */
>> if (migratetype == MIGRATE_RESERVE)
>> - continue;
>> + break;
>>
>> area = &(zone->free_area[current_order]);
>> if (list_empty(&area->free_list[migratetype]))
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Micha? ?mina86? Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ permalink raw reply
* [BUG] Re: mtd_stresstest module bricked my dockstar
From: Roland Kletzing @ 2011-10-24 19:32 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, adrian.hunter, Artem.Bityutskiy
In-Reply-To: <20111024055705.GA4020@1wt.eu>
Hello,
cc`ing correct email of Adrian Hunter and i found that mtd_torturetest (and
the
other modules) have the same issue and there is another author i could find
the
email for.
> If you can't restore it with JTAG, it means the hardware is really dead.
> JTAG is used when you blank the flash, and is supposed to work. I don't
> know what the module does, but I fail to see how to could wear the flash
> that fast. At worst it could have wiped it, or the flash was already bad.
Yes, i think accidentally insmodding "mtd_stresstest" has just wiped it,
not killed.
The problem is, that it is important stuff for booting and you can`t pull it
out and
re-write externally, like a disk. Sorry, i that was probably not clearly
stated.
Anyway - what would people think if linux had a kernel module which wipes
/dev/sda1 when loaded ? :)
> I got one Iomega Iconnect with a faulty flash that I got replaced for a
> good one, so it's more likely the case here.
Yes, i could give debricking with JTAG a try. But what about the cost for
the JTAG
and the work to be spent with it? I could buy another Dockstar for that.....
> I agree with you. I remember the very old ISA NE2000 driver who used to
> scan various addresses to find a NIC, causing some of them to reconfigure
> their address to *none* and definitely stop responding on the bus to any
> reconfiguration request. That was pretty annoying too. After killing a
> few, I stopped using Linux on a machine with such a NIC for a long time!
Oh, that could be an explanation why i had 2 broken NE2000 NICs in the
nineties.. ;)
> You should keep it and retry the JTAG adapter. You just need a boot loader
> so if you manage to find a usable memory location that you can select by
> soldering two pins together, you could manage to store it and bood from
> another device.
I`m sure debricking with JTAG is possible and it would be an interesting
task.
Maybe i like to spend some money and time with this one day. For now i
don`t.
In the meantime i`d rather being interested in what can be done to add more
safety to the mtd tests.
By writing these lines and looking into the source, i started getting
curious - i
see there is dev param with that module(s), but i did not pass a device
number,
nor did i pass anything to it.
in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mtd/tests/mtd_stresstest.c;h=63920476b57a24c7e61563303eb3abb773b73fdf;hb=7163cea15f7b362795b858e7c130cd617aecc0aa
i see:
static int dev; <-!
module_param(dev, int, S_IRUGO);
MODULE_PARM_DESC(dev, "MTD device number to use");
static int count = 10000;
module_param(count, int, S_IRUGO);
MODULE_PARM_DESC(count, "Number of operations to do (default is 10000)");
and then
static int __init mtd_stresstest_init(void)
{
int err;
int i, op;
uint64_t tmp;
printk(KERN_INFO "\n");
printk(KERN_INFO "=================================================\n");
printk(PRINT_PREF "MTD device: %d\n", dev);
mtd = get_mtd_device(NULL, dev);
if (IS_ERR(mtd)) {
err = PTR_ERR(mtd);
printk(PRINT_PREF "error: cannot get MTD device\n");
return err;
}
My kernel log showed:
mtd_stresstest: MTD device: 0
mtd_stresstest: MTD device size 1048576 etc...
So, apparenly the module accidentally picked mtd0 instead of exiting cleanly
(as
i did not pass a device number)
I`m not a programmer, but doesn`t look that like an "unitialized variable"
issue ?
If yes, then i would call my Dockstar "victim of a bug".
regards
Roland
^ permalink raw reply
* Re: [PATCH 4/9] mm: MIGRATE_CMA migration type added
From: Michal Nazarewicz @ 2011-10-24 19:32 UTC (permalink / raw)
To: Marek Szyprowski, Mel Gorman
Cc: linux-kernel, linux-arm-kernel, linux-media, linux-mm,
linaro-mm-sig, Kyungmin Park, Russell King, Andrew Morton,
KAMEZAWA Hiroyuki, Ankita Garg, Daniel Walker, Arnd Bergmann,
Jesse Barker, Jonathan Corbet, Shariq Hasnain, Chunsang Jeong,
Dave Hansen
In-Reply-To: <20111018130826.GD6660@csn.ul.ie>
> On Thu, Oct 06, 2011 at 03:54:44PM +0200, Marek Szyprowski wrote:
>> The MIGRATE_CMA migration type has two main characteristics:
>> (i) only movable pages can be allocated from MIGRATE_CMA
>> pageblocks and (ii) page allocator will never change migration
>> type of MIGRATE_CMA pageblocks.
>>
>> This guarantees that page in a MIGRATE_CMA page block can
>> always be migrated somewhere else (unless there's no memory left
>> in the system).
On Tue, 18 Oct 2011 06:08:26 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> Or the count is premanently elevated by a device driver for some reason or if
> the page is backed by a filesystem with a broken or unusable migrate_page()
> function. This is unavoidable, I'm just pointing out that you can stil have
> migration failures, particularly if GFP_MOVABLE has been improperly used.
CMA does not handle that well right now. I guess it's something to think about
once the rest is nice and working.
>> It is designed to be used with Contiguous Memory Allocator
>> (CMA) for allocating big chunks (eg. 10MiB) of physically
>> contiguous memory. Once driver requests contiguous memory,
>> CMA will migrate pages from MIGRATE_CMA pageblocks.
>>
>> To minimise number of migrations, MIGRATE_CMA migration type
>> is the last type tried when page allocator falls back to other
>> migration types then requested.
> It would be preferable if you could figure out how to reuse the
> MIGRATE_RESERVE type for just the bitmap.
I'm not entirely sure of what you mean here.
> Like MIGRATE_CMA, it does not
> change type except when min_free_kbytes changes. However, it is
> something that could be done in the future to keep the size of the
> pageblock bitmap where it is now.
>> +enum {
>> + MIGRATE_UNMOVABLE,
>> + MIGRATE_RECLAIMABLE,
>> + MIGRATE_MOVABLE,
>> + MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
>> + MIGRATE_RESERVE = MIGRATE_PCPTYPES,
>> + /*
>> + * MIGRATE_CMA migration type is designed to mimic the way
>> + * ZONE_MOVABLE works. Only movable pages can be allocated
>> + * from MIGRATE_CMA pageblocks and page allocator never
>> + * implicitly change migration type of MIGRATE_CMA pageblock.
>> + *
>> + * The way to use it is to change migratetype of a range of
>> + * pageblocks to MIGRATE_CMA which can be done by
>> + * __free_pageblock_cma() function. What is important though
>> + * is that a range of pageblocks must be aligned to
>> + * MAX_ORDER_NR_PAGES should biggest page be bigger then
>> + * a single pageblock.
>> + */
>> + MIGRATE_CMA,
> This does mean that MIGRATE_CMA also does not have a per-cpu list.
> I don't know if that matters to you but all allocations using
> MIGRATE_CMA will take the zone lock.
This is sort of an artefact of my misunderstanding of pcp lists in the
past. I'll have to re-evaluate the decision not to include CMA on pcp
list.
Still, I think that CMA not being on pcp lists should not be a problem
for us. At least we can try and get CMA running and then consider adding
CMA to pcp lists.
> I'm not sure this can be easily avoided because
> if there is a per-CPU list for MIGRATE_CMA, it might use a new cache
> line for it and incur a different set of performance problems.
>> + MIGRATE_ISOLATE, /* can't allocate from here */
>> + MIGRATE_TYPES
>> +};
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 97254e4..9cf6b2b 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -115,6 +115,16 @@ static bool suitable_migration_target(struct page *page)
>> if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
>> return false;
>>
>> + /* Keep MIGRATE_CMA alone as well. */
>> + /*
>> + * XXX Revisit. We currently cannot let compaction touch CMA
>> + * pages since compaction insists on changing their migration
>> + * type to MIGRATE_MOVABLE (see split_free_page() called from
>> + * isolate_freepages_block() above).
>> + */
>> + if (is_migrate_cma(migratetype))
>> + return false;
>> +
>
> This is another reason why CMA and compaction should be using almost
> identical code. It does mean that the compact_control may need to be
> renamed and get flags to control things like the setting of pageblock
> flags but it would be preferable to having two almost identical pieces
> of code.
I've addressed it in my other mail where I've changed the split_free_page()
to not touch CMA and ISOLATE pageblocks. I think that this change should
make the above comment no longer accurate and the check unnecessary.
>> /* If the page is a large free page, then allow migration */
>> if (PageBuddy(page) && page_order(page) >= pageblock_order)
>> return true;
>> @@ -940,12 +963,12 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
>> /* Find the largest possible block of pages in the other list */
>> for (current_order = MAX_ORDER-1; current_order >= order;
>> --current_order) {
>> - for (i = 0; i < MIGRATE_TYPES - 1; i++) {
>> + for (i = 0; i < ARRAY_SIZE(fallbacks[0]); i++) {
>
> I don't see why this change is necessary.
It changes a sort of a magic number into a value that is calculated
from the array. This makes it resistant to changes in the definition
of the fallbacks array. I think this is a reasonable change.
>> migratetype = fallbacks[start_migratetype][i];
>>
>> /* MIGRATE_RESERVE handled later if necessary */
>> if (migratetype == MIGRATE_RESERVE)
>> - continue;
>> + break;
>>
>> area = &(zone->free_area[current_order]);
>> if (list_empty(&area->free_list[migratetype]))
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ permalink raw reply
* Re: [PATCH 4/9] mm: MIGRATE_CMA migration type added
From: Michal Nazarewicz @ 2011-10-24 19:32 UTC (permalink / raw)
To: Marek Szyprowski, Mel Gorman
Cc: linux-kernel, linux-arm-kernel, linux-media, linux-mm,
linaro-mm-sig, Kyungmin Park, Russell King, Andrew Morton,
KAMEZAWA Hiroyuki, Ankita Garg, Daniel Walker, Arnd Bergmann,
Jesse Barker, Jonathan Corbet, Shariq Hasnain, Chunsang Jeong,
Dave Hansen
In-Reply-To: <20111018130826.GD6660@csn.ul.ie>
> On Thu, Oct 06, 2011 at 03:54:44PM +0200, Marek Szyprowski wrote:
>> The MIGRATE_CMA migration type has two main characteristics:
>> (i) only movable pages can be allocated from MIGRATE_CMA
>> pageblocks and (ii) page allocator will never change migration
>> type of MIGRATE_CMA pageblocks.
>>
>> This guarantees that page in a MIGRATE_CMA page block can
>> always be migrated somewhere else (unless there's no memory left
>> in the system).
On Tue, 18 Oct 2011 06:08:26 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> Or the count is premanently elevated by a device driver for some reason or if
> the page is backed by a filesystem with a broken or unusable migrate_page()
> function. This is unavoidable, I'm just pointing out that you can stil have
> migration failures, particularly if GFP_MOVABLE has been improperly used.
CMA does not handle that well right now. I guess it's something to think about
once the rest is nice and working.
>> It is designed to be used with Contiguous Memory Allocator
>> (CMA) for allocating big chunks (eg. 10MiB) of physically
>> contiguous memory. Once driver requests contiguous memory,
>> CMA will migrate pages from MIGRATE_CMA pageblocks.
>>
>> To minimise number of migrations, MIGRATE_CMA migration type
>> is the last type tried when page allocator falls back to other
>> migration types then requested.
> It would be preferable if you could figure out how to reuse the
> MIGRATE_RESERVE type for just the bitmap.
I'm not entirely sure of what you mean here.
> Like MIGRATE_CMA, it does not
> change type except when min_free_kbytes changes. However, it is
> something that could be done in the future to keep the size of the
> pageblock bitmap where it is now.
>> +enum {
>> + MIGRATE_UNMOVABLE,
>> + MIGRATE_RECLAIMABLE,
>> + MIGRATE_MOVABLE,
>> + MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
>> + MIGRATE_RESERVE = MIGRATE_PCPTYPES,
>> + /*
>> + * MIGRATE_CMA migration type is designed to mimic the way
>> + * ZONE_MOVABLE works. Only movable pages can be allocated
>> + * from MIGRATE_CMA pageblocks and page allocator never
>> + * implicitly change migration type of MIGRATE_CMA pageblock.
>> + *
>> + * The way to use it is to change migratetype of a range of
>> + * pageblocks to MIGRATE_CMA which can be done by
>> + * __free_pageblock_cma() function. What is important though
>> + * is that a range of pageblocks must be aligned to
>> + * MAX_ORDER_NR_PAGES should biggest page be bigger then
>> + * a single pageblock.
>> + */
>> + MIGRATE_CMA,
> This does mean that MIGRATE_CMA also does not have a per-cpu list.
> I don't know if that matters to you but all allocations using
> MIGRATE_CMA will take the zone lock.
This is sort of an artefact of my misunderstanding of pcp lists in the
past. I'll have to re-evaluate the decision not to include CMA on pcp
list.
Still, I think that CMA not being on pcp lists should not be a problem
for us. At least we can try and get CMA running and then consider adding
CMA to pcp lists.
> I'm not sure this can be easily avoided because
> if there is a per-CPU list for MIGRATE_CMA, it might use a new cache
> line for it and incur a different set of performance problems.
>> + MIGRATE_ISOLATE, /* can't allocate from here */
>> + MIGRATE_TYPES
>> +};
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 97254e4..9cf6b2b 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -115,6 +115,16 @@ static bool suitable_migration_target(struct page *page)
>> if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
>> return false;
>>
>> + /* Keep MIGRATE_CMA alone as well. */
>> + /*
>> + * XXX Revisit. We currently cannot let compaction touch CMA
>> + * pages since compaction insists on changing their migration
>> + * type to MIGRATE_MOVABLE (see split_free_page() called from
>> + * isolate_freepages_block() above).
>> + */
>> + if (is_migrate_cma(migratetype))
>> + return false;
>> +
>
> This is another reason why CMA and compaction should be using almost
> identical code. It does mean that the compact_control may need to be
> renamed and get flags to control things like the setting of pageblock
> flags but it would be preferable to having two almost identical pieces
> of code.
I've addressed it in my other mail where I've changed the split_free_page()
to not touch CMA and ISOLATE pageblocks. I think that this change should
make the above comment no longer accurate and the check unnecessary.
>> /* If the page is a large free page, then allow migration */
>> if (PageBuddy(page) && page_order(page) >= pageblock_order)
>> return true;
>> @@ -940,12 +963,12 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
>> /* Find the largest possible block of pages in the other list */
>> for (current_order = MAX_ORDER-1; current_order >= order;
>> --current_order) {
>> - for (i = 0; i < MIGRATE_TYPES - 1; i++) {
>> + for (i = 0; i < ARRAY_SIZE(fallbacks[0]); i++) {
>
> I don't see why this change is necessary.
It changes a sort of a magic number into a value that is calculated
from the array. This makes it resistant to changes in the definition
of the fallbacks array. I think this is a reasonable change.
>> migratetype = fallbacks[start_migratetype][i];
>>
>> /* MIGRATE_RESERVE handled later if necessary */
>> if (migratetype == MIGRATE_RESERVE)
>> - continue;
>> + break;
>>
>> area = &(zone->free_area[current_order]);
>> if (list_empty(&area->free_list[migratetype]))
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 5/6] IIO:hwmon interface client driver.
From: Russell King - ARM Linux @ 2011-10-24 19:33 UTC (permalink / raw)
To: Jonathan Cameron
Cc: guenter.roeck, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linus.ml.walleij@gmail.com,
zdevai@gmail.com, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA58B39.8030608@cam.ac.uk>
On Mon, Oct 24, 2011 at 04:58:49PM +0100, Jonathan Cameron wrote:
> On 10/24/11 16:39, Guenter Roeck wrote:
> > Is div_s64 really necessary, or would
> >
> > result = (long)val * (long)scaleint +
> > DIV_ROUND_CLOSEST((s64)val * (s64)scalepart,
> > 1000000000LL);
> >
> > work as well ?
> Not if you want it to compile on arm v5 by the look of it.
>
> ERROR: "__aeabi_ldivmod" [drivers/staging/iio/iio_hwmon.ko] undefined!
You know, div64 is there to deal with the case of _sanely_ dividing
a 64-bit number by a 32-bit number - there should be absolutely no
question about _not_ using it if that's the operation you are wanting
to perform.
Expecting gcc to do a better job without using div64 is just asking for
bad code on 32-bit platforms.
^ permalink raw reply
* Re: [lm-sensors] [PATCH 5/6] IIO:hwmon interface client driver.
From: Russell King - ARM Linux @ 2011-10-24 19:33 UTC (permalink / raw)
To: Jonathan Cameron
Cc: guenter.roeck, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linus.ml.walleij@gmail.com,
zdevai@gmail.com, arnd@arndb.de,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de,
lm-sensors@lm-sensors.org, khali@linux-fr.org,
thomas.petazzoni@free-electrons.com,
maxime.ripard@free-electrons.com
In-Reply-To: <4EA58B39.8030608@cam.ac.uk>
On Mon, Oct 24, 2011 at 04:58:49PM +0100, Jonathan Cameron wrote:
> On 10/24/11 16:39, Guenter Roeck wrote:
> > Is div_s64 really necessary, or would
> >
> > result = (long)val * (long)scaleint +
> > DIV_ROUND_CLOSEST((s64)val * (s64)scalepart,
> > 1000000000LL);
> >
> > work as well ?
> Not if you want it to compile on arm v5 by the look of it.
>
> ERROR: "__aeabi_ldivmod" [drivers/staging/iio/iio_hwmon.ko] undefined!
You know, div64 is there to deal with the case of _sanely_ dividing
a 64-bit number by a 32-bit number - there should be absolutely no
question about _not_ using it if that's the operation you are wanting
to perform.
Expecting gcc to do a better job without using div64 is just asking for
bad code on 32-bit platforms.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Simon Glass @ 2011-10-24 19:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ034S5uMOxEvh8J0dJTbKNL9OjguJVC79PUabZJ+VYirg@mail.gmail.com>
Hi Albert,
On Sat, Oct 22, 2011 at 9:13 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Albert,
>
> On Sat, Oct 22, 2011 at 12:56 AM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
>> Le 22/10/2011 07:05, Simon Glass a ?crit :
>>
>>>>> Well I actually haven't moved it! It is just that previously it was
>>>>> impossible to call cp15_init from anywhere later.
>>>>
>>>> It is moved, in that it belongs to low level init... of A9.
>>>
>>> OK, I see - you mean moved in order if not in source code file.
>>
>> Yes. In the code, though, it belongs to low-level init.
>
> Arguably this could go in a library like arch/arm/cpu/armv7/lib/cache.S
>
>>
>>>>> What you say can be done, it would involve some assembler though and
>>>>> would need to be another CONFIG option. Was trying to avoid adding new
>>>>> assembler.
>>>>
>>>> Low level init is about assembler and, well, low level. :)
>>>
>>> Yes but it's yuck. Part of the clean-up is to remove most of the
>>> assembler - really very little is needed.
>>
>> I don't think "yuck" is a valid reasoned argument against assembly language
>> :) but I assume what you mainly mean is 'hard to understand and replaceable
>> by easy to understand C code'. I agree to the first part, and to the second
>> one for the general case, but not for the startup path where, precisely, we
>> don't have a working C run-time and most of the understanding requires
>> knowledge of hardware, not only general programming knowledge. Past that, C
>
> I'm not arguing for the cache init stuff to move to C, just trying to
> avoid any creeping growth of assembler when C can do it.
>
>> is ok -- but then beware: some C++ guy could chime in and contend that C is
>> "yuck" by your own standards. :)
>
> The C++ guy who finds himself in U-Boot is probably lost :-)
>
>>
>>>> But I don't see why there should be another CONFIG option. IIUC, you
>>>> should
>>>> be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level
>>>> init
>>>> code under it, you would do the equivalent of a switch, with one branch
>>>> for
>>>> AVM (and DDR init etc) and one branch for A9 (with cp15 init etc).
>>>
>>> Yes I can, but I need to be able to call cp15_init. And I can't do
>>> that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is
>>> compiled out! So I need to move that cp15_init code outside the
>>> CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do,
>>> honest!
>>
>> I understand, and I think the approach here is wrong, because you *do* want
>> low-level init in the A9 case, and thus you should not have
>> CONFIG_SKIP_LOWLEVEL_INIT set. But you also need the AVP low-level init to
>> be empty, and the AVP and A9 must follow the same startup path. And all this
>> it not necessarily required for all armv7 platforms, but some of them will
>> want lowlevel init, and some not. Considering all this...
>>
>> For now, I would opt for a CONFIG_ARCH_GENERIC_LOWLEVEL_INIT option which
>> start.S would use to compile out the low level init code definition (like
>> CONFIG_SKIP_LOWLEVEL_INIT does) but not the the calls to it (UNline
>> CONFIG_SKIP_LOWLEVEL_INIT does). Then you could provide a SoC-specific
>> version of lowlevel_init.
>
> If I understand you correctly, this is the opposite of what I want. It
> is basically what we have now.
>
> All ARMv7 chips are going to turn off MMU, caches, flush TLBs, and the
> like - this is an architecture feature, not an SOC one. We have
> conflated ARM arch init with SOC init as you say, but the solution is
> not to force the SOC to copy code from start.S just so that it can do
> ARM arch init later.
>
> And I'd argue for LOWLEVEL_INIT being about setting up the memory so
> we can run code, and in particular relocate it later. The cp15_init
> stuff should arguably be in arch_cpu_init() (or perhaps a new
> arch_init()) as the first thing called from board_init_f() in my view.
>
> So how about I create a patch to move the cp15_init() code into
> arch/arm/cpu/armv7/lib/lowlevel.S or similar so I can call it later?
I had a look at this, and it is a bit of a pain since the SPL builds
all bring in files by name from random directories around U-Boot,
including arch/arm/cpu/armv7/start.S. If I move code out of that file
into lib.S or cp15.S then I need to fix up various SPL builds. But it
seems to me that it would be better for arch/arm/cpu/armv7/Makefile
(another other Makefiles) to specify what object files are needed for
an SPL build, rather than putting it in *_spl/Makefile.
Therefore I have left this along, and would like proceed as previously!
I will send an updated patch series when MAKEALL finishes.
Regards,
Simon
>
>>
>> In the longer term, I would be more in favor of a weak definition system
>> with hierarchical ARCH, ISA, SoC, board priority order (yes, I am kind of
>> fond of it) for lowlevel init -- but that will require looking into asm weak
>> symbol handling and may require splitting of the assembly code function by
>> function.
>
> I think you are trying to avoid the
>
> #ifdef CONFIG_ARCH_CPU_INIT
> ? arch_cpu_init,
> #endif
> #ifdef ...
> ? some_other_thing
> #endif
>
> in the board_init_f() function table. Yes I agree it would tidy things
> up, although I wonder if Graeme's initcall thing isn't better again.
> It has the same confusion level coefficient (only the linker decides
> what code is included) with a bit more flexibility. Then each arch /
> board / cpu / soc / squirrel can decide on its own init and put it in
> its own file. C only please :-)
>
> Regards,
> Simon
>
>>
>>> Regards,
>>> Simon
>>
>> Amicalement,
>> --
>> Albert.
>>
>
^ permalink raw reply
* [U-Boot] [PATCH] Update s3c24x0 timer implementation
From: Wolfgang Denk @ 2011-10-24 19:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAJtrzLNz3TBBRHoNtHkuGci4YJZ9PLrJfvGaR_XdVbrdcprxbQ@mail.gmail.com>
Dear Mark Norman,
In message <CAJtrzLNz3TBBRHoNtHkuGci4YJZ9PLrJfvGaR_XdVbrdcprxbQ@mail.gmail.com> you wrote:
> Dear Wolfgang Denk,
>
> Thank you for your response.
>
> >> =A0Since the .rel.text section is required by the relocation code, I
> >> assume that .bss global variables cannot be used until after
> >> relocation?
> >
> > Why do you have to make such assumptions? =A0That's documented
> > behaviour. =A0Didn't you RTFM?
> >
>
> I thought I had done a thorough search previously but after receiving
> your response I managed to find some of the details outlined in the
> README file.
>
> I have attached an updated patch below which hopefully addresses the
> other issues you highlighted.
It seems you read my message only halfway through.
> Kind Regards,
>
> Mark Norman
>
>
>
> The s3c24x0 timer has been updated to use the global_data struct.
> Restructured code based on other timer.c files.
> Updated comments and several parameters.
>
> Signed-off-by: Mark Norman <mpnorman@gmail.com>
> ---
I wrote before:
Then please submit a proper patch - these introductory comments don't
belong into the commit message and should be moved into the comment
section (below the "---" line).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sometimes a feeling is all we humans have to go on.
-- Kirk, "A Taste of Armageddon", stardate 3193.9
^ permalink raw reply
* Re: [PATCH 1/3] drm/i915: set the right SDVO transcoder for CPT
From: Paulo Zanoni @ 2011-10-24 19:34 UTC (permalink / raw)
To: Keith Packard; +Cc: intel-gfx
In-Reply-To: <d08817$1rqs4i@azsmga001.ch.intel.com>
Hi Keith,
This patch isn't in your -next pull request. Please consider merging for
3.2.
Thank you,
Paulo
2011/10/14 Chris Wilson <chris@chris-wilson.co.uk>:
> On Fri, 14 Oct 2011 18:16:22 -0300, przanoni@gmail.com wrote:
>> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>
>> v2: add a CPT-specific macro, make code cleaner
>> v3: fix commit message
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41272
>> Cc: stable@kernel.org
>> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
--
Paulo Zanoni
^ permalink raw reply
* Xen dom0 linux kernel 3.1 boot failure ptwr_emulate: could not get_page_from_l1e
From: 2013pfoley @ 2011-10-24 19:34 UTC (permalink / raw)
To: xen-devel, linux-kernel; +Cc: Andrew Hamilton
Hi,
I'm having xen dom0 crash during bootup when using the linux 3.1 kernel
however it worked when using the linux 2.6.34 kernel.
I tried using xen-unstable but got the exact same error as with xen
4.1.1.
xen-unstable changeset: 23981:6c583d35d76d
linux kernel 3.1.0
I've included the backtrace below.
let me know if you need any more info.
Peter
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/xen2.gz com2=9600,8n1 console=com2 loglvl=all
guest_loglvl=all nor
eboot
[Multiboot-elf, <0x100000:0x19ae10:0x5c1f0>, shtab=0x2f7078,
entry=0x100000]
module /boot/kernel-xen-git root=/dev/sda2 bonding.mode=4
bonding.miimon=100 co
nsole=hvc0 debug initcall_debug earlyprintk=xen
[Multiboot-module @ 0x2f8000, 0x1410eb7 bytes]
__ __ _ _ ____ _ _ _
\ \/ /___ _ __ | || | |___ \ _ _ _ __ ___| |_ __ _| |__ | |
___
\ // _ \ '_ \ | || |_ __) |__| | | | '_ \/ __| __/ _` | '_ \| |/
_ \
/ \ __/ | | | |__ _| / __/|__| |_| | | | \__ \ || (_| | |_) | |
__/
/_/\_\___|_| |_| |_|(_)_____| \__,_|_|
|_|___/\__\__,_|_.__/|_|\___|
(XEN) Xen version 4.2-unstable (2013pfoley@csl.tjhsst.edu) (gcc version
4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) Fri Oct 21 15:10:43 EDT 2011
(XEN) Latest ChangeSet: Thu Oct 20 15:36:01 2011 +0100
23981:6c583d35d76d
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: com2=9600,8n1 console=com2 loglvl=all
guest_loglvl=all noreboot
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 2 seconds
(XEN) EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009f400 (usable)
(XEN) 000000000009f400 - 00000000000a0000 (reserved)
(XEN) 00000000000f0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000df61f000 (usable)
(XEN) 00000000df61f000 - 00000000df62c000 (ACPI data)
(XEN) 00000000df62c000 - 00000000df62d000 (usable)
(XEN) 00000000df62d000 - 00000000e4000000 (reserved)
(XEN) 00000000fec00000 - 00000000fee10000 (reserved)
(XEN) 00000000ff800000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 000000061ffff000 (usable)
(XEN) ACPI: RSDP 000F4F00, 0024 (r2 HP )
(XEN) ACPI: XSDT DF620340, 00B4 (r1 HP ProLiant 2 �
162E)
(XEN) ACPI: FACP DF620440, 00F4 (r3 HP ProLiant 2 �
162E)
(XEN) ACPI: DSDT DF620540, 200D (r1 HP DSDT 1 INTL
20030228)
(XEN) ACPI: FACS DF61F100, 0040
(XEN) ACPI: SPCR DF61F140, 0050 (r1 HP SPCRRBSU 1 �
162E)
(XEN) ACPI: MCFG DF61F1C0, 003C (r1 HP ProLiant 1
0)
(XEN) ACPI: HPET DF61F200, 0038 (r1 HP ProLiant 2 �
162E)
(XEN) ACPI: FFFF DF61F240, 0064 (r2 HP ProLiant 2 �
162E)
(XEN) ACPI: SPMI DF61F2C0, 0040 (r5 HP ProLiant 1 �
162E)
(XEN) ACPI: ERST DF61F300, 01D0 (r1 HP ProLiant 1 �
162E)
(XEN) ACPI: APIC DF61F500, 015E (r1 HP ProLiant 2
0)
(XEN) ACPI: SRAT DF61F680, 0570 (r1 HP Proliant 1 �
162E)
(XEN) ACPI: FFFF DF61FC00, 0176 (r1 HP ProLiant 1 �
162E)
(XEN) ACPI: BERT DF61FD80, 0030 (r1 HP ProLiant 1 �
162E)
(XEN) ACPI: HEST DF61FDC0, 00BC (r1 HP ProLiant 1 �
162E)
(XEN) ACPI: DMAR DF61FE80, 0154 (r1 HP ProLiant 1 �
162E)
(XEN) ACPI: SSDT DF622580, 0125 (r3 HP CRSPCI0 2 HP
1)
(XEN) ACPI: SSDT DF6226C0, 0255 (r3 HP riser1a 2 INTL
20061109)
(XEN) ACPI: SSDT DF622940, 03BB (r1 HP pcc 1 INTL
20090625)
(XEN) ACPI: SSDT DF622D00, 0377 (r1 HP pmab 1 INTL
20090625)
(XEN) ACPI: SSDT DF623080, 2B64 (r1 INTEL PPM RCM 1 INTL
20061109)
(XEN) System RAM: 24565MB (25155320kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 6 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 7 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 16 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 17 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 18 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 19 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 20 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 21 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 22 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 23 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-e0000000
(XEN) SRAT: Node 0 PXM 0 100000000-320000000
(XEN) SRAT: Node 1 PXM 1 320000000-620000000
(XEN) NUMA: Using 17 for the hash shift.
(XEN) Domain heap initialised DMA width 31 bits
(XEN) found SMP MP-table at 000f4f80
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x908
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[904,0], pm1x_evt[900,0]
(XEN) ACPI: wakeup_vec[df61f10c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x20] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] enabled)
(XEN) Processor #16 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x30] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x24] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x14] enabled)
(XEN) Processor #20 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x34] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x22] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x12] enabled)
(XEN) Processor #18 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x32] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x26] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x16] enabled)
(XEN) Processor #22 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x36] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x11] enabled)
(XEN) Processor #17 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x19] lapic_id[0x31] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
(XEN) Processor #5 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x15] enabled)
(XEN) Processor #21 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x35] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
(XEN) Processor #3 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] enabled)
(XEN) Processor #19 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x33] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
(XEN) Processor #7 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x27] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x17] enabled)
(XEN) Processor #23 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x37] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x00] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec80000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Phys. Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) ERST table is invalid
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 3040 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.778 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1219: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 -
3f
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 16 CPUs
(XEN) HPET's MSI mode hasn't been supported when Interrupt Remapping is
enabled.
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0xa69000
(XEN) elf_parse_binary: phdr: paddr=0x1c00000 memsz=0x990e0
(XEN) elf_parse_binary: phdr: paddr=0x1c9a000 memsz=0x13400
(XEN) elf_parse_binary: phdr: paddr=0x1cae000 memsz=0x2d4000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1f82000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81cae200
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES =
"!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff81000000
(XEN) virt_kend = 0xffffffff81f82000
(XEN) virt_entry = 0xffffffff81cae200
(XEN) p2m_base = 0xffffffffffffffff
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1f82000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000608000000->0000000610000000 (6140612 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff81f82000
(XEN) Init. ramdisk: ffffffff81f82000->ffffffff81f82000
(XEN) Phys-Mach map: ffffffff81f82000->ffffffff84e9b620
(XEN) Start info: ffffffff84e9c000->ffffffff84e9c4b4
(XEN) Page tables: ffffffff84e9d000->ffffffff84ec8000
(XEN) Boot stack: ffffffff84ec8000->ffffffff84ec9000
(XEN) TOTAL: ffffffff80000000->ffffffff85000000
(XEN) ENTRY ADDRESS: ffffffff81cae200
(XEN) Dom0 has maximum 16 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 ->
0xffffffff81a69000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81c00000 ->
0xffffffff81c990e0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81c9a000 ->
0xffffffff81cad400
(XEN) elf_load_binary: phdr 3 at 0xffffffff81cae000 ->
0xffffffff81d54000
(XEN) Scrubbing Free RAM: .done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 244kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.1.0 (root@galapagos) (gcc version 4.5.3
(Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #4 SMP Mon Oct 24 15:03:22 EDT 2011
[ 0.000000] Command line: root=/dev/sda2 bonding.mode=4
bonding.miimon=100 console=hvc0 debug initcall_debug earlyprintk=xen
[ 0.000000] Freeing e4000-fec00 pfn range: 109568 pages freed
[ 0.000000] Freeing fee10-ff800 pfn range: 2544 pages freed
[ 0.000000] released 112112 pages of unused memory
[ 0.000000] 1-1 mapping on a0->100
[ 0.000000] 1-1 mapping on df61f->df62c
[ 0.000000] 1-1 mapping on df62d->100000
[ 0.000000] Set 133696 page(s) to 1-1 mapping.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable)
[ 0.000000] Xen: 000000000009f400 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 00000000df61f000 (usable)
[ 0.000000] Xen: 00000000df61f000 - 00000000df62c000 (ACPI data)
[ 0.000000] Xen: 00000000df62c000 - 00000000df62d000 (usable)
[ 0.000000] Xen: 00000000df62d000 - 00000000e4000000 (reserved)
[ 0.000000] Xen: 00000000fec00000 - 00000000fee10000 (reserved)
[ 0.000000] Xen: 00000000ff800000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000100000000 - 000000063b5ef000 (usable)
[ 0.000000] bootconsole [xenboot0] enabled
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] DMI 2.7 present.
[ 0.000000] DMI: HP ProLiant DL380 G6, BIOS P62 05/05/2011
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000
(usable) ==> (reserved)
[ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000
(usable)
[ 0.000000] No AGP bridge found
[ 0.000000] last_pfn = 0x63b5ef max_arch_pfn = 0x400000000
[ 0.000000] last_pfn = 0xdf62d max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [ffff8800000f4f80] f4f80
(XEN) mm.c:945:d0 Error getting mfn 100 (pfn 5555555555555555) from L1
entry 8000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:5046:d0 ptwr_emulate: could not get_page_from_l1e()
[ 0.000000] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 0.000000] IP: [<ffffffff81008a5a>] xen_set_pte+0x3a/0x1f0
[ 0.000000] PGD 0
[ 0.000000] Oops: 0003 [#1] SMP
[ 0.000000] CPU 0
[ 0.000000] Modules linked in:
[ 0.000000]
[ 0.000000] Pid: 0, comm: swapper Not tainted 3.1.0 #4 HP ProLiant
DL380 G6
[ 0.000000] RIP: e030:[<ffffffff81008a5a>] [<ffffffff81008a5a>]
xen_set_pte+0x3a/0x1f0
[ 0.000000] RSP: e02b:ffffffff81c01d50 EFLAGS: 00010097
[ 0.000000] RAX: 0000000000000000 RBX: ffffffff81d573c0 RCX:
0000000000000001
[ 0.000000] RDX: 0000000010000001 RSI: 8000000000100461 RDI:
ffffffff81d573c0
[ 0.000000] RBP: ffffffff81c01d90 R08: 0000000000000000 R09:
00000000000f4f90
[ 0.000000] R10: 00000000deadbeef R11: 0000000000000010 R12:
8000000000100461
[ 0.000000] R13: 8000000000100463 R14: 8000000000000563 R15:
0000000000100000
[ 0.000000] FS: 0000000000000000(0000) GS:ffffffff81c9a000(0000)
knlGS:0000000000000000
[ 0.000000] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.000000] CR2: 0000000000000000 CR3: 0000000001c05000 CR4:
0000000000002660
[ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7:
0000000000000000
[ 0.000000] Process swapper (pid: 0, threadinfo ffffffff81c00000,
task ffffffff81c0d020)
[ 0.000000] Stack:
[ 0.000000] ffffffff81004ef1 0000000000000010 00000000deadbeef
ffffffff81d573c0
[ 0.000000] 0000000000000100 8000000000100463 8000000000000563
0000000000100000
[ 0.000000] ffffffff81c01dc0 ffffffff81cb299f 0000000000100000
ffffffffff478000
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff81004ef1>] ?
__raw_callee_save_xen_pte_val+0x11/0x1e
[ 0.000000] [<ffffffff81cb299f>] xen_set_pte_init+0x7f/0x87
[ 0.000000] [<ffffffff81cc2a99>] __early_set_fixmap+0x73/0xbc
[ 0.000000] [<ffffffff81cc2c01>] __early_ioremap+0x11f/0x1ad
[ 0.000000] [<ffffffff81cc2f07>] early_ioremap+0x13/0x15
[ 0.000000] [<ffffffff81cbc2ad>] get_mpc_size+0x14/0x4c
[ 0.000000] [<ffffffff81cbc3b1>] smp_scan_config+0xcc/0xfa
[ 0.000000] [<ffffffff81cf3300>] ?
firmware_map_add_hotplug+0xa4/0xa4
[ 0.000000] [<ffffffff81cbcfb3>] default_find_smp_config+0x36/0x5a
[ 0.000000] [<ffffffff81cb4770>] setup_arch+0x539/0xad7
[ 0.000000] [<ffffffff81009ecf>] ?
__raw_callee_save_xen_restore_fl+0x11/0x1e
[ 0.000000] [<ffffffff81cf3300>] ?
firmware_map_add_hotplug+0xa4/0xa4
[ 0.000000] [<ffffffff81709534>] ? printk+0x3c/0x3e
[ 0.000000] [<ffffffff8170c2ea>] ?
_raw_spin_unlock_irqrestore+0x1a/0x20
[ 0.000000] [<ffffffff81cf3300>] ?
firmware_map_add_hotplug+0xa4/0xa4
[ 0.000000] [<ffffffff81cae93b>] start_kernel+0x8e/0x359
[ 0.000000] [<ffffffff81cae347>]
x86_64_start_reservations+0x132/0x136
[ 0.000000] [<ffffffff81cb1eac>] xen_start_kernel+0x5ef/0x5f6
[ 0.000000] Code: 89 5d d8 4c 89 65 e0 48 89 fb 4c 89 6d e8 4c 89 75
f0 49 89 f4 85 c0 4c 89 7d f8 0f 85 17 01 00 00 e8 2b 06 03 00 83 f8 01
74 1e <4c> 89 23 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b
[ 0.000000] RIP [<ffffffff81008a5a>] xen_set_pte+0x3a/0x1f0
[ 0.000000] RSP <ffffffff81c01d50>
[ 0.000000] CR2: 0000000000000000
[ 0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle
task!
[ 0.000000] Pid: 0, comm: swapper Tainted: G D 3.1.0 #4
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff817093d8>] panic+0x8c/0x1ac
[ 0.000000] [<ffffffff8105db63>] do_exit+0x803/0x950
[ 0.000000] [<ffffffff8170c2ea>] ?
_raw_spin_unlock_irqrestore+0x1a/0x20
[ 0.000000] [<ffffffff8105b3b5>] ? kmsg_dump+0x45/0x100
[ 0.000000] [<ffffffff8170d46f>] oops_end+0xaf/0xf0
[ 0.000000] [<ffffffff8103e050>] no_context+0xf0/0x260
[ 0.000000] [<ffffffff8103e2dd>] __bad_area_nosemaphore+0x11d/0x220
[ 0.000000] [<ffffffff8103e3ee>] bad_area_nosemaphore+0xe/0x10
[ 0.000000] [<ffffffff8170fd8b>] do_page_fault+0x36b/0x510
[ 0.000000] [<ffffffff81009ecf>] ?
__raw_callee_save_xen_restore_fl+0x11/0x1e
[ 0.000000] [<ffffffff8170c7b5>] page_fault+0x25/0x30
[ 0.000000] [<ffffffff81008a5a>] ? xen_set_pte+0x3a/0x1f0
[ 0.000000] [<ffffffff81004ef1>] ?
__raw_callee_save_xen_pte_val+0x11/0x1e
[ 0.000000] [<ffffffff81cb299f>] xen_set_pte_init+0x7f/0x87
[ 0.000000] [<ffffffff81cc2a99>] __early_set_fixmap+0x73/0xbc
[ 0.000000] [<ffffffff81cc2c01>] __early_ioremap+0x11f/0x1ad
[ 0.000000] [<ffffffff81cc2f07>] early_ioremap+0x13/0x15
[ 0.000000] [<ffffffff81cbc2ad>] get_mpc_size+0x14/0x4c
[ 0.000000] [<ffffffff81cbc3b1>] smp_scan_config+0xcc/0xfa
[ 0.000000] [<ffffffff81cf3300>] ?
firmware_map_add_hotplug+0xa4/0xa4
[ 0.000000] [<ffffffff81cbcfb3>] default_find_smp_config+0x36/0x5a
[ 0.000000] [<ffffffff81cb4770>] setup_arch+0x539/0xad7
[ 0.000000] [<ffffffff81009ecf>] ?
__raw_callee_save_xen_restore_fl+0x11/0x1e
[ 0.000000] [<ffffffff81cf3300>] ?
firmware_map_add_hotplug+0xa4/0xa4
[ 0.000000] [<ffffffff81709534>] ? printk+0x3c/0x3e
[ 0.000000] [<ffffffff8170c2ea>] ?
_raw_spin_unlock_irqrestore+0x1a/0x20
[ 0.000000] [<ffffffff81cf3300>] ?
firmware_map_add_hotplug+0xa4/0xa4
[ 0.000000] [<ffffffff81cae93b>] start_kernel+0x8e/0x359
[ 0.000000] [<ffffffff81cae347>]
x86_64_start_reservations+0x132/0x136
[ 0.000000] [<ffffffff81cb1eac>] xen_start_kernel+0x5ef/0x5f6
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
^ permalink raw reply
* 11 Seconds waiting between pings, but network-throughput is fast
From: Andreas Piening @ 2011-10-24 19:35 UTC (permalink / raw)
To: kvm
Dear KVM-List,
I have a really strange network-issue and I'm running out of ideas how to track this down.
I have two tap-devices on one bridge:
bridge name bridge id STP enabled interfaces
br0 8000.00e081c682e7 no eth0
vm0
vm1
Each of them are connected to a virtual machine with virtio. The machines are both running MS Windows Server 2008 R2 and are configured equally from the kvm-perspective. I can transfer data over the network from a windows-share in both directions with over 40 MB/sec.
On one server, I have a noticeable latency over RDP. When I do a ping from this server, the first response comes immediately but there is a 11 seconds delay before the second ping is send on it's way!
I know this sounds crazy but I've installed wireshark to track this down and the response for every ping comes immediately but there are huge pauses (about 11 seconds) between the pings are sent out. The CPU utilization is nearly zero and the disk-io is fast (raid10, lvm, virtio).
Any help or ideas on that are appreciated,
Andreas Piening
^ 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.