* struct ipt_entry how to
From: Volkan YAZICI @ 2011-02-01 22:23 UTC (permalink / raw)
To: netfilter-devel
Hi,
I know that libiptc is not encouraged[1] for public use, but I'm trying
to figure out how rapidly I can interrupt the traffic on an interface
(if possible) with microsecond granularity; hence I want to issue direct
iptc_insert_entry() and iptc_delete_entry() calls without any strings
attached, e.g., start-up time, parsing, information gathering, table
initialization, etc. I'm reading the iptables sources and lost in the
mazes of generate_entry() stuff for creating a proper ipt_entry struct.
Does anybody have a sample code for that? Or can you point me to some
other relevant resource? Or, the worst, am I on my own on this matter?
Regards.
[1] http://lists.netfilter.org/pipermail/netfilter-devel/2004-June/015844.html
^ permalink raw reply
* RE: XCP PV driver
From: James Harper @ 2011-02-01 22:21 UTC (permalink / raw)
To: Soubir Acharya; +Cc: Paul Durrant, xen-devel
In-Reply-To: <4D484A11.3000909@kubisys.com>
>
> Is the latest GP PV driver, signed and will it install on 2008 without
> requiring "bcdedit driver signing off"?
>
It's test signed. You have to turn testsigning on for 64 bit windows.
James
^ permalink raw reply
* [PATCH 1/2] isimodem: fix problems in call state reporting
From: Pekka.Pessi @ 2011-02-01 22:22 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 4715 bytes --]
From: Pekka Pessi <Pekka.Pessi@nokia.com>
Do not report early incoming calls.
Report "disconnected" state separately.
Call ofono_voicecall_disconnected() only after call id is released.
---
drivers/isimodem/voicecall.c | 84 ++++++++++++++++++++++++++++++------------
1 files changed, 60 insertions(+), 24 deletions(-)
diff --git a/drivers/isimodem/voicecall.c b/drivers/isimodem/voicecall.c
index 6a1e582..6e23986 100644
--- a/drivers/isimodem/voicecall.c
+++ b/drivers/isimodem/voicecall.c
@@ -363,10 +363,13 @@ static int isi_call_status_to_clcc(const struct isi_call *call)
case CALL_STATUS_WAITING:
return 5;
- case CALL_STATUS_ANSWERED:
- case CALL_STATUS_ACTIVE:
case CALL_STATUS_MO_RELEASE:
case CALL_STATUS_MT_RELEASE:
+ case CALL_STATUS_TERMINATED:
+ return 6;
+
+ case CALL_STATUS_ANSWERED:
+ case CALL_STATUS_ACTIVE:
case CALL_STATUS_HOLD_INITIATED:
return 0;
@@ -375,11 +378,10 @@ static int isi_call_status_to_clcc(const struct isi_call *call)
return 1;
case CALL_STATUS_RECONNECT_PENDING:
- case CALL_STATUS_TERMINATED:
case CALL_STATUS_SWAP_INITIATED:
+ default:
return 0;
}
- return 0;
}
static struct ofono_call isi_call_as_ofono_call(const struct isi_call *call)
@@ -433,13 +435,27 @@ static struct isi_call *isi_call_set_idle(struct isi_call *call)
return call;
}
-static void isi_call_release(struct ofono_voicecall *ovc, struct isi_call *call)
+static void isi_call_disconnected(struct ofono_voicecall *ovc,
+ struct isi_call *call)
{
struct ofono_error error = {
OFONO_ERROR_TYPE_NO_ERROR, 0
};
+
+ DBG("disconnected id=%u reason=%u", call->id, call->reason);
+
+ ofono_voicecall_disconnected(ovc, call->id, call->reason, &error);
+
+ isi_call_set_idle(call);
+}
+
+static void isi_call_set_disconnect_reason(struct isi_call *call)
+{
enum ofono_disconnect_reason reason;
+ if (call->reason != OFONO_DISCONNECT_REASON_UNKNOWN)
+ return;
+
switch (call->status) {
case CALL_STATUS_IDLE:
reason = OFONO_DISCONNECT_REASON_UNKNOWN;
@@ -456,17 +472,9 @@ static void isi_call_release(struct ofono_voicecall *ovc, struct isi_call *call)
case CALL_STATUS_TERMINATED:
default:
reason = OFONO_DISCONNECT_REASON_ERROR;
- break;
- }
-
- if (!call->reason) {
- call->reason = reason;
- DBG("disconnected id=%u reason=%u", call->id, reason);
- ofono_voicecall_disconnected(ovc, call->id, reason, &error);
}
- if (!reason)
- isi_call_set_idle(call);
+ call->reason = reason;
}
static void isi_call_notify(struct ofono_voicecall *ovc, struct isi_call *call)
@@ -487,11 +495,20 @@ static void isi_call_notify(struct ofono_voicecall *ovc, struct isi_call *call)
switch (call->status) {
case CALL_STATUS_IDLE:
+ isi_call_disconnected(ovc, call);
+ return;
+
+ case CALL_STATUS_COMING:
+ case CALL_STATUS_PROCEEDING:
+ if ((call->mode_info & CALL_MODE_ORIGINATOR))
+ /* Do not notify early MT calls */
+ return;
+ break;
+
case CALL_STATUS_MO_RELEASE:
case CALL_STATUS_MT_RELEASE:
case CALL_STATUS_TERMINATED:
- isi_call_release(ovc, call);
- return;
+ isi_call_set_disconnect_reason(call);
}
ocall = isi_call_as_ofono_call(call);
@@ -615,17 +632,33 @@ static void isi_call_status_ind_cb(const GIsiMessage *msg, void *data)
}
}
- if (old_status != call->status) {
+ if (old_status == call->status)
+ return;
- if (call->status == CALL_STATUS_IDLE) {
- call->status = CALL_STATUS_TERMINATED;
+ isi_call_notify(ovc, call);
+}
- isi_call_notify(ovc, call);
- isi_call_set_idle(call);
- return;
- }
- }
+static void isi_call_terminated_ind_cb(const GIsiMessage *msg, void *data)
+{
+ struct ofono_voicecall *ovc = data;
+ struct isi_voicecall *ivc = ofono_voicecall_get_data(ovc);
+ struct isi_call *call;
+ uint8_t call_id;
+ uint8_t old_status;
+
+ if (ivc == NULL || g_isi_msg_id(msg) != CALL_TERMINATED_IND ||
+ !g_isi_msg_data_get_byte(msg, 0, &call_id) ||
+ (call_id & 7) == 0)
+ return;
+
+ call = &ivc->calls[call_id & 7];
+ old_status = call->status;
+
+ if (old_status == CALL_STATUS_IDLE)
+ return;
+
+ call->status = CALL_STATUS_TERMINATED;
isi_call_notify(ovc, call);
}
@@ -1255,6 +1288,9 @@ static void isi_call_verify_cb(const GIsiMessage *msg, void *data)
g_isi_client_ind_subscribe(ivc->client, CALL_STATUS_IND,
isi_call_status_ind_cb, ovc);
+ g_isi_client_ind_subscribe(ivc->client, CALL_TERMINATED_IND,
+ isi_call_terminated_ind_cb, ovc);
+
if (!isi_call_status_req(ovc, CALL_ID_ALL,
CALL_STATUS_MODE_ADDR_AND_ORIGIN,
NULL, NULL))
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] voicecall: try harder to avoid Dial mismatches
From: Pekka.Pessi @ 2011-02-01 22:22 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296598930-3093-1-git-send-email-Pekka.Pessi@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
From: Pekka Pessi <Pekka.Pessi@nokia.com>
There were some cases where Dial returned an incorrect call object,
e.g., after oFono crash and recover.
---
src/voicecall.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/voicecall.c b/src/voicecall.c
index 6246787..418e928 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -1160,6 +1160,17 @@ static ofono_bool_t clir_string_to_clir(const char *clirstr,
}
}
+static void prepare_to_dial(struct ofono_voicecall *vc)
+{
+ GSList *l;
+ struct voicecall *v;
+
+ for (l = vc->call_list; l; l = l->next) {
+ v = l->data;
+ v->dial_result_handled = TRUE;
+ }
+}
+
static struct ofono_call *synthesize_outgoing_call(struct ofono_voicecall *vc,
const char *number)
{
@@ -1325,6 +1336,8 @@ static DBusMessage *manager_dial(DBusConnection *conn,
vc->pending = dbus_message_ref(msg);
+ prepare_to_dial(vc);
+
string_to_phone_number(number, &ph);
vc->driver->dial(vc, &ph, clir, manager_dial_callback, vc);
@@ -2461,6 +2474,8 @@ static void dial_request_cb(const struct ofono_error *error, void *data)
static void dial_request(struct ofono_voicecall *vc)
{
+ prepare_to_dial(vc);
+
vc->driver->dial(vc, &vc->dial_req->ph, OFONO_CLIR_OPTION_DEFAULT,
dial_request_cb, vc);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] arm: mach-omap2: potential NULL dereference
From: Kevin Hilman @ 2011-02-01 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110119125721.GA9203@albatros>
Vasiliy Kulikov <segoon@openwall.com> writes:
> kzalloc() may fail, if so return -ENOMEM. Also Walter Harms suggested
> to use kasprintf() instead of kzalloc+strcpy+strcat.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Cannot compile this driver, so it is not tested at all.
Boot tested on 3430/n900 and 3630/Zoom3.
Queueing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> arch/arm/mach-omap2/smartreflex.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 77ecebf..697d8d4 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -260,9 +260,11 @@ static int sr_late_init(struct omap_sr *sr_info)
> if (sr_class->class_type = SR_CLASS2 &&
> sr_class->notify_flags && sr_info->irq) {
>
> - name = kzalloc(SMARTREFLEX_NAME_LEN + 1, GFP_KERNEL);
> - strcpy(name, "sr_");
> - strcat(name, sr_info->voltdm->name);
> + name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
> + if (name = NULL) {
> + ret = -ENOMEM;
> + goto error;
> + }
> ret = request_irq(sr_info->irq, sr_interrupt,
> 0, name, (void *)sr_info);
> if (ret)
^ permalink raw reply
* [PATCH v2] arm: mach-omap2: potential NULL dereference
From: Kevin Hilman @ 2011-02-01 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110119125721.GA9203@albatros>
Vasiliy Kulikov <segoon@openwall.com> writes:
> kzalloc() may fail, if so return -ENOMEM. Also Walter Harms suggested
> to use kasprintf() instead of kzalloc+strcpy+strcat.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Cannot compile this driver, so it is not tested at all.
Boot tested on 3430/n900 and 3630/Zoom3.
Queueing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> arch/arm/mach-omap2/smartreflex.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 77ecebf..697d8d4 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -260,9 +260,11 @@ static int sr_late_init(struct omap_sr *sr_info)
> if (sr_class->class_type == SR_CLASS2 &&
> sr_class->notify_flags && sr_info->irq) {
>
> - name = kzalloc(SMARTREFLEX_NAME_LEN + 1, GFP_KERNEL);
> - strcpy(name, "sr_");
> - strcat(name, sr_info->voltdm->name);
> + name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
> + if (name == NULL) {
> + ret = -ENOMEM;
> + goto error;
> + }
> ret = request_irq(sr_info->irq, sr_interrupt,
> 0, name, (void *)sr_info);
> if (ret)
^ permalink raw reply
* Re: [PATCH v2] arm: mach-omap2: potential NULL dereference
From: Kevin Hilman @ 2011-02-01 22:22 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, walter harms, kernel-janitors, Tony Lindgren,
Russell King, linux-omap, linux-arm-kernel
In-Reply-To: <20110119125721.GA9203@albatros>
Vasiliy Kulikov <segoon@openwall.com> writes:
> kzalloc() may fail, if so return -ENOMEM. Also Walter Harms suggested
> to use kasprintf() instead of kzalloc+strcpy+strcat.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Cannot compile this driver, so it is not tested at all.
Boot tested on 3430/n900 and 3630/Zoom3.
Queueing for 2.6.39 (branch: for_2.6.39/pm-misc)
Kevin
> arch/arm/mach-omap2/smartreflex.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 77ecebf..697d8d4 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -260,9 +260,11 @@ static int sr_late_init(struct omap_sr *sr_info)
> if (sr_class->class_type == SR_CLASS2 &&
> sr_class->notify_flags && sr_info->irq) {
>
> - name = kzalloc(SMARTREFLEX_NAME_LEN + 1, GFP_KERNEL);
> - strcpy(name, "sr_");
> - strcat(name, sr_info->voltdm->name);
> + name = kasprintf(GFP_KERNEL, "sr_%s", sr_info->voltdm->name);
> + if (name == NULL) {
> + ret = -ENOMEM;
> + goto error;
> + }
> ret = request_irq(sr_info->irq, sr_interrupt,
> 0, name, (void *)sr_info);
> if (ret)
^ permalink raw reply
* [Buildroot] [PATCH 1/2] docs: fix $(PKG)_SITE_METHOD names (UPPER CASE => lower case)
From: Bjørn Forsman @ 2011-02-01 22:22 UTC (permalink / raw)
To: buildroot
Currently, the documentation says $(PKG)_SITE_METHOD should have upper
case names such as SVN or GIT, but the implementation only accepts lower
case svn or git. This fixes the documentation.
Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
---
docs/buildroot.html | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/docs/buildroot.html b/docs/buildroot.html
index 36297e0..de6b1d7 100644
--- a/docs/buildroot.html
+++ b/docs/buildroot.html
@@ -1060,17 +1060,17 @@ $(eval $(call GENTARGETS,package,libfoo,host))
<li><code>LIBFOO_SITE_METHOD</code> may contain the method to
fetch the package source code. It can either
- be <code>WGET</code> (for normal FTP/HTTP downloads of
- tarballs), <code>SVN</code> or <code>GIT</code>. When not
+ be <code>wget</code> (for normal FTP/HTTP downloads of
+ tarballs), <code>svn</code> or <code>git</code>. When not
specified, it is guessed from the URL given
in <code>LIBFOO_SITE</code>: <code>git://</code>
- and <code>svn://</code> URLs will use the <code>GIT</code>
- and <code>SVN</code> methods respectively. All other URL-types
- will use the <code>WGET</code> method. So for example, in the
+ and <code>svn://</code> URLs will use the <code>git</code>
+ and <code>svn</code> methods respectively. All other URL-types
+ will use the <code>wget</code> method. So for example, in the
case of a package whose source code is available through
Subversion repository on HTTP, one <i>must</i>
- specifiy <code>LIBFOO_SITE_METHOD=SVN</code>. For <code>SVN</code>
- and <code>GIT</code> methods, what Buildroot does is a
+ specifiy <code>LIBFOO_SITE_METHOD=svn</code>. For <code>svn</code>
+ and <code>git</code> methods, what Buildroot does is a
checkout/clone of the repository which is then tarballed and
stored into the download cache. Next builds will not
checkout/clone again, but will use the tarball
--
1.7.1
^ permalink raw reply related
* [Buildroot] [PATCH 2/2] docs: add missing info about Bazaar (bzr) download method
From: Bjørn Forsman @ 2011-02-01 22:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296598960-356-1-git-send-email-bjorn.forsman@gmail.com>
Signed-off-by: Bj?rn Forsman <bjorn.forsman@gmail.com>
---
docs/buildroot.html | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/docs/buildroot.html b/docs/buildroot.html
index de6b1d7..67c82a7 100644
--- a/docs/buildroot.html
+++ b/docs/buildroot.html
@@ -1061,12 +1061,12 @@ $(eval $(call GENTARGETS,package,libfoo,host))
<li><code>LIBFOO_SITE_METHOD</code> may contain the method to
fetch the package source code. It can either
be <code>wget</code> (for normal FTP/HTTP downloads of
- tarballs), <code>svn</code> or <code>git</code>. When not
- specified, it is guessed from the URL given
- in <code>LIBFOO_SITE</code>: <code>git://</code>
- and <code>svn://</code> URLs will use the <code>git</code>
- and <code>svn</code> methods respectively. All other URL-types
- will use the <code>wget</code> method. So for example, in the
+ tarballs), <code>svn</code>, <code>git</code> or <code>bzr</code>.
+ When not specified, it is guessed from the URL given
+ in <code>LIBFOO_SITE</code>: <code>svn://</code>, <code>git://</code>
+ and <code>bzr://</code> URLs will use the <code>svn</code>,
+ <code>git</code> and <code>bzr</code> methods respectively. All other
+ URL-types will use the <code>wget</code> method. So for example, in the
case of a package whose source code is available through
Subversion repository on HTTP, one <i>must</i>
specifiy <code>LIBFOO_SITE_METHOD=svn</code>. For <code>svn</code>
--
1.7.1
^ permalink raw reply related
* Re: [PATCHv4] OMAP: Enable Magic SysRq on serial console ttyOx
From: Greg KH @ 2011-02-01 22:23 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, Govindraj.R, open list, Thomas Weber
In-Reply-To: <87ei7ryavx.fsf@ti.com>
On Tue, Feb 01, 2011 at 08:31:30AM -0800, Kevin Hilman wrote:
> Thomas Weber <weber@corscience.de> writes:
>
> > Magic SysRq key is not working for OMAP on new serial
> > console ttyOx because SUPPORT_SYSRQ is not defined
> > for omap-serial.
> >
> > This patch defines SUPPORT_SYSRQ in omap-serial and
> > enables handling of Magic SysRq character.
> >
> > Further there is an issue of losing first break character.
> > Removing the reset of the lsr_break_flag fixes this issue.
> >
> > Signed-off-by: Thomas Weber <weber@corscience.de>
> > Acked-by: Govindraj.R <govindraj.raja@ti.com>
> > Tested-by: Manjunath G Kondaiah <manjugk@ti.com>
> > Acked-by: Kevin Hilman <khilman@ti.com>
>
> Greg,
>
> Will you be taking this? If you prefer, we can take it via OMAP tree
> with your ack.
I can take it if it's not a problem for you. Or if you want to, please
add:
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
to the patch.
Let me know which is easier for you.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 06/18] wl1251: enable beacon early termination while in power-saving mode
From: Kalle Valo @ 2011-02-01 22:23 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45A5B7.9010203@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> Port the beacon early termination feature from wl1251 driver version
> included in the Maemo Fremantle kernel. It is enabled when going to
> power-saving mode and disabled when leaving power-saving mode.
Looks good to me.
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* [PATCH] OMAP2+: remove unused UART base addresses from omap_globals
From: Kevin Hilman @ 2011-02-01 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295649015-26348-1-git-send-email-khilman@ti.com>
Kevin Hilman <khilman@ti.com> writes:
> Now that omap_hwmod + omap_device is used for OMAP UART device and
> driver code, we no longer need the UART physical addresses in
> omap_globals.
>
> Note that the #defines for the base addresses are still left in
> <plat/serial.h> since they are used by DEBUG_LL and uncompress code.
>
> Build tested for OMAP1 (omap1_defconfig) and OMAP2+ (omap2plus_defconfig)
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies on Tony's for-next branch.
For the benefit of the archives, queuing for 2.6.39 (branch:
for_2.6.39/pm-misc)
Kevin
> arch/arm/mach-omap2/common.c | 14 --------------
> arch/arm/plat-omap/include/plat/common.h | 4 ----
> 2 files changed, 0 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
> index d5eaee3..8044c8a 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -50,9 +50,6 @@ static struct omap_globals omap242x_globals = {
> .ctrl = OMAP242X_CTRL_BASE,
> .prm = OMAP2420_PRM_BASE,
> .cm = OMAP2420_CM_BASE,
> - .uart1_phys = OMAP2_UART1_BASE,
> - .uart2_phys = OMAP2_UART2_BASE,
> - .uart3_phys = OMAP2_UART3_BASE,
> };
>
> void __init omap2_set_globals_242x(void)
> @@ -71,9 +68,6 @@ static struct omap_globals omap243x_globals = {
> .ctrl = OMAP243X_CTRL_BASE,
> .prm = OMAP2430_PRM_BASE,
> .cm = OMAP2430_CM_BASE,
> - .uart1_phys = OMAP2_UART1_BASE,
> - .uart2_phys = OMAP2_UART2_BASE,
> - .uart3_phys = OMAP2_UART3_BASE,
> };
>
> void __init omap2_set_globals_243x(void)
> @@ -92,10 +86,6 @@ static struct omap_globals omap3_globals = {
> .ctrl = OMAP343X_CTRL_BASE,
> .prm = OMAP3430_PRM_BASE,
> .cm = OMAP3430_CM_BASE,
> - .uart1_phys = OMAP3_UART1_BASE,
> - .uart2_phys = OMAP3_UART2_BASE,
> - .uart3_phys = OMAP3_UART3_BASE,
> - .uart4_phys = OMAP3_UART4_BASE, /* Only on 3630 */
> };
>
> void __init omap2_set_globals_3xxx(void)
> @@ -119,10 +109,6 @@ static struct omap_globals omap4_globals = {
> .prm = OMAP4430_PRM_BASE,
> .cm = OMAP4430_CM_BASE,
> .cm2 = OMAP4430_CM2_BASE,
> - .uart1_phys = OMAP4_UART1_BASE,
> - .uart2_phys = OMAP4_UART2_BASE,
> - .uart3_phys = OMAP4_UART3_BASE,
> - .uart4_phys = OMAP4_UART4_BASE,
> };
>
> void __init omap2_set_globals_443x(void)
> diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
> index 29b2afb..1b8095b 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -56,10 +56,6 @@ struct omap_globals {
> unsigned long prm; /* Power and Reset Management */
> unsigned long cm; /* Clock Management */
> unsigned long cm2;
> - unsigned long uart1_phys;
> - unsigned long uart2_phys;
> - unsigned long uart3_phys;
> - unsigned long uart4_phys;
> };
>
> void omap2_set_globals_242x(void);
^ permalink raw reply
* Re: [PATCH] OMAP2+: remove unused UART base addresses from omap_globals
From: Kevin Hilman @ 2011-02-01 22:24 UTC (permalink / raw)
To: linux-omap; +Cc: linux-arm-kernel
In-Reply-To: <1295649015-26348-1-git-send-email-khilman@ti.com>
Kevin Hilman <khilman@ti.com> writes:
> Now that omap_hwmod + omap_device is used for OMAP UART device and
> driver code, we no longer need the UART physical addresses in
> omap_globals.
>
> Note that the #defines for the base addresses are still left in
> <plat/serial.h> since they are used by DEBUG_LL and uncompress code.
>
> Build tested for OMAP1 (omap1_defconfig) and OMAP2+ (omap2plus_defconfig)
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies on Tony's for-next branch.
For the benefit of the archives, queuing for 2.6.39 (branch:
for_2.6.39/pm-misc)
Kevin
> arch/arm/mach-omap2/common.c | 14 --------------
> arch/arm/plat-omap/include/plat/common.h | 4 ----
> 2 files changed, 0 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
> index d5eaee3..8044c8a 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -50,9 +50,6 @@ static struct omap_globals omap242x_globals = {
> .ctrl = OMAP242X_CTRL_BASE,
> .prm = OMAP2420_PRM_BASE,
> .cm = OMAP2420_CM_BASE,
> - .uart1_phys = OMAP2_UART1_BASE,
> - .uart2_phys = OMAP2_UART2_BASE,
> - .uart3_phys = OMAP2_UART3_BASE,
> };
>
> void __init omap2_set_globals_242x(void)
> @@ -71,9 +68,6 @@ static struct omap_globals omap243x_globals = {
> .ctrl = OMAP243X_CTRL_BASE,
> .prm = OMAP2430_PRM_BASE,
> .cm = OMAP2430_CM_BASE,
> - .uart1_phys = OMAP2_UART1_BASE,
> - .uart2_phys = OMAP2_UART2_BASE,
> - .uart3_phys = OMAP2_UART3_BASE,
> };
>
> void __init omap2_set_globals_243x(void)
> @@ -92,10 +86,6 @@ static struct omap_globals omap3_globals = {
> .ctrl = OMAP343X_CTRL_BASE,
> .prm = OMAP3430_PRM_BASE,
> .cm = OMAP3430_CM_BASE,
> - .uart1_phys = OMAP3_UART1_BASE,
> - .uart2_phys = OMAP3_UART2_BASE,
> - .uart3_phys = OMAP3_UART3_BASE,
> - .uart4_phys = OMAP3_UART4_BASE, /* Only on 3630 */
> };
>
> void __init omap2_set_globals_3xxx(void)
> @@ -119,10 +109,6 @@ static struct omap_globals omap4_globals = {
> .prm = OMAP4430_PRM_BASE,
> .cm = OMAP4430_CM_BASE,
> .cm2 = OMAP4430_CM2_BASE,
> - .uart1_phys = OMAP4_UART1_BASE,
> - .uart2_phys = OMAP4_UART2_BASE,
> - .uart3_phys = OMAP4_UART3_BASE,
> - .uart4_phys = OMAP4_UART4_BASE,
> };
>
> void __init omap2_set_globals_443x(void)
> diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
> index 29b2afb..1b8095b 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -56,10 +56,6 @@ struct omap_globals {
> unsigned long prm; /* Power and Reset Management */
> unsigned long cm; /* Clock Management */
> unsigned long cm2;
> - unsigned long uart1_phys;
> - unsigned long uart2_phys;
> - unsigned long uart3_phys;
> - unsigned long uart4_phys;
> };
>
> void omap2_set_globals_242x(void);
^ permalink raw reply
* Re: btrfs bug in 2.6.37
From: cwillu @ 2011-02-01 22:25 UTC (permalink / raw)
To: Carlos R. Mafra; +Cc: linux-btrfs
In-Reply-To: <20110201215159.GA1897@Pilar.site>
On Tue, Feb 1, 2011 at 3:51 PM, Carlos R. Mafra <crmafra2@gmail.com> wr=
ote:
>
> I am running 2.6.37 plus the revert of bf9dc102e284 (which is related=
to drm).
>
> My /home is on btrfs as well as a 1TB external USB hard-disk.
>
> I was compiling 2.6.38-rc3 from /home/mafra/linux2.6 using
> the external hd as the destination of the compiled files:
>
> make -j4 O=3D/mnt/wd/kernel-compile
>
> So after some time I got this bug and I was dropped out of X
>
> [ 2730.943101] BUG: unable to handle kernel NULL pointer dereference =
at 0000000000000030
> [ 2730.943159] IP: [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
> [ 2730.943217] PGD 2248f067 PUD 5adc8067 PMD 0
> [ 2730.943256] Oops: 0000 [#1] SMP
> [ 2730.943285] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/=
scaling_cur_freq
> [ 2730.943331] CPU 0
> [ 2730.943346] Modules linked in: ppp_deflate ppp_async ppp_generic s=
lhc snd_seq snd_seq_device vfat fat option usb_wwan usbserial snd_hda_c=
odec_idt snd_hda_intel iwlagn snd_hda_codec sky2 uvcvideo i2c_i801 snd_=
hwdep evdev
> [ 2730.943526]
> [ 2730.943541] Pid: 15437, comm: as Not tainted 2.6.37-xrandr-00001-g=
1d95a75 #16 VAIO/VGN-FZ240E
> [ 2730.943581] RIP: 0010:[<ffffffff811ba3e5>] =A0[<ffffffff811ba3e5>]=
btrfs_print_leaf+0x25/0x820
> [ 2730.943629] RSP: 0000:ffff88005a771ad8 =A0EFLAGS: 00010287
> [ 2730.943661] RAX: 00000000fffffffb RBX: ffff88005b048d90 RCX: ffff8=
80037f49d38
> [ 2730.943695] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8=
8004d456000
> [ 2730.943729] RBP: ffff88005a771b58 R08: 00000000fffffffb R09: 00000=
00000000000
> [ 2730.943763] R10: 0000000000000001 R11: 00000000ffffffff R12: 00000=
00000000005
> [ 2730.943797] R13: ffff88005a771fd8 R14: 0000000000000000 R15: 00000=
00000000000
> [ 2730.943831] FS: =A000002b01b9f88000(0000) GS:ffff88007f400000(0000=
) knlGS:0000000000000000
> [ 2730.943872] CS: =A00010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 2730.943901] CR2: 0000000000000030 CR3: 000000006161c000 CR4: 00000=
000000006f0
> [ 2730.943934] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000=
00000000000
> [ 2730.943968] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000=
00000000400
> [ 2730.944002] Process as (pid: 15437, threadinfo ffff88005a770000, t=
ask ffff88002ffea680)
> [ 2730.944009] Stack:
> [ 2730.944009] =A00000001cc7d27000 ffffffff811e4724 ffff88004d456000 =
0000001cc7784000
> [ 2730.944009] =A0ffff88005a771b58 ffff88005b048d90 0000001cc7d27000 =
00000000005000a8
> [ 2730.944009] =A0ffff8800491a0e00 ffff88006c2de6c0 0000000000000005 =
ffff88005b048d90
> [ 2730.944009] Call Trace:
> [ 2730.944009] =A0[<ffffffff811e4724>] ? set_extent_dirty+0x24/0x30
> [ 2730.944009] =A0[<ffffffff811b30dd>] __btrfs_free_extent+0x61d/0x6e=
0
> [ 2730.944009] =A0[<ffffffff811b635b>] run_clustered_refs+0x1fb/0x810
> [ 2730.944009] =A0[<ffffffff811e7bda>] ? set_extent_buffer_dirty+0x4a=
/0xa0
> [ 2730.944009] =A0[<ffffffff811c342f>] ? btrfs_mark_buffer_dirty+0xaf=
/0x130
> [ 2730.944009] =A0[<ffffffff81201100>] ? btrfs_find_ref_cluster+0x60/=
0x190
> [ 2730.944009] =A0[<ffffffff811b6a30>] btrfs_run_delayed_refs+0xc0/0x=
210
> [ 2730.944009] =A0[<ffffffff811c55b8>] __btrfs_end_transaction+0x68/0=
x240
> [ 2730.944009] =A0[<ffffffff811c57d0>] btrfs_end_transaction+0x10/0x2=
0
> [ 2730.944009] =A0[<ffffffff811ced57>] btrfs_evict_inode+0x1c7/0x1e0
> [ 2730.944009] =A0[<ffffffff810fa8c2>] evict+0x22/0xb0
> [ 2730.944009] =A0[<ffffffff810fb141>] iput+0x1b1/0x290
> [ 2730.944009] =A0[<ffffffff810f14f5>] do_unlinkat+0x115/0x1c0
> [ 2730.944009] =A0[<ffffffff810e94ae>] ? sys_newlstat+0x2e/0x40
> [ 2730.944009] =A0[<ffffffff810f2af1>] sys_unlink+0x11/0x20
> [ 2730.944009] =A0[<ffffffff81002cfb>] system_call_fastpath+0x16/0x1b
> [ 2730.944009] Code: 84 00 00 00 00 00 55 48 89 e5 48 83 c4 80 48 89 =
5d d8 4c 89 6d e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 88=
b5 00 00 <48> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba=
00
> [ 2730.944009] RIP =A0[<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x82=
0
> [ 2730.944009] =A0RSP <ffff88005a771ad8>
> [ 2730.944009] CR2: 0000000000000030
> [ 2730.950886] ---[ end trace 3c2d14569018819f ]---
> [ 2731.229129] BUG: unable to handle kernel NULL pointer dereference =
at 0000000000000030
> [ 2731.230010] IP: [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
> [ 2731.230010] PGD 22623067 PUD 2278d067 PMD 0
> [ 2731.230010] Oops: 0000 [#2] SMP
> [ 2731.230010] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/=
scaling_cur_freq
> [ 2731.230010] CPU 1
> [ 2731.230010] Modules linked in: ppp_deflate ppp_async ppp_generic s=
lhc snd_seq snd_seq_device vfat fat option usb_wwan usbserial snd_hda_c=
odec_idt snd_hda_intel iwlagn snd_hda_codec sky2 uvcvideo i2c_i801 snd_=
hwdep evdev
> [ 2731.230010]
> [ 2731.230010] Pid: 15444, comm: as Tainted: G =A0 =A0 =A0D =A0 =A0 2=
=2E6.37-xrandr-00001-g1d95a75 #16 VAIO/VGN-FZ240E
> [ 2731.230010] RIP: 0010:[<ffffffff811ba3e5>] =A0[<ffffffff811ba3e5>]=
btrfs_print_leaf+0x25/0x820
> [ 2731.230010] RSP: 0000:ffff88004d42dad8 =A0EFLAGS: 00010287
> [ 2731.230010] RAX: 00000000fffffffb RBX: ffff88005b048b50 RCX: ffff8=
80037f49d38
> [ 2731.230010] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8=
8004d456000
> [ 2731.230010] RBP: ffff88004d42db58 R08: 00000000fffffffb R09: 00000=
00000000000
> [ 2731.230010] R10: 0000000000000001 R11: 00000000ffffffff R12: 00000=
00000000005
> [ 2731.230010] R13: ffff88004d42dfd8 R14: 0000000000000000 R15: 00000=
00000000000
> [ 2731.230010] FS: =A000002aac5cec6000(0000) GS:ffff88007f500000(0000=
) knlGS:0000000000000000
> [ 2731.230010] CS: =A00010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 2731.230010] CR2: 0000000000000030 CR3: 00000000226af000 CR4: 00000=
000000006e0
> [ 2731.230010] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000=
00000000000
> [ 2731.230010] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000=
00000000400
> [ 2731.230010] Process as (pid: 15444, threadinfo ffff88004d42c000, t=
ask ffff88007b69e280)
> [ 2731.230010] Stack:
> [ 2731.230010] =A00000001cc7d2c000 ffffffff811dd7c5 ffff88004d456000 =
ffff8800218b8898
> [ 2731.230010] =A0ffff88004d42dba8 ffff88005b048b50 0000001cc7d2c000 =
00000000005000a8
> [ 2731.230010] =A0ffff88004d42db00 ffff88005a5e5cc0 0000000000000005 =
ffff88005b048b50
> [ 2731.230010] Call Trace:
> [ 2731.230010] =A0[<ffffffff811dd7c5>] ? btrfs_key_generation+0xe5/0x=
f0
> [ 2731.230010] =A0[<ffffffff811b30dd>] __btrfs_free_extent+0x61d/0x6e=
0
> [ 2731.230010] =A0[<ffffffff811e7bda>] ? set_extent_buffer_dirty+0x4a=
/0xa0
> [ 2731.230010] =A0[<ffffffff811c342f>] ? btrfs_mark_buffer_dirty+0xaf=
/0x130
> [ 2731.230010] =A0[<ffffffff811b635b>] run_clustered_refs+0x1fb/0x810
> [ 2731.230010] =A0[<ffffffff81201100>] ? btrfs_find_ref_cluster+0x60/=
0x190
> [ 2731.230010] =A0[<ffffffff811b6a30>] btrfs_run_delayed_refs+0xc0/0x=
210
> [ 2731.230010] =A0[<ffffffff811c55b8>] __btrfs_end_transaction+0x68/0=
x240
> [ 2731.230010] =A0[<ffffffff811c57d0>] btrfs_end_transaction+0x10/0x2=
0
> [ 2731.230010] =A0[<ffffffff811ced1f>] btrfs_evict_inode+0x18f/0x1e0
> [ 2731.230010] =A0[<ffffffff810fa8c2>] evict+0x22/0xb0
> [ 2731.230010] =A0[<ffffffff810fb141>] iput+0x1b1/0x290
> [ 2731.230010] =A0[<ffffffff810f14f5>] do_unlinkat+0x115/0x1c0
> [ 2731.230010] =A0[<ffffffff810e94ae>] ? sys_newlstat+0x2e/0x40
> [ 2731.230010] =A0[<ffffffff810f2af1>] sys_unlink+0x11/0x20
> [ 2731.230010] =A0[<ffffffff81002cfb>] system_call_fastpath+0x16/0x1b
> [ 2731.230010] Code: 84 00 00 00 00 00 55 48 89 e5 48 83 c4 80 48 89 =
5d d8 4c 89 6d e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 88=
b5 00 00 <48> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba=
00
> [ 2731.230010] RIP =A0[<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x82=
0
> [ 2731.230010] =A0RSP <ffff88004d42dad8>
> [ 2731.230010] CR2: 0000000000000030
> [ 2731.304076] ---[ end trace 3c2d1456901881a0 ]---
> [ 2731.778512] BUG: unable to handle kernel NULL pointer dereference =
at 0000000000000030
> [ 2731.779007] IP: [<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x820
> [ 2731.779007] PGD 2ffa8067 PUD 5a93d067 PMD 0
> [ 2731.779007] Oops: 0000 [#3] SMP
> [ 2731.779007] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/=
scaling_cur_freq
> [ 2731.779007] CPU 0
> [ 2731.779007] Modules linked in: ppp_deflate ppp_async ppp_generic s=
lhc snd_seq snd_seq_device vfat fat option usb_wwan usbserial snd_hda_c=
odec_idt snd_hda_intel iwlagn snd_hda_codec sky2 uvcvideo i2c_i801 snd_=
hwdep evdev
> [ 2731.779007]
> [ 2731.779007] Pid: 15448, comm: as Tainted: G =A0 =A0 =A0D =A0 =A0 2=
=2E6.37-xrandr-00001-g1d95a75 #16 VAIO/VGN-FZ240E
> [ 2731.779007] RIP: 0010:[<ffffffff811ba3e5>] =A0[<ffffffff811ba3e5>]=
btrfs_print_leaf+0x25/0x820
> [ 2731.779007] RSP: 0018:ffff8800227c5ad8 =A0EFLAGS: 00010287
> [ 2731.779007] RAX: 00000000fffffffb RBX: ffff88005b048c70 RCX: ffff8=
80021f9fd38
> [ 2731.779007] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8=
8004d456000
> [ 2731.779007] RBP: ffff8800227c5b58 R08: 00000000fffffffb R09: 00000=
00000000000
> [ 2731.779007] R10: 0000000000000001 R11: 00000000ffffffff R12: 00000=
00000000005
> [ 2731.779007] R13: ffff8800227c5fd8 R14: 0000000000000000 R15: 00000=
00000000000
> [ 2731.779007] FS: =A000002b0f18c8e000(0000) GS:ffff88007f400000(0000=
) knlGS:0000000000000000
> [ 2731.779007] CS: =A00010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 2731.779007] CR2: 0000000000000030 CR3: 000000006c0b5000 CR4: 00000=
000000006f0
> [ 2731.779007] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000=
00000000000
> [ 2731.779007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000=
00000000400
> [ 2731.779007] Process as (pid: 15448, threadinfo ffff8800227c4000, t=
ask ffff88003acfc5c0)
> [ 2731.779007] Stack:
> [ 2731.779007] =A00000001cc7d3c000 ffffffff811dd7c5 ffff88004d456000 =
ffff8800218b21f0
> [ 2731.779007] =A0ffff8800227c5ba8 ffff88005b048c70 0000001cc7d3c000 =
00000000005000a8
> [ 2731.779007] =A0ffff8800227c5b00 ffff88007229ea40 0000000000000005 =
ffff88005b048c70
> [ 2731.779007] Call Trace:
> [ 2731.779007] =A0[<ffffffff811dd7c5>] ? btrfs_key_generation+0xe5/0x=
f0
> [ 2731.779007] =A0[<ffffffff811b30dd>] __btrfs_free_extent+0x61d/0x6e=
0
> [ 2731.779007] =A0[<ffffffff811dd9b4>] ? btrfs_item_offset+0xe4/0xf0
> [ 2731.779007] =A0[<ffffffff811b635b>] run_clustered_refs+0x1fb/0x810
> [ 2731.779007] =A0[<ffffffff811e7bda>] ? set_extent_buffer_dirty+0x4a=
/0xa0
> [ 2731.779007] =A0[<ffffffff811c342f>] ? btrfs_mark_buffer_dirty+0xaf=
/0x130
> [ 2731.779007] =A0[<ffffffff81201100>] ? btrfs_find_ref_cluster+0x60/=
0x190
> [ 2731.779007] =A0[<ffffffff811b6a30>] btrfs_run_delayed_refs+0xc0/0x=
210
> [ 2731.779007] =A0[<ffffffff811c55b8>] __btrfs_end_transaction+0x68/0=
x240
> [ 2731.779007] =A0[<ffffffff811c57d0>] btrfs_end_transaction+0x10/0x2=
0
> [ 2731.779007] =A0[<ffffffff811ced57>] btrfs_evict_inode+0x1c7/0x1e0
> [ 2731.779007] =A0[<ffffffff810fa8c2>] evict+0x22/0xb0
> [ 2731.779007] =A0[<ffffffff810fb141>] iput+0x1b1/0x290
> [ 2731.779007] =A0[<ffffffff810f14f5>] do_unlinkat+0x115/0x1c0
> [ 2731.779007] =A0[<ffffffff810e94ae>] ? sys_newlstat+0x2e/0x40
> [ 2731.779007] =A0[<ffffffff810f2af1>] sys_unlink+0x11/0x20
> [ 2731.779007] =A0[<ffffffff81002cfb>] system_call_fastpath+0x16/0x1b
> [ 2731.779007] Code: 84 00 00 00 00 00 55 48 89 e5 48 83 c4 80 48 89 =
5d d8 4c 89 6d e8 4c 89 65 e0 4c 89 75 f0 4c 89 7d f8 65 4c 8b 2c 25 88=
b5 00 00 <48> 8b 46 30 49 81 ed d8 1f 00 00 48 89 f3 41 ff 45 1c 48 ba=
00
> [ 2731.779007] RIP =A0[<ffffffff811ba3e5>] btrfs_print_leaf+0x25/0x82=
0
> [ 2731.779007] =A0RSP <ffff8800227c5ad8>
> [ 2731.779007] CR2: 0000000000000030
> [ 2731.855520] ---[ end trace 3c2d1456901881a1 ]---
> [ 2732.101887] btrfs csum failed ino 244904 extent 124692799488 csum =
4201110721 wanted 126609361 mirror 0
> [ 2732.102064] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102084] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102102] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102121] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102139] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102158] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102176] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102195] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102213] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102231] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.102250] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2732.103048] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 0
> [ 2732.103086] btrfs csum failed ino 244904 extent 124692799488 csum =
2566472073 wanted 126609361 mirror 1
> [ 2738.344564] btrfs csum failed ino 244835 extent 124686446592 csum =
4201110721 wanted 3023272677 mirror 0
> [ 2738.344662] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344683] btrfs csum failed ino 244835 extent 124686446592 csum =
4201110721 wanted 3023272677 mirror 1
> [ 2738.344702] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344729] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344748] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344752] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344768] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344772] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344792] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344823] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344843] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344862] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
> [ 2738.344884] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 0
> [ 2738.344932] btrfs csum failed ino 244835 extent 124686446592 csum =
2566472073 wanted 3023272677 mirror 1
>
>
> Is this problem already known?
Was there anything else before the first bug in dmesg? I would
predict there to have been some additional debugging info, and
probably a USB device disconnect or similar.
If I'm correct, there was an io error while writing to the external
device, which as of 2.6.37 isn't handled terribly well (and errors in
general; in that sense, it's known).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
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: [PATCH 07/18] wl1251: implement connection quality monitoring
From: Kalle Valo @ 2011-02-01 22:26 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45A5C1.8050503@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> Implement connection quality monitoring similar to the wl1271 driver.
> It triggers ieee80211_cqm_rssi_notify with the corresponding event when
> RSSI drops blow RSSI threshold or rises again above the RSSI threshold.
> It should be noted that wl1251 doesn't support RSSI hysteresis, instead it
> uses RSSI averageing and delays events until a certain count of frames
> proved RSSI change.
Had a quick look and no problems with this one.
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* Re: Early crash (was: Re: module: show version information for built-in modules in sysfs)
From: Dmitry Torokhov @ 2011-02-01 22:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rusty Russell, linux-kernel@vger.kernel.org, Linux/m68k
In-Reply-To: <AANLkTimv=KqtuR36dMNa+=OMi0mgd8JK4qsb_SpmKmhs@mail.gmail.com>
On Tue, Feb 01, 2011 at 02:03:23PM -0800, Geert Uytterhoeven wrote:
> On Tue, Feb 1, 2011 at 22:09, Dmitry Torokhov <dtor@vmware.com> wrote:
> > On Tue, Feb 01, 2011 at 12:33:29PM -0800, Geert Uytterhoeven wrote:
> >> On Mon, Jan 24, 2011 at 11:59, Linux Kernel Mailing List
> >> <linux-kernel@vger.kernel.org> wrote:
> >> > Gitweb: http://git.kernel.org/linus/e94965ed5beb23c6fabf7ed31f625e66d7ff28de
> >>
> >> > module: show version information for built-in modules in sysfs
> >> >
> >> > Currently only drivers that are built as modules have their versions
> >> > shown in /sys/module/<module_name>/version, but this information might
> >> > also be useful for built-in drivers as well. This especially important
> >> > for drivers that do not define any parameters - such drivers, if
> >> > built-in, are completely invisible from userspace.
> >> >
> >> > This patch changes MODULE_VERSION() macro so that in case when we are
> >> > compiling built-in module, version information is stored in a separate
> >> > section. Kernel then uses this data to create 'version' sysfs attribute
> >> > in the same fashion it creates attributes for module parameters.
> >>
> >> This commit causes the crash below on m68k (ARAnyM).
> >> Reverting this commit and its dependency
> >> 3b90a5b292321b2acac3921f77046ae195aef53f
> >> ("module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=n")
> >> makes it boot again.
> >>
> >
> > Hi Geert,
> >
> > Does the follwing help by any chance?
> >
> > From d6fd4a6e0fc2d3f0a74962d4a6f663a46d230ecd Mon Sep 17 00:00:00 2001
> > diff --git a/arch/m68knommu/kernel/vmlinux.lds.S b/arch/m68knommu/kernel/vmlinux.lds.S
> > index ef33213..47e15eb 100644
> > --- a/arch/m68knommu/kernel/vmlinux.lds.S
> > +++ b/arch/m68knommu/kernel/vmlinux.lds.S
>
> The crash happened on m68k with MMU, not m68knommu.
>
Hmm, OK then. Could you please see if the crash happens if you return
early in kernel/params.c::version_sysfs_builtin() ? Also, do you see
anything in __modev section of your build?
Thanks,
Dmitry
^ permalink raw reply
* Re: snd_soc_jack_add_gpios vs. SOC_DAPM_PIN_SWITCH
From: Mark Brown @ 2011-02-01 22:27 UTC (permalink / raw)
To: Stephen Warren; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310C8E48A@HQMAIL01.nvidia.com>
On Tue, Feb 01, 2011 at 10:59:00AM -0800, Stephen Warren wrote:
> Mark Brown wrote at Tuesday, February 01, 2011 4:34 AM:
> > Using these two together makes no sense. Either you manually control
> > the state of the output or you manage it automatically.
> I was thinking that the jack detect would be used to enable/disable widgets
> for power purposes, but with a manual override to allow SW to set up use
> cases where only the internal speakers were used, and never headphones.
> That said, if that isn't something that's ever typically done, I'm fine
> not supporting that.
It's really uncommon - generally if headphones are inserted you want to
play audio on them even if also using the speakers as when people have
headphones in they may not be able to hear the speakers. Headphones are
often pretty good earplugs too.
> > Generally a PIN_SWITCH() should only be used to offer control if none is
> > availabile within the CODEC - in the case of Harmony it wouldn't make
> > much sense as there's plenty of control in the CODEC for what gets
> > routed to the various outputs.
> IIRC, the codec controls allow selecting only what gets routed, but there
> wasn't an overall "enable/disable speakers" switch (the mute switch does
> not disable the DAPM widgets). One would have to disable all the routing
> options to disable the speaker amplifiers, which would entail remembering
> what those routing options were to restore them once the speakers were
> desired again. A manual switch avoids this.
It may make sense to have a pin switch for the speakers, it's much more
of a userspace question if you want the speakers on when the headphones
are inserted so they probably shouldn't be connected to the jack at all
(as we discussed previously). Bear in mind that in the *very* common
case where the outputs are connected to DACs only everything will get
powered off when there's no audio playing anyway.
Having looked at the WM8903 again this probably does make most sense for
the speakers.
^ permalink raw reply
* Re: [PATCH 09/18] wl1251: enable adhoc mode
From: Kalle Valo @ 2011-02-01 22:27 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45A5CF.6050603@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> Enable adhoc support in wl1251 driver.
>
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: Tree for February 1 (sound/soc)
From: Mark Brown @ 2011-02-01 22:27 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, Liam Girdwood, linux-next, LKML
In-Reply-To: <20110201093256.f5ff0252.randy.dunlap@oracle.com>
On Tue, Feb 01, 2011 at 09:32:56AM -0800, Randy Dunlap wrote:
> That function call is surrounded by CONFIG_PM but the function itself is
> surrounded by CONFIG_PM_SLEEP.
I really am going to finish off the changelog for removing CONFIG_PM
soon...
^ permalink raw reply
* Re: [PATCH 06/11] xen/setup: Skip over 1st gap after System RAM.
From: Konrad Rzeszutek Wilk @ 2011-02-01 22:28 UTC (permalink / raw)
To: Ian Campbell
Cc: linux-kernel@vger.kernel.org, Xen-devel@lists.xensource.com,
konrad@kernel.org, jeremy@goop.org, hpa@zytor.com,
Stefano Stabellini
In-Reply-To: <1296572896.13091.240.camel@zakaz.uk.xensource.com>
On Tue, Feb 01, 2011 at 03:08:16PM +0000, Ian Campbell wrote:
> On Mon, 2011-01-31 at 22:44 +0000, Konrad Rzeszutek Wilk wrote:
> > If the kernel is booted with dom0_mem=max:512MB and the
> > machine has more than 512MB of RAM, the E820 we get is:
> >
> > Xen: 0000000000100000 - 0000000020000000 (usable)
> > Xen: 00000000b7ee0000 - 00000000b7ee3000 (ACPI NVS)
> >
> > while in actuality it is:
> >
> > (XEN) 0000000000100000 - 00000000b7ee0000 (usable)
> > (XEN) 00000000b7ee0000 - 00000000b7ee3000 (ACPI NVS)
> >
> > Based on that, we would determine that the "gap" between
> > 0x20000 -> 0xb7ee0 is not System RAM and try to assign it to
> > 1-1 mapping. This meant that later on when we setup the page tables
> > we would try to assign those regions to DOMID_IO and the
> > Xen hypervisor would fail such operation. This patch
> > guards against that and sets the "gap" to be after the first
> > non-RAM E820 region.
>
> This seems dodgy to me and makes assumptions about the sanity of the
> BIOS provided e820 maps. e.g. it's not impossible that there are systems
> out there with 2 or more little holes under 1M etc.
[edit: I am droppping this patch.. explanation at the end of email]
Are you thinking of something like this:
000->a00 [RAM]
b00->c00 [reserved]
dff->f00 [RAM]
So there is a gap between a00->b00, and c00->dff which is not System RAM
but real PCI space and as such should be considered identity mapping?
(Lets ignore the fact that we consider any access under ISA_END_ADDRESS
to be identity).
The hypervisor is the one that truncates the E820_RAM such that it is dangerous
to consider the gap after the end of E820_RAM to be not System RAM.
(You actually were hitting this way back when you ran my patchset the first time).
[edit: actually I was mistaken, read below..]
>
> The truncation (from 0xb7ee0000 to 0x20000000 in this case) happens in
> the dom0 kernel not the hypervisor right? So we can at least know that
> we've done it.
The hypervisor does this. [edit: I missed this code:
280 if (map[i].type == E820_RAM && end > mem_end) {
281 /* RAM off the end - may be partially included */
282 u64 delta = min(map[i].size, end - mem_end);
283
which shows that we, dom0, truncate the E820 entries.]
>
> Can we do the identity setup before that truncation happens? If not can
Sadly no. [edit: happily yes]
There are two types of truncation:
1). The hypervisor truncates the E820_RAM to the proper PFN number. If
there are E820_RAM regions past the first one (see the
example in "x86/setup: Consult the raw E820 for zero sized E820 RAM regions.")
it makes the size of those E820_RAM to be zero. The patch I mentioned
consults the 'raw' E820 to see if this exists.
[edit: ignore this pls, the code in xen_memory_setup does the truncation]
2). The Linux kernel e820 library "sanititizes" the E820. This means
if you have E820_RAM regions with zero size they disappear. We can't
use the E820 before this sanitization b/c the increase/decrease code has to
run its course to fill up the E820_RAM past the 4GB.
> can we not remember the untruncated map too and refer to it as
> necessary. One way of doing that might be to insert an e820 region
> covering the truncated region to identify it as such (perhaps
> E820_UNUSABLE?) or maybe integrating e.g. with the memblock reservations
> (or whatever the early enough allocator is).
>
> The scheme we have is that all pre-ballooned memory goes at the end of
> the e820 right, as opposed to allowing it to first fill truncated
> regions such as this?
Correct. We siphon out any Sysem RAM memory that is under 4GB that can
be siphoned out and expand the E820_RAM entry past the 4GB with the count
of PFNs that we siphoned out.
[edit: reason why I am dropping this patch]
Your email got me thinking that maybe I missed something about the E820
and sure enough - I somehow skipped that whole process of figuring
out the delta and messing with e820->size. The weird part is
I knew about increase/decrease memory and the delta but somehow did not
connect that those numbers are gathered during the first loop over the E820.
Talk about tunnel vision.
Anyhow, your suggestion of refering to the raw, unmodified version of
the E820 makes this all work quite nicely and I can drop:
xen/setup: Skip over 1st gap after System RAM
x86/setup: Consult the raw E820 for zero sized E820 RAM regions.
I am attaching the patch I am talking about to the "xen/setup: Set
identity mapping for non-RAM E820 and E820 gaps"
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 07/11] x86/setup: Consult the raw E820 for zero sized E820 RAM regions.
From: Konrad Rzeszutek Wilk @ 2011-02-01 22:29 UTC (permalink / raw)
To: Stefano Stabellini
Cc: jeremy@goop.org, Xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, Ian Campbell, konrad@kernel.org,
hpa@zytor.com
In-Reply-To: <alpine.DEB.2.00.1102011537050.7277@kaball-desktop>
On Tue, Feb 01, 2011 at 05:52:15PM +0000, Stefano Stabellini wrote:
> On Mon, 31 Jan 2011, Konrad Rzeszutek Wilk wrote:
> > When the Xen hypervisor provides us with an E820, it can
> > contain zero sized RAM regions. Those are entries that have
> > been trimmed down due to the user utilizing the dom0_mem flag.
> >
> > What it means is that there is RAM at those regions, and we
> > should _not_ be considering those regions as 1-1 mapping.
> >
> > This dom0_mem parameter changes a nice looking E820 like this:
> >
> > Xen: 0000000000000000 - 000000000009d000 (usable)
> > Xen: 000000000009d000 - 0000000000100000 (reserved)
> > Xen: 0000000000100000 - 000000009cf67000 (usable)
> > Xen: 000000009cf67000 - 000000009d103000 (ACPI NVS)
> > Xen: 000000009d103000 - 000000009f6bd000 (usable)
> > Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
> > Xen: 000000009f6bf000 - 000000009f714000 (usable)
> >
> > (wherein we would happily set 9d->100, 9cf67->9d103, and
> > 9f6bd->9f6bf to identity mapping) .. but with a dom0_mem
> > argument (say dom0_mem=700MB) it looks as so:
> >
> > Xen: 0000000000000000 - 000000000009d000 (usable)
> > Xen: 000000000009d000 - 0000000000100000 (reserved)
> > Xen: 0000000000100000 - 000000002bc00000 (usable)
> > Xen: 000000009cf67000 - 000000009d103000 (ACPI NVS)
> > Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
> >
> > We would set 9d->100, and 9cf670->9f6bf to identity
> > mapping. The region from 9d103->9f6bd - which is
> > System RAM where a guest could be allocated from,
> > would be considered identity which is incorrect.
> >
> > [Note: this printout of the E820 is after E820
> > sanitization, the raw E820 would look like this]:
> >
> > Xen: 0000000000000000 - 000000000009d000 (usable)
> > Xen: 000000000009d000 - 0000000000100000 (reserved)
> > Xen: 0000000000100000 - 000000002bc00000 (usable)
> > Xen: 000000009cf67000 - 000000009d103000 (ACPI NVS)
> > Xen: 000000009d103000 - 000000009d103000 (usable) <===
> > Xen: 000000009f6bd000 - 000000009f6bf000 (reserved)
> >
> > [Notice the "usable" zero sized region]
> >
> > This patch consults the non-sanitized version of the E820
> > and checks if there are zero-sized RAM regions right before
> > the non-RAM E820 entry we are currently evaluating.
> > If so, we utilize the 'ram_end' value to piggyback on the
> > code introduced by "xen/setup: Pay attention to zero sized
> > E820_RAM regions" patch. Also we add a printk to help
> > us determine which region has been set to 1-1 mapping and
> > add some sanity checking.
> >
> > We must keep those regions zero-size E820 RAM regions
> > as is (so missing), otherwise the M2P override code can
> > malfunction if a guest grant page is present in those regions.
> >
> > Shifting the "xen_set_identity" to be called earlier (so that
> > we are using the non-sanitized version of the &e820) does not
> > work as we need to take into account the E820 after the
> > initial increase/decrease reservation done and addition of a
> > new E820 region in 'xen_add_extra_mem').
>
> Can we just call two different functions, one before sanitizing the e820
> and another after xen_add_extra_mem?
> We could just go through the original e820 and set as identity all the
> non-ram regions, after all we don't want to risk setting as identity
> valid ram regions.
> If the problem is caused by xen_memory_setup modifying the e820, maybe
> we could avoid doing that, adding all the extra memory regions to the
> balloon without moving them together to the end.
> It is just that this code (and xen_memory_setup) lookis a bit too
> complicated.
Another idea occured to me after I was ingesting Ian's comments
and that is just to parse the "raw" E820 from the hypervisor. It works
quite nicely, so dropping this patch.
^ permalink raw reply
* Re: [PATCH 05/11] xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
From: Konrad Rzeszutek Wilk @ 2011-02-01 22:32 UTC (permalink / raw)
To: linux-kernel, Xen-devel, konrad, jeremy
Cc: Ian.Campbell, stefano.stabellini, hpa
In-Reply-To: <1296513876-31415-6-git-send-email-konrad.wilk@oracle.com>
On Mon, Jan 31, 2011 at 05:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> We walk the E820 region and start at 0 (for PV guests we start
> at ISA_END_ADDRESS) and skip any E820 RAM regions. For all other
> regions and as well the gaps we set them to be identity mappings.
>
> The reasons we do not want to set the identity mapping from 0->
> ISA_END_ADDRESS when running as PV is b/c that the kernel would
> try to read DMI information and fail (no permissions to read that).
> There is a lot of gnarly code to deal with that weird region so
> we won't try to do a cleanup in this patch.
>
> This code ends up calling 'set_phys_to_identity' with the start
> and end PFN of the the E820 that are non-RAM or have gaps.
> On 99% of machines that means one big region right underneath the
> 4GB mark. Usually starts at 0xc0000 (or 0x80000) and goes to
> 0x100000.
>
Please consider this one instead. The change is that we
use the unmodified E820 retrieved from the hypervisor. This E820
has no changes to the size of the System RAM (which were throwing off my
ranges earlier):
commit acaf45c9c7d1b0d87c047590b9bffa0d8a30cbee
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue Feb 1 17:15:30 2011 -0500
xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
We walk the E820 region and start at 0 (for PV guests we start
at ISA_END_ADDRESS) and skip any E820 RAM regions. For all other
regions and as well the gaps we set them to be identity mappings.
The reasons we do not want to set the identity mapping from 0->
ISA_END_ADDRESS when running as PV is b/c that the kernel would
try to read DMI information and fail (no permissions to read that).
There is a lot of gnarly code to deal with that weird region so
we won't try to do a cleanup in this patch.
This code ends up calling 'set_phys_to_identity' with the start
and end PFN of the the E820 that are non-RAM or have gaps.
On 99% of machines that means one big region right underneath the
4GB mark. Usually starts at 0xc0000 (or 0x80000) and goes to
0x100000.
[v2: Fix for E820 crossing 1MB region and clamp the start]
[v3: Squshed in code that does this over ranges]
[v4: Moved the comment to the correct spot]
[v5: Use the "raw" E820 from the hypervisor]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7201800..54d9379 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -143,12 +143,55 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn,
return released;
}
+static unsigned long __init xen_set_identity(const struct e820entry *list,
+ ssize_t map_size)
+{
+ phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS;
+ phys_addr_t start_pci = last;
+ const struct e820entry *entry;
+ unsigned long identity = 0;
+ int i;
+
+ for (i = 0, entry = list; i < map_size; i++, entry++) {
+ phys_addr_t start = entry->addr;
+ phys_addr_t end = start + entry->size;
+
+ if (start < last)
+ start = last;
+
+ if (end <= start)
+ continue;
+
+ /* Skip over the 1MB region. */
+ if (last > end)
+ continue;
+
+ if (entry->type == E820_RAM) {
+ if (start > start_pci)
+ identity += set_phys_range_identity(
+ PFN_UP(start_pci), PFN_DOWN(start));
+
+ /* Without saving 'last' we would gooble RAM too
+ * at the end of the loop. */
+ last = end;
+ start_pci = end;
+ continue;
+ }
+ start_pci = min(start, start_pci);
+ last = end;
+ }
+ if (last > start_pci)
+ identity += set_phys_range_identity(
+ PFN_UP(start_pci), PFN_DOWN(last));
+ return identity;
+}
/**
* machine_specific_memory_setup - Hook for machine specific memory setup.
**/
char * __init xen_memory_setup(void)
{
static struct e820entry map[E820MAX] __initdata;
+ static struct e820entry map_raw[E820MAX] __initdata;
unsigned long max_pfn = xen_start_info->nr_pages;
unsigned long long mem_end;
@@ -156,6 +199,7 @@ char * __init xen_memory_setup(void)
struct xen_memory_map memmap;
unsigned long extra_pages = 0;
unsigned long extra_limit;
+ unsigned long identity_pages = 0;
int i;
int op;
@@ -181,6 +225,7 @@ char * __init xen_memory_setup(void)
}
BUG_ON(rc);
+ memcpy(map_raw, map, sizeof(map));
e820.nr_map = 0;
xen_extra_mem_start = mem_end;
for (i = 0; i < memmap.nr_entries; i++) {
@@ -251,6 +296,13 @@ char * __init xen_memory_setup(void)
xen_add_extra_mem(extra_pages);
+ /*
+ * Set P2M for all non-RAM pages and E820 gaps to be identity
+ * type PFNs. We supply it with the non-sanitized version
+ * of the E820.
+ */
+ identity_pages = xen_set_identity(map_raw, memmap.nr_entries);
+ printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages);
return "Xen";
}
^ permalink raw reply related
* Re: ARM Architecture and GENERIC_CMOS_UPDATE
From: Tony Lindgren @ 2011-02-01 22:32 UTC (permalink / raw)
To: Grant Erickson; +Cc: linux-omap
In-Reply-To: <5CF2B383-9CD5-4295-82C5-9466311E1E62@gmail.com>
* Grant Erickson <marathon96@gmail.com> [110128 16:34]:
> Is there any reason, to date, that the ARM architecture has not had the following kernel configuration option?
>
> config GENERIC_CMOS_UPDATE
> def_bool y
Looks like it would just require implementing update_persitent_clock.
No idea why it's not done for ARM , maybe send some patches for that?
Tony
^ permalink raw reply
* Re: [PATCH 05/11] xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
From: Konrad Rzeszutek Wilk @ 2011-02-01 22:32 UTC (permalink / raw)
To: linux-kernel, Xen-devel, konrad, jeremy
Cc: hpa, stefano.stabellini, Ian.Campbell
In-Reply-To: <1296513876-31415-6-git-send-email-konrad.wilk@oracle.com>
On Mon, Jan 31, 2011 at 05:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> We walk the E820 region and start at 0 (for PV guests we start
> at ISA_END_ADDRESS) and skip any E820 RAM regions. For all other
> regions and as well the gaps we set them to be identity mappings.
>
> The reasons we do not want to set the identity mapping from 0->
> ISA_END_ADDRESS when running as PV is b/c that the kernel would
> try to read DMI information and fail (no permissions to read that).
> There is a lot of gnarly code to deal with that weird region so
> we won't try to do a cleanup in this patch.
>
> This code ends up calling 'set_phys_to_identity' with the start
> and end PFN of the the E820 that are non-RAM or have gaps.
> On 99% of machines that means one big region right underneath the
> 4GB mark. Usually starts at 0xc0000 (or 0x80000) and goes to
> 0x100000.
>
Please consider this one instead. The change is that we
use the unmodified E820 retrieved from the hypervisor. This E820
has no changes to the size of the System RAM (which were throwing off my
ranges earlier):
commit acaf45c9c7d1b0d87c047590b9bffa0d8a30cbee
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue Feb 1 17:15:30 2011 -0500
xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
We walk the E820 region and start at 0 (for PV guests we start
at ISA_END_ADDRESS) and skip any E820 RAM regions. For all other
regions and as well the gaps we set them to be identity mappings.
The reasons we do not want to set the identity mapping from 0->
ISA_END_ADDRESS when running as PV is b/c that the kernel would
try to read DMI information and fail (no permissions to read that).
There is a lot of gnarly code to deal with that weird region so
we won't try to do a cleanup in this patch.
This code ends up calling 'set_phys_to_identity' with the start
and end PFN of the the E820 that are non-RAM or have gaps.
On 99% of machines that means one big region right underneath the
4GB mark. Usually starts at 0xc0000 (or 0x80000) and goes to
0x100000.
[v2: Fix for E820 crossing 1MB region and clamp the start]
[v3: Squshed in code that does this over ranges]
[v4: Moved the comment to the correct spot]
[v5: Use the "raw" E820 from the hypervisor]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7201800..54d9379 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -143,12 +143,55 @@ static unsigned long __init xen_return_unused_memory(unsigned long max_pfn,
return released;
}
+static unsigned long __init xen_set_identity(const struct e820entry *list,
+ ssize_t map_size)
+{
+ phys_addr_t last = xen_initial_domain() ? 0 : ISA_END_ADDRESS;
+ phys_addr_t start_pci = last;
+ const struct e820entry *entry;
+ unsigned long identity = 0;
+ int i;
+
+ for (i = 0, entry = list; i < map_size; i++, entry++) {
+ phys_addr_t start = entry->addr;
+ phys_addr_t end = start + entry->size;
+
+ if (start < last)
+ start = last;
+
+ if (end <= start)
+ continue;
+
+ /* Skip over the 1MB region. */
+ if (last > end)
+ continue;
+
+ if (entry->type == E820_RAM) {
+ if (start > start_pci)
+ identity += set_phys_range_identity(
+ PFN_UP(start_pci), PFN_DOWN(start));
+
+ /* Without saving 'last' we would gooble RAM too
+ * at the end of the loop. */
+ last = end;
+ start_pci = end;
+ continue;
+ }
+ start_pci = min(start, start_pci);
+ last = end;
+ }
+ if (last > start_pci)
+ identity += set_phys_range_identity(
+ PFN_UP(start_pci), PFN_DOWN(last));
+ return identity;
+}
/**
* machine_specific_memory_setup - Hook for machine specific memory setup.
**/
char * __init xen_memory_setup(void)
{
static struct e820entry map[E820MAX] __initdata;
+ static struct e820entry map_raw[E820MAX] __initdata;
unsigned long max_pfn = xen_start_info->nr_pages;
unsigned long long mem_end;
@@ -156,6 +199,7 @@ char * __init xen_memory_setup(void)
struct xen_memory_map memmap;
unsigned long extra_pages = 0;
unsigned long extra_limit;
+ unsigned long identity_pages = 0;
int i;
int op;
@@ -181,6 +225,7 @@ char * __init xen_memory_setup(void)
}
BUG_ON(rc);
+ memcpy(map_raw, map, sizeof(map));
e820.nr_map = 0;
xen_extra_mem_start = mem_end;
for (i = 0; i < memmap.nr_entries; i++) {
@@ -251,6 +296,13 @@ char * __init xen_memory_setup(void)
xen_add_extra_mem(extra_pages);
+ /*
+ * Set P2M for all non-RAM pages and E820 gaps to be identity
+ * type PFNs. We supply it with the non-sanitized version
+ * of the E820.
+ */
+ identity_pages = xen_set_identity(map_raw, memmap.nr_entries);
+ printk(KERN_INFO "Set %ld page(s) to 1-1 mapping.\n", identity_pages);
return "Xen";
}
^ permalink raw reply related
* Re: RE: [xen-unstable test] 5482: regressions - FAIL
From: Keir Fraser @ 2011-02-01 22:34 UTC (permalink / raw)
To: Ian Jackson, Kay, Allen M; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <19784.23263.850797.620012@mariner.uk.xensource.com>
On 01/02/2011 20:11, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> Kay, Allen M writes ("[Xen-devel] RE: [xen-unstable test] 5482: regressions -
> FAIL"):
>> Attached patch disables pci_vtd_quirk for 32-bit Xen since 32-bit xen does
>> not support MMCFG access.
>
> Thanks, that looks like a plausible fix to me so I have applied it.
> That way we should avoid getting this failure in our tests again.
>
> CC'd Keir in case he minds the #ifdef or has some other comment to
> make.
It'll do.
Acked-by: Keir Fraser <keir@xen.org>
-- Keir
> Ian.
^ 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.