* [PATCH user-cr 1/2] use Suka's v11 api
From: Serge E. Hallyn @ 2009-11-10 16:58 UTC (permalink / raw)
To: Linux Containers; +Cc: Nathan T Lynch
This patch:
1. changes restart to pass the right values to
clone-with-pids.
2. updates the clone_s390x.c to work with the
new kernel.
All tests under cr_tests/ pass with this patch.
Signed-off-by: Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
clone_s390x.c | 92 +++++++++++++++++++++++++++++++++++++--------------------
restart.c | 14 +++++----
2 files changed, 68 insertions(+), 38 deletions(-)
diff --git a/clone_s390x.c b/clone_s390x.c
index dada822..71cf52f 100644
--- a/clone_s390x.c
+++ b/clone_s390x.c
@@ -14,6 +14,7 @@
#include <unistd.h>
#include <errno.h>
+#include <string.h>
#include <sys/types.h>
#include <sys/syscall.h>
#include <asm/unistd.h>
@@ -25,48 +26,75 @@
#include <linux/checkpoint.h>
#if defined(__NR_clone_with_pids)
-/* this really belongs to some kernel header ! */
struct pid_set {
int num_pids;
pid_t *pids;
};
-/* (see: http://lkml.indiana.edu/hypermail/linux/kernel/9604.3/0204.html) */
+typedef unsigned long long u64;
+typedef unsigned int u32;
+typedef int pid_t;
+struct clone_args {
+ u64 clone_flags_high;
-#define do_clone_with_pids(stack, flags, ptid, ctid, setp) ({ \
- register unsigned long int __r2 asm ("2") = (unsigned long int)(stack);\
- register unsigned long int __r3 asm ("3") = (unsigned long int)(flags);\
- register unsigned long int __r4 asm ("4") = (unsigned long int)(ptid); \
- register unsigned long int __r5 asm ("5") = (unsigned long int)(ctid); \
- register unsigned long int __r6 asm ("6") = (unsigned long int)(NULL); \
- register unsigned long int __r7 asm ("7") = (unsigned long int)(setp); \
- register unsigned long int __result asm ("2"); \
- __asm__ __volatile__( \
- " lghi %%r1,%7\n" \
- " svc 0\n" \
- : "=d" (__result) \
- : "0" (__r2), "d" (__r3), \
- "d" (__r4), "d" (__r5), "d" (__r6), "d" (__r7), \
- "i" (__NR_clone_with_pids) \
- : "1", "cc", "memory" \
- ); \
- __result; \
- })
+ u64 child_stack_base;
+ u64 child_stack_size;
-int clone_with_pids(int (*fn)(void *), void *child_stack, int flags,
+ u64 parent_tid_ptr;
+ u64 child_tid_ptr;
+
+ u32 nr_pids;
+
+ u32 reserved0;
+ u64 reserved1;
+};
+
+#define do_cwp(flags, pids, args, sz) \
+( { \
+ register unsigned long int __r1 asm ("1") = (unsigned long int)(__NR_clone_with_pids); \
+ register unsigned long int __r2 asm ("2") = (unsigned long int)(flags); \
+ register unsigned long int __r3 asm ("3") = (unsigned long int)(args); \
+ register unsigned long int __r4 asm ("4") = (unsigned long int)(sz); \
+ register unsigned long int __r5 asm ("5") = (unsigned long int)(pids); \
+ register long int __result asm ("2"); \
+ __asm__ __volatile__( \
+ " svc 0\n" /* do __NR_cwp syscall */ \
+ " ltgr %%r2,%%r2\n" /* returned 0? */ \
+ " jnz 1f\n" /* if not goto label 1 */ \
+ " lg %%r3,0(%%r15)\n" /* get fnarg off stack into arg 1 */ \
+ " lg %%r2,8(%%r15)\n" /* get fn off stack int r3 basr*/ \
+ " lgr %%r1,%%r15\n" /* tmp store old stack pointer */ \
+ " aghi %%r15,-160\n" /* move the stack */ \
+ " stg %%r1,0(%%r15)\n" /* and save old stack pointer */ \
+ " basr %%r14,%%r3\n" /* call fn(arg) */ \
+ " svc 1\n" /* call exit */ \
+ " 1:\n" \
+ : "=d" (__result) \
+ : "d" (__r1), "0" (__r2), "d" (__r3), "d" (__r4), "d" (__r5) \
+ : "memory"); \
+ __result; \
+} )
+
+int clone_with_pids(int (*fn)(void *), void *child_stack,
+ unsigned long stack_size, unsigned long flags,
struct pid_set *target_pids, void *arg)
{
- long retval;
- retval = do_clone_with_pids(child_stack, flags, NULL, NULL,
- target_pids);
+ struct clone_args clone_args, *ca = &clone_args;
+ u64 *s;
+
+ memset(ca, 0, sizeof(struct clone_args));
+ ca->nr_pids = target_pids->num_pids;
+ ca->child_stack_size = stack_size - 16;
+ ca->child_stack_base = (u64) child_stack;
+ if (child_stack) {
+ s = (u64 *) (ca->child_stack_base + ca->child_stack_size);
+ *--s = (u64) arg;
+ *--s = (u64) fn;
+ ca->child_stack_size -= 16;
+ }
- if (retval < 0) {
- errno = -retval;
- return -1;
- } else if (retval == 0) {
- return fn(arg);
- } else
- return retval;
+ return do_cwp(flags, target_pids->pids, ca,
+ sizeof(struct clone_args));
}
#endif /* !defined(__NR_clone_with_pids) */
diff --git a/restart.c b/restart.c
index 35c54ea..ebc7bf8 100644
--- a/restart.c
+++ b/restart.c
@@ -43,10 +43,12 @@ struct pid_set {
/* (until it's supported by libc) from clone_ARCH.c */
#if defined(__NR_clone_with_pids) && defined(ARCH_HAS_CLONE_WITH_PID)
-extern int clone_with_pids(int (*fn)(void *), void *child_stack, int flags,
+extern int clone_with_pids(int (*fn)(void *), void *child_stack,
+ unsigned long stack_size, int flags,
struct pid_set *target_pids, void *arg);
#else
-static int clone_with_pids(int (*fn)(void *), void *child_stack, int flags,
+static int clone_with_pids(int (*fn)(void *), void *child_stack,
+ unsigned long stack_size, int flags,
struct pid_set *target_pids, void *arg)
{
return clone(fn, child_stack, flags, arg);
@@ -1749,18 +1751,17 @@ static pid_t ckpt_fork_child(struct ckpt_ctx *ctx, struct task *child)
{
struct pid_set pid_set;
char *stack_region;
- char *stack_start;
unsigned long flags = SIGCHLD;
+ unsigned long stack_size = PTHREAD_STACK_MIN;
pid_t pid = 0;
ckpt_dbg("forking child vpid %d flags %#x\n", child->pid, child->flags);
- stack_region = malloc(PTHREAD_STACK_MIN);
+ stack_region = malloc(stack_size);
if (!stack_region) {
perror("stack malloc");
return -1;
}
- stack_start = stack_region + PTHREAD_STACK_MIN - 1;
pid_set.pids = &pid;
pid_set.num_pids = 1;
@@ -1788,7 +1789,8 @@ static pid_t ckpt_fork_child(struct ckpt_ctx *ctx, struct task *child)
else
child->real_parent = _getpid();
- pid = clone_with_pids(ckpt_fork_stub, stack_start, flags, &pid_set, child);
+ pid = clone_with_pids(ckpt_fork_stub, stack_region, stack_size - 16,
+ flags, &pid_set, child);
if (pid < 0) {
perror("clone");
free(stack_region);
--
1.6.1.1
^ permalink raw reply related
* [PATCH 1/1] clean up audio/gateway.c
From: Gustavo F. Padovan @ 2009-11-10 16:58 UTC (permalink / raw)
To: linux-bluetooth
remove all code related to the AT engine
---
audio/gateway.c | 760 +------------------------------------------------------
1 files changed, 1 insertions(+), 759 deletions(-)
diff --git a/audio/gateway.c b/audio/gateway.c
index 984bc42..401977e 100644
--- a/audio/gateway.c
+++ b/audio/gateway.c
@@ -53,52 +53,6 @@
#include "dbus-common.h"
#define RFCOMM_BUF_SIZE 256
-/* not-more-then-16 defined by GSM + 1 for NULL + padding */
-#define AG_INDICATOR_DESCR_SIZE 20
-#define AG_CALLER_NUM_SIZE 64 /* size of number + type */
-
-/* commands */
-#define AG_FEATURES "AT+BRSF=26\r" /* = 0x7F = All features supported */
-#define AG_INDICATORS_SUPP "AT+CIND=?\r"
-#define AG_INDICATORS_VAL "AT+CIND?\r"
-#define AG_INDICATORS_ENABLE "AT+CMER=3,0,0,1\r"
-#define AG_HOLD_MPTY_SUPP "AT+CHLD=?\r"
-#define AG_CALLER_IDENT_ENABLE "AT+CLIP=1\r"
-#define AG_CARRIER_FORMAT "AT+COPS=3,0\r"
-#define AG_EXTENDED_RESULT_CODE "AT+CMEE=1\r"
-
-#define AG_FEATURE_3WAY 0x1
-#define AG_FEATURE_EXTENDED_RES_CODE 0x100
-/* Hold and multipary AG features.
- * Comments below are copied from hands-free spec for reference */
-/* Releases all held calls or sets User Determined User Busy (UDUB)
- * for a waiting call */
-#define AG_CHLD_0 0x01
-/* Releases all active calls (if any exist) and accepts the other
- * (held or waiting) call */
-#define AG_CHLD_1 0x02
-/* Releases specified active call only <x> */
-#define AG_CHLD_1x 0x04
-/* Places all active calls (if any exist) on hold and accepts the other
- * (held or waiting) call */
-#define AG_CHLD_2 0x08
-/* Request private consultation mode with specified call <x> (Place all
- * calls on hold EXCEPT the call <x>) */
-#define AG_CHLD_2x 0x10
-/* Adds a held call to the conversation */
-#define AG_CHLD_3 0x20
-/* Connects the two calls and disconnects the subscriber from both calls
- * (Explicit Call Transfer). Support for this value and its associated
- * functionality is optional for the HF. */
-#define AG_CHLD_4 0x40
-
-#define OK_RESPONSE "\r\nOK\r\n"
-#define ERROR_RESPONSE "\r\nERROR\r\n"
-
-struct indicator {
- gchar descr[AG_INDICATOR_DESCR_SIZE];
- gint value;
-};
struct gateway {
gateway_state_t state;
@@ -108,387 +62,10 @@ struct gateway {
gateway_stream_cb_t sco_start_cb;
void *sco_start_cb_data;
DBusMessage *connect_message;
- guint ag_features;
- guint hold_multiparty_features;
- GSList *indies;
- gboolean is_dialing;
- gboolean call_active;
-
- int sp_gain;
- int mic_gain;
};
-static gboolean rfcomm_ag_data_cb(GIOChannel *chan, GIOCondition cond,
- struct audio_device *device);
-
int gateway_close(struct audio_device *device);
-static void rfcomm_start_watch(struct audio_device *dev)
-{
- struct gateway *gw = dev->gateway;
-
- gw->rfcomm_watch_id = g_io_add_watch(gw->rfcomm,
- G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
- (GIOFunc) rfcomm_ag_data_cb, dev);
-}
-
-static void rfcomm_stop_watch(struct audio_device *dev)
-{
- struct gateway *gw = dev->gateway;
-
- g_source_remove(gw->rfcomm_watch_id);
-}
-
-static gboolean io_channel_write_all(GIOChannel *io, gchar *data,
- gsize count)
-{
- gsize written = 0;
- GIOStatus status;
-
- while (count > 0) {
- status = g_io_channel_write_chars(io, data, count, &written,
- NULL);
- if (status != G_IO_STATUS_NORMAL)
- return FALSE;
-
- data += written;
- count -= written;
- }
- return TRUE;
-}
-
-/* it's worth to mention that data and response could be the same pointers */
-static gboolean rfcomm_send_and_read(struct gateway *gw, gchar *data,
- gchar *response, gsize count)
-{
- GIOChannel *rfcomm = gw->rfcomm;
- gsize read = 0;
- gboolean got_ok = FALSE;
- gboolean got_error = FALSE;
- gchar *resp_buf = response;
- gsize toread = RFCOMM_BUF_SIZE - 1;
- GIOStatus status;
-
- if (!io_channel_write_all(rfcomm, data, count))
- return FALSE;
-
- while (!(got_ok || got_error)) {
- status = g_io_channel_read_chars(rfcomm, resp_buf, toread,
- &read, NULL);
- if (status == G_IO_STATUS_NORMAL)
- resp_buf[read] = '\0';
- else {
- debug("rfcomm_send_and_read(): %m");
- return FALSE;
- }
- got_ok = NULL != strstr(resp_buf, OK_RESPONSE);
- got_error = NULL != strstr(resp_buf, ERROR_RESPONSE);
- resp_buf += read;
- toread -= read;
- }
- return TRUE;
-}
-
-/* get <descr> from the names: (<descr>, (<values>)), (<descr>, (<values>))
- * ... */
-static GSList *parse_indicator_names(gchar *names, GSList *indies)
-{
- gchar *current = names - 1;
- GSList *result = indies;
- gchar *next;
- struct indicator *ind;
-
- while (current != NULL) {
- current += 2;
- next = strstr(current, ",(");
- ind = g_slice_new(struct indicator);
- strncpy(ind->descr, current, 20);
- ind->descr[(intptr_t) next - (intptr_t) current] = '\0';
- result = g_slist_append(result, (gpointer) ind);
- current = strstr(next + 1, ",(");
- }
- return result;
-}
-
-/* get values from <val0>,<val1>,... */
-static GSList *parse_indicator_values(gchar *values, GSList *indies)
-{
- gint val;
- gchar *current = values - 1;
- GSList *runner = indies;
- struct indicator *ind;
-
- while (current != NULL) {
- current += 1;
- sscanf(current, "%d", &val);
- current = strchr(current, ',');
- ind = g_slist_nth_data(runner, 0);
- ind->value = val;
- runner = g_slist_next(runner);
- }
- return indies;
-}
-
-/* get values from <val0>,<val1>,... */
-static guint get_hold_mpty_features(gchar *features)
-{
- guint result = 0;
-
- if (strstr(features, "0"))
- result |= AG_CHLD_0;
-
- if (strstr(features, "1"))
- result |= AG_CHLD_1;
-
- if (strstr(features, "1x"))
- result |= AG_CHLD_1x;
-
- if (strstr(features, "2"))
- result |= AG_CHLD_2;
-
- if (strstr(features, "2x"))
- result |= AG_CHLD_2x;
-
- if (strstr(features, "3"))
- result |= AG_CHLD_3;
-
- if (strstr(features, "4"))
- result |= AG_CHLD_4;
-
- return result;
-}
-
-static gboolean establish_service_level_conn(struct gateway *gw)
-{
- gchar buf[RFCOMM_BUF_SIZE];
- gboolean res;
-
- debug("at the begin of establish_service_level_conn()");
- res = rfcomm_send_and_read(gw, AG_FEATURES, buf,
- sizeof(AG_FEATURES) - 1);
- if (!res || sscanf(buf, "\r\n+BRSF:%d", &gw->ag_features) != 1)
- return FALSE;
-
- debug("features are 0x%X", gw->ag_features);
- res = rfcomm_send_and_read(gw, AG_INDICATORS_SUPP, buf,
- sizeof(AG_INDICATORS_SUPP) - 1);
- if (!res || !strstr(buf, "+CIND:"))
- return FALSE;
-
- gw->indies = parse_indicator_names(strchr(buf, '('), NULL);
-
- res = rfcomm_send_and_read(gw, AG_INDICATORS_VAL, buf,
- sizeof(AG_INDICATORS_VAL) - 1);
- if (!res || !strstr(buf, "+CIND:"))
- return FALSE;
-
- gw->indies = parse_indicator_values(strchr(buf, ':') + 1, gw->indies);
-
- res = rfcomm_send_and_read(gw, AG_INDICATORS_ENABLE, buf,
- sizeof(AG_INDICATORS_ENABLE) - 1);
- if (!res || !strstr(buf, "OK"))
- return FALSE;
-
- if ((gw->ag_features & AG_FEATURE_3WAY) != 0) {
- res = rfcomm_send_and_read(gw, AG_HOLD_MPTY_SUPP, buf,
- sizeof(AG_HOLD_MPTY_SUPP) - 1);
- if (!res || !strstr(buf, "+CHLD:")) {
- g_slice_free1(RFCOMM_BUF_SIZE, buf);
- return FALSE;
- }
- gw->hold_multiparty_features = get_hold_mpty_features(
- strchr(buf, '('));
-
- } else
- gw->hold_multiparty_features = 0;
-
- debug("Service layer connection successfully established!");
- rfcomm_send_and_read(gw, AG_CALLER_IDENT_ENABLE, buf,
- sizeof(AG_CALLER_IDENT_ENABLE) - 1);
- rfcomm_send_and_read(gw, AG_CARRIER_FORMAT, buf,
- sizeof(AG_CARRIER_FORMAT) - 1);
- if ((gw->ag_features & AG_FEATURE_EXTENDED_RES_CODE) != 0)
- rfcomm_send_and_read(gw, AG_EXTENDED_RESULT_CODE, buf,
- sizeof(AG_EXTENDED_RESULT_CODE) - 1);
-
- return TRUE;
-}
-
-static void process_ind_change(struct audio_device *dev, guint index,
- gint value)
-{
- struct gateway *gw = dev->gateway;
- struct indicator *ind = g_slist_nth_data(gw->indies, index - 1);
- gchar *name = ind->descr;
-
- ind->value = value;
-
- debug("at the begin of process_ind_change, name is %s", name);
- if (!strcmp(name, "\"call\"")) {
- if (value > 0) {
- g_dbus_emit_signal(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE,
- "CallStarted", DBUS_TYPE_INVALID);
- gw->is_dialing = FALSE;
- gw->call_active = TRUE;
- } else {
- g_dbus_emit_signal(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE,
- "CallEnded", DBUS_TYPE_INVALID);
- gw->call_active = FALSE;
- }
-
- } else if (!strcmp(name, "\"callsetup\"")) {
- if (value == 0 && gw->is_dialing) {
- g_dbus_emit_signal(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE,
- "CallTerminated",
- DBUS_TYPE_INVALID);
- gw->is_dialing = FALSE;
- } else if (!gw->is_dialing && value > 0)
- gw->is_dialing = TRUE;
-
- } else if (!strcmp(name, "\"callheld\"")) {
- /* FIXME: The following code is based on assumptions only.
- * Has to be tested for interoperability
- * I assume that callheld=2 would be sent when dial from HF
- * failed in case of 3-way call
- * Unfortunately this path is not covered by the HF spec so
- * the code has to be tested for interop
- */
- /* '2' means: all calls held, no active calls */
- if (value == 2) {
- if (gw->is_dialing) {
- g_dbus_emit_signal(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE,
- "CallTerminated",
- DBUS_TYPE_INVALID);
- gw->is_dialing = FALSE;
- }
- }
- } else if (!strcmp(name, "\"service\""))
- emit_property_changed(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE, "RegistrationStatus",
- DBUS_TYPE_UINT16, &value);
- else if (!strcmp(name, "\"signal\""))
- emit_property_changed(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE, "SignalStrength",
- DBUS_TYPE_UINT16, &value);
- else if (!strcmp(name, "\"roam\""))
- emit_property_changed(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE, "RoamingStatus",
- DBUS_TYPE_UINT16, &value);
- else if (!strcmp(name, "\"battchg\""))
- emit_property_changed(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE, "BatteryCharge",
- DBUS_TYPE_UINT16, &value);
-}
-
-static void process_ring(struct audio_device *device, GIOChannel *chan,
- gchar *buf)
-{
- gchar number[AG_CALLER_NUM_SIZE];
- gchar *cli;
- gchar *sep;
- gsize read;
- GIOStatus status;
-
- rfcomm_stop_watch(device);
- status = g_io_channel_read_chars(chan, buf, RFCOMM_BUF_SIZE - 1, &read, NULL);
- if (status != G_IO_STATUS_NORMAL)
- return;
-
- debug("at the begin of process_ring");
- if (strlen(buf) > AG_CALLER_NUM_SIZE + 10)
- error("process_ring(): buf is too long '%s'", buf);
- else if ((cli = strstr(buf, "\r\n+CLIP"))) {
- if (sscanf(cli, "\r\n+CLIP: \"%s", number) == 1) {
- sep = strchr(number, '"');
- sep[0] = '\0';
-
- /* FIXME:signal will be emitted on each RING+CLIP.
- * That's bad */
- cli = number;
- g_dbus_emit_signal(device->conn, device->path,
- AUDIO_GATEWAY_INTERFACE, "Ring",
- DBUS_TYPE_STRING, &cli,
- DBUS_TYPE_INVALID);
- device->gateway->is_dialing = TRUE;
- } else
- error("process_ring(): '%s' in place of +CLIP after RING", buf);
-
- }
-
- rfcomm_start_watch(device);
-}
-
-static gboolean rfcomm_ag_data_cb(GIOChannel *chan, GIOCondition cond,
- struct audio_device *device)
-{
- gchar buf[RFCOMM_BUF_SIZE];
- struct gateway *gw;
- gsize read;
- /* some space for value */
- gchar indicator[AG_INDICATOR_DESCR_SIZE + 4];
- gint value;
- guint index;
- gchar *sep;
-
- debug("at the begin of rfcomm_ag_data_cb()");
- if (cond & G_IO_NVAL)
- return FALSE;
-
- gw = device->gateway;
-
- if (cond & (G_IO_ERR | G_IO_HUP)) {
- debug("connection with remote BT is closed");
- gateway_close(device);
- return FALSE;
- }
-
- if (g_io_channel_read_chars(chan, buf, sizeof(buf) - 1, &read, NULL)
- != G_IO_STATUS_NORMAL)
- return TRUE;
- buf[read] = '\0';
-
- if (strlen(buf) > AG_INDICATOR_DESCR_SIZE + 14)
- error("rfcomm_ag_data_cb(): buf is too long '%s'", buf);
- else if (sscanf(buf, "\r\n+CIEV:%s\r\n", indicator) == 1) {
- sep = strchr(indicator, ',');
- sep[0] = '\0';
- sep += 1;
- index = atoi(indicator);
- value = atoi(sep);
- process_ind_change(device, index, value);
- } else if (strstr(buf, "RING"))
- process_ring(device, chan, buf);
- else if (sscanf(buf, "\r\n+BVRA:%d\r\n", &value) == 1) {
- if (value == 0)
- g_dbus_emit_signal(device->conn, device->path,
- AUDIO_GATEWAY_INTERFACE,
- "VoiceRecognitionActive",
- DBUS_TYPE_INVALID);
- else
- g_dbus_emit_signal(device->conn, device->path,
- AUDIO_GATEWAY_INTERFACE,
- "VoiceRecognitionInactive",
- DBUS_TYPE_INVALID);
- } else if (sscanf(buf, "\r\n+VGS:%d\r\n", &value) == 1) {
- gw->sp_gain = value;
- emit_property_changed(device->conn, device->path,
- AUDIO_GATEWAY_INTERFACE, "SpeakerGain",
- DBUS_TYPE_UINT16, &value);
- } else if (sscanf(buf, "\r\n+VGM:%d\r\n", &value) == 1) {
- gw->mic_gain = value;
- emit_property_changed(device->conn, device->path,
- AUDIO_GATEWAY_INTERFACE, "MicrophoneGain",
- DBUS_TYPE_UINT16, &value);
- } else
- error("rfcomm_ag_data_cb(): read wrong data '%s'", buf);
-
- return TRUE;
-}
-
static gboolean sco_io_cb(GIOChannel *chan, GIOCondition cond,
struct audio_device *dev)
{
@@ -541,7 +118,6 @@ static void rfcomm_connect_cb(GIOChannel *chan, GError *err,
{
struct audio_device *dev = user_data;
struct gateway *gw = dev->gateway;
- DBusMessage *conn_mes = gw->connect_message;
gchar gw_addr[18];
GIOFlags flags;
@@ -563,29 +139,6 @@ static void rfcomm_connect_cb(GIOChannel *chan, GError *err,
if (!gw->rfcomm)
gw->rfcomm = g_io_channel_ref(chan);
- if (establish_service_level_conn(dev->gateway)) {
- gboolean value = TRUE;
-
- debug("%s: Connected to %s", dev->path, gw_addr);
- rfcomm_start_watch(dev);
- if (conn_mes) {
- DBusMessage *reply =
- dbus_message_new_method_return(conn_mes);
- dbus_connection_send(dev->conn, reply, NULL);
- dbus_message_unref(reply);
- dbus_message_unref(conn_mes);
- gw->connect_message = NULL;
- }
-
- gw->state = GATEWAY_STATE_CONNECTED;
- emit_property_changed(dev->conn, dev->path,
- AUDIO_GATEWAY_INTERFACE,
- "Connected", DBUS_TYPE_BOOLEAN, &value);
- return;
- } else
- error("%s: Failed to establish service layer connection to %s",
- dev->path, gw_addr);
-
if (NULL != gw->sco_start_cb)
gw->sco_start_cb(NULL, gw->sco_start_cb_data);
@@ -732,321 +285,20 @@ static DBusMessage *ag_disconnect(DBusConnection *conn, DBusMessage *msg,
return reply;
}
-static DBusMessage *process_ag_reponse(DBusMessage *msg, gchar *response)
-{
- DBusMessage *reply;
-
-
- debug("in process_ag_reponse, response is %s", response);
- if (strstr(response, OK_RESPONSE))
- reply = dbus_message_new_method_return(msg);
- else {
- /* FIXME: some code should be here to processes errors
- * in better fasion */
- debug("AG responded with '%s' to %s method call", response,
- dbus_message_get_member(msg));
- reply = dbus_message_new_error(msg, ERROR_INTERFACE
- ".OperationFailed",
- "Operation failed.See log for details");
- }
- return reply;
-}
-
-static DBusMessage *process_simple(DBusMessage *msg, struct audio_device *dev,
- gchar *data)
-{
- struct gateway *gw = dev->gateway;
- gchar buf[RFCOMM_BUF_SIZE];
-
- rfcomm_stop_watch(dev);
- rfcomm_send_and_read(gw, data, buf, strlen(data));
- rfcomm_start_watch(dev);
- return process_ag_reponse(msg, buf);
-}
-
-#define AG_ANSWER "ATA\r"
-
-static DBusMessage *ag_answer(DBusConnection *conn, DBusMessage *msg,
- void *data)
-{
- struct audio_device *dev = data;
- struct gateway *gw = dev->gateway;
-
- if (!gw->rfcomm)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".NotConnected",
- "Not Connected");
-
- if (gw->call_active)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".CallAlreadyAnswered",
- "Call AlreadyAnswered");
-
- return process_simple(msg, dev, AG_ANSWER);
-}
-
-#define AG_HANGUP "AT+CHUP\r"
-
-static DBusMessage *ag_terminate_call(DBusConnection *conn, DBusMessage *msg,
- void *data)
-{
- struct audio_device *dev = data;
- struct gateway *gw = dev->gateway;
-
- if (!gw->rfcomm)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".NotConnected",
- "Not Connected");
-
- return process_simple(msg, dev, AG_HANGUP);
-}
-
-/* according to GSM spec */
-#define ALLOWED_NUMBER_SYMBOLS "1234567890*#ABCD"
-#define AG_PLACE_CALL "ATD%s;\r"
-/* dialing from memory is not supported as headset spec doesn't define a way
- * to retreive phone memory entries.
- */
-static DBusMessage *ag_call(DBusConnection *conn, DBusMessage *msg,
- void *data)
-{
- struct audio_device *device = data;
- struct gateway *gw = device->gateway;
- gchar buf[RFCOMM_BUF_SIZE];
- gchar *number;
- gint atd_len;
- DBusMessage *result;
-
- debug("at the begin of ag_call()");
- if (!gw->rfcomm)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".NotConnected",
- "Not Connected");
-
- dbus_message_get_args(msg, NULL, DBUS_TYPE_STRING, &number,
- DBUS_TYPE_INVALID);
- if (strlen(number) != strspn(number, ALLOWED_NUMBER_SYMBOLS))
- return dbus_message_new_error(msg,
- ERROR_INTERFACE ".BadNumber",
- "Number contains characters which are not allowed");
-
- atd_len = sprintf(buf, AG_PLACE_CALL, number);
- rfcomm_stop_watch(device);
- rfcomm_send_and_read(gw, buf, buf, atd_len);
- rfcomm_start_watch(device);
-
- result = process_ag_reponse(msg, buf);
- return result;
-}
-
-#define AG_GET_CARRIER "AT+COPS?\r"
-
-static DBusMessage *ag_get_operator(DBusConnection *conn, DBusMessage *msg,
- void *data)
-{
- struct audio_device *dev = (struct audio_device *) data;
- struct gateway *gw = dev->gateway;
- gchar buf[RFCOMM_BUF_SIZE];
- GIOChannel *rfcomm = gw->rfcomm;
- gsize read;
- gchar *result, *sep;
- DBusMessage *reply;
- GIOStatus status;
-
- if (!gw->rfcomm)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".NotConnected",
- "Not Connected");
-
- rfcomm_stop_watch(dev);
- io_channel_write_all(rfcomm, AG_GET_CARRIER, strlen(AG_GET_CARRIER));
-
- status = g_io_channel_read_chars(rfcomm, buf, RFCOMM_BUF_SIZE - 1,
- &read, NULL);
- rfcomm_start_watch(dev);
- if (G_IO_STATUS_NORMAL == status) {
- buf[read] = '\0';
- if (strstr(buf, "+COPS")) {
- if (!strrchr(buf, ','))
- result = "0";
- else {
- result = strchr(buf, '\"') + 1;
- sep = strchr(result, '\"');
- sep[0] = '\0';
- }
-
- reply = dbus_message_new_method_return(msg);
- dbus_message_append_args(reply, DBUS_TYPE_STRING,
- &result, DBUS_TYPE_INVALID);
- } else {
- info("ag_get_operator(): '+COPS' expected but"
- " '%s' received", buf);
- reply = dbus_message_new_error(msg, ERROR_INTERFACE
- ".Failed",
- "Unexpected response from AG");
- }
- } else {
- error("ag_get_operator(): %m");
- reply = dbus_message_new_error(msg, ERROR_INTERFACE
- ".ConnectionFailed",
- "Failed to receive response from AG");
- }
-
- return reply;
-}
-
-#define AG_SEND_DTMF "AT+VTS=%c\r"
-static DBusMessage *ag_send_dtmf(DBusConnection *conn, DBusMessage *msg,
- void *data)
-{
- struct audio_device *device = data;
- struct gateway *gw = device->gateway;
- gchar buf[RFCOMM_BUF_SIZE];
- gchar *number;
- gint com_len;
- gboolean got_ok = TRUE;
- gint num_len;
- gint i = 0;
-
- if (!gw->rfcomm)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".NotConnected",
- "Not Connected");
-
- dbus_message_get_args(msg, NULL, DBUS_TYPE_STRING, &number,
- DBUS_TYPE_INVALID);
- if (strlen(number) != strspn(number, ALLOWED_NUMBER_SYMBOLS))
- return dbus_message_new_error(msg,
- ERROR_INTERFACE ".BadNumber",
- "Number contains characters which are not allowed");
-
- num_len = strlen(number);
- rfcomm_stop_watch(device);
- while (i < num_len && got_ok) {
- com_len = sprintf(buf, AG_SEND_DTMF, number[i]);
- rfcomm_send_and_read(gw, buf, buf, com_len);
- got_ok = NULL != strstr(buf, OK_RESPONSE);
- i += 1;
- }
- rfcomm_start_watch(device);
- return process_ag_reponse(msg, buf);
-}
-
-#define AG_GET_SUBSCRIBER_NUMS "AT+CNUM\r"
-#define CNUM_LEN 5 /* length of "+CNUM" string */
-#define MAX_NUMBER_CNT 16
-static DBusMessage *ag_get_subscriber_num(DBusConnection *conn,
- DBusMessage *msg, void *data)
-{
- struct audio_device *device = data;
- struct gateway *gw = device->gateway;
- gchar buf[RFCOMM_BUF_SIZE];
- gchar *number, *end;
- DBusMessage *reply = dbus_message_new_method_return(msg);
-
- if (!gw->rfcomm)
- return g_dbus_create_error(msg, ERROR_INTERFACE
- ".NotConnected",
- "Not Connected");
-
- rfcomm_stop_watch(device);
- rfcomm_send_and_read(gw, AG_GET_SUBSCRIBER_NUMS, buf,
- strlen(AG_GET_SUBSCRIBER_NUMS));
- rfcomm_start_watch(device);
-
- if (strlen(buf) > AG_CALLER_NUM_SIZE + 21)
- error("ag_get_subscriber_num(): buf is too long '%s'", buf);
- else if (strstr(buf, "+CNUM")) {
- number = strchr(buf, ',');
- number++;
- end = strchr(number, ',');
- if (end) {
- *end = '\0';
- dbus_message_append_args(reply, DBUS_TYPE_STRING,
- &number, DBUS_TYPE_INVALID);
- }
- } else
- error("ag_get_subscriber_num(): read wrong data '%s'", buf);
-
- return reply;
-}
-
static DBusMessage *ag_get_properties(DBusConnection *conn, DBusMessage *msg,
void *data)
{
- struct audio_device *device = data;
- struct gateway *gw = device->gateway;
- DBusMessage *reply;
- DBusMessageIter iter;
- DBusMessageIter dict;
- gboolean value;
- guint index = 0;
- struct indicator *ind;
-
- reply = dbus_message_new_method_return(msg);
- if (!reply)
- return NULL;
-
- dbus_message_iter_init_append(reply, &iter);
-
- dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
- DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
- DBUS_TYPE_STRING_AS_STRING DBUS_TYPE_VARIANT_AS_STRING
- DBUS_DICT_ENTRY_END_CHAR_AS_STRING, &dict);
-
- /* Connected */
- value = gateway_is_connected(device);
- dict_append_entry(&dict, "Connected", DBUS_TYPE_BOOLEAN, &value);
-
- if (!value)
- goto done;
-
- while ((ind = g_slist_nth_data(gw->indies, index))) {
- if(!strcmp(ind->descr, "\"service\""))
- dict_append_entry(&dict, "RegistrationStatus",
- DBUS_TYPE_UINT16, &ind->value);
- else if (!strcmp(ind->descr, "\"signal\""))
- dict_append_entry(&dict, "SignalStrength",
- DBUS_TYPE_UINT16, &ind->value);
- else if (!strcmp(ind->descr, "\"roam\""))
- dict_append_entry(&dict, "RoamingStatus",
- DBUS_TYPE_UINT16, &ind->value);
- else if (!strcmp(ind->descr, "\"battchg\""))
- dict_append_entry(&dict, "BatteryCharge",
- DBUS_TYPE_UINT16, &ind->value);
- index++;
- }
-
- /* SpeakerGain */
- dict_append_entry(&dict, "SpeakerGain", DBUS_TYPE_UINT16,
- &device->gateway->sp_gain);
-
- /* MicrophoneGain */
- dict_append_entry(&dict, "MicrophoneGain", DBUS_TYPE_UINT16,
- &device->gateway->mic_gain);
-done:
- dbus_message_iter_close_container(&iter, &dict);
- return reply;
+ return NULL;
}
static GDBusMethodTable gateway_methods[] = {
{ "Connect", "", "", ag_connect, G_DBUS_METHOD_FLAG_ASYNC },
{ "Disconnect", "", "", ag_disconnect },
- { "AnswerCall", "", "", ag_answer },
- { "TerminateCall", "", "", ag_terminate_call },
- { "Call", "s", "", ag_call },
- { "GetOperatorName", "", "s", ag_get_operator },
- { "SendDTMF", "s", "", ag_send_dtmf },
- { "GetSubscriberNumber", "", "s", ag_get_subscriber_num },
{ "GetProperties", "", "a{sv}", ag_get_properties },
{ NULL, NULL, NULL, NULL }
};
static GDBusSignalTable gateway_signals[] = {
- { "Ring", "s" },
- { "CallTerminated", "" },
- { "CallStarted", "" },
- { "CallEnded", "" },
{ "PropertyChanged", "sv" },
{ NULL, NULL }
};
@@ -1063,9 +315,6 @@ struct gateway *gateway_init(struct audio_device *dev)
debug("in gateway_init, dev is %p", dev);
gw = g_new0(struct gateway, 1);
- gw->indies = NULL;
- gw->is_dialing = FALSE;
- gw->call_active = FALSE;
gw->state = GATEWAY_STATE_DISCONNECTED;
return gw;
@@ -1107,11 +356,6 @@ void gateway_start_service(struct audio_device *device)
rfcomm_connect_cb(device->gateway->rfcomm, NULL, device);
}
-static void indicator_slice_free(gpointer mem)
-{
- g_slice_free(struct indicator, mem);
-}
-
int gateway_close(struct audio_device *device)
{
struct gateway *gw = device->gateway;
@@ -1119,8 +363,6 @@ int gateway_close(struct audio_device *device)
GIOChannel *sco = gw->sco;
gboolean value = FALSE;
- g_slist_foreach(gw->indies, (GFunc) indicator_slice_free, NULL);
- g_slist_free(gw->indies);
if (rfcomm) {
g_io_channel_shutdown(rfcomm, TRUE, NULL);
g_io_channel_unref(rfcomm);
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH v4] [x86] detect and report lack of NX protections
From: Kees Cook @ 2009-11-10 16:57 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Arjan van de Ven, Thomas Gleixner, Ingo Molnar, x86, Pekka Enberg,
Jan Beulich, Vegard Nossum, Yinghai Lu, Jeremy Fitzhardinge,
linux-kernel
In-Reply-To: <4AF9991B.20400@zytor.com>
On Tue, Nov 10, 2009 at 08:47:23AM -0800, H. Peter Anvin wrote:
> On 11/10/2009 07:49 AM, Kees Cook wrote:
> >>
> >> The second clause can only get executed if CONFIG_X86_PAE is unset,
> >> which in turn means _PAGE_NX == 0... so that piece of code is meaningless.
> >
> > CONFIG_X86_PAE is unset for x86_64, where _PAGE_NX is valid. (This was
> > the main situation I was trying to address.) So that chunk runs for
> > non-pae 32bit, and all 64bit:
> >
>
> In reality, X86_PAE really should have been defined for 64 bits, since
> 64 bits really is PAE in most aspects.
>
> Anyway, for the 64-bit case it looks like the proper place for any of
> this is in check_efer() just below, not in this null routine.
64-bit does not set nx_enabled to "1" by default anywhere. And setting
the default to 1 in check_efer() seemed out of place to me.
-Kees
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply
* [ath9k-devel] AR922X in Netgear WNDR3700 (and Linksys WRT400N)
From: Porsch, Marco @ 2009-11-10 16:58 UTC (permalink / raw)
To: ath9k-devel
Hello list,
upon loading the ath9k module on the device, the system completely stalls and reboots with following output:
root at OpenWrt:/# modprobe ath9k debug=0xffffffff
ath9k 0000:00:11.0: failed to initialize device
ath9k: probe of 0000:00:11.0 failed with error -22
ath9k 0000:00:12.0: failed to initialize device
ath9k: probe of 0000:00:12.0 failed with error -22
Since it is running as a ramdisk image i cannot get any debug outputs after reboot.
Hardware is 2.4GHz/5GHz AR9220 and 2.4GHz AR9223 radios (according to http://www.smallnetbuilder.com/content/view/30913/96/) and Atheros 9280 MAC (according to stock firmware).
This is the related thread at the openWrt forum: https://forum.openwrt.org/viewtopic.php?id=22311
Since this router is router is not fully supported by openWrt it _may_ be possible there is a problem with the PCI bus. Could i check this somehow?
Driver is from compat wireless 2009-08-20.
More info:
root at OpenWrt:/# uname -a
Linux OpenWrt 2.6.30.9 #60 Tue Nov 10 17:09:22 CET 2009 mips GNU/Linux
root at OpenWrt:/# lspci -n
00:00.0 0000: 0700:1107 (rev 01)
00:11.0 0280: 168c:0029 (rev 01)
00:12.0 0280: 168c:0029 (rev 01)
root at OpenWrt:/# lspci -vvv
00:11.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01)
Subsystem: Atheros Communications Inc. Device a095
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 48
Region 0: Memory@10000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=100mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:12.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01)
Subsystem: Atheros Communications Inc. Device a094
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 49
Region 0: Memory@10010000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=100mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Regards
Marco
^ permalink raw reply
* [PATCH] prevent deadlock in __unmap_hugepage_range() when alloc_huge_page() fails.
From: Larry Woodman @ 2009-11-10 17:00 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
hugetlb_fault() takes the mm->page_table_lock spinlock then calls
hugetlb_cow(). If the alloc_huge_page() in hugetlb_cow() fails due to
an insufficient huge page pool it calls unmap_ref_private() with the
mm->page_table_lock held. unmap_ref_private() then calls
unmap_hugepage_range() which tries to acquire the mm->page_table_lock.
[<ffffffff810928c3>] print_circular_bug_tail+0x80/0x9f
[<ffffffff8109280b>] ? check_noncircular+0xb0/0xe8
[<ffffffff810935e0>] __lock_acquire+0x956/0xc0e
[<ffffffff81093986>] lock_acquire+0xee/0x12e
[<ffffffff8111a7a6>] ? unmap_hugepage_range+0x3e/0x84
[<ffffffff8111a7a6>] ? unmap_hugepage_range+0x3e/0x84
[<ffffffff814c348d>] _spin_lock+0x40/0x89
[<ffffffff8111a7a6>] ? unmap_hugepage_range+0x3e/0x84
[<ffffffff8111afee>] ? alloc_huge_page+0x218/0x318
[<ffffffff8111a7a6>] unmap_hugepage_range+0x3e/0x84
[<ffffffff8111b2d0>] hugetlb_cow+0x1e2/0x3f4
[<ffffffff8111b935>] ? hugetlb_fault+0x453/0x4f6
[<ffffffff8111b962>] hugetlb_fault+0x480/0x4f6
[<ffffffff8111baee>] follow_hugetlb_page+0x116/0x2d9
[<ffffffff814c31a7>] ? _spin_unlock_irq+0x3a/0x5c
[<ffffffff81107b4d>] __get_user_pages+0x2a3/0x427
[<ffffffff81107d0f>] get_user_pages+0x3e/0x54
[<ffffffff81040b8b>] get_user_pages_fast+0x170/0x1b5
[<ffffffff81160352>] dio_get_page+0x64/0x14a
[<ffffffff8116112a>] __blockdev_direct_IO+0x4b7/0xb31
[<ffffffff8115ef91>] blkdev_direct_IO+0x58/0x6e
[<ffffffff8115e0a4>] ? blkdev_get_blocks+0x0/0xb8
[<ffffffff810ed2c5>] generic_file_aio_read+0xdd/0x528
[<ffffffff81219da3>] ? avc_has_perm+0x66/0x8c
[<ffffffff81132842>] do_sync_read+0xf5/0x146
[<ffffffff8107da00>] ? autoremove_wake_function+0x0/0x5a
[<ffffffff81211857>] ? security_file_permission+0x24/0x3a
[<ffffffff81132fd8>] vfs_read+0xb5/0x126
[<ffffffff81133f6b>] ? fget_light+0x5e/0xf8
[<ffffffff81133131>] sys_read+0x54/0x8c
[<ffffffff81011e42>] system_call_fastpath+0x16/0x1b
This can be fixed by dropping the mm->page_table_lock around the call
to unmap_ref_private() if alloc_huge_page() fails, its dropped right below
in the normal path anyway:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5d7601b..f4daef4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1973,12 +1973,15 @@ retry_avoidcopy:
*/
if (outside_reserve) {
BUG_ON(huge_pte_none(pte));
+ spin_unlock(&mm->page_table_lock);
if (unmap_ref_private(mm, vma, old_page, address)) {
+ spin_lock(&mm->page_table_lock);
BUG_ON(page_count(old_page) != 1);
BUG_ON(huge_pte_none(pte));
goto retry_avoidcopy;
}
WARN_ON_ONCE(1);
+ spin_lock(&mm->page_table_lock);
}
return -PTR_ERR(new_page);
Signed-off-by: Larry Woodman <lwooman@redhat.com>
[-- Attachment #2: hugetlb_cow.diff --]
[-- Type: text/x-patch, Size: 550 bytes --]
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5d7601b..f4daef4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1973,12 +1973,15 @@ retry_avoidcopy:
*/
if (outside_reserve) {
BUG_ON(huge_pte_none(pte));
+ spin_unlock(&mm->page_table_lock);
if (unmap_ref_private(mm, vma, old_page, address)) {
+ spin_lock(&mm->page_table_lock);
BUG_ON(page_count(old_page) != 1);
BUG_ON(huge_pte_none(pte));
goto retry_avoidcopy;
}
WARN_ON_ONCE(1);
+ spin_lock(&mm->page_table_lock);
}
return -PTR_ERR(new_page);
^ permalink raw reply related
* Bitbake 1.8.18 released!
From: Richard Purdie @ 2009-11-10 16:52 UTC (permalink / raw)
To: bitbake-dev; +Cc: openembedded-devel
Bitbake 1.8.18 has been released.
Some fixes have emerged that are important enough to warrant another
release including some issues with the last release not allowing all the
improvements OE wished to make to its core.
This release can be downloaded at:
http://prdownload.berlios.de/bitbake/bitbake-1.8.18.tar.gz
Changes since the last release:
Chris Conroy (1):
providers.py: Fix package sorting order to reflect priorities
Denys Dmytriyenko (1):
utils.py: add special handling for version delimiters
Richard Purdie (6):
Increment version post release
git.py: Search mirrors for tarballs before fetching, not just local directories
fetch/__init__.py: Fix a bug where errors could corrupt bitbake internal state wrt SRCREVINACTION (from Poky)
fetch/__init__.py: Allow SRC_URI to be overridden in fetcher go() function
BBHandler.py: Backport anonymous function handling improvements from 1.10 branch
Release 1.8.18
^ permalink raw reply
* Bitbake 1.8.16 released!
From: Richard Purdie @ 2009-11-10 16:52 UTC (permalink / raw)
To: bitbake-dev; +Cc: openembedded-devel
Bitbake 1.8.16 has been released.
This is the same as the 1.8.14 release with a typo made during the
release process fixed. Sorry about the noise
^ permalink raw reply
* OEDEM 2009 summary: Death to checksums.ini?
From: Phil Blundell @ 2009-11-10 16:55 UTC (permalink / raw)
To: openembedded-devel
The current checksums.ini arrangement has a number of issues:
- single monolithic file is a rich source of merge conflicts
- concrete URIs require many duplicate entries for different mirrors
- can be annoying for folks using overlays and/or collections
- storing the checksum separately from the rest of the .bb file makes
cherry-picking harder than it needs to be
- large amount of churn in checksums.ini can make it hard to spot cases
where checksums were changed rather than just added.
It was proposed that, rather than storing checksums centrally in
checksums.ini, they should be placed in the individual .bb file to which
the checksum relates. Bitbake already has a certain level of support
for reading checksums from SRC_URI and it would seem natural to try to
make use of that.
There was some discussion around alternative proposals of storing the
checksums in separate files within the recipes/ directory. These
proposals didn't seem to offer any real advantage over storing the
checksums within the .bb file (and, importantly, didn't really solve the
issues around recipe copying/merging) so they were not pursued further.
Some concerns were raised around .inc files and other places where
multiple recipes shared a single definition of SRC_URI, but it seems
like these can all be addressed with strategic use of variable
substitutions.
Also, some concerns were raised over the disk space impact of the
lengthened SRC_URIs. However, the net increase in disk space usage
seems like it will be marginal at worst: many packages will actually
wind up using less space with the new arrangement.
There was a side discussion around providing a separate mechanism for a
site-local cache of checksums, to be used solely for verifying that a
particular source archive has not changed from one build to the next.
This cache would not be checked in anywhere or distributed. RP noted
that this was the original intent of checksums.ini. Agreed to park this
for now since it is independent of (though somewhat related to) the
topic of shared checksums.
Conclusions:
- checksums are clearly part of the metadata, it seems like they
naturally belong in the .bb file.
- there was general acceptance that the checksums belong in SRC_URI.
Next steps:
- figure out a way to implement sha256sum checking, either by extending
the code in bitbake's fetcher or by providing equivalent functionality
in base.bbclass
- work out a migration strategy: is it feasible to splice the existing
checksums into the SRC_URIs programmatically? RP thinks yes. PB
suggests leaving the existing checksums.ini as read-only and switching
to checksums incrementally for new packages. RP: can make a git hook to
allow deletion from checksums.ini but no other changes.
^ permalink raw reply
* Re: pci 0000:01:04.0: BAR 0: no parent found for of device
From: Domenico Andreoli @ 2009-11-10 16:56 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-parisc, Matthew Wilcox, John David Anglin
In-Reply-To: <4AF099F7.10903@gmx.de>
On Tue, Nov 03, 2009 at 10:00:39PM +0100, Helge Deller wrote:
> Hi all,
hi,
> Something broke the stifb graphics driver in 2.6.32-rc5 (Linus' current head).
mine was a PCI controller for additional USB ports or maybe the MGA
graphic controller, i don't rememer. i will check ;)
> Somehow it seems, that the PCI subsystem does not activate this PCI slot:
>
> Linux version 2.6.32-rc5-32bit (deller@p100) (gcc version 4.4.1 (GCC) ) #157 Tue Nov 3 21:49:24 CET 2009
> ...
> Searching for devices...
> Found devices:
> 1. Astro BC Runway Port at 0xfed00000 [10] { 12, 0x0, 0x582, 0x0000b }
> 2. Elroy PCI Bridge at 0xfed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
> 3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
> 4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
> 5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
> 6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
> 7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
> CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
> Setting cache flush threshold to 780 (1 CPUs online)
> SBA found Astro 2.1 at 0xfed00000
> Elroy version TR4.0 (0x5) found at 0xfed30000
> PCI: Enabled native mode for NS87415 (pif=0x8f)
> Elroy version TR4.0 (0x5) found at 0xfed32000
> pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff]
> ^^^ HERE
i had a couple of these messages and also a couple of BAR collisions
on my J5600, recently booted with 2.6.32-rc6.
these threads seem related:
http://lkml.org/lkml/2009/8/2/82
http://lkml.org/lkml/2009/11/9/356
i will try to learn something new later, when I turn on my hppa box later.
cheers,
Domenic
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: vlan/macvlan 02/02: propagate transmission state to upper layers
From: Patrick McHardy @ 2009-11-10 16:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <20091110084814.02593603@nehalam>
Stephen Hemminger wrote:
> On Tue, 10 Nov 2009 17:14:24 +0100
> Patrick McHardy <kaber@trash.net> wrote:
>
>> vlan/macvlan: propagate transmission state to upper layers
>>
>> Both vlan and macvlan devices usually don't use a qdisc and immediately
>> queue packets to the underlying device. Propagate transmission state of
>> the underlying device to the upper layers so they can react on congestion
>> and/or inform the sending process.
>>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
>
> Bridging and bonding have same issue, but the solution is more difficult.
Yes, in both cases the packet might be sent out on multiple
interfaces, so its not really clear which state we should
propagate. I guess it would make sense to indicate an error
if transmission on *all* interfaces fail, but I'm not sure
about the other cases.
^ permalink raw reply
* [PATCH v5] [x86] detect and report lack of NX protections
From: Kees Cook @ 2009-11-10 16:55 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Pekka Enberg,
Jan Beulich, Vegard Nossum, Yinghai Lu, Jeremy Fitzhardinge,
linux-kernel
In-Reply-To: <20091109221015.GB5129@outflux.net>
It is possible for x86_64 systems to lack the NX bit (see check_efer())
either due to the hardware lacking support or the BIOS having turned
off the CPU capability, so NX status should be reported. Additionally,
anyone booting NX-capable CPUs in 32bit mode without PAE will lack NX
functionality, so this change provides feedback for that case as well.
v2: use "Alert:" instead of "Warning:" to avoid confusion with WARN_ON()
v3: use "Notice:" instead of "Alert:" to avoid confusion with KERN_ALERT,
and switch to KERN_NOTICE, in keeping with its use for "normal but
significant condition" messages.
v4: check that _NX_PAGE is non-zero to avoid setting nx_enabled accidentally.
v5: check for disable_nx.
Signed-off-by: Kees Cook <kees.cook@canonical.com>
---
arch/x86/mm/init.c | 10 ++++++++++
arch/x86/mm/setup_nx.c | 6 +++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 73ffd55..d98b43a 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -149,6 +149,16 @@ unsigned long __init_refok init_memory_mapping(unsigned long start,
set_nx();
if (nx_enabled)
printk(KERN_INFO "NX (Execute Disable) protection: active\n");
+ else if (cpu_has_pae)
+#if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE)
+ /* PAE kernel, PAE CPU, without NX */
+ printk(KERN_NOTICE "Notice: NX (Execute Disable) protection "
+ "missing in CPU or disabled in BIOS!\n");
+#else
+ /* 32bit non-PAE kernel, PAE CPU */
+ printk(KERN_NOTICE "Notice: NX (Execute Disable) protection "
+ "cannot be enabled: non-PAE kernel!\n");
+#endif
/* Enable PSE if available */
if (cpu_has_pse)
diff --git a/arch/x86/mm/setup_nx.c b/arch/x86/mm/setup_nx.c
index 513d8ed..93d7b43 100644
--- a/arch/x86/mm/setup_nx.c
+++ b/arch/x86/mm/setup_nx.c
@@ -51,8 +51,12 @@ void __init set_nx(void)
}
}
#else
-void set_nx(void)
+void __init set_nx(void)
{
+ /* notice if _PAGE_NX exists and was removed during check_efer() */
+ if (!disable_nx && _PAGE_NX &&
+ ((__supported_pte_mask & _PAGE_NX) == _PAGE_NX))
+ nx_enabled = 1;
}
#endif
--
1.6.5
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply related
* Re: PCI bus node location
From: Rafal Jaworowski @ 2009-11-10 16:55 UTC (permalink / raw)
To: David Gibson; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <20091110031218.GG26042-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
On 2009-11-10, at 04:12, David Gibson wrote:
> On Mon, Nov 09, 2009 at 07:36:57PM -0700, Grant Likely wrote:
>> On Mon, Nov 9, 2009 at 12:20 PM, Rafal Jaworowski
>> <raj-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org> wrote:
>>> Hi,
>>> I have a couple of questions regarding host/PCI bridges nodes
>>> location:
>>>
>>> - What is the reason most of the DTS definitions have the host/PCI
>>> bridges
>>> hanging off the root node, even though they are most often really
>>> part of
>>> the soc?
>>> - Is this is some OF heritage (I couldn't find anything explicit
>>> about it in
>>> the original PCI bindings docs)?
>>> - Is this convention enforced in FDT, or could PCI bus nodes be
>>> children of
>>> the soc node as well?
>>
>> It was a solution to an engineering problem. The PCI control
>> registers are indeed within the IMMR region, and when we first
>> started
>> doing PowerPC FDT board ports, the PCI node was a child of the SoC
>> node. However, since PCI is also bridge with its own address space
>> translation, having it live in the SoC node causes difficulties.
>> Specifically, all of the entries in the PCI node ranges property
>> would
>> need similar counterparts in the SoC node ranges property; a scheme
>> that doesn't reflect well the actual behaviour of the IMMR region.
>>
>> Two alternate solutions were proposed. One was to split the PCI node
>> into a PCI bridge node which describes the translations, and a PCI
>> control node which describes how to access the PCI bridge registers.
>> Some sort of linkage (probably a phandle) would be needed to relate
>> the two. The second was to simply move the PCI node out to be a
>> parent of the root. The second option was the one chosen because it
>> was the path of least resistance. It may not be the most 'correct'
>> solution, but it has worked out quite well in practice. There is
>> nothing in the PCI or FDT infrastructure code that enforces this
>> convention. In fact, if the appropriate ranges properties were added
>> back to the IMMR node, then the PCI node could become a child of the
>> IMMR node without any code changes (but it still wouldn't be a 100%
>> 'correct' description of the hardware).
>
> Right.
>
> Under the new scheme, the "soc" node is really a historical misnomer -
> it represents just the things within the IMMR, not everything on the
> SoC. A number of chips also have the localbus controller as a
> separate node, likewise within the SoC but not within the IMMR, so not
> a child of the soc node.
Hm, how do we know whether something belongs under the IMMR/CCSR node
or not (even though it physically sits there :-)?
Is the 'soc' node going to be named something less confusing then?
> Note also that 4xx chips, unlike the Freescale ones do have the PCI
> host bridge under the plb node (which represents the main bus on the
> SoC).
Yea, I noticed, which made me even more confused, so thanks again for
clarifications.
Rafal
^ permalink raw reply
* Re: ov538-ov7690
From: Michael Trimarchi @ 2009-11-10 16:51 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-media@vger.kernel.org
In-Reply-To: <20091110081000.9e7c7717.rdunlap@xenotime.net>
Hi,
Randy Dunlap wrote:
> On Tue, 10 Nov 2009 11:18:13 +0100 Michael Trimarchi wrote:
>
>> Hi,
>>
>> Michael Trimarchi wrote:
>>> Hi all
>>>
>>> I'm working on the ov538 bridge with the ov7690 camera connected.
>>> Somentimes I receive
>>>
>>> [ 1268.146705] gspca: ISOC data error: [110] len=1020, status=-71
>>> [ 1270.946739] gspca: ISOC data error: [114] len=1020, status=-71
>>> [ 1271.426689] gspca: ISOC data error: [82] len=1020, status=-71
>>> [ 1273.314640] gspca: ISOC data error: [1] len=1020, status=-71
>>> [ 1274.114661] gspca: ISOC data error: [17] len=1020, status=-71
>>> [ 1274.658718] gspca: ISOC data error: [125] len=1020, status=-71
>>> [ 1274.834666] gspca: ISOC data error: [21] len=1020, status=-71
>>> [ 1275.666684] gspca: ISOC data error: [94] len=1020, status=-71
>>> [ 1275.826645] gspca: ISOC data error: [40] len=1020, status=-71
>>> [ 1276.226721] gspca: ISOC data error: [100] len=1020, status=-71
>>>
>>> This error from the usb, how are they related to the camera?
>
> -71 = -EPROTO (from include/asm-generic/errno.h).
>
> -EPROTO in USB drivers means (from Documentation/usb/error-codes.txt):
>
> -EPROTO (*, **) a) bitstuff error
> b) no response packet received within the
> prescribed bus turn-around time
> c) unknown USB error
>
> footnotes:
> (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
> hardware problems such as bad devices (including firmware) or cables.
>
OK, but it's a failure of the ehci transaction on my laptop and seems that is
not so frequent. I think that can be a cable problem.
> (**) This is also one of several codes that different kinds of host
> controller use to indicate a transfer has failed because of device
> disconnect. In the interval before the hub driver starts disconnect
> processing, devices may receive such fault reports for every request.
>
>
>> Ok, this is not a big issue because I can use vlc to test the camera. But anybody
>> knows why camorama, camstream, cheese crash during test. is it driver depend? or not?
>
> Could be driver. Easily could be a device problem too.
I think that it can be a vl2 vl1 problem. Because now I can manage in skype too using
the v4l1-compat library. Maybe my 2.6.32-rc5 is too new :(
Michael
>
> ---
> ~Randy
>
^ permalink raw reply
* Known-good LSI PCIe SAS HBAs?
From: Kristleifur Daðason @ 2009-11-10 16:54 UTC (permalink / raw)
To: linux-raid
Hi,
I'm looking to replace a problematic Marvell PCIe SAS JBOD controller
from Supermicro, type AOC-SASLP-MV8. (mdadm freaks out on it and the
controller drops the drives - there has been discussion of the problem
on the list. Seems to be a mvsas driver problem but seems to surface
only under mdadm use.)
It's a nice controller, but we have to get an array going, so I'm
shelving the Marvell card and getting a new one. I'll be using mdadm
raid5 / raid6 over the controller.
This one, LSI SAS 3081E-R, looks good with eight SAS ports for around $200:
http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/internal/sas3081e-r/index.html
I can't find anything concrete regarding Linux, but I did find a
known-good confirmation for Solaris/ZFS here:
http://jmlittle.blogspot.com/2008/06/recommended-disk-controllers-for-zfs.html
Can anyone confirm/deny that the PCIe JBOD controllers from LSI work
on Linux out of the box? Or give other recommendations for 8 port
controllers in the $150-$200 range? (Or thereabouts. It'd be great to
know about any known-good 4-port controllers for even up to $250.)
Thanks!
-- Kristleifur
^ permalink raw reply
* [RFC] vlan: GRO rx statistics
From: Eric Dumazet @ 2009-11-10 16:52 UTC (permalink / raw)
To: David S. Miller; +Cc: Herbert Xu, Linux Netdev List
It seems vlan interfaces with hardware-assisted VLAN reception
dont have rx statistics.
Following patch cures the problem for me but I have no idea
if it is correct ?
Another problem about all rx stats is about multi rx queues devices.
Several cpus can access these counters in parallel ?
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 8d5ca2a..e13b007 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -89,6 +89,11 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
if (!skb->dev)
goto drop;
+ skb->dev->stats.rx_packets++;
+ skb->dev->stats.rx_bytes += skb->len;
+ if (skb->pkt_type == PACKET_MULTICAST)
+ skb->dev->stats.multicast++;
+
for (p = napi->gro_list; p; p = p->next) {
NAPI_GRO_CB(p)->same_flow =
p->dev == skb->dev && !compare_ether_header(
^ permalink raw reply related
* Re: tw68-v2/tw68-i2c.c:145: error: unknown field ???client_register??? specified in initializer
From: Roman Gaufman @ 2009-11-10 16:51 UTC (permalink / raw)
To: linux-media
In-Reply-To: <20091110150328.GA4514@raptus.dandreoli.com>
2009/11/10 Domenico Andreoli <cavokz@gmail.com>:
> On Tue, Nov 10, 2009 at 01:48:43PM +0000, Roman Gaufman wrote:
>> I swapped my graphics card and techwell DVR card places and now it
>> works, thanks you!!!
>
> have you a PCI-E techwell board?
Yep, it's PCI-E 8 audio/video dvr card.
>
> i'm taking the driver out of the freezer trying to get rid of
> the IRQF_DISABLED warning flag. i'm interested in seeing your
> /proc/interrupts, if possible, before and after the boards swap.
Both with the patch:
After the swap (working):
CPU0 CPU1 CPU2 CPU3
0: 22 0 0 40 IO-APIC-edge timer
1: 0 0 0 2 IO-APIC-edge i8042
4: 0 0 0 2 IO-APIC-edge
8: 0 0 0 1 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
16: 0 0 0 543773 IO-APIC-fasteoi
ahci, uhci_hcd:usb3, uhci_hcd:usb9, tw6804[0], tw6804[4]
17: 0 0 0 40297 IO-APIC-fasteoi
pata_jmicron, ohci1394, tw6804[1], tw6804[5]
18: 0 0 0 24680 IO-APIC-fasteoi
ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, tw6804[2], tw6804[6]
19: 0 0 40184 0 IO-APIC-fasteoi
uhci_hcd:usb7, tw6804[3], tw6804[7]
21: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb4
22: 0 218 0 0 IO-APIC-fasteoi HDA Intel
23: 0 0 0 108 IO-APIC-fasteoi
ehci_hcd:usb2, uhci_hcd:usb6
24: 934040 0 0 0 HPET_MSI-edge hpet2
25: 0 390326 0 0 HPET_MSI-edge hpet3
26: 0 0 590635 0 HPET_MSI-edge hpet4
27: 0 0 0 845999 HPET_MSI-edge hpet5
33: 0 0 0 0 PCI-MSI-edge ahci
34: 812442 0 0 0 PCI-MSI-edge eth1
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 54 38 23 8 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
CNT: 0 0 0 0 Performance counter
interrupts
PND: 0 0 0 0 Performance pending work
RES: 4027 5400 6102 6462 Rescheduling interrupts
CAL: 124 139 137 44 Function call interrupts
TLB: 27517 22022 23155 17498 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 41 41 41 41 Machine check polls
ERR: 0
MIS: 0
Before swap (system freezes as soon as I try to open video device):
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 22 0 0 1 IO-APIC-edge timer
1: 0 0 0 2 IO-APIC-edge i8042
4: 0 0 0 2 IO-APIC-edge
8: 0 0 0 1 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
16: 0 0 0 9090 IO-APIC-fasteoi
ahci, uhci_hcd:usb3, uhci_hcd:usb9, tw6804[0], tw6804[4]
17: 0 0 0 3 IO-APIC-fasteoi
pata_jmicron, ohci1394, tw6804[1], tw6804[5]
18: 0 0 0 0 IO-APIC-fasteoi
ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, tw6804[2], tw6804[6]
19: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb7, tw6804[3], tw6804[7]
21: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb4
22: 0 218 0 0 IO-APIC-fasteoi HDA Intel
23: 0 0 0 103 IO-APIC-fasteoi
ehci_hcd:usb2, uhci_hcd:usb6
24: 3102 0 0 0 HPET_MSI-edge hpet2
25: 0 2403 0 0 HPET_MSI-edge hpet3
26: 0 0 1899 0 HPET_MSI-edge hpet4
27: 0 0 0 2835 HPET_MSI-edge hpet5
33: 0 0 0 0 PCI-MSI-edge ahci
34: 816 0 0 0 PCI-MSI-edge eth1
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 54 38 23 8 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
CNT: 0 0 0 0 Performance counter
interrupts
PND: 0 0 0 0 Performance pending work
RES: 8 7 6 7 Rescheduling interrupts
CAL: 118 130 129 46 Function call interrupts
TLB: 970 879 706 739 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 2 2 2 2 Machine check polls
ERR: 0
MIS: 0
>
>> Only 1 question, the readme says there is no audio yet - any ideas
>> when/if audio will be available? :)
>
> bad news here, i can't promise anything. anyway i'd like to push this
> driver to kernel staging and audio support is required for this step. so
> it is one of my topmost TODO entries.
Heh, fair enough - thank you for working on this!
Roman
>
> Domenico
>
> -----[ Domenico Andreoli, aka cavok
> --[ http://www.dandreoli.com/gpgkey.asc
> ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
>
^ permalink raw reply
* Re: [PATCH v4] [x86] detect and report lack of NX protections
From: H. Peter Anvin @ 2009-11-10 16:47 UTC (permalink / raw)
To: Kees Cook
Cc: Arjan van de Ven, Thomas Gleixner, Ingo Molnar, x86, Pekka Enberg,
Jan Beulich, Vegard Nossum, Yinghai Lu, Jeremy Fitzhardinge,
linux-kernel
In-Reply-To: <20091110154956.GF5129@outflux.net>
On 11/10/2009 07:49 AM, Kees Cook wrote:
>>
>> The second clause can only get executed if CONFIG_X86_PAE is unset,
>> which in turn means _PAGE_NX == 0... so that piece of code is meaningless.
>
> CONFIG_X86_PAE is unset for x86_64, where _PAGE_NX is valid. (This was
> the main situation I was trying to address.) So that chunk runs for
> non-pae 32bit, and all 64bit:
>
In reality, X86_PAE really should have been defined for 64 bits, since
64 bits really is PAE in most aspects.
Anyway, for the 64-bit case it looks like the proper place for any of
this is in check_efer() just below, not in this null routine.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* [U-Boot] [PATCH 3/7] 83xx/85xx/86xx: Add ECC support
From: Ira W. Snyder @ 2009-11-10 16:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1257822445.7312.12.camel@ptyser-laptop>
On Mon, Nov 09, 2009 at 09:07:25PM -0600, Peter Tyser wrote:
[ big snip ]
> >
> > I haven't looked at your code. When I was running the old ecc command, I
> > had the 83xx reference manual open to decode the command's output, IIRC.
> >
> > PS - I'm happy to test stuff on 83xx, I'll try and find time to test
> > this patch series tomorrow.
>
> Thanks, its much appreciated.
>
Ok, here are my results, this is on a 8349EMDS-derived board. My
8349EMDS eval board doesn't have ECC memory.
1) It might be nice to have something to print the current injection
registers. It is not a big deal, anyone using this should be an expert
anyway.
2) ecc inject off didn't seem to work, see the following capture:
=> ecc info
No ECC errors have occurred
=> ecc inject low 0x1
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0ff7ae40
Data: 0x0fffdf9c_0ff7aed1 ECC: 0x81
Expect: 0x0fffdf9c_0ff7aed0 ECC: 0x81
Net: DATA0
Syndrome: 0x3b
Single-Bit errors: 0x1e
Attrib: 0x01002001
Detect: 0x80000004 (MME, SBE)
=> ecc inject off
# Ok, now error injection is off, I still expect some errors to be
# present in the error registers
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0ff7ae1c
Data: 0x0fffdf9c_0ff7d2a1 ECC: 0xe4
Expect: 0x0fffdf9c_0ff7d2a0 ECC: 0xe4
Net: DATA0
Syndrome: 0x3b
Single-Bit errors: 0xd1
Attrib: 0x01003001
Detect: 0x80000004 (MME, SBE)
# And there was the error. Now, I don't expect any more errors to
# be present, after all, injection is disabled.
#
# But there is one! Why?
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0fff8a0c
Data: 0x0fff8a00_0fff8a01 ECC: 0xff
Expect: 0x0fff8a00_0fff8a00 ECC: 0xff
Net: DATA0
Syndrome: 0x3b
Single-Bit errors: 0x04
Attrib: 0x01003001
Detect: 0x00000000
=>
# Note that I keep seeing ecc errors until I run the command:
# ecc inject low 0
Here is another trace showing "interesting" behavior:
=> ecc info
No ECC errors have occurred
=> ecc inject high 1
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0ff7ae40
Data: 0x0fffdf9d_0ff7aed0 ECC: 0x81
Expect: 0x0fffdf9c_0ff7aed0 ECC: 0x81
Net: DATA32
Syndrome: 0xce
Single-Bit errors: 0xd8
Attrib: 0x01002001
Detect: 0x80000004 (MME, SBE)
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0fff89c4
Data: 0x0fff89b9_0ff7d268 ECC: 0x02
Expect: 0x0fff89b8_0ff7d268 ECC: 0x02
Net: DATA32
Syndrome: 0xce
Single-Bit errors: 0xea
Attrib: 0x01003001
Detect: 0x80000004 (MME, SBE)
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0ff7d2e8
Data: 0x00000001_0ff7d300 ECC: 0x99
Expect: 0x00000000_0ff7d300 ECC: 0x99
Net: DATA32
Syndrome: 0xce
Single-Bit errors: 0x30
Attrib: 0x01002001
Detect: 0x80000004 (MME, SBE)
=> ecc inject high 0
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0ff7d2e8
Data: 0x00000001_0ff7d300 ECC: 0x99
Expect: 0x00000000_0ff7d300 ECC: 0x99
Net: DATA32
Syndrome: 0xce
Single-Bit errors: 0x81
Attrib: 0x01002001
Detect: 0x80000004 (MME, SBE)
=> ecc info
WARNING: ECC error in DDR Controller 0
Addr: 0x0_0fff8a0c
Data: 0x0fff8a01_0fff8a00 ECC: 0xff
Expect: 0x0fff8a00_0fff8a00 ECC: 0xff
Net: DATA32
Syndrome: 0xce
Single-Bit errors: 0x04
Attrib: 0x01003001
Detect: 0x00000000
=> ecc info
No ECC errors have occurred
=> ecc info
No ECC errors have occurred
# Why did it take two runs of ecc info to clear all of the errors?
Other than the above strangeness, everything is working great on my 83xx
board. I think the new output is pretty nice. It serves my purposes
equally well to the old code.
Ira
^ permalink raw reply
* Re: [PATCH v7 04/17] tracing: add static function tracer support for MIPS
From: David Daney @ 2009-11-10 16:43 UTC (permalink / raw)
To: wuzhangjin
Cc: linux-mips, linux-kernel, zhangfx, zhouqg, Ralf Baechle, rostedt,
Frederic Weisbecker, Ingo Molnar, Nicholas Mc Guire,
Richard Sandiford, Patrik Kluba, Thomas Gleixner, Michal Simek
In-Reply-To: <1257814817.2822.3.camel@falcon.domain.org>
Wu Zhangjin wrote:
> Hi,
>
> On Mon, 2009-11-09 at 16:26 -0800, David Daney wrote:
>> Wu Zhangjin wrote:
>>
>>>
>>> +ifndef CONFIG_FUNCTION_TRACER
>>> cflags-y := -ffunction-sections
>>> +else
>>> +cflags-y := -mlong-calls
>>> +endif
>>> cflags-y += $(call cc-option, -mno-check-zero-division)
>>>
>> That doesn't make sense to me. Modules are already compiled with
>> -mlong-calls. The only time you would need the entire kernel compiled
>> with -mlong-calls is if the tracer were in a module. The logic here
>> doesn't seem to reflect that.
>
> Yes, I knew the module have gotten the -mlong-calls, Here we just want
> to use -mlong-calls for the whole kernel, and then we get the same
> _mcount stuff in the whole kernel, at last, we can use the same
> scripts/recordmcount.pl and ftrace_make_nop & ftrace_make_call for the
> dynamic ftracer.
>
-mlong-calls really degrades performance. I have seen things like 6%
drop in network packet forwarding rates with -mlong-calls.
It would be better to fix all the tools so that they could handle both
-mlong-calls and -mno-long-calls code.
David Daney
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 2/3] usb-gotemp: new module emulating a USB thermometer
From: Avi Kivity @ 2009-11-10 16:50 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Tsai, qemu-devel
In-Reply-To: <374D220D-FE6E-410B-83F3-E8988BA61A6D@suse.de>
On 11/10/2009 05:33 PM, Alexander Graf wrote:
> How about having a monitor command to change the temperature,
> leveraging a "common interface"?
> That way in the future real host temperature measurements could maybe
> get forwarded there too. At least for battery I've had several people
> ask already if it's possible to read the host battery status (incl. AC
> status) from inside the VM.
More ACPI functionality, so we can forward ACPI events from the host to
the guest, would be welcome indeed.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors
From: Patrick McHardy @ 2009-11-10 16:50 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <767BAF49E93AFB4B815B11325788A8ED45F0BA@L01SLCXDB03.calltower.com>
ben@bigfootnetworks.com wrote:
> We have observed significant reassembly errors when combining
> routing/bridging with conntrack + nf_defrag_ipv4 loaded, and
> skb_recycle_check - enabled interfaces. For our test, we had a single
> linux device with two interfaces (gianfars in this case) with SKB
> recycling enabled. We sent large, continuous pings across the bridge,
> like this:
> ping -s 64000 -A <dest IP>
>
> Then, we ran netstat -s --raw, and noticed that IPSTATS_MIB_REASMFAILS
> were happening for about 40% of the received datagrams. Tracing the
> code in ip_fragment.c, we instrumented each of the
> IPSTATS_MIB_REASMFAILS locations, and found the culprit to be
> ip_evictor. Nothing looked unusual here, so we placed tracing in
> ip_frag_queue, directly above:
> atomic_add(skb->truesize, &qp->q.net->mem);
>
> We noticed that quite a few of the skb->truesize numbers were in the 67K
> range, which quickly overwhelms the default 192K-ish ipfrag_low_thresh.
> This means that the next time inet_frag_evictor is run:
> work = atomic_read(&nf->mem) - nf->low_thresh;
>
> Will surely be positive, and it is likely that our huge-frag-containing
> queue will be one of those evicted.
>
> Looking at the source of these huge skbs, it seems that during
> re-fragmentation in br_nf_dev_queue_xmit (which calls ip_fragment with
> CONFIG_NF_CONNTRACK_IPV4 enabled), the huge datagram that was allocated
> to hold a successfully-reassembled skb may be getting reused? In any
> case, when skb_recycle_check(skb, min_rx_size) is called, the huge
> (skb->truesize huge, not data huge) skb is recycled for use on RX, and
> it eventually gets enqueued for reassembly, causing the
> inet_frag_evictor to have a positive work value.
Interesting problem. I wonder what the linear size of the skb was
and whether we're just not properly adjusting truesize of the head
during refragmentation.
This code in ip_fragment() looks suspicious:
if (skb_has_frags(skb)) {
...
skb_walk_frags(skb, frag) {
...
if (skb->sk) {
frag->sk = skb->sk;
frag->destructor = sock_wfree;
truesizes += frag->truesize;
}
truesizes is later used to adjust truesize of the head skb.
For some reason this is only done when it originated from a
local socket.
> Our solution was to add an upper-bounds check to skb_recycle_check,
> which prevents the large-ish SKBs from being used to create future
> frags, and overwhelming ipfrag_low_thresh. This seems quite clunky,
> although I would be happy to submit this as a patch...
This seems reasonable to me, there might be large skbs for
different reasons.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Fix incoming migration
From: Mark McLoughlin @ 2009-11-10 16:47 UTC (permalink / raw)
To: Juan Quintela; +Cc: qemu-devel
In-Reply-To: <1257519486-14786-1-git-send-email-quintela@redhat.com>
On Fri, 2009-11-06 at 15:58 +0100, Juan Quintela wrote:
> commit b04c4134d6de28c249277de19e523bfbe4aebbd6
> broke incoming migration. After talking with Gleb, code was intended
> to be the way is in this fix. This fixes migration here.
Tried to reproduce and it works fine for me. More details?
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
> savevm.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/savevm.c b/savevm.c
> index b7abf43..fd98ccd 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -126,6 +126,8 @@ static int announce_self_create(uint8_t *buf,
> static void qemu_announce_self_once(void *opaque)
> {
> int i, len;
> + VLANState *vlan;
> + VLANClientState *vc;
> uint8_t buf[60];
> static int count = SELF_ANNOUNCE_ROUNDS;
> QEMUTimer *timer = *(QEMUTimer **)opaque;
> @@ -134,7 +136,10 @@ static void qemu_announce_self_once(void *opaque)
> if (!nd_table[i].used)
> continue;
> len = announce_self_create(buf, nd_table[i].macaddr);
> - qemu_send_packet_raw(nd_table[i].vc, buf, len);
> + vlan = nd_table[i].vlan;
> + QTAILQ_FOREACH(vc, &vlan->clients, next) {
> + qemu_send_packet_raw(vc, buf, len);
> + }
A NIC isn't necessarily connected to a vlan any more, which is why the
change was made.
With your patch, I'd expect it to crash if you used -netdev rather than
-net
Cheers,
Mark.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-10 16:49 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Linux Kernel Network Developers, Eric Dumazet, Joe Perches
In-Reply-To: <alpine.DEB.2.00.0911101605050.20637@melkinpaasi.cs.helsinki.fi>
Ilpo Järvinen wrote:
> After some time I returned to it. My apologies for my previous harsh
> response. My point was to say that you must separate such changes because
> they add to noise which makes it rather annoying to review. At least my
> brains are rather limited still in keeping track of different things.
>
Apology accepted.
I'd think we agree, and that's why I wouldn't go around fixing all the
misspelled comments -- just those in the code I'm actually revising.
>> This *is* actually in CodingStyle (line 679), and I'm trying to conform:
>
> Sure, fell free to but not in some random places like you now do in this
> patch. If you are not touching a line because of a real change and want do
> a syntax cleanup, please do it in another patch. Especially when your
> actual change is as complicated as this is.
>
Not a single one is in a random place.
>>> ...Also some comment changes which certainly are not mandatory nor even
>>> related.
>>>
>> 1) The first is a hole left by the removal of the data fields some time
>> ago, but they left the old (now incorrect) comment:
>>
>> -/* SACKs data */
>> + u8 cookie_plus:6, /* bytes in authenticator/cookie option */
>> + cookie_out_never:1,
>> + cookie_in_always:1;
>> u8 num_sacks; /* Number of SACK blocks */
>>...
> I'm sorry but this response tells me that you don't seem to know even
> yourself what you were submitting. Does this ring a bell:
>
> - if (th->doff == sizeof(struct tcphdr) >> 2) {
> + /* In the spirit of fast parsing, compare doff directly to shifted
> + * constant values. Because equality is used, short doff can be
> + * ignored here, and checked later.
> + */
> + if (th->doff == (sizeof(*th) >> 2)) {
>
Ah, it's become apparent that you didn't click through to any of the
references, internet-drafts, or mailing list discussion, so you don't
know what this patch series is implementing.
One of the great difficulties in tracking down all several hundred uses
of doff -- and functions that use doff -- is the serious deficiency of
comments (compared to other code bases).
Oh yeah -- Miller says I'm anal. This is TCP. Strict scrutiny is much
better than the alternative.
> Besides, I don't understand even what you're trying to say. ...I think we
> already checked the length in tcp_v[46]_rcv against underflow. Why you add
> such a non-sense comment here (plus the sizeof change I covered
> elsewhere)? This is just a noise to annoy reviewer, nothing else.
>
You merely think? You don't know? (I didn't find one on the code walk
through that got me to this point in the code, but perhaps I missed
something.) If that's the case, there should at least be a comment that
underflow was already checked, and *where* it was checked!
The lack of pertinent comments and error checking annoys the next coder
that comes down the pike.
>> 2) The second is a spelling error that I noticed in passing. It's within
>> the same diff -u area (close to other insertions both before and after), so
>> fixing it was trivial:
>>
>> - * to increse this, although since:
>> + * to increase this, although since:
>>
>> Are we not supposed to fix spelling errors in comments?
>
> How many extra lines a reviewer has to read because of that? Why not do it
> in a separate patch. git add -i / git stash would help you there. ...To be
> honest, I'd rather have typos in comments which like this are not
> trouble for the reader than clutter feature patches with all this random
> junk.
>
I'll have to look up the usage of git add -i / git stash, but in any case,
I'm not likely to go around fixing comments later.
Each patch requires a great deal of time. I'd rather combine such things,
or not do them at all.
> ...I really wish that next time when you submit you get rid of all these
> showstoppers and annoyances (ie., at least honestly try to do your best)
> that we could finally concentrate to the actual change and reviewing
> that :-). My recommendation is that before hitting the send button you
> review (read through) your own patches, and if you find something to
> correct instead of submitting, postpone that until the problem is solved.
> Like DaveM once noted somebody, you'll not be timed :-). ...I usually do
> that (read my own patches) and end up rather often to not submit (and find
> even real bugs that way quite often).
>
Maybe you've been dealing too much with some folks that submitted a patch
that was accepted (over my expressed reservations), and then had to send
out 2 emergency patches to handle crashing bugs last week....
Before I send any patch, it's been compared against my last patch sent,
*and* tested for compilation individually, *and* _usually_ tested pretty
thoroughly -- although not this time, because the net-next-2.6 modules
don't compile, as I warned at the head of this patch series.
Because the compile blew up, I actually spent my Sunday evening
re-reviewing the patches again! I wanted to ensure it wasn't something
that I'd done, so I recompiled everything again incrementally.
It took me more than a day to make the syntax changes requested, and
another 6 hours to prepare and send these 5 patches.
I cannot promise there will never be any bugs, this patch series will be
much too complicated for that, but the very idea that I'd send without
reviewing.... At this point, I'm rather personally insulted.
And now I'm done with email for the day. I'll do the split that Eric
suggested, and send it out whenever the damn modules compile again.
In the meantime, I'd appreciate that you "finally concentrate"....
^ permalink raw reply
* Re: vlan/macvlan 02/02: propagate transmission state to upper layers
From: Stephen Hemminger @ 2009-11-10 16:48 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AF99160.2060607@trash.net>
On Tue, 10 Nov 2009 17:14:24 +0100
Patrick McHardy <kaber@trash.net> wrote:
> vlan/macvlan: propagate transmission state to upper layers
>
> Both vlan and macvlan devices usually don't use a qdisc and immediately
> queue packets to the underlying device. Propagate transmission state of
> the underlying device to the upper layers so they can react on congestion
> and/or inform the sending process.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Bridging and bonding have same issue, but the solution is more difficult.
^ permalink raw reply
* Re: Performance regression in IO scheduler still there
From: Jeff Moyer @ 2009-11-10 16:47 UTC (permalink / raw)
To: Corrado Zoccolo
Cc: Jan Kara, jens.axboe, LKML, Chris Mason, Andrew Morton,
Mike Galbraith
In-Reply-To: <4e5e476b0911080901n6b855b0dle63f0151073ec2c6@mail.gmail.com>
Corrado Zoccolo <czoccolo@gmail.com> writes:
> Jeff, Jens,
> do you think we should try to do more auto-tuning of cfq parameters?
> Looking at those numbers for SANs, I think we are being suboptimal in
> some cases.
> E.g. sequential read throughput is lower than random read.
I investigated this further, and this was due to a problem in the
benchmark. It was being run with only 500 samples for random I/O and
65536 samples for sequential. After fixing this, we see random I/O is
slower than sequential, as expected.
> I also think that current slice_idle and slice_sync values are good
> for devices with 8ms seek time, but they are too high for non-NCQ
> flash devices, where "seek" penalty is under 1ms, and we still prefer
> idling.
Do you have numbers to back that up? If not, throw a fio job file over
the fence and I'll test it on one such device.
> If we agree on this, should the measurement part (I'm thinking to
> measure things like seek time, throughput, etc...) be added to the
> common elevator code, or done inside cfq?
Well, if it's something that is of interest to others, than pushing it
up a layer makes sense. If only CFQ is going to use it, keep it there.
Cheers,
Jeff
^ 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.