* [PATCH 3/16] cell: set ARCH_SPARSEMEM_DEFAULT in Kconfig
From: Geoff Levand @ 2006-11-10 20:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
The current cell processor support needs sparsemem, so set it as
the default memory model.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
As noted by Benjamin Herrenschmidt.
Index: cell--common--6/arch/powerpc/Kconfig
===================================================================
--- cell--common--6.orig/arch/powerpc/Kconfig
+++ cell--common--6/arch/powerpc/Kconfig
@@ -734,7 +734,7 @@
config ARCH_SPARSEMEM_DEFAULT
def_bool y
- depends on SMP && PPC_PSERIES
+ depends on (SMP && PPC_PSERIES) || PPC_CELL
config ARCH_POPULATES_NODE_MAP
def_bool y
^ permalink raw reply
* [PATCH 2/16] spufs: change ppc_rtas declaration to weak
From: Geoff Levand @ 2006-11-10 20:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
Change the definition of powerpc's cond_syscall() to use the standard gcc
weak attribute specifier which provides proper support for C linkage as
needed by spu_syscall_table[].
Fixes this powerpc build error with CONFIG_SPU_FS=y, CONFIG_PPC_RTAS=n:
arch/powerpc/platforms/built-in.o: undefined reference to `ppc_rtas'
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
include/asm-powerpc/unistd.h | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
Index: cell--common--6/include/asm-powerpc/unistd.h
===================================================================
--- cell--common--6.orig/include/asm-powerpc/unistd.h
+++ cell--common--6/include/asm-powerpc/unistd.h
@@ -445,7 +445,6 @@
#include <linux/types.h>
#include <linux/compiler.h>
#include <linux/linkage.h>
-#include <asm/syscalls.h>
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR
@@ -480,16 +479,9 @@
/*
* "Conditional" syscalls
- *
- * What we want is __attribute__((weak,alias("sys_ni_syscall"))),
- * but it doesn't work on all toolchains, so we just do it by hand
*/
-#ifdef CONFIG_PPC32
-#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
-#else
-#define cond_syscall(x) asm(".weak\t." #x "\n\t.set\t." #x ",.sys_ni_syscall")
-#endif
-
+#define cond_syscall(x) \
+ asmlinkage long x (void) __attribute__((weak,alias("sys_ni_syscall")))
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply
* [PATCH 0/16] patches for 2.6.20
From: Geoff Levand @ 2006-11-10 20:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
This is the set of patches I have queued for 2.6.20. Patches 1-6 have
already been posted, but I did some re-work on a few to bring them up
to the latest powerpc.git. Patches 7-16 are new and add the core
platform support for the PS3 game console.
For the convenience of anyone interested, I have put this patchset, plus
a few other drivers I am working on with some info here:
http://67.117.136.164/pub/cell/
-Geoff
^ permalink raw reply
* patch for handling CLARiiON I/O to inactive snapshot logical units
From: Edward Goggin @ 2006-11-10 19:58 UTC (permalink / raw)
To: christophe.varoqui; +Cc: dm-devel
Christophe,
Here is my 2nd attempt at a patch which attempts to prevent an I/O hang
which can occur with host I/O to an inactive CLARiiON snapshot logical
unit. While the inactive snapshot LU is presented to a host, inquiry,
TUR, and read capacity commands succeed, but read and write commands are
failed. Complicating the matter is the fact that read/write to the
active paths fails with a particular sense code/asc/ascq combination
while read/write to the passive paths does not.
Unlike the previous patch, I've tried to make this one CLARiiON
specific. Two exceptions though. First, I did keep the change to
libcheckers/readsector0.c to allow other checkers than readsector0 to
use sg_read(). Second, I changed libmultipath/discovery.c to allow
pathinfo() to invoke the path priority callout function of a path with a
path state of PATH_DOWN since some paths (e.g., paths to inactive
snapshot LU on CLARiiON) may have their state set to PATH_DOWN for
reasons other than transport connectivity failure. Without the latter
change, it is possible to create a situation whereby there are paths of
different priorities in the same path group even though the path group
policy is priority based grouping. This is certainly the case for paths
to a multipath mapped device for an inactive snapshot CLARiiON LUs when
the paths change to a healthy state as soon as the snapshot is
activated.
Thanks,
Ed Goggin
diff --git a/libcheckers/emc_clariion.c b/libcheckers/emc_clariion.c
index a883e3d..1539921 100644
--- a/libcheckers/emc_clariion.c
+++ b/libcheckers/emc_clariion.c
@@ -10,10 +10,13 @@
#include <fcntl.h>
#include <sys/ioctl.h>
#include <errno.h>
+#include <pthread.h>
#include "checkers.h"
#include "../libmultipath/sg_include.h"
+#include "../libmultipath/vector.h"
+#include "../libmultipath/debug.h"
#define INQUIRY_CMD 0x12
#define INQUIRY_CMDLEN 6
@@ -22,31 +25,285 @@
struct emc_clariion_checker_context {
char wwn[16];
unsigned wwn_set;
+ dev_t rdev;
};
+/*
+ * Mechanism to track active and passive CLARiiON paths to inactive
+ * CLARiiON snapshot LUs. This is done so that we can fail passive
paths
+ * to an inactive snapshot LU even though the read test contained
herein
+ * will return 02/04/03 instead of 05/25/01 sense code/ASC/ASCQ data.
+ */
+int sg_read (int sg_fd, unsigned char * buff, unsigned char *
senseBuff);
+
+/*
+ * Entry in fwwn_vec for each inactive snapshot LU. path_vec vector
contains
+ * dev_t entries for each path to the LU.
+ */
+typedef struct fwwne {
+ char wwn[16]; /* WWN of inactive snapshot LU */
+ vector path_vec; /* array of paths to this LU */
+} fwwne;
+vector fwwn_vec = NULL; /* vector of inactive snapshot
LUs */
+pthread_mutex_t fwwn_mutex = PTHREAD_MUTEX_INITIALIZER;
+
+#define WWN_SIZE 16
+#define INIT_WWN(dwwn, swwn) memcpy(dwwn, swwn, WWN_SIZE)
+#define MATCH_WWNS(wwn1, wwn2) (memcmp(wwn1, wwn2,
WWN_SIZE) == 0)
+
+#define INIT_PATH(dpath, spath) memcpy(dpath, spath,
sizeof(dev_t))
+#define MATCH_PATHS(rdev1, rdev2) (memcmp(rdev1, rdev2, \
+ sizeof(dev_t)) == 0)
+
+/*
+ * Setup LU and path associated with this path checker to be known as
an
+ * inactive snapshot LU and path to same.
+ */
+void failwwn(struct checker *c)
+{
+ struct emc_clariion_checker_context * ct =
+ (struct emc_clariion_checker_context *)c->context;
+ char *wwn = ct->wwn;
+ vector path_vec;
+ fwwne *fp;
+ dev_t *pp;
+ int i, j;
+
+ pthread_mutex_lock(&fwwn_mutex);
+ if (fwwn_vec) {
+ vector_foreach_slot(fwwn_vec, fp, i) {
+ /*
+ * Check for already known inactive snapshot LU.
+ */
+ if (MATCH_WWNS(fp->wwn, wwn)) {
+ path_vec = fp->path_vec;
+ vector_foreach_slot(path_vec, pp, j) {
+ /*
+ * Check for already known path
+ * to already known inactive
+ * snapshot LU.
+ */
+ if (MATCH_PATHS(pp, &ct->rdev))
{
+ pthread_mutex_unlock(
+ &fwwn_mutex);
+ return;
+ }
+ }
+ /*
+ * Identify new path to already known
+ * inactive snapshot LU.
+ */
+ if (vector_alloc_slot(path_vec)) {
+ vector_set_slot(path_vec,
&ct->rdev);
+ condlog(4, "failwwn %s count is
%d.\n",
+ wwn,
VECTOR_SIZE(path_vec));
+ }
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+ }
+ } else {
+ /*
+ * Allocate the inactive snapshot LU vector.
+ */
+ fwwn_vec = vector_alloc();
+ if (fwwn_vec == 0) {
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+ }
+
+ /*
+ * Allocate the path vector for this inactive snapshot LU.
+ */
+ path_vec = vector_alloc();
+ if (path_vec == 0) {
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+ if (!vector_alloc_slot(path_vec)) {
+ vector_free(path_vec);
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+ vector_set_slot(path_vec, &ct->rdev);
+
+ /*
+ * Allocate the inactive snapshot vector entry itself.
+ */
+ fp = malloc(sizeof(fwwne));
+ if (fp == 0) {
+ vector_free(path_vec);
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+ if (!vector_alloc_slot(fwwn_vec)) {
+ free(fp);
+ vector_free(path_vec);
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+
+ /*
+ * Initialize fields and link to the vector.
+ */
+ INIT_WWN(fp->wwn, wwn);
+ fp->path_vec = path_vec;
+ vector_set_slot(fwwn_vec, fp);
+
+ condlog(4, "failwwn %s count is %d.\n", wwn,
VECTOR_SIZE(fp->path_vec));
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+}
+
+/*
+ * Determine if the LU and path associated with this path checker are
already
+ * associated with an-active snapshot LU.
+ */
+int findwwn(struct checker *c)
+{
+ struct emc_clariion_checker_context * ct =
+ (struct emc_clariion_checker_context *)c->context;
+ char *wwn = ct->wwn;
+ vector path_vec;
+ fwwne *fp;
+ dev_t *pp;
+ int i, j;
+
+ pthread_mutex_lock(&fwwn_mutex);
+ if (fwwn_vec) {
+ vector_foreach_slot(fwwn_vec, fp, i) {
+ /*
+ * Check for already known inactive snapshot LU.
+ */
+ if (MATCH_WWNS(fp->wwn, wwn)) {
+ path_vec = fp->path_vec;
+ vector_foreach_slot(path_vec, pp, j) {
+ /*
+ * Check for already known path
+ * to already known inactive
+ * snapshot LU.
+ */
+ if (MATCH_PATHS(pp, &ct->rdev))
{
+ pthread_mutex_unlock(
+ &fwwn_mutex);
+ return 1;
+ }
+ }
+ /*
+ * Identify new path to already known
+ * inactive snapshot LU.
+ */
+ if (vector_alloc_slot(path_vec)) {
+ vector_set_slot(path_vec,
&ct->rdev);
+ condlog(4, "failwwn %s count is
%d.\n",
+ wwn,
VECTOR_SIZE(path_vec));
+ }
+ pthread_mutex_unlock(&fwwn_mutex);
+ return 1;
+ }
+ }
+ }
+ pthread_mutex_unlock(&fwwn_mutex);
+ return 0;
+}
+
+#define UNFAILWWN(c) unfailwwnpath(c, 0)
+#define UNFAILWWNPATH(c) unfailwwnpath(c, 1)
+
+/*
+ * Remove LU and path associated with this path checker as
+ * inactive snapshot LU and path to same.
+ */
+void unfailwwnpath(struct checker *c, int match_paths)
+{
+ struct emc_clariion_checker_context * ct =
+ (struct emc_clariion_checker_context *)c->context;
+ char *wwn = ct->wwn;
+ vector path_vec;
+ fwwne *fp;
+ dev_t *pp;
+ int i, j;
+
+ pthread_mutex_lock(&fwwn_mutex);
+ if (fwwn_vec) {
+ vector_foreach_slot(fwwn_vec, fp, i) {
+ /*
+ * Check for already known inactive snapshot LU.
+ */
+ if (MATCH_WWNS(fp->wwn, wwn)) {
+ path_vec = fp->path_vec;
+ vector_foreach_slot(path_vec, pp, j) {
+ /*
+ * Check for already known path
+ * to already known inactive
+ * snapshot LU.
+ */
+ if (!match_paths ||
+ MATCH_PATHS(pp, &ct->rdev))
{
+
vector_del_slot(path_vec, j);
+ condlog(4, "unfailwwn %s
"
+ "count is
%d.\n",
+ wwn,
+
VECTOR_SIZE(path_vec));
+ if (match_paths)
+ break;
+ }
+ }
+ if (VECTOR_SIZE(path_vec) == 0) {
+ vector_del_slot(fwwn_vec, i);
+ free(fp);
+ vector_free(path_vec);
+
pthread_mutex_unlock(&fwwn_mutex);
+ condlog(4, "unfailwwn de-alloc "
+ "%s.\n", wwn);
+ }
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+ }
+ }
+ }
+ pthread_mutex_unlock(&fwwn_mutex);
+ return;
+}
+
int emc_clariion_init (struct checker * c)
{
+ struct stat stat;
+ int err;
+
c->context = malloc(sizeof(struct
emc_clariion_checker_context));
if (!c->context)
return 1;
((struct emc_clariion_checker_context *)c->context)->wwn_set =
0;
+
+ err = fstat(c->fd, &stat);
+ if (err == 0) {
+ INIT_PATH(&((struct emc_clariion_checker_context *)
+ c->context)->rdev, &stat.st_rdev);
+ }
+
return 0;
}
void emc_clariion_free (struct checker * c)
{
+ UNFAILWWNPATH(c);
free(c->context);
}
int emc_clariion(struct checker * c)
{
- unsigned char sense_buffer[256] = { 0, };
+ unsigned char sense_buffer[256] = { 0, }, *sbb;
unsigned char sb[128] = { 0, };
+ unsigned char buf[512];
unsigned char inqCmdBlk[INQUIRY_CMDLEN] = {INQUIRY_CMD, 1, 0xC0,
0,
sizeof(sb), 0};
struct sg_io_hdr io_hdr;
struct emc_clariion_checker_context * ct =
(struct emc_clariion_checker_context *)c->context;
+ int ret;
+ int retry_count=3;
memset(&io_hdr, 0, sizeof (struct sg_io_hdr));
io_hdr.interface_id = 'S';
@@ -69,7 +326,8 @@ int emc_clariion(struct checker * c)
}
if (/* Verify the code page - right page & revision */
sense_buffer[1] != 0xc0 || sense_buffer[9] != 0x00) {
- MSG(c, "emc_clariion_checker: Path unit report page in
unknown format");
+ MSG(c, "emc_clariion_checker: Path unit report page in "
+ "unknown format");
return PATH_DOWN;
}
@@ -79,13 +337,15 @@ int emc_clariion(struct checker * c)
|| (sense_buffer[28] & 0x07) != 0x04
/* Arraycommpath should be set to 1 */
|| (sense_buffer[30] & 0x04) != 0x04) {
- MSG(c, "emc_clariion_checker: Path not correctly
configured for failover");
+ MSG(c, "emc_clariion_checker: Path not correctly "
+ "configured for failover");
return PATH_DOWN;
}
if ( /* LUN operations should indicate normal operations */
sense_buffer[48] != 0x00) {
- MSG(c, "emc_clariion_checker: Path not available for
normal operations");
+ MSG(c, "emc_clariion_checker: Path not available for "
+ "normal operations");
return PATH_SHAKY;
}
@@ -102,15 +362,76 @@ int emc_clariion(struct checker * c)
*/
if (ct->wwn_set) {
if (memcmp(ct->wwn, &sense_buffer[10], 16) != 0) {
- MSG(c, "emc_clariion_checker: Logical Unit WWN
has changed!");
+ MSG(c, "emc_clariion_checker: Logical Unit WWN "
+ "has changed!");
return PATH_DOWN;
}
} else {
memcpy(ct->wwn, &sense_buffer[10], 16);
ct->wwn_set = 1;
}
-
-
- MSG(c, "emc_clariion_checker: Path healthy");
- return PATH_UP;
+
+retry:
+ memset(sense_buffer, 0, sizeof(sense_buffer));
+ ret = sg_read(c->fd, &buf[0], sbb = &sense_buffer[0]);
+ if (ret == PATH_DOWN) {
+ char str[256];
+
+ condlog(4, "emc_clariion_checker: Read error for "
+ "(0x%llx), sense data are 0x%x/0x%x/0x%x",
+ ct->rdev, sbb[2]&0xf, sbb[12], sbb[13]);
+
+ /*
+ * Check for inactive snapshot lu this way. Must fail
these.
+ */
+ if (((sbb[2]&0xf) == 5) && (sbb[12] == 0x25) &&
(sbb[13]==1)) {
+ /*
+ * Do this so that we can fail even the passive
paths
+ * which will return 02/04/03 not 05/25/01.
+ */
+ failwwn(c);
+ sprintf(str, "emc_clariion_checker: Active path
"
+ "(0x%llx) to inactive snapshot.",
ct->rdev);
+ MSG(c, str);
+ }
+ /*
+ * Check for passive/standby path this way. Must OK
these
+ * as long as not path to inactive snapshot LU.
+ */
+ else if (((sbb[2]&0xf)==2) && (sbb[12]==4) &&
(sbb[13]==3)) {
+ if (findwwn(c)) {
+ MSG(c, "emc_clariion_checker: Passive
path "
+ "to inactive snapshot.");
+ } else {
+ MSG(c,
+ "emc_clariion_checker: Passive path is
healthy.");
+ ret = PATH_UP; /* not ghost */
+ }
+ } else {
+ sprintf(str, "emc_clariion_checker: Read error
for "
+ "(0x%llx), sense data are
0x%x/0x%x/0x%x",
+ ct->rdev, sbb[2]&0xf, sbb[12], sbb[13]);
+ MSG(c, str);
+ /*
+ * Retry if UNIT_ATTENTION check condition since
+ * this likely indicates a path group
re-assignment
+ * operation (trespass) took place.
+ */
+ if (((sbb[2]&0xf) == 6) && (sbb[12] == 0x29) &&
+ (sbb[13]==0)) {
+ if (--retry_count)
+ goto retry;
+ }
+ }
+ } else {
+ MSG(c, "emc_clariion_checker: Active path is healthy.");
+ /*
+ * Remove the path from the set of paths to inactive
+ * snapshot LUs if it was in this list since the
snapshot
+ * is no longer inactive.
+ */
+ UNFAILWWN(c);
+ }
+
+ return ret;
}
diff --git a/libcheckers/readsector0.c b/libcheckers/readsector0.c
index b0acec9..dd18528 100644
--- a/libcheckers/readsector0.c
+++ b/libcheckers/readsector0.c
@@ -34,8 +34,8 @@ void readsector0_free (struct checker *
return;
}
-static int
-sg_read (int sg_fd, unsigned char * buff)
+int
+sg_read (int sg_fd, unsigned char * buff, unsigned char * senseBuff)
{
/* defaults */
int blocks = 1;
@@ -45,7 +45,6 @@ sg_read (int sg_fd, unsigned char * buff
int * diop = NULL;
unsigned char rdCmd[cdbsz];
- unsigned char senseBuff[SENSE_BUFF_LEN];
struct sg_io_hdr io_hdr;
int res;
int rd_opcode[] = {0x8, 0x28, 0xa8, 0x88};
@@ -97,9 +96,10 @@ extern int
readsector0 (struct checker * c)
{
unsigned char buf[512];
+ unsigned char sbuf[SENSE_BUFF_LEN];
int ret;
- ret = sg_read(c->fd, &buf[0]);
+ ret = sg_read(c->fd, &buf[0], &sbuf[0]);
switch (ret)
{
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index efc2016..15fe89b 100644
--- a/libmultipath/discovery.c
+++ b/libmultipath/discovery.c
@@ -701,7 +701,14 @@ pathinfo (struct path *pp, vector hwtabl
if (mask & DI_CHECKER && get_state(pp))
goto blank;
- if (mask & DI_PRIO && pp->state != PATH_DOWN)
+
+ /*
+ * Path state of PATH_DOWN does not necessarily prevent
+ * path priority callout (or getuid callouot) from
+ * succeeding since the path may be being considered
+ * failed for reasons other than transport connectivity.
+ */
+ if (mask & DI_PRIO /*&& pp->state != PATH_DOWN*/)
get_prio(pp);
if (mask & DI_WWID && !strlen(pp->wwid))
^ permalink raw reply related
* Re: [uml-devel] [Pkg-uml-devel] Re: [Pkg-uml-pkgs] Bug#393263: uml-utilities: New version uml_utilities_20060622 has humsify, please update
From: Blaisorblade @ 2006-11-10 19:54 UTC (permalink / raw)
To: Jeff Dike
Cc: Pkg-UML developers, 393263, stefano.melchior,
user-mode-linux-user, user-mode-linux-devel
In-Reply-To: <20061031211155.GA6824@ccure.user-mode-linux.org>
On Tuesday 31 October 2006 22:11, Jeff Dike wrote:
> > About this, I'd have one question to pose to Jeff: when are you going to
> > include humfs in mainline? Last time I asked you this you said "ok", so I
> > can guess you'll send for next cycle (2.6.20). Is that right?
>
> Yeah, I was going to do it a couple of weeks ago, but then I decided to
> bang on it a bit. I fixed the inode refcount bugs that turned up, but you
> still get still some interesting link counts when removing directories.
>
> See the gory details in yesterday's diary entry.
Compliments for your work on this, I'm favourably impressed by this
improvements - I would also gather they apply to all externfs, i.e. both to
new hostfs and humfs?
That would be exceptionally good, however even humfs alone would be already
good for merging. And an earlier trip in -mm might help if somebody takes a
look at it (Al Viro did review our fs work in the past so he might decide to
give a look here too).
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* [RFT] mv643xxx_eth_start_xmit oops
From: Stephen Hemminger @ 2006-11-10 19:54 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20061110191745.GA13783@codepoet.org>
On Fri, 10 Nov 2006 12:17:45 -0700
Erik Andersen <andersen@codepoet.org> wrote:
> I have a Pegasos2 powerpc system acting as my home server. With
> 2.6.16.x it was 100% stable and I had months of uptime, rebooting
> only to periodically apply security updates to the kernel.
>
> With 2.6.17 and 2.6.18, after an uptime of no more than 2 days,
> and usually much less, I get a kernel panic, with nothing in the
> log. I finally caught it in the act, and took a picture.
> http://codepoet.org/oops.jpg
>
> A quick transcription of the Oops in the screenshot follows:
> --------------------------------------------
>
The code int mv643xx_eth_start_xmit is not safe on SMP it was checking for space outside of lock.
Does the following (untested) fix it?
0. Fix race where space check is outside of lock.
1. Eliminate bogus BUG_ON()'s
2. Use proper transmit routine return values
3. Cleanup potential kernel log overrun if hit with unaligned frags
4. Compare with actual space needed rather than worst case
5. Use correct return code for case of linearize() failure.
---
drivers/net/mv643xx_eth.c | 30 ++++++++++++++----------------
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 9997081..4052bfe 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1191,25 +1191,23 @@ static int mv643xx_eth_start_xmit(struct
struct net_device_stats *stats = &mp->stats;
unsigned long flags;
- BUG_ON(netif_queue_stopped(dev));
- BUG_ON(skb == NULL);
-
- if (mp->tx_ring_size - mp->tx_desc_count < MAX_DESCS_PER_SKB) {
- printk(KERN_ERR "%s: transmit with queue full\n", dev->name);
- netif_stop_queue(dev);
- return 1;
- }
-
- if (has_tiny_unaligned_frags(skb)) {
- if (__skb_linearize(skb)) {
- stats->tx_dropped++;
+ if (has_tiny_unaligned_frags(skb) && __skb_linearize(skb)) {
+ stats->tx_dropped++;
+ if (net_ratelimit())
printk(KERN_DEBUG "%s: failed to linearize tiny "
- "unaligned fragment\n", dev->name);
- return 1;
- }
+ "unaligned fragment\n", dev->name);
+ return NETDEV_TX_OK;
}
spin_lock_irqsave(&mp->lock, flags);
+ if (mp->tx_ring_size - mp->tx_desc_count < skb_shinfo(skb)->nr_frags + 1) {
+ if (!netif_queue_stopped(dev)) {
+ printk(KERN_ERR "%s: transmit with queue full\n", dev->name);
+ netif_stop_queue(dev);
+ }
+ spin_unlock_irqrestore(&mp->lock, flags);
+ return NETDEV_TX_BUSY;;
+ }
eth_tx_submit_descs_for_skb(mp, skb);
stats->tx_bytes = skb->len;
@@ -1221,7 +1219,7 @@ static int mv643xx_eth_start_xmit(struct
spin_unlock_irqrestore(&mp->lock, flags);
- return 0; /* success */
+ return NETDEV_TX_OK;
}
/*
--
1.4.1
--
Stephen Hemminger <shemminger@osdl.org>
^ permalink raw reply related
* [RFT] mv643xxx_eth_start_xmit oops
From: Stephen Hemminger @ 2006-11-10 19:54 UTC (permalink / raw)
To: Erik Andersen, Dale Farnsworth, Manish Lachwani; +Cc: netdev
In-Reply-To: <20061110191745.GA13783@codepoet.org>
On Fri, 10 Nov 2006 12:17:45 -0700
Erik Andersen <andersen@codepoet.org> wrote:
> I have a Pegasos2 powerpc system acting as my home server. With
> 2.6.16.x it was 100% stable and I had months of uptime, rebooting
> only to periodically apply security updates to the kernel.
>
> With 2.6.17 and 2.6.18, after an uptime of no more than 2 days,
> and usually much less, I get a kernel panic, with nothing in the
> log. I finally caught it in the act, and took a picture.
> http://codepoet.org/oops.jpg
>
> A quick transcription of the Oops in the screenshot follows:
> --------------------------------------------
>
The code int mv643xx_eth_start_xmit is not safe on SMP it was checking for space outside of lock.
Does the following (untested) fix it?
0. Fix race where space check is outside of lock.
1. Eliminate bogus BUG_ON()'s
2. Use proper transmit routine return values
3. Cleanup potential kernel log overrun if hit with unaligned frags
4. Compare with actual space needed rather than worst case
5. Use correct return code for case of linearize() failure.
---
drivers/net/mv643xx_eth.c | 30 ++++++++++++++----------------
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 9997081..4052bfe 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1191,25 +1191,23 @@ static int mv643xx_eth_start_xmit(struct
struct net_device_stats *stats = &mp->stats;
unsigned long flags;
- BUG_ON(netif_queue_stopped(dev));
- BUG_ON(skb == NULL);
-
- if (mp->tx_ring_size - mp->tx_desc_count < MAX_DESCS_PER_SKB) {
- printk(KERN_ERR "%s: transmit with queue full\n", dev->name);
- netif_stop_queue(dev);
- return 1;
- }
-
- if (has_tiny_unaligned_frags(skb)) {
- if (__skb_linearize(skb)) {
- stats->tx_dropped++;
+ if (has_tiny_unaligned_frags(skb) && __skb_linearize(skb)) {
+ stats->tx_dropped++;
+ if (net_ratelimit())
printk(KERN_DEBUG "%s: failed to linearize tiny "
- "unaligned fragment\n", dev->name);
- return 1;
- }
+ "unaligned fragment\n", dev->name);
+ return NETDEV_TX_OK;
}
spin_lock_irqsave(&mp->lock, flags);
+ if (mp->tx_ring_size - mp->tx_desc_count < skb_shinfo(skb)->nr_frags + 1) {
+ if (!netif_queue_stopped(dev)) {
+ printk(KERN_ERR "%s: transmit with queue full\n", dev->name);
+ netif_stop_queue(dev);
+ }
+ spin_unlock_irqrestore(&mp->lock, flags);
+ return NETDEV_TX_BUSY;;
+ }
eth_tx_submit_descs_for_skb(mp, skb);
stats->tx_bytes = skb->len;
@@ -1221,7 +1219,7 @@ static int mv643xx_eth_start_xmit(struct
spin_unlock_irqrestore(&mp->lock, flags);
- return 0; /* success */
+ return NETDEV_TX_OK;
}
/*
--
1.4.1
--
Stephen Hemminger <shemminger@osdl.org>
^ permalink raw reply related
* Re: [linux-lvm] LVM groups not visible
From: Lamont R. Peterson @ 2006-11-10 19:22 UTC (permalink / raw)
To: LVM
In-Reply-To: <1163174415.2961.95.camel@laguna.nwhq.nl>
[-- Attachment #1: Type: text/plain, Size: 7013 bytes --]
On Friday 10 November 2006 09:00am, J.L. Blom wrote:
> On Fri, 2006-11-10 at 09:27 -0600, Jonathan E Brassow wrote:
> > I can't imagine putting LVM on a USB drive... Are you sure LVM is even
> > involved here?
> >
> > You can type 'mount' or 'df' at the command prompt. That will tell you
> > how the usbdisk is mounted. If it is mounted from /dev/sda1 - then
> > there is no LVM in the mix.
> >
> > brassow
>
> Jonathan,
> Thanks for your reply.
> I didn't know that an USB disk couldn't be used for logical volumes as
> pvcreate and lvcreate did not complain.
> However, when I now do a lvscan it gives me:
> _______________________________________
> [root@laguna ~]# lvscan
> Couldn't find device with uuid
> 'G6vIxd-bp54-0zd0-PKzf-WI31-xPmr-qoeFAT'.
> Couldn't find all physical volumes for volume group VolGroup00.
> Couldn't find device with uuid
> 'G6vIxd-bp54-0zd0-PKzf-WI31-xPmr-qoeFAT'.
> Couldn't find all physical volumes for volume group VolGroup00.
> Volume group "VolGroup00" not found
> ACTIVE '/dev/VolGroup01/LogVol00' [9.75 GB] inherit
> ACTIVE '/dev/VolGroup01/LogVol02' [9.75 GB] inherit
> ACTIVE '/dev/VolGroup01/LogVol03' [4.88 GB] inherit
> ACTIVE '/dev/VolGroup01/LogVol04' [9.75 GB] inherit
> ACTIVE '/dev/VolGroup01/LogVol05' [9.75 GB] inherit
> ACTIVE '/dev/VolGroup01/LogVol01' [9.75 GB] inherit
> _________________________________________________________________
> As VolGroup00 is on the USB disk which I just had connected.
Looks like the USB device wasn't plugged in when the box was booted, perhaps?
> df gives:
> _____________________________________
> /dev/mapper/VolGroup01-LogVol00
> 9903432 1035860 8356392 12% /
> /dev/hda1 99043 25640 68289 28% /boot
> tmpfs 512492 0 512492 0% /dev/shm
> /dev/mapper/VolGroup01-LogVol02
> 9903432 1789628 7602624 20% /home
> /dev/mapper/VolGroup01-LogVol03
> 4951688 4137648 558452 89% /usr
> /dev/mapper/VolGroup01-LogVol04
> 9903432 342224 9050028 4% /usr/local
> /dev/mapper/VolGroup01-LogVol05
> 9903432 761312 8630940 9% /var
>
> /dev/sda1 240362656 38037368 190115488 17% /media/disk
> ___________________________________________________
>
> and fdisk says:
Next time, try running "fdisk -l /dev/sda" (or just "fdisk -l" to see all of
them).
> _____________________________________________________
> The number of cylinders for this disk is set to 30400.
> There is nothing wrong with that, but this is larger than 1024,
> and could in certain setups cause problems with:
> 1) software that runs at boot time (e.g., old versions of LILO)
> 2) booting and partitioning software from other OSs
> (e.g., DOS FDISK, OS/2 FDISK)
Standard thing to see. It's a mostly stupid warning these days, as every
desktop & notebook motherboard made in the past 8 years (or so) has LBA
support out of the box, so it isn't an issue. In other words, you can just
ignore that.
> Warning: invalid flag 0x0000 of partition table 4 will be corrected by
> w(rite)
That sometimes happens when the partition table was initially created by some
other tool (like Windows, or Partition Magic), as they don't all do exactly
the same thing with some parts of it. Given that the "offending" flag's
value was 0x0000, I think it be that it was just never set by the other tool.
However, that's not why this is happening in this case (read the next bit to
see what's up).
> Command (m for help): p
>
> Disk /dev/sda1: 250.0 GB, 250056705024 bytes
> 255 heads, 63 sectors/track, 30400 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot Start End Blocks Id System
>
> Command (m for help): q
This is blank because you are trying to read a partition table from the 1st
partition. You ran "fdisk /dev/sda1" not "fdisk /dev/sda" as it should have
been. I hate it when I do that :) .
> ______________________________________
> So I'm at a loss how this is possible. The disk can be reached but
> neither lvm nor fdisk can tell me what's on the disk,
Since it's a USB disk, I would guess that it wasn't inserted when you booted
your box. So, when LVM was being set up by /etc/rc.sysinit, it didn't find
that device. If you did another "pvscan" after inserting the USB disk, it
might find it.
I already covered the problem with fdisk.
> Can you perhaps shine some light on it?
OK. Overall, I wouldn't bother trying to use LVM with a removable drive
(USB/Firewire hard drives, keychain drives, etc.). I can think of one
possibly viable way of doing it, but I still probably wouldn't even in that
case, because it wouldn't really give you any benefits.
So, if you have already included the USB drive into your VG(s), get everything
plugged in, make sure pvdisplay, vgdisplay, lvscan and friends are all happy,
then run "pvmove /dev/sda1". This will move any data you may have on there
to other drives (the one built in to your box).
In this thread, everyone has been *assuming* that your USB disk is /dev/sda.
If your main hard drive is SATA or SCSI, it very well could be /dev/sda and
your USB drive could be /dev/sdb or some other device; i.e., the last letter
in the device name could be 'a', 'b', 'c', etc. Run "fdisk -l" to see a list
of all the hard drives your system currently sees without the USB drive
plugged in, then plug it in and re-run "fdisk -l" and the extra one the
second time is your USB drive. Make sure you use the correct device name in
your pvmove command.
Once the pvmove command is finished, you can safely "redo" your USB device.
If it's a hard drive, format it with ext3 or reiserfs or jfs or xfs (as you
prefer). If it's a flash device, I would recommend that you look at using
JFFS2 for the filesystem. Either way, make sure that the "type" (i.e. System
ID) of the partition on your USB device is "83" (for regular Linux
filesystems) and not "8e" (which is for Linux LVM PVs).
> (sorry for the long mail).
np. HTH.
[snip]
--
Lamont Peterson <peregrine@OpenBrainstem.net>
Founder [ http://blog.OpenBrainstem.net/peregrine/ ]
GPG Key fingerprint: 0E35 93C5 4249 49F0 EC7B 4DDD BE46 4732 6460 CCB5
___ ____ _ _
/ _ \ _ __ ___ _ __ | __ ) _ __ __ _(_)_ __ ___| |_ ___ _ __ ___
| | | | '_ \ / _ \ '_ \| _ \| '__/ _` | | '_ \/ __| __/ _ \ '_ ` _ \
| |_| | |_) | __/ | | | |_) | | | (_| | | | | \__ \ || __/ | | | | |
\___/| .__/ \___|_| |_|____/|_| \__,_|_|_| |_|___/\__\___|_| |_| |_|
|_| Intelligent Open Source Software Engineering
[ http://www.OpenBrainstem.net/ ]
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1
From: robert corley @ 2006-11-10 19:53 UTC (permalink / raw)
To: linux linuxppc-embedded
Rimas;=0A=0AGood call on the PHY address. I thought that I was on to somet=
hing when=0AI saw that a week or so ago; however, after I checked the datas=
heet on the=0AMARVELL 88E1111 PHY chip and its connection on the ML403 boar=
d, I=0Afound that it is addressed to 0b00000.=0A=0AIt does appear that acce=
ss to the mgmt registers is working, albeit not completely=0Aas expected (s=
ee boot dump, below) with regards to the PHY ID.=0A=0AThe initialization pr=
ocess is pretty simple:=0A=0A1. Query the PHY [using XTemac_PhyRead(...)=
] and see what speed it's set to:=0A=0A [ 5.358347] XTemac(set_mac_sp=
eed): PHY Speed from XTemac_PhyRead() =3D 0M, where 2=3D1000M, 1=3D100M, an=
d 0=3D10M=0A=0A=0A2. Set the MAC to the same speed (in a switch statemen=
t):=0A XTemac_SetOperatingSpeed(&lp->Emac, 10);=0A=0AI suspect t=
hat the problem is with the first step as it is reporting a different speed=
than what the LED's on the board show.=0A=0AAny thoughts?=0A =0ARobert Cor=
ley (rdcorle@yahoo.com)=0A=0A=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Apartial boot dump fol=
lows...=0A=0A=0A[ 2.706547] XTemac (xtenet_probe): Device initialized to=
:=0A[ 2.712064] Device ID 0=0A[ 2.714595] Base Addr 0x6=
0000000=0A[ 2.717918] Rx FIFO 131072=0A[ 2.720723] Tx FIFO=
131072=0A[ 2.723508] MAC FIFO 64=0A[ 2.726052] DMA mod=
e 3=0A[ 2.728514] TX Dre 2=0A[ 2.730782] Rx Dre 2=0A=
[ 2.733067] Tx CSUM 0=0A[ 2.735421] Rx CSUM 0=0A[ 2.=
737792] Phy Type 1=0A[ 2.740268] XTemac (xtenet_probe): MAC initi=
alized to: 00:0A:35:00:22:00=0A[ 2.746964] XTemac: using sgDMA mode.=0A[=
2.750637] XTemac: using TxDRE mode=0A[ 2.754221] XTemac: using RxDRE=
mode=0A[ 2.757815] XTemac: buffer descriptor size: 32768 (0x8000)=0A[ =
2.763779] XTemac: (buffer_descriptor_init) phy: 0x978000, virt: 0xff10000=
0, size: 0x8000=0A[ 2.777432] eth0: Dropping NETIF_F_SG since no checksu=
m feature.=0A[ 2.784323] eth0: Xilinx TEMAC #0 at 0x60000000 mapped to 0=
xC5050000, irq=3D0=0A[ 2.791327] eth0: XTemac id 1.0f, block id 5, type =
8=0A[ 2.796886] mice: PS/2 mouse device common for all mice=0A[ 2.802=
782] TCP bic registered=0A[ 3.308299] eth0: XTemac: Options: 0xb8f2=0A[ =
5.306282] XTemac(marvell_reset): Marvell 88E1111 reset.=0A[ 5.311715]=
XTemac: (set_mac_speed) Marvell 88E1111 basic-mode status register(#1) =3D=
0x0148=0A[ 5.320083] XTemac: (set_mac_speed) Marvell 88E1111 PHY ID 1 =
=3D 0x0000=0A[ 5.326547] XTemac: (set_mac_speed) Marvell 88E1111 PHY ID =
2 =3D 0x0400=0A[ 5.333009] XTemac: (set_mac_speed) Marvell 88E1111 1000B=
ASE-T status register(#10) =3D 0x0000=0A[ 5.341466] XTemac: (set_mac_spe=
ed) Marvell 88E1111 extended status register(#15) =3D 0x0000=0A[ 5.34975=
2] XTemac: (set_mac_speed) Marvell 88E1111 PHY specific status register(#17=
) =3D 0x0000=0A[ 5.358347] XTemac(set_mac_speed): PHY Speed from XTemac_=
PhyRead() =3D 0M, where 2=3D1000M, 1=3D100M, and 0=3D10M=0A[ 5.367887] e=
th0: XTemac: EMAC speed set to 10Mb/s=0A[ 5.372666] XTemac (set_mac_spee=
d): verifying speed settings. Expect 10M=0A[ 5.379480] XTemac: (set_mac=
_speed) Marvell 88E1111 PHY specific status register(#17) =3D 0x0900=0A[ =
5.388074] eth0: XTemac: PHY Speed from XTemac_PhyRead() =3D 0M, where 2=3D=
1000M, 1=3D100M, and 0=3D10M=0A[ 5.396839] eth0: XTemac: EMAC Speed from=
XTemac_GetOperatingSpeed() =3D 10M=0A[ 5.405544] eth0: XTemac: Send Thr=
eshold =3D 16, Receive Threshold =3D 2=0A[ 5.411917] eth0: XTemac: Send =
Wait bound =3D 1, Receive Wait bound =3D 1=0A[ 6.420309] IP-Config: Comp=
lete:=0A[ 6.423375] device=3Deth0, addr=3D192.168.1.100, mask=3D25=
5.255.255.0, gw=3D192.168.1.1,=0A[ 6.431272] host=3Dnab, domain=3D,=
nis-domain=3D(none),=0A[ 6.436422] bootserver=3D192.168.1.144, roo=
tserver=3D192.168.1.144, rootpath=3D=0A=0A=0A=0A=0A=0A
^ permalink raw reply
* Re: Generic Netlink HOW-TO based on Jamal's original doc
From: Paul Moore @ 2006-11-10 19:50 UTC (permalink / raw)
To: Randy Dunlap; +Cc: hadi, tgraf, netdev
In-Reply-To: <20061110102318.7b344d30.randy.dunlap@oracle.com>
Randy Dunlap wrote:
> On Fri, 10 Nov 2006 01:08:23 -0500 Paul Moore wrote:
>
>>An Introduction To Using Generic Netlink
>>===============================================================================
>>3.1.2. The genl_family Structure
>>
>>Generic Netlink services are defined by the genl_family structure, which is
>>shown below:
>>
>> struct genl_family
>> {
>> unsigned int id;
>> unsigned int hdrsize;
>> char name[GENL_NAMSIZ];
>> unsigned int version;
>> unsigned int maxattr;
>> struct nlattr ** attrbuf;
>> struct list_head ops_list;
>> struct list_head family_list;
>> };
>
> Any alignment/packing concerns here? or that is already
> handled, just not presented here?
>
> and same questions for other structs below (deleted).
These structure contents/layout were taken straight from the code.
> Typo patch attached.
Applied, thanks.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: A proposal; making 2.6.20 a bugfix only version.
From: Arjan van de Ven @ 2006-11-10 19:49 UTC (permalink / raw)
To: Al Boldi; +Cc: Randy Dunlap, Stephen Hemminger, Jesper Juhl, linux-kernel
In-Reply-To: <200611102233.30542.a1426z@gawab.com>
>
> The problem is not just simple bugs that surface, it's deeper than that.
> Deep structural problems is what plagues 2.6.
>
> Only a focused model may deal with such problems.
can you at least provide a list of such structural problems?
In fact, why don't you collect them and mail them out (bi)weekly... that
may already do wonders.
Look at what Adrian is doing with the regressions; although the response
isn't 100% people DO pay attention to it.... so maybe if you post a
"structural problems list" people will actually start working on
things.. (and of course you can help too ;)
^ permalink raw reply
* Re: Non-ASCII paths and git-cvsserver
From: Junio C Hamano @ 2006-11-10 19:49 UTC (permalink / raw)
To: sf; +Cc: git, Martin Langhoff
In-Reply-To: <45530CEE.6030008@b-i-t.de>
sf <sf@b-i-t.de> writes:
> I want to access a git repository via git-cvsserver. The problem is
> that the repository contains paths with umlauts. These paths come out
> quoted and escaped when checked out with cvs.
I think this is because the cvsserver invokes diff-tree and
ls-tree without -z and the output from these command quote
non-ascii letters as unsafe.
Martin's sqlite may probably be needed as well, but regardless
of that something like this patch is needed -- otherwise what
populates sqlite database will be quoted to begin with so it
would not help much.
I've tested with your reproduction recipe, but otherwise not
tested this patch.
-- >8 --
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 8817f8b..ca519b7 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2343,67 +2343,72 @@ sub update
if ( defined ( $lastpicked ) )
{
- my $filepipe = open(FILELIST, '-|', 'git-diff-tree', '-r', $lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree : $!");
+ my $filepipe = open(FILELIST, '-|', 'git-diff-tree', '-z', '-r', $lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree : $!");
+ local ($/) = "\0";
while ( <FILELIST> )
{
- unless ( /^:\d{6}\s+\d{3}(\d)\d{2}\s+[a-zA-Z0-9]{40}\s+([a-zA-Z0-9]{40})\s+(\w)\s+(.*)$/o )
+ chomp;
+ unless ( /^:\d{6}\s+\d{3}(\d)\d{2}\s+[a-zA-Z0-9]{40}\s+([a-zA-Z0-9]{40})\s+(\w)$/o )
{
die("Couldn't process git-diff-tree line : $_");
}
+ my ($mode, $hash, $change) = ($1, $2, $3);
+ my $name = <FILELIST>;
+ chomp($name);
- # $log->debug("File mode=$1, hash=$2, change=$3, name=$4");
+ # $log->debug("File mode=$mode, hash=$hash, change=$change, name=$name");
my $git_perms = "";
- $git_perms .= "r" if ( $1 & 4 );
- $git_perms .= "w" if ( $1 & 2 );
- $git_perms .= "x" if ( $1 & 1 );
+ $git_perms .= "r" if ( $mode & 4 );
+ $git_perms .= "w" if ( $mode & 2 );
+ $git_perms .= "x" if ( $mode & 1 );
$git_perms = "rw" if ( $git_perms eq "" );
- if ( $3 eq "D" )
+ if ( $change eq "D" )
{
- #$log->debug("DELETE $4");
- $head->{$4} = {
- name => $4,
- revision => $head->{$4}{revision} + 1,
+ #$log->debug("DELETE $name");
+ $head->{$name} = {
+ name => $name,
+ revision => $head->{$name}{revision} + 1,
filehash => "deleted",
commithash => $commit->{hash},
modified => $commit->{date},
author => $commit->{author},
mode => $git_perms,
};
- $self->insert_rev($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($name, $head->{$name}{revision}, $hash, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
- elsif ( $3 eq "M" )
+ elsif ( $change eq "M" )
{
- #$log->debug("MODIFIED $4");
- $head->{$4} = {
- name => $4,
- revision => $head->{$4}{revision} + 1,
- filehash => $2,
+ #$log->debug("MODIFIED $name");
+ $head->{$name} = {
+ name => $name,
+ revision => $head->{$name}{revision} + 1,
+ filehash => $hash,
commithash => $commit->{hash},
modified => $commit->{date},
author => $commit->{author},
mode => $git_perms,
};
- $self->insert_rev($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($name, $head->{$name}{revision}, $hash, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
- elsif ( $3 eq "A" )
+ elsif ( $change eq "A" )
{
- #$log->debug("ADDED $4");
- $head->{$4} = {
- name => $4,
+ #$log->debug("ADDED $name");
+ $head->{$name} = {
+ name => $name,
revision => 1,
- filehash => $2,
+ filehash => $hash,
commithash => $commit->{hash},
modified => $commit->{date},
author => $commit->{author},
mode => $git_perms,
};
- $self->insert_rev($4, $head->{$4}{revision}, $2, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
+ $self->insert_rev($name, $head->{$name}{revision}, $hash, $commit->{hash}, $commit->{date}, $commit->{author}, $git_perms);
}
else
{
- $log->warn("UNKNOWN FILE CHANGE mode=$1, hash=$2, change=$3, name=$4");
+ $log->warn("UNKNOWN FILE CHANGE mode=$mode, hash=$hash, change=$change, name=$name");
die;
}
}
@@ -2412,10 +2417,12 @@ sub update
# this is used to detect files removed from the repo
my $seen_files = {};
- my $filepipe = open(FILELIST, '-|', 'git-ls-tree', '-r', $commit->{hash}) or die("Cannot call git-ls-tree : $!");
+ my $filepipe = open(FILELIST, '-|', 'git-ls-tree', '-z', '-r', $commit->{hash}) or die("Cannot call git-ls-tree : $!");
+ local $/ = "\0";
while ( <FILELIST> )
{
- unless ( /^(\d+)\s+(\w+)\s+([a-zA-Z0-9]+)\s+(.*)$/o )
+ chomp;
+ unless ( /^(\d+)\s+(\w+)\s+([a-zA-Z0-9]+)\t(.*)$/o )
{
die("Couldn't process git-ls-tree line : $_");
}
^ permalink raw reply related
* Fix for unassigned errno in xenstored_core.c
From: Magnus Carlsson @ 2006-11-10 19:45 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <eacc82a40610311232o71fa6e84g64c20c03ca21e810@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Dear all,
In certain cases, when a client doesn't have enough permissions, the
errno variable is not set in xenstored_core.c before its value is
reported back. As a result, the client can learn about the errno of the
last failed request to xenstored (which could have come from another
client). (An unintended information channel! :-)
Attached is a patch that I believe fixes the problem. Also included are
a couple of test cases that demonstrate the problem.
Cheers,
Magnus
[-- Attachment #2: xenstored_core.patch --]
[-- Type: text/x-patch, Size: 690 bytes --]
*** xenstore/xenstored_core.c Sun Apr 9 15:05:54 2006
--- xs/xenstored_core.c Fri Nov 3 15:57:13 2006
***************
*** 555,562 ****
/* If we don't have permission, we don't have node. */
if (node) {
if ((perm_for_conn(conn, node->perms, node->num_perms) & perm)
! != perm)
node = NULL;
}
/* Clean up errno if they weren't supposed to know. */
if (!node)
--- 555,564 ----
/* If we don't have permission, we don't have node. */
if (node) {
if ((perm_for_conn(conn, node->perms, node->num_perms) & perm)
! != perm) {
! errno = EACCES;
node = NULL;
+ }
}
/* Clean up errno if they weren't supposed to know. */
if (!node)
[-- Attachment #3: 99permissions.test --]
[-- Type: text/plain, Size: 255 bytes --]
write /a/b v
setperm /a 1 READ
setperm /a/b 1 NONE
expect read failed: No such file or directory
read /nonexistent
setid 2
# this should presumably fail with EACCES, but fails with previous error instead
expect read failed: Permission denied
read /a/b
[-- Attachment #4: 99permissions2.test --]
[-- Type: text/plain, Size: 236 bytes --]
write /a/b v
setperm /a 1 READ
setperm /a/b 1 NONE
expect read failed: Invalid argument
read //
setid 2
# this should presumably fail with EACCES, but fails with previous error instead
expect read failed: Permission denied
read /a/b
[-- Attachment #5: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [Cluster-devel] conga/luci cluster/form-chooser cluster/form-m ...
From: rmccabe @ 2006-11-10 19:44 UTC (permalink / raw)
To: cluster-devel.redhat.com
CVSROOT: /cvs/cluster
Module name: conga
Changes by: rmccabe at sourceware.org 2006-11-10 19:44:57
Modified files:
luci/cluster : form-chooser form-macros portlet_cluconfig
resource-form-macros resource_form_handlers.js
luci/site/luci/Extensions: cluster_adapters.py
Log message:
- fix the redirection upon completion of async ricci tasks
- fix a bug that caused adding nfs mount resources to fail
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/cluster/form-chooser.diff?cvsroot=cluster&r1=1.12&r2=1.13
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/cluster/form-macros.diff?cvsroot=cluster&r1=1.102&r2=1.103
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/cluster/portlet_cluconfig.diff?cvsroot=cluster&r1=1.2&r2=1.3
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/cluster/resource-form-macros.diff?cvsroot=cluster&r1=1.23&r2=1.24
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/cluster/resource_form_handlers.js.diff?cvsroot=cluster&r1=1.21&r2=1.22
http://sourceware.org/cgi-bin/cvsweb.cgi/conga/luci/site/luci/Extensions/cluster_adapters.py.diff?cvsroot=cluster&r1=1.160&r2=1.161
--- conga/luci/cluster/form-chooser 2006/10/16 20:25:33 1.12
+++ conga/luci/cluster/form-chooser 2006/11/10 19:44:57 1.13
@@ -12,7 +12,7 @@
<span tal:condition="not: busywaiting">
<span tal:omit-tag="" tal:define="global ptype request/pagetype |nothing"/>
<span tal:omit-tag="" tal:condition="python: not ptype">
- <div metal:use-macro="here/form-macros/macros/entry-form"/>
+ <div metal:use-macro="here/form-macros/macros/clusters-form"/>
</span>
<span tal:omit-tag="" tal:condition="python: ptype == '0' or ptype == '1' or ptype == '2' or ptype == '3'">
<div metal:use-macro="here/form-macros/macros/clusters-form"/>
--- conga/luci/cluster/form-macros 2006/11/09 20:32:02 1.102
+++ conga/luci/cluster/form-macros 2006/11/10 19:44:57 1.103
@@ -7,7 +7,6 @@
<body>
<div metal:define-macro="entry-form">
- <h2>Entry Form</h2>
</div>
<div metal:define-macro="busywaitpage">
--- conga/luci/cluster/portlet_cluconfig 2006/09/27 22:24:11 1.2
+++ conga/luci/cluster/portlet_cluconfig 2006/11/10 19:44:57 1.3
@@ -10,7 +10,7 @@
<dl class="portlet" id="portlet-cluconfig-tree">
<dt class="portletHeader">
- <a href="#">
+ <a href="/luci/cluster/index_html?pagetype=3">
Clusters
</a>
</dt>
@@ -36,7 +36,8 @@
<dl class="portlet" id="portlet-cluconfig-tree">
<dt class="portletHeader">
- <a href="#" tal:attributes="href python:here.getClusterURL(request,modelb)">
+ <a href="/luci/cluster/index_html?pagetype=3"
+ tal:attributes="href python:here.getClusterURL(request,modelb)">
<div tal:omit-tag="" tal:content="python: here.getClusterAlias(modelb)" />
</a>
</dt>
--- conga/luci/cluster/resource-form-macros 2006/11/07 21:33:52 1.23
+++ conga/luci/cluster/resource-form-macros 2006/11/10 19:44:57 1.24
@@ -684,14 +684,12 @@
<input type="radio" name="nfstype" value="nfs"
tal:attributes="
disabled python: editDisabled;
- content string: NFS (version 3);
- checked python: nfstype == 'nfs' and 'checked'" />
+ checked python: nfstype != 'nfs4' and 'checked'" />NFS3
<br/>
<input type="radio" name="nfstype" value="nfs4"
tal:attributes="
disabled python: editDisabled;
- content string: NFS4;
- checked python: nfstype == 'nfs4' and 'checked'" />
+ checked python: nfstype == 'nfs4' and 'checked'" />NFS4
</td>
</tr>
--- conga/luci/cluster/resource_form_handlers.js 2006/10/30 21:21:16 1.21
+++ conga/luci/cluster/resource_form_handlers.js 2006/11/10 19:44:57 1.22
@@ -101,7 +101,7 @@
function validate_nfs_mount(form) {
var errors = new Array();
- if (!form.mountpoint || str_is_blank(form.mounpoint.value)) {
+ if (!form.mountpoint || str_is_blank(form.mountpoint.value)) {
errors.push('No mount point was given.');
set_form_err(form.mountpoint);
} else
--- conga/luci/site/luci/Extensions/cluster_adapters.py 2006/11/10 18:18:09 1.160
+++ conga/luci/site/luci/Extensions/cluster_adapters.py 2006/11/10 19:44:57 1.161
@@ -901,13 +901,13 @@
cname = None
try:
cname = request[CLUNAME]
- except KeyError, e:
+ except:
cname = ""
try:
url = request['URL']
- except KeyError, e:
- url = "."
+ except:
+ url = "/luci/cluster/index_html"
try:
pagetype = request[PAGETYPE]
@@ -998,13 +998,13 @@
#There should be a positive page type
try:
pagetype = request[PAGETYPE]
- except KeyError, e:
+ except:
pagetype = '3'
try:
url = request['URL']
except KeyError, e:
- url = "."
+ url = "/luci/cluster/index_html"
#The only way this method can run is if there exists
#a clustername query var
@@ -1444,7 +1444,7 @@
else:
selectedtab = "homebase"
except KeyError, e:
- pass
+ selectedtab = None
htab = { 'Title':"homebase",
'Description':"Home base for this luci server",
@@ -1457,7 +1457,7 @@
ctab = { 'Title':"cluster",
'Description':"Cluster configuration page",
- 'Taburl':"/luci/cluster?pagetype=3"}
+ 'Taburl':"/luci/cluster/index_html?pagetype=3"}
if selectedtab == "cluster":
ctab['isSelected'] = True
else:
@@ -1633,18 +1633,18 @@
baseurl = req['URL']
if not baseurl:
raise KeyError, 'is blank'
- except KeyError, e:
- baseurl = '.'
+ except:
+ baseurl = '/luci/cluster/index_html'
try:
cluname = req['clustername']
if not cluname:
raise KeyError, 'is blank'
- except KeyError, e:
+ except:
try:
cluname = req.form['clusterName']
if not cluname:
- raise
+ raise KeyError, 'is blank'
except:
cluname = '[error retrieving cluster name]'
@@ -1678,8 +1678,8 @@
baseurl = req['URL']
if not baseurl:
raise KeyError, 'is blank'
- except KeyError, e:
- baseurl = '.'
+ except:
+ baseurl = '/luci/cluster/index_html'
try:
cluname = req['clustername']
@@ -1835,7 +1835,7 @@
luci_log.debug_verbose('startService4: error setting flags for service %s at node %s for cluster %s' % (svcname, nodename, cluname))
response = req.RESPONSE
- response.redirect(req['HTTP_REFERER'] + "&busyfirst=true")
+ response.redirect(req['URL'] + "?pagetype=" + SERVICE_LIST + "&clustername=" + cluname + '&busyfirst=true')
def serviceRestart(self, rc, req):
svcname = None
@@ -1875,7 +1875,7 @@
luci_log.debug_verbose('serviceRestart3: error setting flags for service %s for cluster %s' % (svcname, cluname))
response = req.RESPONSE
- response.redirect(req['HTTP_REFERER'] + "&busyfirst=true")
+ response.redirect(req['URL'] + "?pagetype=" + SERVICE_LIST + "&clustername=" + cluname + '&busyfirst=true')
def serviceStop(self, rc, req):
svcname = None
@@ -1915,7 +1915,7 @@
luci_log.debug_verbose('serviceStop3: error setting flags for service %s for cluster %s' % (svcname, cluname))
response = req.RESPONSE
- response.redirect(req['HTTP_REFERER'] + "&busyfirst=true")
+ response.redirect(req['URL'] + "?pagetype=" + SERVICE_LIST + "&clustername=" + cluname + '&busyfirst=true')
def getFdomsInfo(self, modelb, request, clustatus):
slist = list()
@@ -2031,7 +2031,7 @@
response = request.RESPONSE
response.redirect('%s?pagetype=%s&clustername=%s&busyfirst=true' \
- % (request['URL'], CLUSTER, model.getClusterName()))
+ % (request['URL'], NODES, model.getClusterName()))
def getClusterInfo(self, model, req):
try:
@@ -2638,39 +2638,35 @@
luci_log.debug_verbose('NTP: nodeLeave failed')
return None
- #Is this correct? Should we re-direct to the cluster page?
response = request.RESPONSE
- response.redirect(request['URL'] + "?pagetype=" + CLUSTER_CONFIG + "&clustername=" + clustername)
+ response.redirect(request['URL'] + "?pagetype=" + NODE_LIST + "&clustername=" + clustername + '&busyfirst=true')
elif task == NODE_JOIN_CLUSTER:
if nodeJoin(self, rc, clustername, nodename_resolved) is None:
luci_log.debug_verbose('NTP: nodeJoin failed')
return None
- #Once again, is this correct? Should we re-direct to the cluster page?
response = request.RESPONSE
- response.redirect(request['URL'] + "?pagetype=" + CLUSTER_CONFIG + "&clustername=" + clustername)
+ response.redirect(request['URL'] + "?pagetype=" + NODE_LIST + "&clustername=" + clustername + '&busyfirst=true')
elif task == NODE_REBOOT:
if forceNodeReboot(self, rc, clustername, nodename_resolved) is None:
luci_log.debug_verbose('NTP: nodeReboot failed')
return None
- #Once again, is this correct? Should we re-direct to the cluster page?
response = request.RESPONSE
- response.redirect(request['URL'] + "?pagetype=" + CLUSTER_CONFIG + "&clustername=" + clustername)
+ response.redirect(request['URL'] + "?pagetype=" + NODE_LIST + "&clustername=" + clustername + '&busyfirst=true')
elif task == NODE_FENCE:
if forceNodeFence(self, clustername, nodename, nodename_resolved) is None:
luci_log.debug_verbose('NTP: nodeFencefailed')
return None
- #Once again, is this correct? Should we re-direct to the cluster page?
response = request.RESPONSE
- response.redirect(request['URL'] + "?pagetype=" + CLUSTER_CONFIG + "&clustername=" + clustername)
+ response.redirect(request['URL'] + "?pagetype=" + NODE_LIST + "&clustername=" + clustername + '&busyfirst=true')
elif task == NODE_DELETE:
if nodeDelete(self, rc, model, clustername, nodename, nodename_resolved) is None:
luci_log.debug_verbose('NTP: nodeDelete failed')
return None
response = request.RESPONSE
- response.redirect(request['HTTP_REFERER'] + "&busyfirst=true")
+ response.redirect(request['URL'] + "?pagetype=" + NODE_LIST + "&clustername=" + clustername + '&busyfirst=true')
def getNodeInfo(self, model, status, request):
infohash = {}
@@ -3360,7 +3356,7 @@
luci_log.debug('ICB5: An error occurred while looking for cluster %s flags at path %s' % (cluname, path))
return map
- luci_log.debug_verbose('ICB6: isClusterBusy: %s is busy: %d flags' \
+ luci_log.debug_verbose('ICB6: %s is busy: %d flags' \
% (cluname, len(items)))
map['busy'] = "true"
#Ok, here is what is going on...if there is an item,
@@ -3541,7 +3537,7 @@
try:
clusterfolder.manage_delObjects(item[0])
except Exception, e:
- luci_log.info('Unable to delete %s: %s' % (item[0], str(e)))
+ luci_log.info('ICB16: Unable to delete %s: %s' % (item[0], str(e)))
else:
node_report = {}
map['busy'] = "true"
@@ -3563,7 +3559,12 @@
map['refreshurl'] = "5; url=" + wholeurl
req['specialpagetype'] = "1"
else:
- map['refreshurl'] = '5; url=\".\"'
+ try:
+ query = req['QUERY_STRING'].replace('&busyfirst=true', '')
+ map['refreshurl'] = '5; url=' + req['ACTUAL_URL'] + '?' + query
+ except:
+ map['refreshurl'] = '5; url=/luci/cluster?pagetype=3'
+ luci_log.debug_verbose('ICB17: refreshurl is \"%s\"' % map['refreshurl'])
return map
def getClusterOS(self, rc):
@@ -3739,7 +3740,7 @@
luci_log.debug_verbose('delResource7: failed to set flags: %s' % str(e))
response = request.RESPONSE
- response.redirect(request['HTTP_REFERER'] + "&busyfirst=true")
+ response.redirect(request['URL'] + "?pagetype=" + RESOURCES + "&clustername=" + clustername + '&busyfirst=true')
def addIp(request, form=None):
if form is None:
@@ -4452,7 +4453,7 @@
luci_log.debug_verbose('addResource7: failed to set flags: %s' % str(e))
response = request.RESPONSE
- response.redirect(request['HTTP_REFERER'] + "&busyfirst=true")
+ response.redirect(request['URL'] + "?pagetype=" + RESOURCES + "&clustername=" + clustername + '&busyfirst=true')
def getResourceForEdit(modelb, name):
resPtr = modelb.getResourcesPtr()
^ permalink raw reply
* Re: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly
From: Jeremy Fitzhardinge @ 2006-11-10 19:38 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Avi Kivity, Arnd Bergmann, kvm-devel, akpm, linux-kernel
In-Reply-To: <6e0cfd1d0611100446j77a27b29jc23f76a515451377@mail.gmail.com>
Martin Schwidefsky wrote:
> On 11/10/06, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>> >> Or gcc
>> >> might move the assignment of phys_addr to after the inline assembly.
>> >>
>> > "asm volatile" prevents that (and I'm not 100% sure it's necessary).
>>
>> No, it won't necessarily. "asm volatile" simply forces gcc to emit the
>> assembler, even if it thinks its output doesn't get used. It makes no
>> ordering guarantees with respect to other code (or even other "asm
>> volatiles"). The "memory" clobbers should fix the ordering of the asms
>> though.
>
> The "memory" clobber just tells the compiler that any memory object
> might get access by the inline.
I just meant that two asms with a "memory" clobber will be generated
with a fixed ordering, which "asm volatile" does not necessarily do.
J
^ permalink raw reply
* Re: [PATCH] KVM: Avoid using vmx instruction directly
From: Jeremy Fitzhardinge @ 2006-11-10 19:38 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, akpm-3NddpPZAyC0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <6e0cfd1d0611100446j77a27b29jc23f76a515451377-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Martin Schwidefsky wrote:
> On 11/10/06, Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org> wrote:
>> >> Or gcc
>> >> might move the assignment of phys_addr to after the inline assembly.
>> >>
>> > "asm volatile" prevents that (and I'm not 100% sure it's necessary).
>>
>> No, it won't necessarily. "asm volatile" simply forces gcc to emit the
>> assembler, even if it thinks its output doesn't get used. It makes no
>> ordering guarantees with respect to other code (or even other "asm
>> volatiles"). The "memory" clobbers should fix the ordering of the asms
>> though.
>
> The "memory" clobber just tells the compiler that any memory object
> might get access by the inline.
I just meant that two asms with a "memory" clobber will be generated
with a fixed ordering, which "asm volatile" does not necessarily do.
J
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* [PATCH] H4 / 2430SDP ethernet IRQ flags fix
From: Syed Mohammed, Khasim @ 2006-11-10 19:36 UTC (permalink / raw)
To: linux-omap-open-source
In-Reply-To: <77C7F7CB1230A74A9D19C0C111E6EDBE01D91956@DLEE09.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 197 bytes --]
Hi Tony,
The attached patch configures the Ethernet IRQ flag on H4 / 2430SDP to
IRQF_TRIGGER_LOW
This has been tested and validated on 2430 SDP and H4 board.
Thanks & Regards,
Khasim
[-- Attachment #2: ethernet_fix_H4_2430.patch --]
[-- Type: application/octet-stream, Size: 1074 bytes --]
This patch configures the Ethernet IRQ flag on H4 / 2430SDP to IRQF_TRIGGER_LOW.
Signed-off-by: Syed Mohammed Khasim <x0khasim@ti.com>
Files changed:
smc91x.h | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
==============================================================================
diff -purN linux-omap/drivers/net/smc91x.h dev-linux-omap-2.6.git/drivers/net/smc91x.h
--- linux-omap/drivers/net/smc91x.h 2006-11-02 00:16:21.000000000 -0600
+++ dev-linux-omap-2.6.git/drivers/net/smc91x.h 2006-11-10 13:22:53.000000000 -0600
@@ -193,11 +193,12 @@ SMC_outw(u16 val, void __iomem *ioaddr,
#include <asm/arch/cpu.h>
#define SMC_IRQ_FLAGS (( \
- machine_is_omap_h2() \
+ machine_is_omap_h2() \
|| machine_is_omap_h3() \
- || machine_is_omap_h4() \
|| (machine_is_omap_innovator() && !cpu_is_omap1510()) \
- ) ? IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING)
+ )? IRQF_TRIGGER_FALLING : \
+ ((machine_is_omap_h4() || machine_is_omap_2430sdp())? \
+ IRQF_TRIGGER_LOW : IRQF_TRIGGER_RISING))
#elif defined(CONFIG_SH_SH4202_MICRODEV)
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* LVM2 ./WHATS_NEW lib/metadata/mirror.c
From: agk @ 2006-11-10 19:35 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: agk at sourceware.org 2006-11-10 19:35:03
Modified files:
. : WHATS_NEW
lib/metadata : mirror.c
Log message:
Fix adjusted_mirror_region_size() for 64-bit size.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.492&r2=1.493
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/mirror.c.diff?cvsroot=lvm2&r1=1.34&r2=1.35
--- LVM2/WHATS_NEW 2006/11/10 18:24:11 1.492
+++ LVM2/WHATS_NEW 2006/11/10 19:35:02 1.493
@@ -1,6 +1,7 @@
Version 2.02.14 -
===================================
- Add some missing bounds checks on 32 bit extent counters.
+ Fix adjusted_mirror_region_size() to handle 64-bit size.
+ Add some missing bounds checks on 32-bit extent counters.
Add Petabyte and Exabyte support.
Fix lvcreate error message when 0 extents requested.
lvremove man page: volumes must be cluster inactive before being removed.
--- LVM2/lib/metadata/mirror.c 2006/10/18 18:01:52 1.34
+++ LVM2/lib/metadata/mirror.c 2006/11/10 19:35:03 1.35
@@ -36,20 +36,20 @@
}
/*
- * Ensure region size is compatible with volume size.
+ * Reduce the region size if necessary to ensure
+ * the volume size is a multiple of the region size.
*/
uint32_t adjusted_mirror_region_size(uint32_t extent_size, uint32_t extents,
uint32_t region_size)
{
- uint32_t region_max;
+ uint64_t region_max;
region_max = (1 << (ffs((int)extents) - 1)) * extent_size;
- if (region_max < region_size) {
- region_size = region_max;
+ if (region_max < UINT32_MAX && region_size > region_max) {
+ region_size = (uint32_t) region_max;
log_print("Using reduced mirror region size of %" PRIu32
- " sectors", region_max);
- return region_max;
+ " sectors", region_size);
}
return region_size;
^ permalink raw reply
* Re: A proposal; making 2.6.20 a bugfix only version.
From: Al Boldi @ 2006-11-10 19:33 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Hemminger, Jesper Juhl, linux-kernel
In-Reply-To: <20061110085311.54fd65f2.rdunlap@xenotime.net>
Randy Dunlap wrote:
> On Fri, 10 Nov 2006 08:42:58 -0800 Stephen Hemminger wrote:
> > Jesper Juhl wrote:
> > > On 10/11/06, Al Boldi <a1426z@gawab.com> wrote:
> > >> Stephen Hemminger wrote:
> > >
> > > [...]
> > >
> > >> > There are bugfixes which are too big for stable or -rc releases,
> > >> > that are queued for 2.6.20. "Bugfix only" is a relative statement.
> > >>
> > >> > Do you include, new hardware support, new security api's,
> > >> > performance fixes. It
> > >> > gets to be real hard to decide, because these are the changes that
> > >> > often cause regressions; often one major bug fix causes two minor
> > >> > bugs.
> > >>
> > >> That's exactly the point I'm trying to get across; the 2.6 dev model
> > >> tries to
> > >> be two cycles in one, dev and stable, which yields an awkward catch22
> > >> situation.
> > >>
> > >> The only sane way forward in such a situation is to realize the
> > >> mistake and
> > >> return to the focused dev-only / stable-only model.
> > >>
> > >> This would probably involve pushing the current 2.6 kernel into 2.8
> > >> and starting 2.9 as a dev-cycle only, once 2.8 has structurally
> > >> stabilized.
> > >
> > > That was not what I was arguing for in the initial mail at all.
> > > I think the 2.6 model works very well in general. All I was pushing
> > > for was a single cycle focused mainly on bug fixes once in a while.
Temporary focusing won't help much, as you are dealing with people, who
cannot be turned on and off like machines.
> > I like the current model fine. From a developer point of view:
>
> I don't think that it's great, but having even/odd stable/development
> is even worse.
>
> But I agree with Jesper and Andrew's comments in general, that
> we do have stability problems and we have a lack of people
> who are working on bugs.
The problem is not just simple bugs that surface, it's deeper than that.
Deep structural problems is what plagues 2.6.
Only a focused model may deal with such problems.
> > * More branches means having to fix and retest a bug more places.
> > Workload goes up geometrically with number of versions.
> > So most developers end up ignoring fixing more than 2 versions;
> > anything more than -current and -stable are ignored.
> > * Holding off the tide of changes doesn't work. It just leads to
> > massive integration headaches.
> > * Many bugs don't show up until kernel is run on wide range of
> > hardware, but kernel doesn't get exposed to wide range of hardware and
> > applications until after it is declared stable. It is a Catch-22.
No Catch-22 here. You just fix those to achieve stability.
It's when you start to flip-flop dev/stable/dev/stable/... that you get
Catch-22, which inhibits stability.
> > The current stability range of
> > -subtree ... -mm ... 2.6.X ... 2.6.X.Y... 2.6.vendor
> > works well for most people. The people it doesn't work for are
> > trying to get something for nothing. They want stability and the latest
> > kernel at the same time.
That's not the impression I got from Andrew's stats.
> > There are some things that do need working on:
> > * Old bugs die, the bugzilla database needs a 6mo prune out.
> >
> > * Bugzilla.kernel.org is underutilized and is only a small sample of
> > the real problems. Not sure if it is a training, user, behaviour issue
> > or just that bugzilla is crap.
>
> Behavior, ease of use vs. email.
Go email. Maybe even automated.
> > * Vendor bugs (that could be fixed) aren't forwarded to lkml or
> > bugzilla
>
> ack
>
> > * LKML is an overloaded communication channel, do we need:
> > linux-bugs@vger.kernel.org ?
No.
> Either that or lkml is/remains for bug reporting and we move development
> somewhere else. Or my [repeated] preference:
>
> do development on specific mailing lists (although there would
> likely need to be a fallback list when it's not clear which mailing
> list should be used)
Yes. Needs more thought, though.
> > * Developers can't get (or afford to buy) the new hardware that
> > causes a lot of the pain. Just look at the number of bug reports due to
> > new flavors of motherboards, chipsets, etc. I spent 3mo on a bug that
> > took one day to fix once I got the hardware.
>
> Yep.
Thanks!
--
Al
^ permalink raw reply
* Re: [PATCH] spidernet: fix transmit routine.
From: Stephen Hemminger @ 2006-11-10 19:30 UTC (permalink / raw)
To: James K Lewis; +Cc: Andrew Morton, Jeff Garzik, jim, netdev
In-Reply-To: <OFF9C5DB9C.8DD003F3-ON87257222.0068A615-86257222.006950CA@us.ibm.com>
On Fri, 10 Nov 2006 13:10:25 -0600
James K Lewis <jklewis@us.ibm.com> wrote:
> Stephen,
>
> I had already tried that previously, the fail still occurred. Note that
> the skb_pad (or skb_padto) never actually fails. There is just something
> about calling it that causes the hang. Note too that I believe your patch
> is incorrect, you would still have to pci_unmap_single the correct length
> (skb_pad does not actually change skb->len which just seems plain wrong to
> me).
Yeah, that was a bad choice not to set skb->len to start with. Too late
now given how it might affect other drivers.
> I checked, and none of our "mainstream" PPC ethernet drivers (e100,
> e1000, pcnet32, tg3) have this check in them. When I have time I may add
> the pad to pcnet32 (for example) to see if it fails.
The hardware for all these drivers does padding.
> Jim Lewis
> Advisory Software Engineer
> IBM Linux Technology Center
> 512-838-7754
>
>
^ permalink raw reply
* Re: [linux-usb-devel] 2.6.19-rc5-mm1
From: Benoit Boissinot @ 2006-11-10 19:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Alan Stern, Mattia Dongili, USB development list,
Kernel development list, SCSI development list
In-Reply-To: <20061109145100.01d6ec46.akpm@osdl.org>
On Thu, Nov 09, 2006 at 02:51:00PM -0800, Andrew Morton wrote:
> On Thu, 9 Nov 2006 16:58:31 -0500 (EST)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Thu, 9 Nov 2006, Mattia Dongili wrote:
> > > On Thu, Nov 09, 2006 at 11:04:53AM -0800, Andrew Morton wrote:
> > > [...]
> > > > > [27526.232000] EIP: [<e8074e26>]
> > > > > scsi_device_dev_release_usercontext+0x36/0x100 [scsi_mod] SS:ESP
> > > > > 0068:dfdb1e3c
> > > > >
> > > > > full dmesg attached, I can test patches and provide any useful
> > > > > information if needed (just not now because the dock is at work).
> > > >
> > > > You're the second or third person to report this (to no effect, btw).
> > >
> > > oh, great. I was going to report the same (had with usb key unplug).
> > > Linux version 2.6.19-rc5-mm1-1 (mattia@tadamune) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #4 SMP Wed Nov 8 22:46:11 CET 2006
> >
> > I don't know exactly where the problem lies, but I have narrowed it down.
> >
> > In drivers/scsi/sd.c:sd_probe(), the call to add_disk() increases the
> > device's refcount by 1. However in sd_remove(), the call to del_gendisk()
> > decreases the device's refcount by 2. Consequently the structure is
> > deallocated too early, causing the oops.
> >
> > Somebody who knows more than I do about add_disk() and del_gendisk() will
> > have to figure what's going wrong.
> >
>
> hm. Maybe it's the disk_sysfs_symlinks() changes.
>
> Could someone who can reproduce this please try this revert, on
> 2.6.19-rc2-mm2 through 2.6.19-rc5-mm1?
>
I confirm it fixes it for me too.
regards,
Benoit
--
:wq
^ permalink raw reply
* Re: 2.6.19-rc5-mm1
From: Benoit Boissinot @ 2006-11-10 19:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, Alan Stern, USB development list,
SCSI development list, Kernel development list
In-Reply-To: <20061109145100.01d6ec46.akpm@osdl.org>
On Thu, Nov 09, 2006 at 02:51:00PM -0800, Andrew Morton wrote:
> On Thu, 9 Nov 2006 16:58:31 -0500 (EST)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Thu, 9 Nov 2006, Mattia Dongili wrote:
> > > On Thu, Nov 09, 2006 at 11:04:53AM -0800, Andrew Morton wrote:
> > > [...]
> > > > > [27526.232000] EIP: [<e8074e26>]
> > > > > scsi_device_dev_release_usercontext+0x36/0x100 [scsi_mod] SS:ESP
> > > > > 0068:dfdb1e3c
> > > > >
> > > > > full dmesg attached, I can test patches and provide any useful
> > > > > information if needed (just not now because the dock is at work).
> > > >
> > > > You're the second or third person to report this (to no effect, btw).
> > >
> > > oh, great. I was going to report the same (had with usb key unplug).
> > > Linux version 2.6.19-rc5-mm1-1 (mattia@tadamune) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #4 SMP Wed Nov 8 22:46:11 CET 2006
> >
> > I don't know exactly where the problem lies, but I have narrowed it down.
> >
> > In drivers/scsi/sd.c:sd_probe(), the call to add_disk() increases the
> > device's refcount by 1. However in sd_remove(), the call to del_gendisk()
> > decreases the device's refcount by 2. Consequently the structure is
> > deallocated too early, causing the oops.
> >
> > Somebody who knows more than I do about add_disk() and del_gendisk() will
> > have to figure what's going wrong.
> >
>
> hm. Maybe it's the disk_sysfs_symlinks() changes.
>
> Could someone who can reproduce this please try this revert, on
> 2.6.19-rc2-mm2 through 2.6.19-rc5-mm1?
>
I confirm it fixes it for me too.
regards,
Benoit
--
:wq
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* Re: [PATCH]send slave cpus to SAL slave loop on crash (IA64)
From: Jay Lan @ 2006-11-10 19:23 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <4546623D.5000105@engr.sgi.com>
Zou, Nanhai wrote:
>>> But this will rely on machine crash on CPU 0?
>> We do not rely on machine crash on CPU 0 any more. If the
>> crashing CPU is not cpu 0 and the cpu 0 not being returned to
>> the slave loop, this case is handled by our PROM now.
>>
>> However, if somebody tries to boot up a production kernel using '-le'
>> option _after_ the kexec'ed kernel is up running, the third kernel
>> would not boot unless we boot up the second kernel with cpu 0. I
>> posted a question on "if running 'kexec -le' on a kexec'ed kdump
>> kernel is legal" earlier and Vivek responded saying the scenario
>> is not guranteed to work. So, i think we are fine here.
>
> Ok, so with this patch and the PROM fix, on a SN system,
> 1. Kdump -> 2nd kernel works.
> 2. Kdump -> 2nd kernel -> Kexec to third kernel will not work.
> 3. Kexec -> 2nd Kernel -> Kexec -> 3rd kernel works?
> 4. Kexec -> 2nd Kernel -> Kdump -> 3rd kernel works?
>
> I think if scenario 1, 3 and 4 works it will be ok. Scenario 2 is not so useful I guess.
Hi Nanhai,
Where do we stand as to this patch's concern? Did you include this yet?
As to Scenario 3 and 4, 'kexec -l' failed on "Inivalid memory segment"
on SN Altix systems, and i have not had time to dig into it. This patch
is pretty much doing what you suggested "calling ia64_jump_to_sal"
to send the cpus to slave loop.
We can include cpu 0 also by calling fix_b0_for)bsp() to set up b0
for cpu 0 in ia64_mca_init(), if so desired. What do you think?
Regards,
- jay
[root@pogo1 boot]# /home/jlan/kexec-noio -l /boot/vmlinuz-2.6.18-kdump
--noio -
-initrd=/boot/initrd-2.6.18-kdump --append="root=/dev/sdb6 irqpoll ro
console=t
tySG0"
Done with process_options
kernel: 0x2000000000328010 kernel_size: 3502601
memory_range: crashk, idx=5, start018000000, end028000000
memory_range: Boot, idx=7, start07a280010, end07a280061
memory_range: MemoryMap, idx=9, start07a3f0010, end07a3f0611
build_mem_shdrs: ei_class=2, e_shnumF, e_shoffT506776
build_mem_shdrs: sizeof(e_shdr)r, e_shdr=0x6000000000014120
ready to load. type=0,
build_mem_shdrs: ei_class=2, e_shnumF, e_shoffT506776
build_mem_shdrs: sizeof(e_shdr)r, e_shdr=0x6000000000014f30
elf_exec_load
Invalid memory segment 0x4000000 - 0x4997fff
Segmentation fault
[root@pogo1 boot]#
>
^ permalink raw reply
* Re: [PATCH] speedstep-centrino should ignore upper performance control bits
From: Gary Hade @ 2006-11-10 19:20 UTC (permalink / raw)
To: Dave Jones; +Cc: cpufreq, Dominik Brodowski
In-Reply-To: <20061109002208.GA805@redhat.com>
On Wed, Nov 08, 2006 at 07:22:08PM -0500, Dave Jones wrote:
> On Wed, Nov 08, 2006 at 04:00:31PM -0800, Gary Hade wrote:
>
> > > Argh. I sat on the fence on this one until the dest settled,
> > > and now, as soon as I merge it, this happens. Bah!
> > Dave, I'm sorry. I just discovered the problem. :(
>
> Ok, I just tried to reconstruct my git tree without that diff
> and hit problems trying to get the older patches applying against
> a current tree, so I don't want to go down the route of making
> everyone rediff and resend the 20 or so patches already queued.
> However..
>
> > > Send an incremental against cpufreq.git so I don't have to
> > > reconstruct the whole git tree?
> > Okay, I'll try to figure out how to do that.
>
> git revert has nuked the change, but leaves a mess in the commits,
> but I think we can live with that. So just send the right fix,
> and we'll make like this never happened :-)
Dave, I apologize again for the trouble. Improved patch
which does essentially the same thing but avoids modifying
the in-kernel ACPI data is included below.
Thanks!
Gary
--
Gary Hade
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc
On some systems there could be bits set in the upper half of
the control value provided by the _PSS object. These bits are
only relevant for cpufreq drivers that use IO ports which are not
currently supported by the speedstep-centrino driver. The current
MSR oriented code assumes that upper bits are not set and thus
fails to work correctly when they are. e.g. the control and status
value equality check failed on the IBM x3650 even though the ACPI
spec allows inequality.
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
--- linux-2.6.19-rc5/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.orig 2006-11-07 18:24:20.000000000 -0800
+++ linux-2.6.19-rc5/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-11-10 09:02:29.000000000 -0800
@@ -36,6 +36,7 @@
#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-centrino", msg)
+#define INTEL_MSR_RANGE (0xffff)
struct cpu_id
{
@@ -463,8 +464,9 @@ static int centrino_cpu_init_acpi(struct
}
for (i=0; i<p->state_count; i++) {
- if (p->states[i].control != p->states[i].status) {
- dprintk("Different control (%llu) and status values (%llu)\n",
+ if ((p->states[i].control & INTEL_MSR_RANGE) !=
+ (p->states[i].status & INTEL_MSR_RANGE)) {
+ dprintk("Different MSR bits in control (%llu) and status (%llu)\n",
p->states[i].control, p->states[i].status);
result = -EINVAL;
goto err_unreg;
@@ -500,7 +502,7 @@ static int centrino_cpu_init_acpi(struct
}
for (i=0; i<p->state_count; i++) {
- centrino_model[cpu]->op_points[i].index = p->states[i].control;
+ centrino_model[cpu]->op_points[i].index = p->states[i].control & INTEL_MSR_RANGE;
centrino_model[cpu]->op_points[i].frequency = p->states[i].core_frequency * 1000;
dprintk("adding state %i with frequency %u and control value %04x\n",
i, centrino_model[cpu]->op_points[i].frequency, centrino_model[cpu]->op_points[i].index);
^ permalink raw reply
* Re: [PATCH] libata: use FLUSH_EXT only when driver is larger than LBA28 limit
From: Stefan Seyfried @ 2006-11-10 19:18 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jeff Garzik, linux-ide, Danny Kukawka
In-Reply-To: <20061110183304.GA22793@htj.dyndns.org>
On Sat, Nov 11, 2006 at 03:33:04AM +0900, Tejun Heo wrote:
> Interestingly, at least one of such drives (ST960812A) has problems
> dealing with FLUSH_EXT. It eventually completes the command but takes
> around 7 seconds to finish in many cases thus drastically slowing down
> IO transactions. This seems to be a firmware bug which sneaked into
> production probably because no other ATA driver including linux IDE
> issues FLUSH_EXT to drives which report support for LBA48 & FLUSH_EXT
> but is smaller than 1<<28 blocks.
Note that i'm quite sure that i have seen this on more than this single
drive. It might be that those were all seagates, though.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
^ 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.